Atom I Helicopter hacking

A co-worker received a Proper Atom I bluetooth helicopter and wants to control it with his Windows Phone… but Propel has only released iPhone and Android apps.  I installed the android app on my tablet, paired with the helicopter, and we tried flying it.  We noticed a delay of about a second between pushing a button and seeing the helicopter respond (when toggling headlight, for instance).

Strangely, the helicopter connects as a media device and the instructions suggest turning up the volume on your device to make sure the signal is strong enough.  That means the app is generating an audio signal, playing it out over an A2DP bluetooth connection, which encodes it into a digital stream, and sends it to the bluetooth transceiver.  The processed is reversed on the other side: the digital stream is decoded into an audio signal (basically analog), only to be converted back to some digital representation used by the helicopter.  And apparently the signal quality is also dependent upon the volume of the device… if you have your volume turned down, the helicopter might not fly as well.  Seems like a lot of work and overhead when there are more suitable bluetooth profiles for sending small packets of digital data.  Not to mention even the serial port profile would have done the trick.

I suppose this could make hacking the device easier though.  I found instructions for setting up an A2DP sink in Linux using the BlueZ driver.  This enabled me to stream music from my tablet to my computer and also to fool the Atom I app into thinking it was connected to a real helicopter.  As expected, the app generated an audio signal, which I captured and inspected in Audacity.  In each screenshot, the signal on top is from an MP3 (lossy) and the one on the bottom is from a FLAC file (lossless).  Each screenshot is zoomed closer than the last:

Full 30 seconds

One second interval

Three Pulses

Single Pulse

Detail

Listen to the audio here (warning – very loud):

I had some theories that the app might be using a common encoding scheme like Frequency Shift Keying (FSK) or Phase Shift Keying (PSK), so I compared the sound of the audio to clips of some common FSK/PSK modes I found online.  No clear match.  I looked around for signal analysis software and ended up trying Baudline.  Here’s a spectral analysis plot:

Spectrum in Baudline

The spectrum seems pretty level during intervals where there is sound, so no frequencies standing out.  <speculation> My current opinion is that the sound is intentionally just random noise, not a more advanced encoding scheme.  I believe that the timing and duration of the pulses is encoding binary data, which could explain the long delay between the controller and the helicopter.  Such a system would work with a weak signal and could be resistant to noise, especially if the data packets contain a CRC. </speculation>

As a first test, I tried playing back the recorded audio from my tablet to the helicopter, but no dice.

More experiments:
-Pass-through: tablet => PC => helicopter
-Pass-through with added noise
-Isolate a clip of audio that the helicopter understands

More Atom I helicopter hacking here: http://blog.davelester.org/2012/12/29/help-hacking-bluetooth-helicopter

Advertisement

Privacy Settings

Atari 2600-like LFSR Random Noise [555 Timer Contest]

555/LFSR Random Noise Schematic

This project was conceived and completed over the course of one or two days, so it is not intended to be anything outstanding or innovative. Building on the concept of the Atari Punk Console, this circuit uses a 555 timer (and two other ICs) to generate random noise. When the random signal is played through a speaker, a distinctly “Atari 2600” sound is produced. This is not surprising, since the Atari 2600’s TIA chip allowed programmers to incorporate random noise into their games.

The circuit consists of a astable 555 timer circuit that produces a square wave to clock a shift register. The shift register, an SN74HC164, is configured as a 7-bit Linear Feedback Shift Register (LFSR), which produces a stream of pseudo-random bits. In order to act as an LFSR, the input to the shift register is the result of the 6th and 7th bits XORed* together. The feedback creates a repeating pseudorandom series of 127 states. In order to create audible random noise, the final bit of the shift register is coupled to a speaker through a 100uF capacitor. (*The XOR gate comes from an SN7486 Quad-XOR chip).

The frequency of the 555 timer circuit can be adjusted using a potentiometer, so the result is an amusing Atari-like sound effect.

555/LFSR Random Noise Schematic

LFSR random noise circuit, from the side

LFSR random noise circuit, from above

Pseudo-random pulse train produced by 7-bit LFSR

Square wave produced by 555 timer.

References
http://en.wikipedia.org/wiki/Linear_feedback_shift_register
http://www.kpsec.freeuk.com/555timer.htm

