Friday, April 22, 2011

Broken Drone

HOW THE DRONE BROKE
We were trying to use a serial cable to connect to the drone motherboard. The drone motherboard has a port on it that is labeled as USB but it has a non-standard connector. On line were instructions on how to make a cable that would connect to the drone motherboard, but the instructions were not entirely clear.

The part of the process that was clear was that some special software needed to be compiled for the drone. This was a kernel module called 'dwc_otg.ko'. Then once the software was in place a special cable could be used to connect to the drone. The kernel module sources were modified and built for the ARM processor and installed on the drone. This took some time.

Then we ended up making two cables, one that was just a wire connecting a standard USB male connector with a specially made connector on the other side for the drone. The second cable was made with the standard USB male connector, an intermediary circuit in between, and again the special connector for the drone.

There were two test circumstances that we wanted to try. First we wanted to test the cables with a USB thumb drive, checking the 'dmesg' output on the drone to see if the device detected the drive. Then we wanted to connect to a computer and try to figure out a way to use the connection as something like a serial terminal. The reasoning for using the thumb drive was that the thumb drive had no power supply, so there was no chance of damaging the drone. In the forum posts people had success with this kind of testing, and the 'dmesg' output showed that a memory device was connected at the serial port.

We tried the cable with the intermediary circuit first. There was 'dmesg' output showing that the kernel module was working, but nothing showing the drive itself was recognized. There was some output on dmesg, but it was just a string of hexadecimal numbers, and it did not look like the output that people on the forums were getting. Then we tried that cable with a computer on the other end of the cable instead of the thumb drive. Again nothing showed on 'dmesg' to identify a computer.

Then on another day we tried the cable with no intermediary circuit. First we tried it with the thumb drive. There was output from 'dmesg' but not enough to identify the drive. Then, thinking that nothing would happen, we connected that cable to a computer. This is how the drone was damaged.

FIXING THE DRONE
Immediately after the drone was damaged we rebooted it. All the indicator lights on the motors went from red to green as they were supposed to do for a normal boot up. The drone even flew briefly, taking off and landing. The first indication was that it was not seriously harmed.

Later it stopped working, so at first we were confused as to what was happening. We could still telnet in to the motherboard but we could not fly the drone, and during boot up, two of the four motor lights that were supposed to light up and turn from red to green did not do that. We took the drone apart and identified a spot on the motherboard where a component had burned. For this reason we decided that the motherboard needed to be replaced.

A new motherboard was ordered and we installed it, but the two motor lights that would not light up before still would not light up. At the time of this writing the drone is still broken, and we are looking at the motors themselves as the cause of the latest problem. The idea now is to interchange the motors in different positions on the drone to see if the motor itself is broken or if it's some kind of other problem. The motors are replaceable but everyone is wary of replacing a part and finding that the drone still does not work.

UPDATE:
It was determined that two motors were broken. New motors were ordered and the old ones were replaced. The drone now works.

Friday, April 1, 2011

Watchdog Command

While working on my embedded program, I found that it needed to constantly be sending something called the "watchdog" command. Once this command is being sent every 100-150ms or so, the pitch and roll values actually make a difference.

Here is the command:
AT*COMWDG=seq

Thursday, March 31, 2011

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

Tuesday, March 29, 2011

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

Monday, March 21, 2011

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!

Monday, March 14, 2011

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.

Sunday, March 13, 2011

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

Friday, March 11, 2011

Steps to USB Serial Port

Before we can use the USB Serial connector (even if we know the electronics works) we need to compile the kernel module from the ARDrone/Parrot site. Instructions for doing this are at the site below.

http://embedded-software.blogspot.com/2010/12/ar-drone-usb.html

