New URBI Info

Take a look at this. It's an update from the guy that modified urbi for the AR Drone:

http://translate.google.fr/translate?hl=fr&sl=fr&tl=en&u=http%3A%2F%2Fwww.psykokwak.com%2Fblog%2Findex.php%2F2011%2F03%2F28%2F60-ar-drone-et-urbi-embedded

I think we can use urbi again, and even better, it's actually embedded on the drone in this more recent example. The site above is originally in French, but this link should provide a translated version. The post that I'm reading is dated March 28, 2011. The only question is weather or not the new urbi download he's providing works with the new firmware. The download is for urbi 2.6. I'm hoping it works.

This is the link to his urbi software package:

http://www.psykokwak.com/blog/images/ardrone/urbi-sdk-2.6-525.tar

This is the link to the howto video:

http://www.youtube.com/watch?v=Cdxq89CigcI&feature=player_embedded

There's more stuff on the translated french site:

http://www.youtube.com/watch?v=Wiv4rC-doJI&feature=player_embedded

Follow up to "Running an application on the drone"

So after working on my UDP client for a while (using a server to echo any commands received) I have been able to develop a working application for the drone that runs natively on it. The code has to be compiled for ARM and is through the CodeSourcery IDE.

Initially I had figured I'd make something that just runs a set of commands and then you would have to edit the source, recompile, etc. to get a different set of commands. Upon further review I decided this wouldn't be all that flexible and would generally be boring. So I wrote up a small command line app that takes commands directly from the standard input and sends them to the drone. Something like "takeoff" or "land" or "gaz .4". Today was the first day I was actually able to test the code and after a few minor changes it worked! I immediately found that I had the same issue with this code as we had had with nearly everything else we'd written for the Drone. We could do the usual takeoff and land and even adjust the Yaw and Gaz, but yet, as usual, we were unable to get the drone to move forward or backward. I dug into the AT command to make sure every bit of information was being sent correctly, and this seemed to be the case. Even other users in the community had used the same commands.

When developing the app I had figured I might run into this issue again, so I had written it so that a thread is immediately dispatched when the code is executed. This thread sends a simple AT command to the drone every 100ms or so, simply to keep the connection alive. In the past when we had looked at this issue before, Dave had found that with a constant "heartbeat" command, we were able to get Pitch and Roll working. Alas, this didn't seem to fix the issue in my case, or so I thought. So I had been sending a command that simply set the Yaw, Pitch, Gaz and Roll to their current settings. So the command had no visible effect on the drone but it did keep reminding it of its current status.

Upon further research I found that this issue had actually been come across by others and they had take a similar, yet slightly different, approach. They had used a heartbeat AT command but the command itself was different. Instead of setting those values mentioned, the simply trigger something called the "Watchdog", using AT*COMWDG=seq, where seq is the current sequence number.

At last, it worked! I was able to get the roll and pitch to change. I quickly realized that it wasn't sticking though and came to the conclusion that I should re-include the other heartbeat command I had used before, to constantly remind the Drone of its state. This fixed it and now the pitch and roll (and yaw and gaz...) stick!

One of the goals of this course was to get the Drone to perform a certain flight pattern on its own. Having to sit in front of the screen typing command after command was somewhat tedious and I thought I might develop a way for the program to read a file. The final scripting files are quite simple and are really the same as typing the commands, with each command one 1 line. I had some trouble getting this to work initially because I had forgotten about implementing a sort of "wait" functionality to pause between commands. Once that was up and running, though, I was able to write out some simple scripts to get the Drone moving.

Here are my sample scripts:

script1.ard:

takeoff
wait 7
land

script2.ard:

takeoff
wait 6
yaw .7
wait 5
yaw 0
wait 4
gaz .3
wait 7
gaz -.3
wait 4
pitch -.3
wait 2
pitch 0
land

script3.ard

takeoff
wait 7
pitch -.3
yaw .3
wait 2
land

These are simply text files and .ard was an extension I made up. I plan on testing this out further and will likely allow you to execute the program with a script as an argument instead of the current method of entering "file" then the script. Or maybe I'll keep both?

