[Noisebridge-discuss] seeking help hacking helicopter remote

[Steve Castellotti]

Hey all-

    Miloh and Tony have been helping me hack the remote control for a
Blade mCX2 RC Helicopter, but I'm having some trouble and could use some
advice, particularly from the Arduino crew.

    The current objective is to be able to control the helicopter
through software, specifically reproducing the joystick settings used to
take off, hover, fly forward, and land. I'm well aware of the future
difficulties involved in tweaking the software just right to perform the
actual flying but for now the first hurdle is getting the control
commands sent to the helicopter. The final goal is to be able to fly the
helicopter using the EEG headsets previously mentioned in the
brain-controlled robotics thread. Again, please don't get concerned with
those details just yet, only know that everything about this hack is
pure awesome.


    First off, here's the remote:

http://brainstorms.puzzlebox.info/tracker/wiki/RCHelicopterHacking


    The remote has four channels, with potentiometers altering changes
in current from the 6V power supply (4 AA batteries) which are picked up
by an ATmega88PA microcontroller. The microcontroller then sends signals
to the transmitter chip. All of the details of the chips on the
transmitter have been burned off and/or painted over, but we do know its
operates the Spektrum DSM2 protocol, with three handy-dandy pins for
Signal, Ground, and Power. 

    We're trying to reverse engineer the protocol sent over the signal
wire from the microcontroller to the transmitter, so that it can be
reproduced in software as a serial stream.

    Miloh found an excellent link to a forum post written by someone who
has apparently already performed this work for a 6-channel remote which
uses the same Spektrum DSM2 protocol:

https://www.noisebridge.net/wiki/Blade_MLP4DSM_RC


    Now note the last photo from the first link, which Tony collected
using his rather spiffy software-based logic analyser. It confirms some
of the key information described in the forum post:

14 bytes per frame
2 header bytes set to "0x00 0x00"

    Also note time between frames is 22ms, with each frame taking just
over 1ms to transmit (the 22ms figure was mentioned in another post or
on another site but either way appears to bear out).

    At the left edge of the image you can see that voltage is looks to
be fully on between frames and between individual bytes within the
frame. This data can be examined in detail by downloading the .logicdata
file from the first link above and opening it in "Logic" from Saleae
(http://www.saleae.com).

    At the time of the recording the throttle was at at 100% and
everything else was in the neutral position. (There is also data
available taken from a recording at 0% throttle). You can't see from the
screenshot but the packet sequence repeats perfectly with no other data
transmitted over a period of 10-15 seconds.

    Currently if the remote transmitter is powered on and sending
frames, when power is applied to the helicopter it will look for the
remote to which it was last bound. If it sees those frames at the
correct interval on the correct channel then the helicopter light turns
solid blue and is ready to fly. If it does not see the signal it is
looking for it blinks blue rapidly which means it has entered binding
mode.


    In theory we should be able to connect a USB-to-Serial converter,
with the Rx port coming from the microcontroller and the Tx port going
to the transmitter and simply echo what comes in Rx back out the Tx and
allow the helicopter to sync up and start flying. (We're pretty sure
there's no issues with different voltages used between the
microcontroller circuit and USB adapter.)

    It should also be possible to simply craft and issue packets at the
correct interval containing the data captured from the analyser.

    Here is my Python source for that script, which uses the PySerial
module:

http://brainstorms.puzzlebox.info/tracker/browser/trunk/brainstorms/Puzzlebox/Brainstorms/Helicopter_Control.py

http://pyserial.sourceforge.net/pyserial_api.html



    The problem is, it isn't working.


    There are numerous potential problems which stand out, primarily
that the forum post mentions 125k baud should be used instead of 115200.
PySerial says it should support this but either Linux or the
USB-to-Serial converter we are using prevents the port from accepting
that setting.

    I think the next step will have to be to examine the Tx output from
the USB link using the logic analyser though that of course will have to
be at Tony's convenience.


    One alternative could be to re-write the protocol handling such as
to be provided by an Arduino, which I assume should have no trouble
getting the baud settings, voltage levels, and frame timing exactly
right.

    Another alternative would be to hack in at the pots again using an
Arduino and possible a filter to normalize the PWM pulses to a steady
voltage (see this link).


    Can anyone else perhaps offer some insight or suggestions?



Cheers

Steve




Steve Castellotti
Puzzlebox Limited


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.noisebridge.net/pipermail/noisebridge-discuss/attachments/20101117/7095489d/attachment-0002.html>