Broken NavBoard?

[wiredrat]

I have compiled Interceptty for ARM, and it can run on my AR.Drone to simulate a "fake" /dev/ttyPA2, logging NavData.
Unfortunately Interceptty has not yet implemented ioctl() calls, thus program.elf can not trigger NavData via ioctl(). Need to find a new serial port sniffer.

After a few hours figuring how to compiling static interceptty (autoconf and automake is something unknown for me) I've been able to run it on the drone. And it worked as expected and I could sniff data from ttyPA1 (ttyPA2 is broken, this thread started on that) and get the some interesting stuff. I even managed to power the motors (uncontrolled, but they rotated ).
As said above, ioctl() TCGETS and TCSETS calls just set tty parameters, as stty does. Interceptty is can try to run stty (-s parameter) but program.elf does it rigth, so no need to worry about this. The ioctl() TCFLSH calls I saw are due the broken navboard and shouldn't happen in normal operation.
Here on some commands and snips.

Code: Select all

# mv /dev/ttyPA1 /dev/ttyPA1-orig
# ./interceptty -o ttyPA1.out /dev/ttyPA1-orig /dev/ttyPA1 &
# program.elf
CTRL+\
# kill %1
# mv /dev/ttyPA1-orig /dev/ttyPA1

And the results!

Code: Select all

< 0xe0           RST?
> 	0xe0
> 	0x00
< 0x01           MOTOR 1
> 	0x01
< 0x40 (@)       GET INFO
> 	0x40 (@)      
> 	0x01
> 	0x0b
> 	0x03
> 	0x00
> 	0x01
> 	0x01
> 	0x09
> 	0x0a
> 	0x07
> 	0x0a
> 	0x0a

It would be nice to run it on a functional drone and see more commands. Maybe I can recycle my AR Drone as a wifi-enabled geek-ad-infinitum ceiling fan.

[MAPGPS]

If we can figure out the protocol of /dev/ttyPA1 for PWM control, we could be able to replace the expensive Parrot BLC/motors with other cheap/powerful BLC/motors in the market.

If you would like to do more DIY, you may create your own Navboard and provide similar NavData to /dev/ttyPA2.

Arduino Mini (or Nano) is a nice open source platform to DIY such Navboard.
We even can add a barometer and mix the ouputs with ultrasonic to get a large range of altitude.

I bought an Arduino Nano, and trying to add barometer, compass and GPS. Attached it to AR.Drone via the serial port.

[scorpion2k]

After a few hours figuring how to compiling static interceptty (autoconf and automake is something unknown for me) I've been able to run it on the drone. And it worked as expected and I could sniff data from ttyPA1 (ttyPA2 is broken, this thread started on that) and get the some interesting stuff. I even managed to power the motors (uncontrolled, but they rotated ).

So.. I finally figured out how the PWM control works. To verify if it is correct I would need a short interceptty dump of the initialization + start + landing. Can anyone provide this to me (e.g. via PM)?

Thanks

Best regards

[wiredrat]

So.. I finally figured out how the PWM control works. To verify if it is correct I would need a short interceptty dump of the initialization + start + landing. Can anyone provide this to me (e.g. via PM)?

I'm so sorry. Didn't got a new Navboard yet and I can't get up my drone. However, I'm very interested on that.

[MAPGPS]

So.. I finally figured out how the PWM control works. To verify if it is correct I would need a short interceptty dump of the initialization + start + landing. Can anyone provide this to me (e.g. via PM)?

I would like to do the flying test and get the data to you on this Wednesday (I'll have free time then).

[polari_jet]

hi everybody! any news on sniffing motor protocol? I've used the following command cat /dev/ttyPA2 > /dev/ttyPA1 hoping to use continuously streaming navdata to get any response from motors but all I got was a lightshow with diodes. will try to use interceptty

[scorpion2k]

hi everybody! any news on sniffing BLC protocol? I've used the following command cat /dev/ttyPA2 > /dev/ttyPA1 hoping to use continuously streaming navdata to get any response from motors but all I got was a lightshow with diodes. will try to use interceptty

Yes. MAPGPS provided me an interceptty dump. With this I was able to analyze all control commands (except for firmware flashing).

For now, I can initialize the motors and control the Speed + LEDs. Sadly, this only works until a Cutout is detected. Seems like the UART is switched off then and I haven't yet figured out how to enable it again.

Best regards.

[MAPGPS]

For now, I can initialize the motors and control the Speed + LEDs. Sadly, this only works until a Cutout is detected. Seems like the UART is switched off then and I haven't yet figured out how to enable it again.

Best regards.

With motor Cutout detected, AR.Drone will get into Emergency state (all LEDs are Red).
To get rid of Emergency state, you can send AT command:
AT*REF=1,290717952

All LEDs will turn to Green again.
(I guess program.elf will send something to /dev/ttyPA1 once it received that AT command)

[scorpion2k]

(I guess program.elf will send something to /dev/ttyPA1 once it received that AT command)

This was also my first assumption, but ttyPA1 is dead once a Cutout was detected. As they use a single-wire UART for motor connection there must be some open collector circuit. I assume that this circuit is deactivated with the cutout signal. Even toggling the motor specific GPIOs does not change this state. I think, to re-enable it some other GPIO pin must be used.
At least restarting program.elf resets the cutout state without sending any relevant command to ttyPA1. I will have to add some printk' to the GPIO driver to see what happens there.

Best regards.

[nullpointer]

Here is a description of the motor control protocol:

http://blog.perquin.com/blog/ardrone-motor-controller/" onclick="window.open(this.href);return false;