555/LFSR Random Noise Schematic

Npower Fusion

At the end of December, I bought an NPower Fusion from Woot for $10.

It’s a media player manufactured by Memorex for Nickelodeon with a SpongeBob Square Pants theme. The player originally sold for $99 when it was released two years ago, so the technology is relatively current. The display is 320×240 (same as the iPhone), it supports WMV9 video, MP3 audio, and java apps (CLDC 1.1, MIDP2), and it includes a lithium-polymer battery. Overall, this looks to be a nice toy to hack and not a bad platform to run simple java programs as-is.

There are several useful pages about the fusion, my favorite being a cool blog post showing a disassembly of the device. As can be seen in the article, the fusion contains a Telechips TCC8200, which has a very capable ARM9 core at 200MHz. For reference, the Nintendo DS has a dual core chip with a similar ARM9 core at 67MHz and an ARM7 core at 33.5MHz. Much thanks to Hunter for his post.

I’ve also found numerous articles covering specific topics like converting videos the proper Windows Media format (WMV9, WMA8) for playback on the fusion. Unfortunately, I’ve had no luck converting in Ubuntu 😦 I have been able to convert videos to wmv using ffmpeg or mencoder, then sync them to the fusion via Windows Media Player. Here are some good fusion links:
http://npowerfusion.blogspot.com/
http://npowerfusiontutorials.blogspot.com/

Now I’d like to share some info of my own. I’d very much like to port Rockbox to this player, so I looked around on the official website for a firmware update. It’s my understanding that a common approach to running custom software on a device like this is to modify a firmware image and load it onto the device through its own update process. Unfortunately, there was no firmware to be found

Regardless, I next began looking for the update mechanism. I have a Sansa c140 music player which contains a Telechips TCC770 and it enters an update mode when a specific button combination is held as it is plugged into the USB port. This update mode is special because it loads the firmware image into RAM without writing it to flash, making it possible to test a hacked firmware without risk of bricking the device. There is a tool in the Rockbox repository called tcctool which performs the firmware copy while in this mode. Additionally, there is a test mode that begins when the c140 is powered on with a different key combo held.

With some trial and error, I discovered both modes on the fusion =) Holding the “-” and “+” keys while powering on the device enters the production test mode, which allows you to check the functionality of your device (screen, keys, audio, etc).

Holding the “bent left arrow” on the top of the fusion while plugging it into a PC will boot it into *what I believe to be* a firmware update mode. Let me explain…

Similar to the Sansa c140, when you plug the fusion into the USB port it ordinarily appears as a storage device and accepts files as expected. When both devices enter this alternate “update” mode however, they don’t act like storage devices. Instead, they identify themselves to the PC as “Telechips, Inc.” devices, with a different (manufacturerID:productID) combination. From Linux, you can observe this difference by executing “lsusb” at a shell. Here’s the output when the device is connected as usual:

~$ lsusb
...
Bus 002 Device 004: ID 0aa6:6511 Perception Digital, Ltd
...

Here is what you see when you’ve connected in update mode:

~$ lsusb
...
Bus 002 Device 003: ID 140e:b051 Telechips, Inc.
...

Interestingly, the product ID is 0xb051, which is identical to that of the iRiver X20. It’s possible they are based on the same platform as well. Since I haven’t found a firmware image yet, hacking the fusion will be much more difficult, but the hidden update mode and the potential to use the the iRiver X20 firmware as a starting point is promising.

PCB Fabrication Comments and New Roomba Controller Board

Since I last posted pictures of my Roomba controller board, I’ve created several other PCBs (not Roomba-related) and improved my design, toner transfer, etching, and soldering techniques. I was particularly nervous about putting the board into my robot, considering the amount of vibration and shock, so I decided to redo it.

First problem: the copper traces were much to fine. During the toner transfer (TT), a couple of these tiny wires were missing or incomplete. Even worse, once I tried to solder the complete wires, the heat of my soldering iron burned up the wire if held there too long. I’ve discovered it’s favorable to make wires as wide as possible, even at the expense of breaking clearance rules (i.e., I changed my DRC clearance setting from 10mil to 5mil). It’s much easier to break shorts between traces after toner transfer by scraping off the toner with a razor blade. Even if a short is overlooked before etching, it’s possible to break the connection by scratching away excess copper.

