I have been experimenting with QAUTOTUNE on the 4.1 release of ArduPlane which generally leads to poor results.
The aircraft is similar to an X8 Tri-tiltrotor and the test bed in SITL on XPlane 11. After several hours with QAUTOTUNE fails, I decided to trust my own intuition to tweak the PIDs and managed to achieve stable hovers and transitions.
Then I decided to check if QAUTOTUNE could improve things a little more using my healthy starting point. Roll check, Pitch check and Yaw check - Ardupliot confirmed successful completion of the QAUTOTUNE. When I took the controls back on the joystick I realized the aircraft was again in a poor state with a lot of oscillations in pitch, roll and Yaw!
What should I take away from all this? I take that QAUTOTUNE works fine for several people with varying aircraft designs.
Are there any aircraft design conditions that prohibit QAUTOTUNE from doing its job? In retrospect, the new AUTO TUNE for conventional flight works perfectly… I am a little puzzled.
Trust me, the interface works quite well. Perhaps the low bandwidth forces conservative PID values, but I would think that QAUTOTUNE algorithm would still adapt treating the aircraft and the bandwidth limit as a black box.
Because of the slow update rate between XPlane and SITL AP has to do smoothing on the attitude/position state. QAUTOTUNE giving step inputs and looking at the response. The smoothing smooths the result of the step input so QAUTOTUNE does not see a true response.
Yes, but shouldn’t QAUTOTUNE fail rather than report that the parameters were built with success? I think there is a missing check somewhere in the algorithm…or the comm frequently between XPLANE and Ardupilot fluctuates wildly.
quadplane defaults to 300Hz. With xplane we rarely get over 50Hz, and often less. So nearly all IMU data is extrapolated. This can work well for flying, but completely fails with VTOL autotune as it relies on the fine detail of gyro response.