Broken NavBoard?

Problems of AR Drone 1.0, Freeflight 1.
wiredrat
Ready for take off
Posts: 13
Joined: 25 Jan 2011, 09:46

Re: Broken NavBoard?

Post by wiredrat » 27 Jan 2011, 00:54

MAPGPS wrote: 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 :D).
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
Strange wobble
Posts: 201
Joined: 26 Oct 2010, 03:03

Re: Broken NavBoard?

Post by MAPGPS » 27 Jan 2011, 05:10

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
Ready for take off
Posts: 22
Joined: 30 Nov 2010, 00:55

Re: Broken NavBoard?

Post by scorpion2k » 31 Jan 2011, 12:45

wiredrat wrote: 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 :D).
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
Ready for take off
Posts: 13
Joined: 25 Jan 2011, 09:46

Re: Broken NavBoard?

Post by wiredrat » 31 Jan 2011, 14:32

scorpion2k wrote: 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
Strange wobble
Posts: 201
Joined: 26 Oct 2010, 03:03

Re: Broken NavBoard?

Post by MAPGPS » 31 Jan 2011, 16:11

scorpion2k wrote: 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
Newcomer
Posts: 2
Joined: 14 Feb 2011, 14:31

Re: Broken NavBoard?

Post by polari_jet » 14 Feb 2011, 14:56

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
Last edited by polari_jet on 14 Feb 2011, 21:51, edited 1 time in total.

scorpion2k
Ready for take off
Posts: 22
Joined: 30 Nov 2010, 00:55

Re: Broken NavBoard?

Post by scorpion2k » 14 Feb 2011, 16:28

polari_jet wrote: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
Strange wobble
Posts: 201
Joined: 26 Oct 2010, 03:03

Re: Broken NavBoard?

Post by MAPGPS » 14 Feb 2011, 16:58

scorpion2k wrote: 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
Ready for take off
Posts: 22
Joined: 30 Nov 2010, 00:55

Re: Broken NavBoard?

Post by scorpion2k » 14 Feb 2011, 17:12

(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
Newcomer
Posts: 1
Joined: 01 Jul 2011, 10:49

BLC Motor Control Protocol

Post by nullpointer » 01 Jul 2011, 11:00

Here is a description of the motor control protocol:

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

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests