Flight - Yaw 'bounce back' PID controller 3

[ctzsnooze]

A number of people have now reported this in detail on rcgroups for PID controller 3 in acro mode. By bounce back I mean:

• the user does a hard yaw, say 180 or 360 degrees
• the quad yaws normally;
• the user then quickly brings the yaw stick back to centre
• the quad stops quickly, but then gently and slowly (say over 1/2-1s) yaws in the reverse direction (to an amount that seems to depend on the cumulative amount of yaw) and then stabilises

It seems to happen in cleanflight more than multiwii controllers. It seems resistant to changing P or I up or down. In my case (well balanced acro X-quad mostly flown LOS) it is subtle - but as soon as I went to FPV using cleanflight it was obvious, then looking closely in LOS I could see it for sure.

I don't know the cause but feel that there must be something someplace in cleanflight contributing to it.

I will experiment with P and I settings but I've never had this issue with default P or I for yaw.

I know hydra is aware of the issue just thought it should be a formal item here.

C

[thenickdude]

Nothing will get diagnosed without Blackbox logs, so anyone who has one, please chime in.

[ctzsnooze]

My apologies, I don't have logging functionality so I can't assist. Happy to test any speculative code mods - can compile from source without drama.

[nebbian]

Is it different when you yaw right vs yawing left?

[rscarawa]

I am having yaw issues as well and not sure it is the same thing. When the mag is off and I do a 360 rotation to the left, it over shoots by 180 degrees and slowly comes back to where I centered the stick. When I do the same maneuver to the right, it overshoots by 45 degrees and snaps back quickly to where I let go of the stick. This behavior is the ssame in base flight as well as pidcontroller 3 and 5 in clean flight. I have not tested all possible combiniations of pid controllers. If the magnetometer is on, then the problem goes away and the over shoot is about 45 degrees regardless of rotation. After 45 degrees of overshoot it comes back to where I centered the yaw stick quickly.

Hardware is Naze32 full.

Is this similar to the problem you are having?

I have a 500kb black box log of the issue. WHere would I attach this log? It seems only png, gif, and jpg are supported.

[MJ666]

I can see that behavior on small brushed multicopters. To get an idea about the size:

http://www.multiwii.com/forum/viewtopic.php?f=12&t=4893

Using Quad, Hexa and Octocopters. Al off them have very similar settings. The issue can not be seen at the Quad, as more rotors I get as stronger this effect will get. unfortunately we have no logging possibilities in the small FC's we are using. We also don't have a magnetometer. Have never seen this on my larger quadcopters. looks to be the effect is very minor in CW yaw direction and stronger in CCW yaw direction.

I already did a loot of experimenting even with modified code but never found the reason for this behavior. There was some discussion recently in the RCG forum. There was also an test build published but there is no real feedback regarding the results yet. Looks to be the line here is influencing the behavior but does not fix it completely:

https://github.com/cleanflight/cleanflight/blob/master/src/main/flight/mixer.c#L570

I need to compare this again side by side to be more sure.

@rscarawa If you have an Rev 5 Naze and using an resent version of CF you can do some BlackBox logging to the internal SPI flash. May be this will give some new ideas where this effect comes from.

We mainly use PID3 and PID5. It looks to be the issue is effecting PID5 more than PID3. I will also give PID2 a try next days.

[rscarawa]

Mj666 I have a log set on my machine. I am not sure how to upload the log to github for examination or how to read the log myself. I See how to upload load pics. Can you tell me how to up load it or do I need software to build a graph of the log first? On Apr 13, 2015 4:29 AM, "MJ666" notifications@github.com wrote:

I can see that behavior on small brushed multicopters. To get an idea about the size:

http://www.multiwii.com/forum/viewtopic.php?f=12&t=4893

Using Quad, Hexa and Octocopters. Al off them have very similar settings. The issue can not be seen at the Quad, as more rotors I get as stronger this effect will get. unfortunately we have no logging possibilities in the small FC's we are using. Have never seen this on my larger quadcopters. looks to be the effect is very minor in CW yaw direction and stronger in CCW yaw direction.

I already did a loot of experimenting even with modified code but never found the reason for this behavior. There was some discussion recently in the RCG forum. There was also an test build published but there is no real feedback regarding the results yet. Looks to be the line here is influencing the behavior but does not fix it completely:

https://github.com/cleanflight/cleanflight/blob/master/src/main/flight/mixer.c#L570

I need to compare this again side by side to be more sure.

