Replies to This Discussion

Permalink Reply by James on May 9, 2012 at 8:47am

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" ;)

 

james

 

 

• ▶ Reply

DeveloperPermalink Reply by Randy on May 10, 2012 at 7:01am

James,

     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.

• ▶ Reply

Permalink Reply by Glenn M on May 12, 2012 at 3:33am

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? 

• ▶ Reply

Permalink Reply by Richard on May 12, 2012 at 3:49am

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!

• ▶ Reply

Permalink Reply by James on May 12, 2012 at 4:04pm

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 ..

• ▶ Reply

Permalink Reply by Alex on May 12, 2012 at 4:51pm

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.

• ▶ Reply

DeveloperPermalink Reply by Randy on May 12, 2012 at 11:11pm

Alex,

    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.

• ▶ Reply

Permalink Reply by Glenn M on May 20, 2012 at 10:02pm

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.

• ▶ Reply

DeveloperPermalink Reply by Randy on May 23, 2012 at 7:01am

Glenn,

     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.

• ▶ Reply