Secondly, I read online that Brother printers (which I have) are inadequate for TT because the toner has a much higher “melting point,” which is hard to reach with an ordinary electric iron. Apparently a portion of toner is made up of plastic, and the goal of TT is to melt it so it bonds to the copper board. The toner is stuck to both the board and the paper, so you remove the paper by soaking it in hot water. For this new board, I printed on an HP printer with much better TT results. Further, I read that glossy magazine covers or magazine pages can be used instead of expensive photo paper. I achieved a nearly flawless transfer using _free_ spring break vacation brochures I found posted around school.

Thirdly, the iron doesn’t always transfer toner evenly and there’s no way to know for sure before you remove the paper. My girlfriend spotted a $15(!) personal laminator for sale at Aldi. Hobbyists mention their laminators frequently online but I never planned to buy one because they commonly cost between $30 and $120… I cautiously assumed you get what you pay for, but a $15 loss would not ruin me. Fortunately, it works great and it’s faster and easier than an iron, giving far better results. As before, I place the layout images on freshly scrubbed and alcohol-cleaned copper board, but instead of ironing, I pass it through the laminator at least 12 times (probably overkill, but one pass seems insufficient… I’ll experiment a bit later), and then soak the board. It’s not actually laminating, so there’s no need to use any special plastic pouches–it’s just applying heat and pressure. To increase the pressure, I taped the board to a folded paper six sheets thick. The extra thickness sometimes causes a jam, but I simply push the board through.

Etching started as a very messy process, but I’ve worked out a clean and effective procedure. I fill up a plastic container with hot tap water. Then I put on rubber gloves, put the board into a reliable ziploc sandwich bag, and carefully pour a meager amount of ferric chloride acid into the bag. Seal the bag completely and place it in the hot water. Now the etching is contained, it’s being warmed, and it can be continuously agitated without touching the acid. If the water cools, I replace it as necessary until the board is etched. When I remove the board, I go out over the grass in my yard and carefully take the board out of the bag, then immediately pour water over the board and my gloved hand to rinse off the acid clinging to the board. Then I place the now-clean board directly into the water to dilute any remaining acid. Next, I liberally pour backing soda into the bag to neutralize the acid and hopefully leave the byproducts more basic than neutral. At this point, the residue seems to be “liquid rust” so it’s important not to spill it anywhere. I pull off my gloves and seal them in the bag, then throw out the bag. I’m not sure this is the best way to dispose of the byproducts, but I do try to use as little acid as possible, it should be less harmful once neutralized and it’s probably somewhat like throwing away rusty metal and copper. I’ve read some sites that suggest pouring the neutralized liquid down the drain and taking the precipitate to a waste management center, but I’m not sure this is much better.

Finally, I learned one more thing through error with this new Roomba board. When I removed the toner, I used nail polish remover as suggested on the web. As you can see in the pictures, the toner from the HP printer smudged all over the bare PCB, although it did clean off the copper traces. Using both acetone-based and acetone-free nail polish remover, the toner clung to the exposed board. Later I tried using my scrubber to mechanically remove the toner without any chemicals… this worked well, as is apparent in the upper-right portion of the board.

Regarding the tiny Roomba graphic in the corner of the board: I opened the official Roomba manual PDF in Inkscape and found a sketch of the Roomba itself as vector art. Before printing the layout, I scaled the graphic to fit the corner, placed it, and tiled the entire layout over the 8.5″x11″ canvas. It etched extremely well =)

Surface-mount LED Board!

Since fabricating my Roomba controller board, I’ve been working to improve my PCB capabilities. My distant goal is design a complete embedded system with chips that are only available in surface-mount packages. Here’s a small LED PCB I began designing over the weekend:

Actually, that’s a mirror image of the board because I forgot to flip the layout before I etched the PCB. Whoops 😐 Here’s the schematic and layout, in gschem and pcb:

Here’s some more pictures:

I’ve started using flux (probably essential for surface-mount) and I ran into trouble with some of the finer traces breaking during etching. I damaged the center LED, so it’s a bit dimmer… maybe I’ll replace it later.

Roomba Progress, 8/4/09

I recently updated the Roomba’s microcontroller program a little bit, then I decided to finally get to work on a printed circuit board (PCB) for the PIC. I was able to design the PCB with open source gEDA tools.