@rscarawa https://github.com/rscarawa If you have an Rev 5 Naze and using an resent version of CF you can do some BlackBox logging to the internal SPI flash. May be this will give some new ideas where this effect comes from.

— Reply to this email directly or view it on GitHub https://github.com/cleanflight/cleanflight/issues/741#issuecomment-92269280 .

[MJ666]

I don't have any experience how to analyze the BlackBox recordings. Likely @thenickdude can be more helpful here

[thenickdude]

@rscarawa, you might sign up for a Dropbox account and put it there? Or https://mega.co.nz/ . I don't know of any other good services for sharing those log files.

I think you can also rename the log to have a .jpg extension and drag and drop it onto a comment here as a fake "image" (to trick GitHub into hosting it).

[ledvinap]

google drive works too ...

[rscarawa]

I have drop box. Will send it there shortly. On Apr 13, 2015 8:51 AM, "Petr Ledvina" notifications@github.com wrote:

google drive works too ...

— Reply to this email directly or view it on GitHub https://github.com/cleanflight/cleanflight/issues/741#issuecomment-92341190 .

[rscarawa]

https://www.dropbox.com/sh/fsnzo2exea2xkts/AABLwDetdozoGTgjju2SW-8Ta?dl=0

I have a backup file of the FC and the blackbox log for 1 min of flight.

[ledvinap]

Hmm ... seems that yaw jump limit is main problem - https://github.com/cleanflight/cleanflight/blob/4154afcb63faa5eedf1e82148419b018b7591315/src/main/flight/mixer.c#L570:

axisPID[YAW] = constrain(axisPID[YAW], -100 - ABS(rcCommand[YAW]), +100 + ABS(rcCommand[YAW]));

When stick is returned to center, rcCommand(YAW) is almost zero, so constrain will limit axisPID[YAW] to +-100. Yaw PID I term will saturate quickly and cause large overshoot ...

[rscarawa]

Is this a defect of a config problem on my side?

Also, how does that compare to the code for yaw control with the mag turned on? I do not have the problem nearly as bad when the mag is enabled.

[ledvinap]

[MJ666]

This is the line I also have commented out for my testing. The removal looks to have an positive effect but does not solve problem completely. I still need to double check and do an side by side testing. Please see my comment more early.

[ledvinap]

@rscarawa : You can reduce YAW I-term, but the it won't probably 'feel' right.

Your quad is a bit unbalanced with respect to yaw - one pair of motors must run a bit faster to prevent rotation around Z axis (nonzero I term in stable state). This is probably causing different right-left overshoot, but it's probably not worth fixing now (unless your motors are tilted a bit)

[rscarawa]

If I reduce I, should I reduce the floating I or the Integer I?

I do not have tilted motors. Why would the quad be unbalanced with respect to yaw? Is there something I should do to correct this? WHy would I not have the issue with the mag on?

[rscarawa]

WOuld this be an issue with fore and aft balance that would cause this?

[ledvinap]

@mj666 : It's hard to tell without blackbox log. Just guessing, but the problem PID I term will cause windup even when YAW jump limiting is disabled (reaction to YAW command is slow on quad, so I term must accumulate). Some of windup prevention methods should be applied ...

BTW: Resetting I-term on stick command is causing asymmetry on unbalanced quad. Maybe some slow integrator may be added to balance quad instead of I term

[ledvinap]

@rscarawa : Don't worry about it, it's probably normal on most quads. IMO COG position should not cause this as long as one of fore/aft or left/right direction is balanced (two motors with opposite directions have to speed up). In linear case this should mean that COG position does not affect yaw.

[rscarawa]

ok. SO is this something that needs to be worked out in the code or should I adjust 'I' down as the fix?

Thx

Scot

[MJ666]

We may need to think about how we can implement BackBox logging into our FC. Unfortunately the serial pins are not exposed and need to be picked up directly at the STM chip. Also the SPI pins are already used (at least partially) and also not exposed. The problems which are described here is exactly what we also can see. Another strange effect I also have seen a couple of times if the copter is getting an strong external impulse in yaw direction (i.e. hitting something during flight) it may starts rotation quite fast and does not stop again. In this case you need to bring it down to stop it. not sure if this is related. Yaw in general does not have a strong resistance against moving out of position like roll and pitch if you hold the copter in hand. I also can ne feel it tries to turn back. I completely agree tis is also depending on the PID settings but I experimented with lots of P and I values. Only D I always have left on 0. I think if I is turned down you will still have an overshoot? My copters are quite symmetrical but I still see a big difference between CW and CCW yaw behavior. The direction is always the same between for multiple different copters. CCW the effect is always stronger. So likely its not the hardware like a bad motor.

