vertical climb mode keeps climbing

[EwoudSmeur]

If adaptive throttle is disabled, rotorcraft are very sensitive to the nominal hover throttle in nav climb mode. If the nominal hover throttle is too high, a nav_climb_speed of -1 can result in the drone ascending to infinity.

This is observed in reality as well as in sim. The problem seems to be that there is only a P gain active in addition to the nominal hover throttle...

[flixr]

The difference between using adaptive throttle and fixed nominal hover throttle is only in the feedforward part. Feedback loop is always the same PID loop: https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/rotorcraft/guidance/guidance_v.c#L452

[dewagter]

In climb mode only the D gain is effective + nominal throttle. A large error in nominal throttle requires a large error in climb rate to compensate. That is why all those quads take off so slowly at 1m/s command. On Apr 22, 2016 16:16, "Felix Ruess" notifications@github.com wrote:

The difference between using adaptive throttle and fixed nominal hover throttle is only in the feedforward part. Feedback loop is always the same PID loop: https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/rotorcraft/guidance/guidance_v.c#L452

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/paparazzi/paparazzi/issues/1627#issuecomment-213445077

[flixr]

While the vertical climb control is not ideal, the P and I gains should still be effective as the z position setpoint (guidance_v_z_ref) is also advanced according to the speed setpoint in gv_update_ref_from_zd_sp.

[dewagter]

they are not because https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/rotorcraft/guidance/guidance_v.c#L296 constantly resets the reference model to the current altitude, so while P and I are active, they steer on a zero error and are not effective.

[flixr]

Yes they are, as it doesn't set the z_ref to the current altitude (which is just passed to limit the max distance the z_ref is advanced), see https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/rotorcraft/guidance/guidance_v_ref.c#L132

[flixr]

@EwoudSmeur @dewagter any more insights here?

[dewagter]

If the P and I gains are active while in climbing mode, then I think this issue can be closed, and it should '''just''' be a matter of tuning.

I should still make some calculations. e.g. the normal bebops with the 1 m/s climb rate command do not take-off properly (even with adaptive throttle): they keep bouncing in ground effect for at least 10 seconds before starting to very slowly climb. With a 2.5m/s climb command they instantly start climbing. This is very likely due to an error in nominal_throttle being too low. A higher p/i-gain on altitude should solve this. But the current p-gain is ideal for normal flight though. So for the take-off this is now solved (I should say '''hacked''') by commanding an artificially high climb rate which is never reached (at least not in the flightplans with a deroute when the altitude is sufficient).

Since the altitude error is limited, whenever the GUIDANCE_V_MAX_ERR_Z * P-gain + GUIDANCE_V_MAX_SUM_ERR * I-gain is smaller than the error in nominal_throttle, it keeps climbing/descending infinitely.

-Christophe

[flixr]

It work just like moving the vertical position setpoint at the given speed, if you want a "real" velocity controller it is a different matter...

[dewagter]

BTW: in general I highly prefer integrating the Error * I-gain and limiting this value (which is the trim setting and can be understood) than to integrate the err and limiting this meaningless value to another meaningless bound and multiplying with the gain afterwards.

Here are my calculations to what happens with bebop and outback

I-gain: 13 (bebop)

1 second x 1 meter too low: 512 * (8-bit-frac) = 130 000 130 000 x 13 / 16bit = 25 / PPRZ_MAX = 0.2% throttle.

5 sec 3 meter low = 2 000 000 (GUIDANCE_V_MAX_SUM_ERR) -> 390/9600 = 4% extra throttle

P-gain: 283

Max Err = 10m * (8bit-frac) = 2560

• gain / 7bit -> +/- 58% throttle

1 second after take-off with too low norminal throttle (staying on the ground): 6% extra throttle ( = still on the ground), ...

outback : I-gain = 6 -> max throttle increment = 1.9% P-gain = 75 -> max throttle increment = 15%

=> nominal throttle error of 17% yields infinite climbing, and error of more than 2% yields a steady state altitude error.

[flixr]

BTW: in general I highly prefer integrating the Error * I-gain and limiting this value (which is the trim setting and can be understood) than to integrate the err and limiting this meaningless value to another meaningless bound and multiplying with the gain afterwards.

Yes, that makes more sense in general... feel free to make a pull request for this.

But coming back the original issue: if you disable adaptive throttle (why?) and nominal throttle is set too high, then you get a too high throttle due the feedforward term. This would need to be compensated by the feedback terms.

[flixr]

Also have a look at the vertical reference model and it's parameters: https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/rotorcraft/guidance/guidance_v_ref.c#L50 Default max velocity is 3 m/s, max acceleration 0.8g, maximum distance altitude setpoint is advanced in climb mode is 2m, etc...

[dewagter]

Thank you for the tip: if the reference model is limited is Z_err=2, then that finally explains why it can happen that during climb something keeps climbing while during hover the gains are sufficient as the P-gain has 5x more authority (max-err * gain) in hover than during climb mode.

-Christophe

On Thu, May 19, 2016 at 12:34 PM, Felix Ruess notifications@github.com wrote:

Also have a look at the vertical reference model and it's parameters: https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/rotorcraft/guidance/guidance_v_ref.c#L50 Default max velocity is 3 m/s, max acceleration 0.8g, maximum distance altitude setpoint is advanced in climb mode is 2m, etc...

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/paparazzi/paparazzi/issues/1627#issuecomment-220287741

[flixr]

I guess we should set the default MAX_Z_DIFF to 10m as well...

[flixr]

any new updates/insights here?

[dewagter]

The behavior is now understood, so for me this can be closed. A small improvement could be to set the same limit for the control and the reference model, which would cause climb to behave more like the hover.

-Christophe

On Tue, Jun 14, 2016 at 9:15 PM, Felix Ruess notifications@github.com wrote:

any new updates/insights here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/paparazzi/paparazzi/issues/1627#issuecomment-225986848, or mute the thread https://github.com/notifications/unsubscribe/AAd6fF-VbjAi_51uQ-XXzlQ2REdkA7mXks5qLv3ogaJpZM4INfuK .

[flixr]

currently we have the defaults:

• GUIDANCE_V_REF_MAX_Z_DIFF at 2m: maximum distance altitude setpoint is advanced in climb mode
• GUIDANCE_V_MAX_ERR_Z at 10m

So set both to 10m or some other value?

[dewagter]

can you

define GUIDANCE_V_REF_MAX_Z_DIFF GUIDANCE_V_MAX_ERR_Z

?

-Christophe

On Wed, Jun 15, 2016 at 11:41 AM, Felix Ruess notifications@github.com wrote:

currently we have the defaults:

• GUIDANCE_V_REF_MAX_Z_DIFF at 2m: maximum distance altitude setpoint is advanced in climb mode
• GUIDANCE_V_MAX_ERR_Z at 10m

So set both to 10m or some other value?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/paparazzi/paparazzi/issues/1627#issuecomment-226138556, or mute the thread https://github.com/notifications/unsubscribe/AAd6fNrY8qYLyl0QDrL7SIbGQWfI1C-Kks5qL8jCgaJpZM4INfuK .

[flixr]

no, we could only make GUIDANCE_V_MAX_ERR_Z and GUIDANCE_V_MIN_ERR_Z default to +-GUIDANCE_V_REF_MAX_Z_DIFF