Category: Robotics
Toy Helicopter Hacking
This Christmas, my parents gave me a palm-sized toy helicopter (Avatar Z008), and my girlfriend’s parents gave me a slightly bigger toy helicopter with a video camera (Egofly Spyhawk). I also have one that I bought myself (Syma S107). All of them are gyro-stabilized, coaxial-rotor helicopters, which basically just means that they automatically don’t roll, and are easy to fly.
I had hoped to convert one of them into a tiny drone. I opened up the S107 this morning to take a look at the internal PCB. The IR signal from the remote goes to an unmarked 14-pin IC. The gyro (which I assume to be the little metal can mounted on a daugther board from the main PCB) is marked, with “C 146” and “Y2373”. One pin of the gyro is grounded, one, marked “TLY” is connected to the unmarked IC, and one goes to Vcc. That is pretty clearly power, ground, and a signal pin.
This means any control that the system is doing based on the gyro is done by that unmarked IC. Chances are that re-implementing the gyro control would be amusing, but much harder than simply adding whatever drone control I decided to add “on top of” the existing hardware.
An easier approach would be to take advantage of work that other people have done on reverse-engineering the IR protocol, and add my own control circuit that sends IR control signals to the existing board. That way, the existing board would take care of driving the motors and keeping the helicopter balanced, while my board would add autonomy.
Downward and front facing versions of SpeckleSense could be used to give the helicopter a sense of its movement in the world, which might be good enough for dead-reckoning navigation over small distances.
Drinking with Robots
I am building a drink-dispensing robot. It has 5 pumps internally, so I want to find the set of five liquids that will produce the largest variety of mixed drinks. To do this, I’m going to need a huge set of drink recipes. I got a bunch from a cocktail database that esquire maintains, but the biggest list I’m aware of is The Webtender. Unfortunately, that database isn’t in a form that permits me to make queries to find out what is the maximal set of drinks that I can make, given the constraint of 5 liquid ingredients. So instead of the web interface, I want the raw data.
This means I want to download every single drink recipe from The Webtender. The URLs there are of the form http://www.webtender.com/db/drink/6217, so the obvious thing to do would be to write up a little bash oneliner that just wgets each of the files in turn. It would probably look something like this:
for (( i=1; i <= 6217; i++ )); do wget http://www.webtender.com/db/drink/$i; done
But it may be that The Webtender issues a 403 Forbidden error if you use wget, probably to prevent just this sort of hijinks. Unfortunately for them, wget can be configured to claim to be something else. These instructions provide the config file to cause wget to claim to be Mozilla on Windows NT, which The Webtender should have no problem with.
For my next trick, I'll use BeautifulSoup to turn the HTML files from the webtender and Esquire into a SQL database, and probably perform some form of normalization on the data, such as making all the measurements be in the same units.
Eclipse Unresolved Imports with ROS on Ubuntu
I use Eclipse as an IDE. I do this to get code completion and syntax highlighting, as it does those pretty well for C/C++. Recently, I was trying to write a ROS plugin, and Eclipse couldn’t find the ros.h header file, which I had included with the line #include "ros/ros.h". Because of this, it marked every line where there was any use of anything from that header as an error, and gave a warning on the include line. They were not errors, and the code still built fine, but the IDE displayed it wrong. To fix this, I tried the normal solution, which is:
Click Project -> Properties -> C/C++ General -> Paths and Symbols -> Includes -> GNU C++ and then use the Add button to add the path to the include file. After that, reindex the project by right-clicking on the project, clicking Index -> Rebuild, and the include should be resolved.
Unfortunately, it wasn’t. Restarting Eclipse didn’t pick it up.
These instructions suggested that it might be something wrong with my language settings, but that doesn’t work either.
This is the proper way of doing it, and it actually works.
Now my tools are out of the way and I can start work. At 5:00PM on Friday.
New ToyBrain Board Design
Version one of the ToyBrain boards had a bunch of problems:
- TX and RX were swapped on the serial line header
- The ICSP header was backwards
- There was no debug LED
- The SMD resistor pads for the reset pull-up resistor were too small
- The connection for the reset switch was a 0.1″ header rather than a proper footprint
- There was a lot of wasted space
Despite all of that, I managed to eventually get them working, with a slowed-down version of the Arduino bootloader, adapters for the ICSP and serial headers, and much messing about.
The new board is smaller, measuring about 1.5″ by 1.28″, and adds a proper reset switch, a SMD LED for debugging, corrected resistor footprints, and a (in my opinion) slicker layout. I still didn’t add voltage regulation or mounting holes, but I may be able to get a little space for the holes by moving a few traces in the corners of the board.
Pride Goeth…
My ToyBrain boards are programmable over ICSP, but when I connect them to an FTDI USB-to-serial cable, I can’t load a program into them from the Arduino development environment. The error I get back is that the programmer is not responding, which could be caused by several things, listed here by increasing order of how tedious they are to check:
- I might have some misconfiguration on the USB ports or Arduino IDE. I can eliminate this possibility by using the same FTDI cable to program a known-working Arduino BBB. If that works, I know that my problem is off the end of the FTDI cable, in my own hardware.
- I tried this, and got a working blinking light program on my BBB. This means my cable and computer are fine.
- I might have messed up the bootloader configuration for my board. I think this is somewhat likely, as I’m using the Arduino bootloader on a board that is running at 8MHz. If the Arduino bootloader or IDE requires the Arduino 16MHz crystal for proper timing, it is now running at half the normal clock speed, resulting in the serial timings being double what they should be. I can test this by telling the IDE to attempt to talk to the board at half of whatever the normal speed is, using the platform support in recent Arduino IDE releases. If it’s a timing issue, that should fix it.
- This was the problem. I reflashed with the 8Mhz bootloader from here, and now I can load programs and have them run.
- I might have screwed something up in the reset or power circuitry of the Arduino (I already know I got TX and RX backwards). I can check out the connections with a voltmeter pretty easily. I can also burn an LED blink program to the board with ICSP and see if it runs.
- The power and reset circuitry is fine. I burned a LED blinking test program to the board using the command avrdude -c usbtiny -p m8 -U flash:w:test.hex and got a square wave on port B, so the chip is running code and the fuses make at least enough sense that the onboard oscillator starts.
- I may have used bad fuse settings, and put it in some mode that doesn’t result in the bootloader starting. I can test this by burning my own LED blink program to the bootloader section and seeing if it blinks an LED. This won’t make it load code, but it will at least confirm that the bootloader is getting started.
- This is covered by the previous section. The chip isn’t bricked, and it runs code.
Oops
When I added the ICSP header to my ToyBrain boards, I mirrored the footprint so that some of the routing would be easier. I did not, however, correct the actual wiring, so now the ICSP header comes off the wrong side of the board.
This is going to be easy to fix in the next revision, but for now I’m going to roll up a little adapter to get the boards programmed.
More later, when it’s closer to noon than midnight.
ToyBrain Boards Arrived
The ToyBrain boards arrived. I have populated four of them with programming headers and microcontrollers. Two have ATMega8 chips, the other two have ATMega48 chips that I salvaged from some thermostats that I found.
I haven’t bothered fully populating the boards because I want to check that the ICSP headers are working by burning the Arduino bootloader to the chips, and that the serial headers are working by loading a program from the Arduino IDE.
Assuming that I haven’t miss-designed the circuit boards or baked the chips while soldering them, this will provide a smoke-test for the computer side of the boards. I still need to get a bunch of SN754410NE quad half-H-Bridge motor driver chips to handle the output side.
So far, I’ve come up with quite a few applications for the little boards:
- Re-animating gutted toys with new programming
- Controlling a single stepper motor with step/direction signals and limit switches
- Driving up to 4 channels of medium-current LED lights (RGB plus white?)
- Making loud noises by using the quad half H-bridges as push-pull speaker drivers
- Solenoid drivers and control hardware for chimes
I’m very eager to get a few of the boards out to beta testers and see what other people come up with.
ToyBrain boards on the way!
The PCBs for my programmable toy controllers are on their way to me. That means that I didn’t mess up the layout in some way that makes it impossible to make the boards, but doesn’t preclude me possibly getting something wrong in the design. I’m going to assemble a few when they arrive and shake them down for layout defects. I also have a beta tester who wants to use one.
One thing I’m considering for the next version is adding an on-board voltage regulator, but that usually calls for caps as well, and starts to drive the board size and price up. I should also add mounting holes, but again, those take board real estate. I may neaten up the connector layout, and make sure everything is on 0.1″ centers for ease of mounting with normal pin headers. If I get all the through-hole connections moved to the edges of the board, or add edge connectors that make good wire lands and good header connections, I may be able to shrink the board more and not have many pins sticking through it. That would mean it would have a smooth bottom, and so be easy to mount with double-sided tape.
Brain Transplants for Toys
I have a bunch of old toy skeletons sitting around. They are not toy versions of the bones of animals, but the frameworks and some of the motors from things like a toy tracked robot, an RC truck, a few toy robot insects, some tiny RC cars, a robot base with continuous-rotation servos, and so forth. All of these things have motors or servos in them. All of them need some form of controller to make them into autonomous robots to do my bidding (or wander around banging into things).
To that end, I’ve developed a little embeddable controller around the ATMega8, ATMega48/88/168, and other pin-compatible microcontrollers. That is the same chip used in the Arduino, so my board will be software-compatible with the Arduino as well.
My controller, which I’m calling ToyBrain, has a pair of 1A (stackable for more current) H-Bridge motor drivers, so it can control up to four motors in one direction, two motors bidirectionally, or one stepper motor. It also provides two headers for servo motors. For inputs, it has four analog or digital inputs and two digital inputs that are connected to interrupt lines, so it can do things like handle bumper switches in an interrupt service routine.
I’ve ordered 10 boards. When they arrive, I’m going to populate them with whatever chips I have around and try to get a few of my old toys running. Assuming everything goes well and I get a polished device together over the winter, this may end up being something I sell at the MIT flea regularly. I’ll hook up a bunch of toys with the same controller, to show off its versatility, and offer the controller as a kit people can buy.
Recent Comments