[ledvinap]

YAW I term is constrained twice (plus yaw jump prevetion):

https://github.com/cleanflight/cleanflight/blob/master/src/main/flight/pid.c#L391 :

errorGyroI[FD_YAW]  = constrain(errorGyroI[FD_YAW], 2 - ((int32_t)1 << 28), -2 + ((int32_t)1 << 28));
ITerm = constrain((int16_t)(errorGyroI[FD_YAW] >> 13), -GYRO_I_MAX, +GYRO_I_MAX);

That means that there are 28 - log2(GYRO_I_MAX) - 13 = 7 bits of hidden I accumulator ...

[ledvinap]

Here is detail with gyro included:

P-term is acting against I-term, so only small action results ...

[rscarawa]

I will drop 'I' back to see if it improves. Are you seeing equal effect for left yaw vs right?

[ledvinap]

@rscarawa : With MAG mode on, there is another control loop that keeps heading in direction when yaw stick was released. This will compensate (relatively small) PID command.

[ledvinap]

Maybe limiting https://github.com/cleanflight/cleanflight/blob/master/src/main/flight/pid.c#L391 will provide reasonable results:

 errorGyroI[FD_YAW]  = constrain(errorGyroI[FD_YAW], -GYRO_I_MAX<<13, GYRO_I_MAX<<13);

[thenickdude]

Agreed, Petr.

Another thought I had is that the yaw's accumulated error term needs assistance to decay faster when the instantaneous error is very different from it. Perhaps the line where the instantaneous error is added to the accumulated error could be changed into a weighted sum, favouring the instantaneous error? This would improve I term decay speed.

[rscarawa]

Uploaded new blackbox logs with I=0 on Yaw. I still got the over rotation but no correction back to where I centered the stick. Should I be increasing I for yaw? What tool are you using to read the log?

https://www.dropbox.com/sh/fsnzo2exea2xkts/AABLwDetdozoGTgjju2SW-8Ta?dl=0

[ledvinap]

@thenickdude : There is lot of literature on handling I-term windup on systems with saturation, literature research is probably better that reinventing wheel ...

The ideal integrator may be necessary to reject disturbances (integral of gyro rate is heading ...). What will happen to disturbance rejection if the integrator is leaky?

It would be great to have some model and simulator to easily check similar ideas ...

Is is probably best to keep control linear if possible and intervene only when saturation is causing problems.

[ledvinap]

@rscarawa , here is part on new log:

It does take some time to stop yaw rotation, but over 2 seconds is very long ... yaw jump prevention code is main problem here

see gyro trace when stick is released, but still nonzero - the decrease is fast. Then limiting kicks in and the decrease is much slower. PID command is saturated here (300 limit in code)

Also it seems that without I term, the quad is slowly rotating (as expected)

You can try increasing I a bit, but overshoot will appear quickly. Or just wait, at least partial fix should be ready soon.

[rscarawa]

Do you need any more testing from me or do we think we know the solution requirements?

[thenickdude]

Maybe the yaw jump limit should be configurable on the CLI.

[rscarawa]

I would love to test out a change like that. If you remove or lower the yaw jump variable, will that lead to odd yaw headshake when initially applying yaw? I had seen some odd yaw movement when I had the yaw rate really cranked up. I guess we will look at this one problem at a time.

[MJ666]

I was already flying an firmware with the yaw jump prevention completely removed. Have not seen any strange behaviour in flying but i also have not done real advanced flying. Only hovering, fly some laps and piroetts. There was also one test version published for the Naze in the RCG forum about two to three weeks ago. I have now prepared two nearly identical Octocopters an will continue test them side by side. One is standard firmware and the oter has the yaw jump prevention removed.

[nebbian]

It seems to me that it's the P term that is the limiting factor here. It's hitting a ceiling at about 250, which is preventing a fast stop. If it were me I'd lower I, and look at what is limiting P. I've been frustrated at the yaw performance after large yaw movements on my A tail as well, it just doesn't seem as snappy as it could be. Small movements work really well and stop on a dime, but large movements seem to not stop as quickly.

[nebbian]

Also, yaw jump can be completely eliminated by using ESCs that support braking (KISS or BLHeli with damped light enabled). Using angled motors helps a lot here as well. Limiting values to prevent yaw jump in inefficient setups should be an option, not something that's enabled for all users imho.

