The ArduPilot QuadPlane code now supports autotune for the VTOL controller PIDs. This uses the same system as the AUTOTUNE mode for copter. It should allow you to improve the tune without having to manually adjust PIDs.
This is still considered experimental so we would like some users to test it and see how well it performs. If you try it then please post logs below, and also describe how the flight performance of the aircraft in Q modes changes after performing the tune.
To try it out, load the latest plane firmware on your quadplane. If using MissionPlanner then use control-Q in the firmware load screen to access the latest firmware. Otherwise download an apj file from here: http://firmware.ardupilot.org/Plane/latest/
To enable QAUTOTUNE do the following:
load the new firmware
setup QAUTOTUNE mode (mode 22) on one of your mode switch positions. It may not show up as an available mode in your GCS, so you may need to set the FLTMODEn parameter in the full parameter list
select which axes you want to tune with Q_AUTOTUNE_AXES. As an autotune can take quite a long time (3 to 5 minutes per axis is common) you may wish to tune one axis at a time.
choose whether you want position hold support while tuning. If you enter QAUTOTUNE mode from QLOITER then it will use a loose position hold, preventing wind from carrying it away while tuning. If you start from QHOVER then it will not hold position, and you may need to reposition while tuning
it will only do tuning (“twitching” to measure responses) while the sticks are centered. You may need to increase the deadzone on your input channels or re-calibrate your RC channels to ensure it can start the tune.
once you start the tune it will “twitch” on the axis it is tuning. So if it is tuning roll then it does small sharp roll movements to measure response.
you can tell that QAUTOTUNE has finished when it stops twitching. You need to then land while staying in QAUTOTUNE mode and disarm without changing modes to save the tune.
if you land in QAUTOTUNE and disarm after some axes have completed but the whole tune is not complete then the PIDs for the axes that have completed will be saved
you can reposition while tuning by moving your sticks. Once you re-center the sticks the tune will continue
if you change modes then the tune stops immediately
NOTE: QAUTOTUNE does not work on axes that need feed-forward. This means it doesn’t work on the pitch axis in tailsitters. If you want to QAUTOTUNE a tailsitter then make sure the pitch axis is disabled by setting Q_AUTOTUNE_AXES=5. If you do use QAUTOTUNE on the pitch axis of a tailsitter then you will end up with a very bad (completely unflyable) tune.
Many thanks to Nikhil Upadhye for the QAUTOTUNE support, and to @pompecukor for testing it. You can see the ARACE QuadPlane that @pompecukor flew in the linked demo video above.
What do you mean “does not work on axes that need feed-forward”?
Is this strictly for a QuadPlane?(4 motors)
Can it work on a Tilting Tri-copter such as the Foxtech Nimbus?
The pitch axis of tailsitters relies on feed-forward to operate correctly, using Q_A_RAT_PIT_FF values greater than zero. The autotune is not able to handle that correctly.
I believe it will work well for tilting tri-copters, but it hasn’t been tried yet. If you can try it and post logs that would be appreciated.
Cheers, Tridge
@tridge super stoked to give this a try! Is there an aggressiveness like with the copter autotune? I didn’t see you mention it. If so, what level of aggressiveness was the bird in the video done with?
As I mentioned in the notes above, QAUTOTUNE may not be in the mode list yet. You need to use the full parameter list and add mode 22 to one of your FLTMODEn parameters.
Thanx man! I thought I should look for QAUTOTUNE in the full params list. I just typed in 22 and wrote the params like that. In flight modes it only shows blank. Will take off in QLOITER and switch to that mode and let you know what happens.
This is my non vectored tailsitter
I set qautotuneaxe to 5 and other parameters default. The autotune work as intended. I can see some improvements of the hover flight. I tested transition and FW flight after the tune was completed and everything worked as expected. Again a good job from the arduplane team.
Is someone can explain the meaning of the feed forward ?
I think the easiest example to understand is car steering. So in order to turn at a certain rate there is a set amount of steering angle that will achieve this. The feed forward turn does exactly this, it turns the steering a set amount based on the rate you want to turn at. Feed forward has no feed back it is just straight from desired rate to output. The PID turns consider the actual rate. They attempt to minimise the error between actual and desired.
So in cases where in ideal conditions a set input will result in the same output only feed forward can be used. PID terms then account for any deviation from the ideal conditions. So using the correct feed forward allows (i’m not 100% sure on this) for larger PID gains as the error is never as large, the feed forward gets the steering to roughly to the right spot, the PID just does the rest. So if with no feed forward you get oscillations due to high gains at some value of (gain x error), with feed forward your error is less so you can have larger gains to maintain the same (gain x error) oscillation threshold. Higher gains result in a ‘better’/‘faster’/‘crisper’ match between desired and actual.
Maybe some control theory people can put me right on the last bit, but that is my understanding of it.
The explanation on feed-forward from @iampete is good, but I’ll add a few things.
The key difference for actuators that need feed-fwd and those that don’t is if a fixed actuation causes a constant acceleration or a constant rate.
For a quadcopter (or roll on a tailsitter), if you put in a constant actuator value (a constant difference in motor thrust) then you get a constant rotational acceleration (ignoring wind resistance). The speed of rotation in roll would (in principle) keep going up forever.
For the pitch axis of a non-vectored tailsitter this isn’t true. With a constant deflection of the control surfaces you will get a fixed pitch rate. This is what makes it an axis that is suitable for feed-forward, and the feed forward value is the ratio of the pitch rate to the amount of deflection.
I know that the same is true for yaw in tailsitters, but the yaw autotune works differently to roll and pitch so it doesn’t matter. For yaw it is primarily tuning the filter frequency. @Leonardthall is the one who really understands this stuff btw, I’m just passing along his words of wisdom
This is the pitch autotune of my vectored tailsitter
I proceeded in two step, first one for roll and yaw, second one for pitch.
No problem so far, the pitch tuning ended in a strong tuning and parameters are not so far from those I have tuned manually.
About the yaw I confirm something I felt only yesterday evening, p and I are too small. This can be seen when rolling the wing at 20° angle (it means it fly fast on its edge) I saw that the wing yaw in an uncontrollable way. I think it will be the same with some wind.
Nevertheless the autotune work nicely and end with strong parameters that normally take hours to find with a manual tune.
This is a comparison of parameters, left column is autotune.
I realize how complex the task is. Because with no wind and no speed the tailsitter fly like a bicopter. But when you add wind you get very strong external forces due to the large wing surface. And when you add speed there are aerodynamic effects as the wing begin to lift and the flaps are more efficient.
A first example is the one I gave in my previous post. When the wing is simply hovering with no wind we do not need aggressive PID as the yaw is almost self stable and the dampening due the wing drag already high. But when the wind come from the side due to speed or wind blowing we need the wing to be strongly locked with dedicated PID.
A second example is with pitch. My wing can hover with up to 70° of pitch and maybe more. At this pitch angle the speed is around 9m/s and the wing is almost flying as a fixed wing.
As I said the autotune work quite well as it is and the result is a good start but the task to take into account all effects seems impossible to me.
You should probably drop your roll and pitch accel parameters down to something like 60000 to give you a little more head room.
Yaw has not been tuned up as well as it could because it is just doing a PI tune and has dropped your filter frequency to 1 because it is not designed for this axis.
The controller will need to drop the gain down with airspeed to get consistent control when moving. This should be very doable.
I would answer it depends on the axis. Obviously yes for the pitch axis. @kd0aij is currently working in that direction. Gain are function of the lean angle assuming high lean angle means high airflow.
But for the roll, this is an other story because airspeed does not mean more airflow on the control surfaces.
Yes, roll should behave the same as a multi-rotor and be pretty constant independent of airflow. I was specifically talking about the pitch and yaw axis (while hovering).