Here’s the schematic:

…and here’s the PCB layout:

I used the well-known “print layout on glossy photo paper, iron onto copperclad board, bathe in ferric chloride, scrub off toner with nail polish remover, drill with dremel tool” method to fabricate my board. Here it is before soldering:

…and here I tilted it so the copper traces catch the light:

I (poorly) soldered all of the components into place:

…the underside:

I learned quite a bit from my mistakes on this PCB. The traces I used are too thin and a couple were broken by either the toner transfer process or during the etch. Next time I’ll use thicker lines and iron it longer. I also tried to patch the lines with sharpie marker, which worked to some extent, but left some ugly black and gray stains all over the board. Some of the thin traces also burned up when I tried to solder in my jumper wire, so I won’t use the same solid copper wire next time. The big nasty solder blob is a repair to one of the broken traces.

Roomba Progress, 3/30/09

This week I did some work behind the scenes, but there’s nothing I can show off in terms of video or pictures.  I have essentially wrapped up my C++ class with some glue code to make it useable from within CMUCL.  The Roomba class itself is useful for controlling the Roomba in a C++ program (as demonstrated by my wiimote example), but it also conveniently organizes the Roomba functionality for Lisp programs.  The C++ class declaration is as summarized below:

class Roomba
{
private:
    ...
public:
    int connect(char *serialDevice);
    int disconnect();
    int launchThread();    // Thread for microcontroller comms
    int killThread();
    
    // Movement style 1 (Direct movement)
    int turnAndForward(float angle, float dist);
    // Movement style 2 (Car)
    int setVelocity(float vel);
    int setSteeringAngle(float angle);
    // Movement style 3 (Independent wheels, velocity-based)
    int setMotorVelocities(float velLeft, float velRight);
    // Movement style 4 (Independent wheels, distance-based)
    int moveMotors(float distLeft, float distRight);
    
    void getStatus(RoombaStatus *rs);
    float getApproxX();
    float getApproxY();
    float getApproxHeading();
};

I’ve used CMUCL’s Alien interface to enable foreign function calls to the C++ code.  C++ name mangling is a nuissance that prevents clean interfacing with Alien, so I elected to write a C++ wrapper that defines un-mangled functions (extern “C”)  that act on a single static Roomba object.  This wrapper compiles into a shared object (a.k.a. dynamic-link library or DLL) that can be manipulated in CMUCL.  Roomba object functions can be called from Lisp like this:

(turnAndForward 9.0 2.5) ;; Rotate 9 units, forward 2.5
(setf vL -1.0)
(setf vR 1.0)
(setMotorVelocities vL vR) ;; Rotate left, full speed

Unfortunately, I have nothing to show in this update because I haven’t written any Lisp programs that to take advantage of the new interface.  In addition to writing this interface, I’ve begun writing a final paper about my work.  My goals for next week are to write some interesting Lisp code based on a competitive Cognitive Robotics scenario I’m writing up in my paper, to try out some SNePS reasoning on top of Lisp, and possibly some additional hardware work (integrating the new battery, adding a webcam, and making a PCB for the microcontroller circuit).

Roomba Progress, 3/16/09

After establishing control over the Roomba through a wifi SSH connection, the next step was to begin working towards the same functionality from within Lisp.  I looked through SWIG’s documentation (tool for providing glue between different languages) and read about CMUCL’s Alien Object system for supporting foreign function calls.  Before completing this connection to Lisp, I began working on a class to wrap up all the functionality necessary for talking to the Roomba.  The fruit of my efforts so far is a partially-implemented class that currently supports all of the capabilities of my previous debug program.  I was quickly able to write a new debug program that creates a Roomba object and a connection to a Wii remote so that a user can move the Roomba by tilting the remote.  The Wiimote affords finer control than the arrow keys and the video below shows the result:

The remaining portion of the class consists of four different methods of controlling the Roomba, position estimation that will attempt to approximate the Roomba’s current x-y displacement and change in heading since it turned on.  The four movement methods are intended to make the Roomba movement feel different:

