I posted the following over on RC groups and thought it would be good to post this here as well.
I have a comment and suggestion regarding the yaw control.
In the ArduCopter code, the code's roll and pitch handling is awesome in stable mode, but the yaw in the way it functions right now is really difficult to fly precisely.
After both flying and looking through the yaw code, I think it could be greatly improved upon with some relatively minor changes.
It seems that as I give rudder input, I am either increasing or decreasing a counter that sets the absolute yaw angle that the quad tries to achieve. If the actual yaw is not keeping up with this counter, if I center the rudder stick, the quad continues to rotate until the yaw matches the requested yaw angle. This causes overshoot and makes it really weird to fly in comparison to a traditional heli with a heading hold gyro.
In a traditional heli with a heading hold gyro, the farther you move the rudder stick from center, you are telling the gyro to rotate the heli at a faster and faster rate, but this has no bearing as to the actual heading. No specific heading is requested. As soon as you center the rudder stick on a traditional heli, the gyro immediately stops rotating the heli and holds the current yaw orientation.
A traditional heli type of yaw control would be MUCH easier to fly in my opinion and would help keep the yaw much more precise than it is now. If when the rudder stick was centered, the quad would immediately save the current heading and lock to this setting, it would be much easier to fly the yaw axis.
I realize that in full autopilot mode (waypoints, etc.) you would still need to be able to request specific yaw compass orientations, but for operator controlled flight, the way it works now is cumbersome.
I certainly don't want to sound like I'm whining because you all do awesome work and this project is exceptional. I just think this would make it even better...
Just my thoughts for the day...
Just a little follow on from Chris's comment. You can check out the ACM code in subversion to see the improved yaw control. In particular if you check out the Attitude.pde's output_yaw_with_hold function you can see it implements both heading hold and rate control depending upon the boolean passed in...
....and then in flight_control.pde's output_manual_yaw function you can see it calls output_yaw_with_hold, passing in true (heading hold) if the yaw channel is zero (i.e. centered), and false (rate contrrol) otherwise.
Just been searching on this issue to try and clean up yaw sloppiness. Can't wait to try this new code version