Category Archives: Parrot AR.Drone

DroneProxy for Parrot AR.DRone first parachute test

I have started to work on DroneProxy some time ago to work around bugs in the firmware of the drone. Basically it is a transparent proxy for the UDP AT command packets arriving on port 5556. The packets are parsed to keep track of the sequence number. If no packets are received for 1500 ms the proxy will start sending “landing” commands with increasing sequence numbers (until somebody plugs the battery…).


Let’s get serial!

During my telnet visits to the Parrot AR.Drone i wondered what all the serial ports (/dev/ttyPA0..2) are for. And now I know which one is used by what and where i can find them on the board.

The pinout for a USB cable can be found at the official Parrot website….here.

/dev/ttyPA0 is used by the bootloader and the kernel and can be found on the “USB” port (Pin 4 is RX and Pin 6 is TX) and greets us with:

Restarting system.
Parrotboot for target MYKONOS, built on Apr 21 2010
NAND: layer initialization
NAND: found 8 bits nand 0xf1
UBI: layer initialization (version 1)
UBI: found volume with id 2147479551
UBI: found volume with id 0
UBI: found volume with id 2
UBI: failed to open volume with ID 1 (Bad file handle)
Attempt booting on UBI volume with ID 0…
Booting Linux…

This serial interface should allow us to attach a GPS module (with a TTL level serial interface) directly, without the need of a new kernel! GPS here we come! :-)

/dev/ttyPA1 is used to interface with the motor controllers. There must be some de-multiplexer between the serial port and the 4 motor controllers. I actually managed to randomly start a motor by typing garbage into this.

/dev/ttyPA2 connects to the navboard and continously spits out navdata from all sensors.


The Parrot AR.Drone GPL saga continues….

After Parrot finally released the GPL sources for their kernel changes it was time to dig into the firmware some more. Last week i was taking a closer look at the closed source control binary which has the innovative name “program.elf”.

It turns out that the binary dynamically links to libiw (from the wireless_tools) which is a GPL licensed library. You can easily check this yourself by telneting into the drone:

strings program.elf | grep iw
libiw.so.29
iw_sockets_open
iw_get_basic_config
iw_set_basic_config
iw_in_key_full

Antoine Ferran (from Parrot) confirmed this fact on the next morning:

The libiw is dynamically linked with the program but it is a mistake.
Libiw is not needed anymore: it is a remnant of a previous test version.
Any calls to libiw has been removed from the current build that will be released soon.

You can find the complete discussion here.

I am pretty confident that they will not get away with that and will have to release the source code. Actually that could be a really good way for Parrot to get help from the community to fix all of the critical bugs in the current firmware (“fly-away” syndrom, random crashes, ….) and make a much better product! :-)


Parrot AR.Drone internals (iBreakIt…)

Now that i am done messing with the software and actually completing a few test flights, I figured it was about time to tear the drone apart. The only thing required is a tiny torx screwdriver (T6X20) which fortunately i had laying around on my desk because we use the same screws to tighten the GSM modules on to our GSM cards.

Once you remove the plastic shielding you can see the mainboard stacked on top of the navboard (which carries the ultrasonic sender/receiver). The front camera is connected with a ribbon cable coming from the right. Above that camera connector is a 7 pin USB header.

Undo 4 little screws and you can remove the navboard (which plugs into the backside of the mainboard with an 8 pin connector…probably serialish). Here you see the mainboard with the camera cable removed and the battery connector ripped out of the shell (to give some space for moving the mainboard). The mainboard has 2 on-circuit wifi antennas (ANT1 and ANT2):

This is the navboard with the ultrasonic sender/receiver pair. The “ugly padding” on the left is probably to shield the right one from receiving the “echo” through vibrations across the pcb (instead of receving the reflected signal through the air). The 8 pin connector connects to the mainboard.

The other side of the navboard:

And the other side of the mainboard:

The drone is really easy to take apart and also to re-assemble. It even does work again. ;-)