Based on the original mod that uses an special Arduino board with WiFi (called YellowJacket) to control the Parrot AR.Drone I present a mod that establishes this without WiFi! Since the YellowJacket module seems not to be available anymore, this is a great alternative that only requires an Arduino Pro Mini!

You can find any files required as well as a detailed how-to on the corresponding Google Code Project:

http://code.google.com/p/ardudrone/wiki/HowTo


I opened up this thread so the original one won't get highjacked with stuff about the Wifi-less variant (it already is a bit ).

Also I want to thank MAPGPS and Mheeli, without them, this mod would not have been possible!

Have fun and tell me what you think about the how-to! Any suggestions appreciated!

Could you add a picture showing how/where the molex connector plugs into the Parrot? that's the only part I'm confused about (so far) on you project page.

thanks!

Ross

Well when it comes to ports there aint much choice, there is only one at the bottom of the drone protected with a rubber plug that has an USB sign on it. But I happily add a picture showing it to the guide if that helps.

Why they didn't just put a standard USB port there is a mystery to me...lol

First Thanks for your work, I've been carefully following the wifiless solution with excitement. So much that I just registered with these forums

I was thinking about an alternative to using the usb module, and instead make use of the standard serial port that comes pined-out in the same connector. The idea is to write a daemon listening on the (native) serial port which would act as a gateway between serial and local host connection.

The advantage would be less embedded weight on the drone, a simpler connection, less power consumption and of course one less point of failure from the USB (which is quite a complex stack for just passing a text stream).

As soon as I can setup a working toolchain to compile C code for the drone, I'll write this daemon (quite trivial).

I'll gladly share my work of course.

Kind Regards,

Benoît.

Also, have you tried using the 1.51 firmware yet? I'm hoping my drone comes with the 1.3.3 installed so I don't have to mess a round with downgrading the firmware. Will this mod even work with 1.51?

Thanks for the excellent how-to! GREAT work!

@ babblin5
ATM the mod is only tested and working on 1.3.3. Downgrading is not a problem, just copy the 1.3.3 firmware to the drone like any other upgrade and execute the following command on the drone before you restart it: (this circumvents the built in version check!)

# echo 0.0.0 > /firmware/version.txt

@ Benoît
Great to hear you joined the discussion! And hold on writing that daemon, it has already be done! The current mod also works perfectly with the built-in serial port on the drone! The provided proxy application can listen on any serial port (the default is hardcoded to /dev/ttyUSB0, the serial port created by the FTDI breakout board) by using the "-d(evice)" option:

./atcomproxy_arm -d /dev/ttyPA0

But besides the advantages you described, this has some disadvantages though:
- This serial port is shared with the system and used for system messages output and also as a serial console. To prevent the system from using it, you have to compile and flash a custom kernel. To disable the serial console, no flash required but you have to modify another system critical config file. Also by disabling the serial console you block your only alternative access to the drone besides wifi. Maybe you want to disable wifi on the drone all together to improve battery life, then you need the serial console for system access!

- If you don't want to flash a custom kernel and only disable the serial console you still get some noise on the serial port from the system. The proxy app has to filter this out to ensure a save communication to the drone, this makes it a bit more complicated and slower (not much though).

Great work, been keeping an eye on your progress. You must post some video of the Drone flying. Will your mod keep up to multiple fast inputs? I found with the YJ, if you really hammered it, it would sometimes not respond right away. Perhaps pushing the YJ to it limits. If you flew smooth, no probs.

Brian.

I would think that the response would be faster since you're sending commands directly through the USB port as opposed to YJ translating and sending through the WIFI, where it's translated again. Just a supposition on my part.

Originally Posted by babblin5

Also, have you tried using the 1.51 firmware yet? I'm hoping my drone comes with the 1.3.3 installed so I don't have to mess a round with downgrading the firmware. Will this mod even work with 1.51?

The kernel comes with AR.Drone official firmware was not built with CONFIG_MODULE_FORCE_LOAD,
so it is not allowed to force load a modules with mismatched version magic.

Actually, our *.ko modules are not version sensitive, you can simply use a binary editor (like UltraEdit) to modify the version magic string in *.ko files to match the kernel in your new firmware (use "uname -r" to find out the version magic).

Originally Posted by nosaari

@ Benoît
Great to hear you joined the discussion! And hold on writing that daemon, it has already be done! The current mod also works perfectly with the built-in serial port on the drone! The provided proxy application can listen on any serial port (the default is hardcoded to /dev/ttyUSB0, the serial port created by the FTDI breakout board) by using the "-d(evice)" option:

./atcomproxy_arm -d /dev/ttyPA0

Cool info., thanks

But besides the advantages you described, this has some disadvantages though:
- This serial port is shared with the system and used for system messages output and also as a serial console. To prevent the system from using it, you have to compile and flash a custom kernel. To disable the serial console, no flash required but you have to modify another system critical config file. Also by disabling the serial console you block your only alternative access to the drone besides wifi. Maybe you want to disable wifi on the drone all together to improve battery life, then you need the serial console for system access!

- If you don't want to flash a custom kernel and only disable the serial console you still get some noise on the serial port from the system. The proxy app has to filter this out to ensure a save communication to the drone, this makes it a bit more complicated and slower (not much though).

Then atcomproxy_arm could be modified to just exit and let the system use the serial port as the console in case no Arduino board is responding at boot, so that when the Arduino board is not plugged in, then the system console remains accessible. By the way, are the sources of atcomproxy_arm available somewhere?

Originally Posted by MAPGPS

The kernel comes with AR.Drone official firmware was not built with CONFIG_MODULE_FORCE_LOAD,
so it is not allowed to force load a modules with mismatched version magic.

Actually, our *.ko modules are not version sensitive, you can simply use a binary editor (like UltraEdit) to modify the version magic string in *.ko files to match the kernel in your new firmware (use "uname -r" to find out the version magic).

So you think this would work then with the mod if I did this, or would I be the guinea pig?

I was trying to look into the sketch you posted on google. I am guessing it is some sort of compiled hex code?

I am trying to do the same but with a MSP430.
Will you posting any of your source code on google? Maybe I can replicate what you have on my MSP430.

Thanks

ok, did some reading.
My bad. Currently downloading the IDE for Mac. Good to know there is something for Mac.
My first time looking at a Arduino programming language. Almost same as PicBasic.

All sources are available on the google Code project, thats why its called google code not google binary

The Arduino programming language actually is C.