Auto-tuning procedure behaves unexpectedly

[kaklik]

There are two related issues with autotuning mode, both are replicable with the same procedure. The first one is there is no Vehicle setup > PID Tuning option for fixed-wing based airframe in the QGC. This seems to be replicable by multiple users.

The second issue is the Auto-tuning procedure fails silently into an unstable controller setup.

To Reproduce
Generally follow the Auto-tuning guide for the fixed-wing airframe.

1. Takeoff sufficiently pre-tuned the TF-G2 autogyro or another real airframe with the fixed-wing controller, which is at the edge of the mathematical model used by the autotuning algorithm.
2. Set position hold to the large enough area
3. Run the Auto-tuning procedure (By setting FW_AT_START = 1 because Vehicle setup > PID Tuning is not available in QGC. to See screenshots below)
4. Waits several minutes and observe the behavior
5. The FW_AT_START should be silently restored to 0 and controller parameters are changed. The vehicle oscillates significantly during the flight. There is no easy option to land safely or restore the previous sufficiently tunned parameters.

Expected behavior

The QGC Vehicle setup > PID Tuning tab which is mentioned in the Auto-tuning guide should be visible.

Instead of setting the incorrect controller parameters, the tuning procedure should either exit with an error or set improved controller parameters. There also should be a "fallback option" to manually restore the original parameters in case if something goes wrong.

Log Files and Screenshots

The complete logfile from the flight is available here

QGroundControl with missing PID tuning option:

[bresch]

@kaklik Thanks for your feedback, I'm having a look at the log

[bresch]

The reason why the identification doesn't work properly on the auto-gyro is that the actual delay is really lage (>0.1s). The RLS then tries to fit a model and obtains something with a much smaller amplitude because of this. I'll try to replay this log and see if we can obtain something better using a larger delay parameter.

Regarding the reason why the auto-tuner didn't detect the bad tuning is that the energy of the control signal was too small for the threshold because of the oscillation is rather slow (period ~= 1s). We should add something to detect this problem as well.

There also should be a "fallback option" to manually restore the original parameters in case if something goes wrong.

I totally agree with that.

[kaklik]

We should add something to detect this problem as well.

Perfect! I am not a control engineer, therefore I do not have the capability to resolve that. But I am willing to test something which could help to improve the solution. :)

[kaklik]

There also should be a "fallback option" to manually restore the original parameters in case if something goes wrong.

I totally agree with that.

Regarding "manual fallback", I think that a sufficient solution should be a notification of the end of the tuning procedure with delayed possibility to abort the procedure by moving RC joysticks.
That could be very similar to the current solution "The sequence can be aborted at any time by the operator by moving the roll/pitch stick on the RC controller", but QCG should display information about the end of the tuning process. Then the tuning process waits for several seconds more, if the operator does not cancel the new parameters set up by moving the sticks.
If there will be the changed parameters displayed in the message, the manual resetting of the touched parameters in QGC could be also possible using the Parameters setup option in QGC.