I'm also going to look into any startup scripts that the Drone has and look at the possibility of having the drone immediately run a set flight pattern when it starts.

AR Drone Demo Android App

I've been working on an Android app for the class that controls the drone and also directs the drone on simple preset flights. The app is about done, and I feel all I have to do is test it out a couple of times in a large room to fine tune the preset flights. The app also records and plays back drone movements. This part of the app still only works marginally well. I'm going to write a short explanation of how the controls for the app work, and put it on the wiki page of the google-code project.

For the time being, there's a version of the app that can be downloaded from the 'Downloads' page of the google code site. I have not yet put it on the Android market. The link to the 'Downloads' page is below.

http://code.google.com/p/ardrone-smash/downloads/list

Running an application on the drone

So I've taken up the project of trying to get something running on the AR Drone. The idea is that there will be an program that will be stored within the memory of the Drone that we can run and it hopefully will be able to send commands which the Drone will respond to. As a start, I was given some (non-working) code that would send UDP packets to a specific port on localhost. The thinking here is that since the Drone already received commands over UDP, it would make sense that an application running on the Drone would simply send commands to itself.

I was given a start with a basic client and server code in C++ that needed to be cleaned up and fixed before I could run it. Once I had gotten it running, I ran into different issues with the network buffers and buffer sizes where the commands weren't being sent as a complete string. Anyway things seem to be running relatively well now.

The server is basically an echo server and outputs anything that is sent to it. It appears to be receiving the entire command, as it should. The client is a basic command line program that lets you input specific commands, although only "land" and "takeoff" right now. Once we are back from break I will ftp the files onto the Drone and hopefully they will work!

more on dwc_otg.ko module

I built the module as per instructions from the earlier post, and edited the 'vermagic' number in the binary file with a hex editor. Hopefully it will still work. The link to the building instructions is here:

http://embedded-software.blogspot.com/2011/01/creating-testing-and-flashing-tbd.html?showComment=1298131219050#c8216733809012047042

The critical part I was missing was to execute

make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig

which gives you a group of config options that is different from those to be found just by typing 'make menuconfig'. With these options, select "System Type ---> Parrot drivers ---> PARROT6 USB driver (Synopsys)" . Then you can type

make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- modules

This will compile the modules, including the dwc_otg.ko module. Then you have to edit the 'vermagic' string as described in the link below:

http://www.rcgroups.com/forums/showthread.php?t=1335257&page=33

Then you ftp the module over and try the insmod command to see if it inserts.

$ ftp -n 192.168.1.1 (with no port num specified)
ftp> put dwc_otg.ko
ftp> exit

$ telnet 192.168.1.1
# ls /data/video
# mv /data/video/dwc_otg.ko /home/default/dwc_otg.ko

check to make sure that the file is large enough because 'ftp 192.168.1.1 5551' puts files in the /update directory, BUT the files have no contents.

# cd /home/default
# insmod dwc_otg.ko
# lsmod
(listing of inserted module)
# rmmod dwc_otg

So, so far it seems to work. Now we need to test the usb cable itself.

AR Smash with Android GPS

At our last meeting I had an idea of having using the Android GPS with the drone. The idea was to build upon the existing AR Drone demo (which Dave has been using as well) and add GPS functionality. Well I've been working on it without a drone, just logging out when the drone would go forward, back, left and right. The problem I've run into though is that the GPS is far too inaccurate for something like this to really work. If I try to make it more accurate by adjusting the change in longitude and latitude that would be required for a "move" to take place, it becomes too much movement too fast. In fact, multiple different movements would be called even when the phone is sitting in one place. I'm going to continue playing around with this delta value in hopes that I can come up with something relative accurate, but at this point it seems somewhat unlikely. Now I'm understanding why the demo uses the accelerometer instead of the GPS.

dwc_otg.ko

This comment explains how to get the dwc_otg.ko module to compile.

http://embedded-software.blogspot.com/2011/01/creating-testing-and-flashing-tbd.html?showComment=1298131219050#c8216733809012047042