ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

tum_ardrone autopilot

asked 2014-05-28 00:39:53 -0600

hsoltani gravatar image

updated 2014-05-28 00:46:02 -0600


I downloaded and was able to compile tum_ardrone on Ubuntu 12.04. I'm using ROS Hydro.

As the README.txt explain for Autopilot section we should do the following:

  • type command "autoInit 500 800" in top-left text-field

    • click Clear and Send (maybe click Reset first)

    => drone will takeoff & init PTAM, then hold position.

But when I do the same, the drone don't take off. If I click takeoff and then clear and send "autoInit 500 800" command, the drone try to go to the target but can't work properly and don't hold the position. How can I fix this problem? Any idea?

I wonder if I should calibrate the camera and initialize PTAM by myself before sending the commands. Is it necessary?

How much the structure of environment influence the accuracy of the algorithm? Which objects is better to be in the field of view of the camera? Can the AR.Drone work properly in small scales and bounded environments?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2014-05-28 05:13:44 -0600

Rabe gravatar image


First of all, it has been over a year when I last used the tum_ardrone package, so my response might not be accurate. From afar I can't answer your first question, but I remember I had some trial and error also regarding to when the drone actually took off, sometimes my message-queue for the drone wasn't empty and the drone took off after inserting a new battery and things like that. You could post some logfiles, maybe I'll see something.

It is hard to tell what you mean with "can't work properly and don't hold the position". The onboard controller of the drone tries to keep the drone in one place via the bottom camera when no commands are sent. If you have a floor without any visible edges, like a grey carpet, this sometimes results in the drone moving into one direction because of the optical illusion that the floor is moving. You can switch to the output from the bottom camera to see for yourself that it is really hard. This isn't a faul of tum_ardrone but rather from the onboard controller. To avoid this, you can place highly distinctive markers (or even just sheets of paper) on the floor or maybe use one of those carpets for children with the city drawn on it City-Carpet

In regards to the more general questions: I managed to get the drone to work pretty well in smaller environments, like offices or hallways. It helped to have objects about 1-5 meters away from the drone. Again, the better the color-contrasts and the more edges visible, the better the algorithm worked.

I hope this helped a little,


edit flag offensive delete link more


Rabe, many thanks for the reply. It was very helpful. 1. In regards to the first question, you are right. I will try it and post the log files. 2. For tracking ground targets reasons, a front camera of the AR.Drone was taken out and mounted on the bottom of the drone looking downwards. Does the tum_ardrone package work in this situation or I should mount the camera on the first position?

hsoltani gravatar image hsoltani  ( 2014-05-29 00:32:46 -0600 )edit

1) Post a gist or a pastebin, I'll have a look 2) My guess is, it won't work per default, you'd definetly have to change some lines of code, since the whole orientation changed. Also, why don't you just use the bottom camera? Because of the resolution, or because of tag-detection?

Rabe gravatar image Rabe  ( 2014-05-30 01:40:13 -0600 )edit

Maybe, you could just tell me the concept of your idea (or PM it to me, if you don't want it to be public) and I could give my 2 cents. Cheers, have a nice weekend!

Rabe gravatar image Rabe  ( 2014-05-30 01:41:10 -0600 )edit

Question Tools

1 follower


Asked: 2014-05-28 00:39:53 -0600

Seen: 890 times

Last updated: May 28 '14