What are we actually commanding with the cmd_vel input?

[parcon]

It isn't exactly related to the code, but here's an interesting question I hope one of you other researchers have answered before. When you send a command to the drone, for example cmd_vel.linear.x =1, are you controlling via velocity or acceleration?

The paper concerning this platform The Navigation and Control technology inside the AR. Drone micro UAV seems to go against the SDK.

The SDK 2.0 states that the input is "a percentage of maximum inclination as configured", while the paper says "velocity setpoints proportional to orientation of the handheld device"

What have you guys found in your work thus far? My lab is just beginning with the platform.

[mikehamer]

Good to see someone else working on dynamics – my experience is that most researchers in this field are focusing on the computer vision side of things, and only using the AR.Drone because it's a cheap & stable flying vehicle that is easy to command.

I'm a Masters student at ETH Zürich currently working (and have been for the last month – when my lab began with the platform) on model identification of the drone; I hope to have something by next monday as I have a meeting with my supervisor to discuss results.

[mikehamer]

In terms of papers to read, the only papers I have found which really deal with AR.Drone modeling is the paper by Jacob Engel at TU Munich (@JakobEngel I assume?) and his associated Masters Thesis, which goes (obviously) into more depth concerning the modeling and parameter estimation procedure, providing values for the model parameters which are lacking in the paper. I found these quite useful to get started, although I am going a bit deeper in my modeling; I hope to fly very aggressively thus I need the model to be more accurate than what Jacob found, as I can't rely so much on accurate CV/PTAM due to motion blur and time constraints.

In this regard, I made the changes to ardrone_autonomy which fix the configuration bug, allowing more aggressive parameters to be set, and also in #31, added full feedback of drone state, including timestamps on each sensor packet to allow more accurate delay estimation.

Adding this full navdata feedback allows access to (among others) the following parameters:

• navdata_reference.ref_theta (and ref_phi)
• navdata_reference.ref_theta_I (and ref_phi_I)
• navdata_reference.ui_theta (and ui_phi)

Which are the internal control signals that drive the drone's PI controller on Pitch/Roll, as well as the received user input.

• navdata_pwm.vz_ref (the z velocity reference)
• navdata_altitude.altitude_ref
• navdata_pwm.altitude_integral
• navdata_pwm.altitude_der

Which are the factors that drive the drone's PID control on altitude.

The above are my observations from the data, but they may be wrong. Furthermore, there are many many more variables which are returned by the drone and have some influence over the control (see the navdata_references message and navdata_pwm message), but I haven't been able to figure out exactly where they are used.

Using these, I can get a better fit on the drone's dynamics. The next step is to estimate the reference input's influence over these factors to be able to construct a controller....

If you're also looking at dynamics modeling and doing research into aggressive flight, perhaps we can collaborate to some extent? My plan is in any case, to release my results publicly and where appropriate, as ros packages for others to use.

Cheers, Mike

[JakobEngel]

yep, thats me :) I'm actually in the process of releasing my code (from the paper / MSc) as ROS package, I'm just waiting for the ok from my Prof. (will probably release the current version of the code tomorrow, but it requires at least the variable loop_rate change). I already wrote a preliminary wiki entry: http://www.ros.org/wiki/tum_ardrone

I originally wrote all code for my MSc on Windows with the 1.5 SDK (that was like a year ago), which required some heavy SDK-hacking to get the SDK and PTAM up-and-running on windows. It however does not work with the 2.0 drone, and I really didn't want to hack my way through the new SDK version - so wrapping everything into ros and using this package was the best way to go :) Unfortunately, some parts of the code were (and some still are) not particularely clean, as they had to go through two OS-conversions and half a year of frickeling around with them.

Still, might be interesting to collaborate, although i'm definitely more on the CV side, as you said ;) - I'm guessing you are with d'Andrea (talking about vicon and agressive flying)?

Cheers, Jakob

[JakobEngel]

hey, I have finally gotten around to uploading my code, if you are welcome to try it: http://www.ros.org/wiki/tum_ardrone

As it is not compatible with the current master branch (e.g. navdata timestamp bug still exists), I have (for now) uploaded an old, modified version to our github repository (-> https://github.com/tum-vision/ardrone_autonomy.git).

It's basically the Nov 07, 2012 master version, with modified ardrone_driver.cpp and teleop_twist.cpp:

• fixed timestamp bug
• made loop_rate variable
• added non-hover zero command

I'll remove that one and link to this original, as soon as it's compatible and running / tested, I hope that is all right.

Cheers, Jakob

[parcon]

The lab I work in is about a year old and just beginning with the process of modeling the drone. After your meeting we should talk about what work you have left to do before publishing. I'd be surprised if a collaboration could come together before the next block of papers are due, so maybe our advisors should talk. We should be able to find a topic where our work could benefit each other.

It appears that you are working to build a controller about the twist command. Unfortunately the drone has a huge number of parameters and inputs to a seeming complex onboard controller. Have you considered commanding motor speeds via a custom onboard controller?

[mani-monaj]

Thank @JakobEngel for sharing this. What about the dev-unstable branch? Does your code work with that branch?

I will take a look at the diffs and try to make master compatible as soon as possible.

[mani-monaj]

I checked the diffs. And it turns out that the navdata time bug still exists in both master and dev-unstable. In brief:

• fixed timestamp bug
• made loop_rate variable
• added non-hover zero command

I will fix that tomorrow on dev-unstable.

[mikehamer]

@parcon I've seen some people replacing the electronics to get much better control of the drone. I've thought about that, but I'd like to see what is possible with the onboard electronics first.

I've finished a model for the drone. The only major improvements over @JakobEngel's model were fitting a second order controller to Pitch and Roll (which as per parrot documentation, use PI rather than P). Also, I mentioned before that using internal control signals could give a better model fit. This is true, but the improvement over a standard controller (P or PI on error) is small enough that it wasn't worth the extra hassle of tracking these signals. Also, although the craft has complex internal controllers and estimators, which make fitting a nice linear model difficult, the upside is that the measurement data and state estimates sent back from the drone are quite accurate and sent back much faster than control signals are sent out, so a poor model fit isn't too much of an issue here.