PID autotuner for velocity loop

[bresch]

Describe problem solved by the proposed pull request
I've never seen anyone tuning the velocity loop. The main reason is that it's really hard to visualize the velocity tracking while flying and it usually "looks okay". After inspecting many log files, I realized that many velocity loops are poorly tuned.

A common practice of the users to "fix" the poorly tuned velocity loops is to modify the parameters of the setpoints such that the handling qualities requirements are fulfilled in most situations (e.g.:a fast-moving setpoint reduces the reaction delay of a poorly tuned loop). The drawback of this approach is that the response does not follow properly the setpoint and that limited dynamics of the setpoint won't be properly applied by the drone (the drone can exceed acceleration and jerk limits in some conditions).

The idea here is to provide a tool to the user to automatically adjust the PID gains of the velocity controller to easily achieve proper tracking.
The method is an improved version of the classical forced oscillation method that automates the tuning of the ultimate gain without introducing too many harmonics (a drawback of the relay-feedback experiment). Once the ultimate gain is found, the ultimate period is measured and the gains are computed using the well known Ziegler-Nichols rules (https://blog.opticontrols.com/archives/131)

Algorithm block diagram:

Additional features:

• A weak P controller is used to prevent the drone drifting too much during the autotuning sequence
• Moving the RC sticks during autotuning immediately switches back to manual position control mode
• The amplitude of the oscillation is bounded

Usage:

• During a calm day, takeoff and hover at around 15m is position mode
• Set MPC_XY_ATUNE to 1 and wait until the tuning finishes
• Adjust the P, I and D gains if needed

You can move the RC sticks at any time to abort the autotuning. To restart autotuning, set the parameter back to 1.

SITL tests:
Left: with parameters after the autotuning
Right: with default parameters

TODO

• Trigger via MAVLink command
• Safety against bad parameters (to discuss: should QGC set the parameters? should it be a way to revert back to the previous set of gains?)

[hamishwillee]

Great description. This could go straight into a blog or release note when the feature delivers.

[bresch]

@PX4/testflights Can you test that PR during a calm (almost no wind) day please?

• With a multicopter, takeoff and hover at around 15m is position mode
• Set MPC_XY_ATUNE to 1 and wait until the tuning finishes (the tuning is done when the drone stops oscillating and that this parameter is reset to 0). This should not take more than 30 seconds.

NOTE the drone will oscillate, this is normal but it should be a controlled oscillation, if this is too extreme, and the drone becomes unstable, simply move the sticks to abort the procedure. You can also switch to stabilized and it will stop.

Also do not forget to save the previous MPC_XY_VEL_[PID] gains as they will be overwritten.

[dannyfpv]

@bresch we are testing this pr and no changes on MPC_XY_VEL_[PID]

tested on pixhawk 4 v5 f-450
3.0 m/s wind

pr log= https://review.px4.io/plot_app?log=534ce58c-5022-4e41-bba0-b874591cd7a0

[jorge789]

Tested on PixRacer V4:

Process:
arm and take off in position the vehicle was positioned at 15 meters high. Change parameter MPC_XY_ATUNE from 0 to 1 the vehicle oscillated 5 seconds and stabilized. After moving the lever and parameter MPC_XY_ATUNE returned from 1 to 0 and landed.

Log:
https://review.px4.io/plot_app?log=cbe5b8ee-2672-496b-8408-c73ed859f440

Tested on Pixhawk 2 Cube V3:

Process:
arm and take off in position the vehicle was positioned at 15 meters high. Change parameter MPC_XY_ATUNE from 0 to 1 the vehicle oscillated 5 seconds and stabilized. After moving the lever and parameter MPC_XY_ATUNE returned from 1 to 0 and landed.

Log:
https://review.px4.io/plot_app?log=537bbf81-91ed-40a6-aa9f-7997018a8ff4

Tested on CUAV+ V5:

Process:
arm and take off in position the vehicle was positioned at 15 meters high. Change parameter MPC_XY_ATUNE from 0 to 1 the vehicle oscillated 5 seconds and stabilized. After moving the lever and parameter MPC_XY_ATUNE returned from 1 to 0 and landed.

Log:
https://review.px4.io/plot_app?log=9ba73064-ce74-462e-8d03-3ff912474698

[bresch]

Unfortunately that didn't work as expected. The learning rate is apparently too fast--the critical gain has been underestimated. I have to find a more appropriate learning rate.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[bresch]

No, this isn't dead, I'm going to work on it at some point

[mzahana]

Great initiative @bresch . I also think the tuning of the outer PID loops such as the transnational states vx/vy/vz/x/y/z are dependent on how well tuned the lower level PID loops (rotational states roll_rate/roll ... etc). So I was wondering if this should be done first? I am personally working on an LQR-based + Genetic Algorithm method for tuning the attitude PID loops using ulog files. Will release once I get a usable version.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[bresch]

I'll continue to work on that after #14212 gets merged.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[bresch]

I'll rebase and continue it now that we have the interface for acceleration input in place!

[LorenzMeier]

Closing as stale, leaving the branch.