1. Turn-and-forward:  This should feel closest to human movement.  Each step consists of first rotating the Roomba toward its desired target, and then moving a specified distance.  Either the turn angle or the distance can be zero, and a negative distance means backward.
2. Velocity plus steering angle: This should feel like the way a car drives. The Roomba maintains a constant velocity and can be steered left or right, as though by a steering wheel.
3. Independent motor velocity: This mode is closest to the way the Roomba is actually controlled.  Each motor turns at a different speed to produce linear and rotational movement.
4. Independent motor distance: This mode will allow each motor to move a specified distance, then stop.

I will attempt to interface this class to Lisp through the Alien system and begin working on autonomous behaviors.  Soon it will begin looking more like a cognitive robot. I additionally need to incorporate a camera and use OpenCV to perform image processing.

Roomba Progress, 3/7/09

The robot is now fully wireless!  It’s amazing that I’ve gotten this far without a major setback like having something expensive burn out (knock on wood).

Since Monday, I have mounted the motherboard to the lid of the Roomba and squeezed the breadboard inside.  The breadboard doesn’t entirely fit, so the lid does not close all the way. Sometime soon I would like to solder the microcontroller circuit to a perfboard or a custom PCB so the circuit will fit inside.

Next, I soldered some wires to the battery terminals inside the Roomba to bring power up to the motherboard and its supply.  When I purchased the supply on eBay, the seller did not send me a short piece of wire that connects the supply to the motherboard’s power switch pins, so until I implement a better solution I have resorted to starting the motherboard by crossing the power switch pins with a coin.

These two changes mean the robot is now mobile.  Here’s some pictures and video clips:

It’s not pretty but it get’s the job done for now.

One concern I have right now is that the robot appears to be quite zippy in the first minute of driving and noticeably slower as time goes on.  I fear that the computer may eat through the Roomba’s battery alarmingly fast.  If this is true, I can either get more batteries for the robot or remove the computer.  Since the motivation for having an entire on-board computer was to enable the robot to be a fully autonomous cognitive agent, it would be a shame to scale back the processing power.  As a precaution, last night I purchased a lead acid battery with almost twice the capacity of the original Roomba battery.  It will way almost four pounds and will be physically bulky, but it will triple the juice.

On the other hand, I can certainly scale back the processing by using any programmable device with a serial port (e.g., Gameboy Advance, PDA, graphing calculator, Cybiko, etc).  The drawback is that I would then need to wirelessly link to a base station computer that would run SNePS and execute vision algorithms.  I hope it doesn’t come to that, but it is appealing to consider the low-power design of something like a Gameboy… the Gameboy Advance SP lasts for something like 15 hours on its own rechargeable battery.

Whatever the case, it’s a relief to have the bulk of the electrical work done so I can focus on software.

Roomba Progress, 3/2/09

Last week I did some more testing, cut a hole in the Roomba’s circuit board housing, reassembled the whole thing (removing some unnecessary brushes and vacuum-related parts) so I can run the wheel motors without worrying about disturbing the electronics.

From there, I moved back to the Roomba’s onboard computer.  For weeks it has been powered by a generic ATX supply which means it could only use AC wall power.  I wired its so-far-unused OPUS DC-to-DC supply to a 12V bench supply and had some intermittent success–it would work for about 15 minutes at a time after which I assume the 12V supply overheated, though everything was fine again after it cooled off.  In an effort to provide better DC power, I cut the cord of an old 18V laptop supply and wired it to the OPUS.  The laptop supply stays cool and allows the computer to run indefinitely.  This should be useful for powering the computer when the Roomba battery is in the charger, so I hope to attach matching power plugs to the laptop supply and the battery terminals and put a power jack on the OPUS so that I can quickly swap supplies.  I’m also brainstorming ways of “hot-swapping” the supplies so I can place the computer on AC power without shutting it down.

Hole in PCB housing.

Close-up of hole.

PCB in place, but not yet assembled.

My final step was to get my debug program to run on the Roomba’s computer and add a “manual mode” that allows me to easily drive it around with the arrow keys.  I’m now able to boot up the computer without attaching a display or keyboard, SSH into its ad-hoc wireless network and drive it around. See the video below.

TO DO:

• Wire the OPUS supply to the battery
• Securely mount the supply, computer, and breadboard to the Roomba
• [Possibly] integrate plugs and jacks into the power wiring
• Move ahead with Lisp, SNePs, cameras, and OpenCV