PX4 PID tuning support

[DonLakeFlyer]

This is a pretty major working in progress from a user model standpoint. Mostly trying thing out at this point. Here are the possibly non-obvious things:

• You get to it from Tuning and then check Advanced
• When the page loads it saves the parameter values for the current tuning set internally. The idea is as you futz with them you have an "oh shit" button to get you back to what are hopefully good values by clicking the Reset button.
• As you adjust and get better values you can save them as new reset values by clicking the Save Values button.
• The +/- buttons increment the values by the amount specified in the Increment/Decrement % combo box. This way you can start by futzing with the 15% changes and then as you fine tune you can drop to 10% or 5% increments.
• You can start/stop and clear the graphs using the Chart buttons.

The above currently is only supported for PX4 Pro firmware and multi-rotors. But that said the whole thing is implemented in a generic fashion such that it just works off of generic lists of parameters. So all I need to do is figure out what all the other param sets are to implemenent other vehicle types and ArduPilot support.

In order to implement all of this I added a bunch of generic support as well:

• SetupPages have a new Advanced checkbox which you can turn on and use
• Added rollRate, pitchRate, yawRow to Vehicle object main FactGroup
• Added new setpoint FactGroup to vehicle with the values: roll, pitch, yaw, rollRate, pitchRate, yawRate
• All new FactGroup values are available for display in the Instrument Panel

Related to #2878

[bkueng]

Nice!
@MaEtUgR I think you're interested in this

[MaEtUgR]

So true, this will make tuning so much more convenient!

I have the suggestion to allow tuning roll and pitch at the same time because in practise that's what you need most of the time even if your vehicle is not perfectly symmetric. It's

1. better to let the mixer take care of asymmetric actuator placement geometry and
2. even if there is asymmetric weight distribution you typically first tune to a certain value and then fine tune asymmetry from there.

I assume the increments are 5% of what was the old value. e.g. if you start out with the default ROLLRATE_D = 0.003 and press the plus button three times you get 0.003 * (1.05)^3 = 0.003472875. Are totally uneven numbers no concern?

[hamishwillee]

I presume that this will change the way we do tuning, and hence some of the docs like https://docs.px4.io/en/advanced_config/pid_tuning_guide_multicopter.html ?

If so, what should be the trigger for updates (now, next QGC release?) and who should update the process/docs?

[DonLakeFlyer]

FYI: Daily builds are still spitting the new tuning page out correctly: #6296. Until then you have to build yourself to get it.

I have the suggestion to allow tuning roll and pitch at the same time because in practise that's what you need most of the time even if your vehicle is not perfectly symmetric.

Not sure how you tune two axes at the same time? You move the vehicle in both roll and pitch at the same time. Or are you talking about copying the same values if you tune roll to pitch.

I assume the increments are 5% of what was the old value. e.g. if you start out with the default ROLLRATE_D = 0.003 and press the plus button three times you get 0.003 * (1.05)^3 = 0.003472875. Are totally uneven numbers no concern?

Correct. Something like that although they are rounded to the decimal places specified in the parameter meta data. Don't see why numbers need to be even.

[DonLakeFlyer]

I believe the PX4 docs just say to use install a QGC daily build if I remember.

[MaEtUgR]

@DonLakeFlyer

Not sure how you tune two axes at the same time? You move the vehicle in both roll and pitch at the same time. Or are you talking about copying the same values if you tune roll to pitch.

Yes, the user should heve the option to lock them to the same value first because roll and pitch are most of the time not completely different. Subsequent fine tuning is still possible.

Correct. Something like that although they are rounded to the decimal places specified in the parameter meta data. Don't see why numbers need to be even.

Technically you are completely right. The only reason I'd prefer rounded values is human readability/siplicity to copy the value over. No strong feelings there...

@hamishwillee I think we should document as soon as it's tested and established... probably before the next QGC release.

[DonLakeFlyer]

I presume that this will change the way we do tuning, and hence some of the docs like

What I would look to see if instructions for how to tune while flying. The concept of holding a pile of swinging Ginsu knives in my hand just seems crazy as the only way to do it. Not something I ever plan to do. For my usage pattern, I choose and airframe which gives me a flyable vehicle. Then I just want to make it better from there. I'm not starting from scratch.