this is an issue ive had since my first flights with v2.1, and has stuck with me through versions 2.2, 2.3, and is exactly(?) the same now in v2.5
on yawing, if i am very very careful to ease the stick back to centre i can make it pull smoothly out of a turn, but if i snap the stick back to centre it stops turning pretty much straight away and then rebounds back about 15 or 20º.
with my very limited experience of PID tuning i can recognise this as simple overshoot in the control loop, but while im making good progress tuning the pitch and roll, i cant see any significant change when adjusting YAW RATE values.
these YAW values arent particularly better or worse than others ive tried, theyre just the latest thing ive flown with. has anybody else solved this problem, any clues about where to start? are my YAW P values simply way too high?
oh come on .. this behaviour has been present at least since v2.0.37 (http://diydrones.com/forum/topics/question-regarding-yaw-and-pid)
somebody must have something to say about this, even if its just "thats how it works, deal with it" ;)
The rebound is caused by I term build up on the outter heading controller. So the way yaw control works is it has an outter heading controller that takes the heading and determines a desired rate of rotation. This desired rate is then pushed into a rate controller. The rate controller takes the desired rate and compares it to the actual rate and adjusts the speed of the motors.
So the problem is that in our yaw control, when the pilot pushes the yaw stick full left (for example)..what we do is we simply tell the outter yaw controller, "hey, i want to face 45 degrees more to the left" and we just repeat that message over and over until the pilot returns the stick to the middle position.
The problem with this is that the I term builds up on the outter controller and this leads to the overshoot (I think). What we should do is instead temporarily pass the pilot commands straight to the rate controller. If we tell the rate controller, spin at 45 deg/sec (or whatever) no I term will build up because it will be able to maintain that rate happily.
I get the same behaviour on my tri.
Is the outer controller I term controlled by STB_YAW_I?, so would setting it to 0 eliminate this problem, or is this something else?
That feels odd to me - is there any particular reason the pilot control works that way?
From how you've described it, I understand the "outer heading controller" to be intended for 'absolute' control of heading, used for RTL, waypoints etc.
Surely the pilot yaw command has no reason to utilise the outer heading controller in the first place, as this stick is generally understood as a 'rate' rather than 'absolute' control? (I've yet to see a remote with a 360deg yaw encoder...)
When entering the pilot zero deadband the outer controller would then be enabled with "required heading = current heading", and would then hold heading as usual.
I've no experience of this kind of control code though (I'm used to absolute position control of robots) so quite prepared to be shot down!
sounds like a very good idea to me, (ill stand over there with you, in case we both have to be shot down).
as you say, from an auto point of view it makes perfect sense to use the outer yaw controller, the autopilot jumps straight to a new heading and needs this loop to perform a smooth transition. in stabilize pitch and roll are the same, we send a new stick position that could be the full throw from the last value read and we need the outer loop to transition to this new attitude with the rate loop following.
then, *as i understand it*, the other thing the outer loops do is compensate for error, maintaining for example a constant offset in roll to compensate an off centre CG. this is the "i term", not the same as the I value in the PID loops. i wonder if perhaps the need for the outer yaw loop would be to counter torque inbalance between CW and CCW motors?
perhaps ill try setting yaw IMAX to zero and see what effect it has, i might even fly in rate mode to see how it handles with the control that step closer to "real" manual. in theory the idea of releasing the heading hold when yaw input is detected and reengaging when the stick comes back to centre sounds great, but i know the nested loops are there for something even if i cant picture clearly exactly what theyre doing ..
I've been flying my tricopter with APM2 for 1 day now so I'm hardly knowledgeable enough to comment, but I'm flying in ACRO mode for now and I'm unable to tune it for fast yaw response without overshoot. My previous KK board had great yaw response with no overshoot on the same airframe so I know it's possible.
BTW thanks for the hard work dev team.
I've been looking at the control code a lot recently as part of a bit of refactoring I'm planning to do shortly.
...and Acro yaw is actually implemented with the stabilize (i.e. heading hold) yaw! So it's not too surprising that you're still seeing overshoot! It sounds crazy but I'm sure there was a reason it was done that way originally but I think we can sort that out eventually (perhaps after the refactoring) so that acro yaw becomes a real acro yaw.
@James & Richard,
Richards description of how it should work (i.e. heading hold engages when the pilot's stick is in the deadband) is exactly how it should work. We will make it work that way.
Thanks for looking into this. Is this something you need someone to test? I'd be happy to spend some time giving some modified code a go if it'll help to sort this problem out.
I've been spending most of my time on a reachitecting of the control code..but I'm planning to take another look at yaw shortly. Maybe by the end of this weekend I'll have something ...if all goes well.