AutonomyLab
Unstable during yaw
The new commit makes the stability much better than the previous one, thanks a lot for that! However everytime I give the drone a yaw or throttle command, the drift is way too much to ignore. Roll and Pitch is fine, and hovering is very good now. Of course, I tested the drone in the same configuration with the official apps, and yaw and throttle are both alright then...
So, is there a reason why this could be happening?
That looks like a bug. However, before I can take a look at it, can you please do a couple of tests? Please rosmake --pre-clean for each compile. (Please do each test independently)
-
The easy test is to increase the
cmd_velqueue size inardrone_driver.cppfrom 1 to a big number like 50-100. -
Increase your robot controller loop rate.
-
Please check that, you do not send any kind of [0,0,0,0,0,0]
cmd_velbetween two throttle or turn commands.
Okay I got a few other lab mates of mine to observe the drone as well for surety, and it turns out the problem is not just with yaw, but just any velocity command...
- did that, no changes
- I'm using my own modification of the brown teleop_twist_keyboard (http://code.google.com/p/brown-ros-pkg/downloads/detail?name=teleop_twist_keyboard.tar.bz2&can=2&q=) , so I believe it remembers the previous command until a new one is issued..my modification simply gives independent linear vel. commands in the x y and z axes, and an angular in the z, as compared to the original stack giving a combined linear vel in x and angular in z for sideways motion...
- It can't be doing that because it only gives a Twist command once and maintains it until another is given (using the teleop package)
The hover is very stable, but any velocity command I give makes it go haywire...
Hi Mani,
Anything on this? I can vouch that this problem is not because of either the wind or any other external disturbances...I've made the same test outdoors...while the linear velocity commands are also fairly unstable, the yaw is particularly noticeable...so at least that can be rectified i believe...
perhaps you would like to see a video of this ?
I've been using the driver without such a problem. The link to a video would definitely be helpful.
BTW, the ROS driver will not send a command to a drone if the new command is the same as the previous command. Maybe this is causing the problem, to quickly disable that, add is_changed = true; before this line in teleop_twist.cpp.
Okay changing that really helped the problem! Also, providing higher velocity commands around 1.0 rather than 0.5!
thanks so much for your time!
You are welcome. I reopened this issue, in order to investigate more to check if it is necessary to have is_changed in the loop at all.
That would be great, thank you very much...just to give you some perspective, this problem is not unique to me (https://projects.ardrone.org/boards/1/topics/show/4794) so it seems the problem may come from the SDK itself, or the hardware perhaps!
One of the possible solutions i've found is to set flat trim before take off...although that solution was primarily suggested for the case when the drone veers away along with take off (also happening in my case sometimes), perhaps that could affect this as well..so does your driver flat trim at all?
should I just add a function call to ardrone_set_at_flat_trim in perhaps ardrone_driver.cpp using 1 as the queue number? you don't seem to have used any AT commands yourself so perhaps this is not such a good idea for me too?
I am also having problems with the drone drifting significantly when using keyboard_controller and sending a yaw command. I've flat trimmed and tried the solutions offered above, but did not notice any major changes in performance. I've noticed that this is not a problem when I use the free flight app for iPhone. With the app I can continuously yaw without drift. Is there a difference between the ways autonomy and the free flight app are handling yaw commands?
