cmd_vel is acceleration in x and y, velocity in z's

[kbogert]

The documentation for the velocity command is very wrong. After working with the drones for the past week and going through Parrot's ardronelib, here's what I have found about cmd_vel:

linear.x - percentage of maximum tilt angle forward to backward (1 to -1)
linear.y - percentage of maximum tilt angle left to right (1 to -1) 
linear.z - velocity of altitude in meters / second (parrot's docs are wrong)
angular.z - velocity of yaw in ~95 degrees / second

This means that x and y are force parameters, not velocity. They can be approximately related to acceleration using the following formula which makes use of the assumption that the drone tries to maintain the same altitude for all orientations it might be in:

accelX = tan (linear.x * maxTiltAngleX) * G
accelY = tan (linear.y * maxTiltAngleY) * G

so

linear.(x or y) = ( atan ( accel / G ) ) / maxTiltAngle

where G is 9.8ms^2, and the max tilt angles are parameters for ardrone_autonomy.

See the file ARDroneLib/Soft/Common/ardrone_api.h starting at lines 697 for the documentation of ardrone_at_set_progress_cmd

 * @param phi Left/right angle between -1 to +1 - negative values bend leftward.
 * @param roll Front/back angle between -1 to +1 - negative values bend forward.
 * @param gaz Vertical speed - negative values make the drone go down.
 * @param yaw Angular speed - negative values make the drone spin left.
 * @param magneto_psi floating value between -1 to +1.
 * @param magneto_psi_accuracy floating value between -1 to +1
 * This function allows the client program to control the drone by giving it a front/back
 * and left/right bending order, a vertical speed order, and a rotation order.
 * All values are given as a percentage of the maximum bending angles (in degrees),
 * vertical speed (in millimeters per second) and angular speed (in degrees per second).

[mani-monaj]

@kbogert Thank you very much for sharing that. I will check those in detail and update the docs in next release.

[kbogert]

I wonder if it's possible to do better than just update the docs, at the very least raising the limits on the z's to match ardronelib's. I suppose a PID controller could convert the given x & y velocity commands into desired angles with updates provided by the drone's navdata.

ardrone_autonomy already has an internal loop separate from the receiving callbacks, so I don't think there will be too many technical issues with doing this. It would, however, break everything that currently depends on ardrone_autonomy.

Thoughts?

[adamantivm]

+1 for a PID controller to achieve a desired speed

[raultron]

Hi! Is somebody working in the PID Controller? I need to implement exactly that for my project and it will be nice if I collaborate with this repo. How can I help?.

Bests

[baryn]

Hi @raultron,

For your PID you could set the error as the difference between your desired linear velocity and the estimated velocity from the drone itself. Then, by setting your P,I and D terms properly you would be able compute an output defined as the pitch (for the velocity along x axis) and the roll (for the velocity along y axis). Indeed, there is a relation between these parameters, a quadrotor cannot translate without tilting. Remember, the output and the input of a PID can have a different unit.

Hope it helps

[raultron]

Hi Baryn,

Thank you very much for your input, but I was asking more about how may I contribute with this repository. Should I branch the repo and then ask for a pull request? I have never done that before. Also I would like to know if its better to add this controller as a separate node or if I should edit one of the source files of the project to add the controller. Right now I am testing the PID controller as a separate package without modifying ardrone autonomy to see if everything works, but I think it will be nice to integrate that into ardrone autonomy.

Bests!

[mani-monaj]

@raultron

IMO it's better to keep the PID controller example in a separate package. I can add a reference to that repository in the documentation so other users can find it more easily.

[raultron]

Yes I think you are right. I am already working in a separate package. I am having problems tuning the controller though and I think it is related to the delays. Anybody knows the delay for commands and measurements due to wifi and the internal processing in the Ar.Drone?, or do you have any ideas how can I measure them?.

[kbogert]

Yes, see page six of this paper https://vision.in.tum.de/_media/spezial/bib/engel14ras.pdf

The tum_ardrone project has a complete PID implementation based on the state provided by an EKF filter if you need a reference.

[raultron]

Thanks for this paper kbogert.

Just want to add that for the PID controller I am working with the velocities from the topic /ardrone/odometry and I was having the problem that the callback was executing at 25hz even when ardrone_autonomy publishes the messages at 200hz. I discovered that the problem was related to this bug:

https://github.com/ros/ros_comm/issues/560

Maybe it is possible to put a warning in the readme for anybody that uses odometry messages.

[mprannoy]

Has it been confirmed that the x and y are force parameters, not velocity? Has it been updated in the release? @mani-monaj