[Noisebridge-discuss] [arduino] Re: seeking help hacking helicopter remote

Steve Castellotti sc at puzzlebox.info
Fri Nov 19 21:14:51 UTC 2010


    If some of the Arduino folks are listening, after further
experimentation on the Tektronics 1241 Logic Analyzer last night with
Miloh and John (thanks guys!) I think I have the problem narrowed down
very specifically:


    The ATmega88PA microcontroller on the helicopter's remote control is
communicating at approximately 133333 baud to the transmitter chip. The
forum post linked to in my original email suggests 125000 baud.

    The chipset on the USB-to-Serial converter we have been using will
not let us set an arbitrary baud rate. The closest to this rate is
115200 which is not fast enough for the transmitter chip, as confirmed
by the logic analyzer.

    My question is, what would be the best way to substitute an Arduino
for the current USB-to-Serial device?



    What I need to be able to do:

- Establish a 133333 baud rate connection between the Arduino and the
transmitter chip.

- Repeatedly transmit a 14-byte sequence once every 22ms (the packet
should start being sent every 22ms, not with a 22ms gap between
transmissions. According to the analyzer packets normally take 1.04 ms
to transmit, so perhaps setting a 21ms "sleep" cycle between would be
acceptable to the transmitter circuit).

- Be able to update the 14-byte sequence sent by the Arduino via USB
connection from the PC at will.



    Does this all sound reasonable?


    Interestingly, there was a spare Arduino Diecimella floating around
last night. We tried connecting the Rx port on the Arduino to the Tx
line from the microcontroller and use that to sniff the packets. The
PySerial module was happy to let me set the baud rate for the
communicate with the Arduino to 133333, but all I received back was a
data stream with null (0x00) packets. Even when the baudrate for the
USB-to-Serial device was [mis]configured at 115200 I was receiving
consistent (though wrong) data which would change gracefully as the
throttle and other controls were adjusted.

    When I got home I tried to do the same with an Arduino UNO, but that
won't let me set the baud rate to 133333, 125000, or 128000! I could get
data at 115200 but it was not a consistent repeating stream and did not
match the data from the original USB-to-Serial device.


    I am assuming I will need to "bit bash" by manually raising and
lowering voltage at some crazy rate which will equate to 133333 baud but
I am uncertain that is possible and it doesn't seem very elegant. Can
anyone perhaps point me in the right direction for what I'm trying to
do? I'm very green when it comes to Arduino but quite solid on the
programming side in general, including serial protocols.


    Next question, Miloh was telling me that since the Rx and Tx ports
on the Arduino are wired through to the USB port, I might expect trouble
trying to communicate with the Arduino while it was running my
application. I will definitely need to be able to update the packet I am
telling it to send to the transmitter in order to fly the helicopter.
Ideally I would like to power the Arduino through this USB connection as
well but that's not necessarily a requirement.


    Any advice would be appreciated.



Cheers

Steve




On Wed, 2010-11-17 at 09:29 -0800, Steve Castellotti wrote:

> 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
> 
> 


Steve Castellotti
Puzzlebox Limited
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noisebridge.net/pipermail/noisebridge-discuss/attachments/20101119/07b8e20d/attachment-0003.html>


More information about the Noisebridge-discuss mailing list