During the dev call on 7/13/22, I talked about my results of following the fixed wing tuning guide to tune an example of a “mostly typical/normal” plane. My question was if it was generally considered appropriate for the loop to be primarily driven by feedforward, and with generally minimal Kp and Ki.I was encouraged to post some logs to the forum for review.
Reviewing the deconvolved step responses, it looks like there is generally good convergence to the setpoints, but note that the FF is primarily driving that. My question is if this could be considered to be a good tune or if this is only appearing to be a good tune due to general lack of disturbances (rough air).
Large setpoint changes in roll and pitch are reasonably fast tracked, though especially the roll is overshooting sometimes the setpoint. And the controller is slow to react to disturbances (noticeable in level flight, the vehicle is oscillating quite a bit). This is not surprising, as with the heavy FF-tuning the rate controller feedback is barely used.
And the yaw rate controller looks over-tuned to me, if you look at the plots the estimated yawrate is ahead of the setpoint.
I would be very interested in seeing the results on the same platform from a more P-heavy tuning strategy. Could you do some testing with all the rate controller gains reset to default (so the FF, P and I), and then increase the P until you see oscillations, then reduce the P a bit (like 20%) and share the log of a flight with that configuration here?
Ok, so I know this isn’t exactly what was asked for, but I changed a number of unrelated hardware/software config items for this flight and didn’t want to go too extreme with changing other things in case. With that in mind, I wanted to see what the effects of more Ki looked like and wanted to share these tuning results. The following are a series of flights increasing Ki on both pitch and roll:
Looks like far too much feedforward on roll. So, I’ll likely back FF down and increase Kp (in the spirit of @sfuhrer 's recommendations).
I still plan to do the test of starting at defaults, and then simply raising Kp until oscillation. For this flight I just needed to flight test the rest of the plane without making too big of changes.
Thanks for sharing! Yeah the rate tracking hasn’t improved with those settings I looks to me. But very curious to see the effect of FF and P ! Keep us posted!
Still not quite exact stock tunings, but I am working my way there without changing anything too rapidly.
I think especially the last flight of this looks pretty good. P was dramatically increased, while FF came down. There is one large initial overshoot in roll, but after that the loop appears nearly nicely converged, unless you think different @sfuhrer . Perhaps this is evidence of a Kp approaching max? Other thoughts on the big overshoot?
Which roll overshoot do you mean? In flight 4 of your list I don’t notice it. Roll tracking looks really good, I think this is about as good as it gets!
I’m attaching screenshots of plots of flight number 4 and a parameter diff of the important rate controller differences to your first flights in this thread, where it was much more relying on FF than P. I see that the pitch FF is still unchanged - have you tried reducing it and increasing the P on pitch instead even more?
Also try improving yawrate tracking by reducing FW_YR_FF and increasing FW_YR_P.
For the roll overshoot, note this in the deconvolved step response plot:
I think I left the pitch largely unchanged here, mostly to avoid changing too much all at once. I’ll go back and tune it in the same way, but now that I know what it looks like to be tuned “as good as it gets”, I think this will be an easy exercise.
So while it’s super nice to have this plane tuned, recall that the original purpose of this investigation was to see if there was either a common ratio of tuning magnitudes across FF, P, and I or a change to the tuning guide required. The guide suggests a procedure (increase FF first, until the open loop process happens to align with the setpoint) which will probably result in a tune that is quite FF heavy like mine originally was. What are your thoughts on these items? Should we change the tuning guide to reflect that a more P-heavy tune is more likely to result in a higher-performing loop?
For the roll overshoot, note this in the deconvolved step response plot:
Ah yes, there the overshoot is quite nicely visible. We could probably reduce the roll rate P and FF slightly (10-20%) to reduce them. And instead make the outer (attitude) loop more aggressive by reducing FW_R_TC, as your plane seems to be quite agile and able to follow higher rate commands. Then the attitude tracking should be as good as it’s now (or better) without the rate overshoots.
Should we change the tuning guide to reflect that a more P-heavy tune is more likely to result in a higher-performing loop?
Yes I think we should. Maybe the guide cold be something like “increase FF gain until oscillations, then reduce by 40%, increase P until oscillations, reduce by 30% (or until significant overshooting, then reduce by 20%)”. What do you think? Maybe you could follow this guide for pitch tuning?
pinging @bresch as he provided me with some tips and is generally interested in the topic of fine tuning vehicles, possibly with an automatic approach. Maybe he can give some secondary opinion on things.
By replaying a log file in the offline autotune python script (with slight modifications) I was able to find that the ideal roll feedforward gain is ~0.124 (given that the ideal feedforward = 1/static_gain and that static_gain = (b0 + b1 + b2) / (1 + a1 + a2))
To see which gains are suggested by the auto-tuner you could set FW_AT_APPLY = 0 (Auto-tuning | PX4 User Guide) to run it without applying the gains. You can then review them in the log file.
Thank you so much for the analysis here. I didn’t realize this worked, and I will do some playing with it. One question, what is the difference between running the auto tuner online vs running this script offline? Is it the case that the exact same analysis can be done without the inflight tuning if sufficient data is collected by a user flying a manual test profile?
To answer your question, no I have not run the auto tuner in flight yet. The biggest blocker to this is that there’s no way to run this module based on RC TX input (like a switch toggle). This is something I want to either fix, or write a module to allow arbitrary execution of shell commands based on manual input. I’ll be taking to Daniel about this on Monday to get his thoughts. I think this would really open up the auto tuner for more practical safe use for many users.
@sfuhrer That all sounds good for the doc stuff, I think this would be a good topic for the next dev call. Will both of you be on it?
Both online and offline auto-tuners have the same algorithms implemented. The only difference should be the sampling frequency (which can slightly affect the tuning and the identification quality).
Yes, but best is to run the identification maneuver automatically to excite a wider range of frequencies (launch auto-tuning with FW_AT_APPLY = 0); Data gathering is a critical step of system identification.
You can put the plane in an automatic loiter, click the button in QGC and move the RC sticks to abort if anything goes wrong. Or don’t you have telemetry?
and P 
! Keep us posted!