[ledvinap]

It will be interesting to get blackbox with yaw jump happening. IMO these are possible sources of yaw jump:

• motor thrust nonlinearity (motor thrust dependence on voltage is u^(4/3) (?)). Linearly increasing one motor command and decreasing another by same amount will increase total thrust.
• motor limiting - if yaw command is too large, slowed motor can't go below zero

Does anyone know why yaw rate is limited by stick deflection? This seems like hack for some concrete problem ...

Even with yaw rate limiting removed, the overshoot won't be fixed. Something needs to be done with I term windup..

@nebbian:

#define GYRO_P_MAX 300
#define GYRO_I_MAX 256

Maybe two ways to fix yaw jump got applied when porting code from other FCs ...

Large movement problem is probably caused by https://github.com/cleanflight/cleanflight/blob/master/src/main/flight/mixer.c#L570. Try pushing the stick to opposite direction, the stop should be much faster ...

As for ESC with braking - did you test it? It can help a bit, but it's effect shall be quite small (unless motor inertia is transferred to frame and acts to stop it)

[ledvinap]

@rscarawa : can you test this version: https://github.com/ledvinap/cleanflight/tree/test-yaw/obj Just removed yaw jump prevention and limited I term more.

[MJ666]

I was flying the Octo with yaw jump prevention removed. Unfortunately the Octo prepared with the standard firmware was not working since I had not properly configured it and could not fix it in the field. will try to test tomorrow again.

There is still some overshoot of about 5-10 degrees but the large overshoot with turning back is gone. So the overshoot is about the same in both directions and is not increasing if you make multiple continuous turns. With the original code the overshoot and bounce back was some kind if unpredictable and likely depending from the speed you and amount you are yawing. So the Octo is flying much better now even with larger yaw movements. The behavior with PID3 is a bit better than with PID5. I have not seen any negative effect during flight with the remove yaw jump prevention.

Also was flying an Hexa with standard firmware to compare and here the effect could be seen but its very minor and usually will not really affect normal flying. You can force to see it more with doing multiple yaw rotations.

[rscarawa]

I see the hex code. I see code fire naze and nazepro. Which would i need? I am also unclear on how to use these files. Do I just swap one hex file for another on a released package or do I have to do a full build of all of these files? Forgive me, I am not a coder.

[MJ666]

Taking into account you have an standard Naze FC. You should download the cleanflight_NAZE.hex file and flash as usual with the CF configurator. Only difference is using "Load Firmware (local)" button and referencing the downloaded file.

[rscarawa]

I went to github and printed the file out in raw mode. Then I did a copy paste into note pad and renamed the file to have a .hex suffix. Will this be suitable for loading using the configurator?

[rscarawa]

I guess the problem is I see no file to download. WHen I click on the file, it opens it up for display. I am a windows xp user so maybe the option of doing a straight download is not available for me.

[rscarawa]

Never mind. I did a 'save link as' and that might have done it. thx.

[rscarawa]

"Save link as" seems to create a file that cleanflight sees as corrupt. The copy paste method seems to work. I have used it to flash the FC. Now I have to reload my settings in. I guess I cannot restore my previous settings for this test version of the firmware? Hope to test later today of the rain holds off.

[MJ666]

If you have unchecked "Full Flash Erase" during flashing you could check your configuration and it should be still there if it is compatible (if your previous firmware was not to old). Otherwise it will reload defaults and you need to reconfigure. The change done for the test build will not require a different configuration the standard build of the same level.

BTW: If you right click to the cleanfligth_NAZE.hex file you should get something like "Save target as".

[rscarawa]

I unchecked "Full Chip Erase" and it lost my old config anyway. I was on 1.8.1 and the test build is 1.9.0.

[ledvinap]

The changes are based on master .. I can rebase them if necessary ..

To download hex right-click 'raw' button and choose 'save as ...' from context menu

[rscarawa]

1.9.0 is improved for sure. Yaw feels much more locked when I unload the stick regardless of whether it is left yaw or right.

https://www.dropbox.com/sh/p5yo99t6z7g6rjj/AACLolr6pAkCGEKGfMtHmARUa?dl=0

One thing I notice about doing hard yaw moves, on this and previous versions is I seem to gain altitude. I am not sure if that is something that I am doing or not. Maybe you can see if there is correlation between vertical movement (up) and increasing throttle either while adding yaw or bringing it back to center.

Thank you for your help.