There are two challenges, one being the actual compiling of the module with the changes mentioned, and the other being compiling the same module for the arm processor on the ARDrone. I've downloaded the source and made the changes to the 'dwc_otg_driver.c' file but I've had trouble compiling it. The basic problem is that if I type 'make modules' a few kernel modules are built, but not the dwc_otg.ko module. (I have downloaded the arm cross-compiler, but have not had a chance to use it yet -- I thought I'd try regular compiling first.)

I went into the kernel configuration screens, typing 'make menuconfig'. I pretty much scoured the various menus but could not find the option for 'dwc_otg'. I tried out several things that I felt were close to the option I was looking for without any luck.

I think this 'dwc_otg.ko' module is very basic and needs to be present in order for the usb port on the Drone to work as a serial port. I have posted a comment on the blog mentioned above asking the 'E/S and I' guy for help. We'll see if he responds.

Droid Incredible and Eclipse

/home/username/bin/android-sdk-linux/platform-tools/adb kill-server
/home/username/bin/android-sdk-linux/platform-tools/adb start-server
/home/username/bin/android-sdk-linux/platform-tools/adb devices

these are commands you might have to run as root to get eclipse to recognize the Droid Incredible.

Tuesday, March 8, 2011

AR Drone 1.6

Once again 1.6 has defeated us. I tried to get it working. Made some headway by stealing a few files from 1.5 but it ended up just causing more problems. It looks like at least while on Linux 1.6 literally wont compile for android. It seems that there are a few syntax errors and other things that just generally don't work. I decided to go back to 1.5 and after a little bit of trouble I was able to get it working. I got the emulator up and running and tested it on the drone. It works. I am now sticking with 1.5. Also I have the drone and will bring it back Thursday or Friday.

Sunday, March 6, 2011

Broken Drone Bumper

I broke one of the AR Drone plastic bumpers today. I'm referring to one of the circular bumpers that are part of the plastic cover. It wasn't a bad break, and I immediately patched it up with tape. I can't say it's as good as new, but it flies just the way it used to. If it's a problem with school I'll buy a new cover. I think they're inexpensive. I felt pretty bad about it when I did it. I wasn't being particularly hard on it or anything, though. My apologies to everybody.

usb/serial cable

This weekend I received the last of the parts for the usb/serial cable. This one is the device that actually transfers the ttl level signals to RS-232 signals. That's at least what I think it does. It's very cool, with its own little circuit board. It will require some special kernel module compiling to work. I think we can get to that after we have an assembled cable. Oh, btw, I believe there's no soldering to be done to connect this particular part. We will need wire, and we will have to solder the wires to the terminals for the small connectors that we've already got...

Friday, March 4, 2011

firmware

Since we already have the newer firmware installed, I vote we keep it for a while and at the same time keep the web location of the older firmware. For the time being we can work with the newer firmware, and if the older is needed later on for some reason we can always go back then.

Old firmware

http://www.ardrone-flyers.com/wiki/V1.1.3

Wednesday, March 2, 2011

urbi doesn't work since firmware update

Since the firmware update Urbi doesn't work. I get output identical to the following.

[00000740] *** ********************************************************
[00000743] *** Urbi SDK version 2.3 rev. 9a84600
[00000756] *** Copyright (C) 2005-2010 Gostai S.A.S.
[00000756] ***
[00000756] *** This program comes with ABSOLUTELY NO WARRANTY. It can
[00000757] *** be used under certain conditions. Type `license;',
[00000757] *** `authors;', or `copyright;' for more information.
[00000757] ***
[00000757] *** Check our community site: www.urbiforge.org.
[00000757] *** ********************************************************
[00000936] ARDrone_0x9bc19c8
before setLocale()
before ardrone_tool_setup_com(NULL)
before ardrone_tool_init(...)
Starting thread navdata_update
Starting thread ardrone_control
Thread navdata_update in progress...
before ardrone_input_add(NULL)
Input device myControl added
Starting thread my_video
Video stage thread initialisation
[00000964] true
[00000996] *** Waiting connection.
Timeout
Tag 19 is not a valid navdata option tag
[Navdata] Checksum failed : 0 (distant) / 25300 (local)
Tag 19 is not a valid navdata option tag
[Navdata] Checksum failed : 0 (distant) / 25733 (local)
Tag 19 is not a valid navdata option tag
[Navdata] Checksum failed : 0 (distant) / 25528 (local)
Tag 19 is not a valid navdata option tag
[Navdata] Checksum failed : 0 (distant) / 25771 (local)
Tag 19 is not a valid navdata option tag
[Navdata] Checksum failed : 0 (distant) / 25495 (local)

I've tried recompiling the urbi ARDrone module with the following patch, but it doesn't work. (The patch applies cleanly and the module actually compiles, but later doesn't work).

https://projects.ardrone.org/issues/show/67

So my question is, what are our options? Does an older version of the firmware exist on line? If it did, could we even install it without bricking the drone? I am going to write to the guy who first published the urbi module for the ARDrone, but until I hear from someone like that I'm just going to work on Android apps.

Tuesday, March 1, 2011

A Sample Android App and Java classes

I have created a sample Android app that is now available on our google SVN repository. As of now the app is very simple, with a simple button and logo. Upon clicking the button the Drone will take off, hover for 5 seconds and then land. This can be expanded out pretty easily and is a good starting point. Most of the logic actually occurs in an external AR Drone class. I hope the final version will take off, fly a certain path, then land.

We have been working with different java classes to try and get better control over the drone but have been struggling so far to find a class that sets the pitch and roll to what we want. All of the classes we're using use AT commands to tell the drone what to do. One would expect a command that sets the pitch and roll to set those values but that doesn't seem to be happening. Instead either nothing happens at all or the change isn't made until we start the drone agan and, thus, it takes off into a different direction (usually right into the wall). We had limited progress with this issue today but found that settings the pitch right before liftoff will have an effect, similar to the one just mentioned.

Upon reading through the SDK documentation we saw that the drone will auto-disconnect if you don't send it a command for 2 seconds. We're thinking of implementing something similar to what Dave has in his Urbi example, where there is a loop that constantly sends the drone commands.

Finally, I put together an extremely basic logo for our final application. And by basic, I mean that it was put together in 5 minutes or less. Enjoy.



Sunday, February 27, 2011

text for google-code project page

I was trying to think up some descriptive text for the project page on Google Code. I had to think up rules for a game that we could play with the drone that incorporates the stuff that we've been doing in class. Also I was thinking about the fact the we only have one drone to work with. This is what I came up with. Look it over and maybe make changes if you like. I haven't put it on the site yet.

'ardrone-smash' is a game for the AR Drone. In the game, a simple course is set out. The course might have an obstacle or a certain goal. Then the player programs the drone to follow a path, and then sets the drone off to follow the path autonomously, and then other people rate the flight for how well or poorly the drone handles things like the obstacles and goals set out at the beginning.

Saturday, February 26, 2011

Where I Am At:

Thus far I have been simply doing a lot of reading into what specs people have discovered about the ar drone and how to mod it.
From what I've read, I've learned that its very possible to add your own hardware and implement it's usage. This is a bit tricky however because Parrot does not appear to favor people tampering with their nifty little toy, and thus there aren't really any data sheets of the hardware to help us out. Nevertheless there are people who have done this, and the link that I previously had posted (yesterday morning) is actually super extra helpful. There is also a forum (on a website i also posted on this blog) that has a section dedicated to modding the drone.

It appears that to get this ball rolling we need to edit one little setting if we are to try flashing the rom via usb (which would be ideal because we can then see the progress from a pc; it should also be noted that we'll have to create our own usb wire, i wonder about a driver for it too?). The drone has a driver that is automatically set to only allow flashing rom from on the drone. After changing the setting, permission will be granted to do it from the usb connection (from a flash drive or straight from the pc are both possible). I'm not totally sure how we do this yet, i think we need to edit the .plf file. It might be possible to just change it from a pc but that doesn't really make sense since we won't have permission.
This brings us to our next step, editing and making our own version of a .plf file. From what i understand, the .plf file has something to do with installing the kernel on the drone. Firmware upgrades from Parrot are also in this file format, and the E/S and I blog talks about making your own kernel as a .plf file. This means that somewhere in the creation of our own (that sounds like way too big a task) or the editing of one of Parrot's firmware upgrade, is the spot we must edit to take advantage of any hardware we might add to the drone.

As for talking about adding hardware, i think the knowledge i have accumulated is still too vague to write about. As previously mentioned, this is a bit of a challenge without data sheets of the hardware. What i can say now is that the project i would like to work on is adding proximity sensors (at this stage i think ultrasound sensors are a good option but ill also need to look into that more, its not a definite decision) to the sides of the drone and edit the kernel so that if the drone gets too close to anything it will react one way or another (which is totally up to us) so that it evades any collisions. This is all up in the air though and we can work on any other projects, so if you guys prefer the gps or have any other ideas feel free to share

Finally...i can go eat =)
Enjoy your day people

serial usb connector for drone

I thought the component from the link below would help us make a serial usb cable for the drone.

http://robosavvy.com/store/product_info.php/products_id/986?osCsid=f188e6f97228c348bebf81772ef60043

I thought that the following diagram would be useful.

https://projects.ardrone.org/attachments/167/ARDrone-USB-Cable.png

I even ordered some of these molex connectors. I think I may need to buy a crimping tool or something to actually use the connectors. I'll also need to go to Radio Shack for wire and a cheap volt meter.

http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&WT.z_homepage_link=hp_go_button&KeyWords=WM18032-ND&x=0&y=0

Look this over and maybe we can come up with a plan for doing this.

Friday, February 25, 2011

Rooting HTC Incredible to control AR Drone 2

To root the Incredible is like the easiest thing ever. All you have to do is plug it into a Linux machine and run the file you can find at this link.
http://unrevoked.com/recovery/

It wipes out the precautionary areas that they put into make it so you cant get root and then it install's all the stuff you need for root. Run the program as root, then when its done and all booted up install rom manager to change the roms, You also need to install BusyBox. It didn't work for me through the market so Install it from titanium backup for root.

From there you can do what you want. Now to actually mess with it with programs.

working urbi script with gamepad

I have a working 'testgamepad.u' script. It controls the AR Drone reasonably well. I also downloaded the Gostai Labs software trial version. It allows for display of video at the same time as using a script, so I can see the video from the camera and move the drone at the same time. I'm going to start working on a urbi script that will record the values from the drone as it's flying, and then play them back again. It should mimic your instructions on the gamepad. At the same time I want the gamepad to still work during that playback so that unseen obstacles can be avoided somehow by having the gamepad override the playback mechanism. The new script is called 'ardrone_record.u'. I may need to write another C++ module for urbi so that the script will work. I will also want to incorporate Gostai Labs, now that I have a version of it.

not compiling urbi 2.6 for arm processor

In a previous post I said I was going to try to compile urbi 2.6 for the arm processor. After several attempts I've decided not to. I've tried several cross compilers and versions of urbi from 2.4 to 2.6 (I was only interested in versions that allowed for Java urbi modules.) Throughout this I've run into a single make error in all the tests I tried. I have posted on the urbi forum, but have received no replies. I cannot think of anything else to try. If someone does reply before the class is finished I will attempt to build it again. Otherwise it's not worth it. Below is a link to my forum post.

http://forum.gostai.com/viewtopic.php?f=26&t=2886

Rooting HTC Incredible to control AR Drone

http://unrevoked.com/rootwiki/doku.php/public/unrevoked3

http://unrevoked.com/recovery/

Useful Link

This person has been working on modding the ar drone and there is a lot of useful information on it at this link:
http://embedded-software.blogspot.com/

Pitch, lean to left.

public void staticPitch() throws Exception{
//pitch 0.1
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
updateDrone();
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
updateDrone();
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
updateDrone();
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
updateDrone();
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
updateDrone();
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
updateDrone();
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
updateDrone();
send_at_cmd("AT*ANIM=401," + (seq++) + ",1000");
waiting(4);
}

Tuesday, February 22, 2011

compiling urbi for an arm processor

I think it might be good to have a urbi sdk version like version 2.6 which can handle java urbi objects (I think.) So I'm looking into compiling the urbi 2.6 sdk for an arm processor. I'm not sure how it will even work, but I think it's worth the time.

Friday, February 18, 2011

One of the many useful third party sites.

well i found this forum today, seems to have its own section dedicated to moding the drone and you can see other peoples ideas and projects (i think the coolest is adding fireworks to it, although i don't know if the drone itself lights it up) but yes, it appears quite a few people have attached a gps to it, one person even went as far as also adding a compass.
On a side note though, i saw someone talking about adding hardware so the drone can detect its surroundings and not crash into anything, so i was just thinking another cool project rather than a gps would be to get it to act like a radar and perhaps send back a stream of what its picking up

and of course, the website; the forum is a part of (it has other useful stuff too of course):
http://www.ardrone-flyers.com/

linux urbi joystick module

I've been pretty avid about getting a joystick program to work with urbi. I found out though that there is already one of these programs on the urbi site. For the time being though I'm going to keep working on my version. If it's necessary I'll switch to the urbi model at another time. This is the link.

http://www.urbiforge.org/index.php/Modules/Joystick-linux

Another ARDrone java class for reference.

https://projects.ardrone.org/attachments/319/ARDrone.java

Java reset command for the ARDrone.java file

public void reset() throws Exception{
send_at_cmd("AT*REF=" + (seq++) + ",290717952");
waiting(4);

}

The java reset command might need an adjustment.

Tuesday, February 15, 2011

AR-Drone with java

https://projects.ardrone.org/boards/1/topics/show/1819

A good site for hacking the AR-Drone

http://dronehacks.com/page/2/

AR-Drone initial thoughts

So I am writing this to say what we have done. We have gotten the drone to work with an android phone, and got it connected to a laptop. We were able to get the bot to run the script that makes it track a red ball and it works flawlessly. I would say for a start that it has been a total success. We have used the URBI SDK to get the bot to run a script to take off turn and land.

We are now trying to get the scripts running all the time. Then we will start to program the bot to do what we want.

Initially we want to program the bot to follow some sort of path and then we may use a phone to connect to the bot and move it with GPS. This is more of a thought at this point and we hope to do it but we have to see how everything else goes.

Here is a link to the code project. There isn't much to speak of on there yest, just what we need to use, like he libraries.

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