Take a pass at the tuning dialog and make it easier to use and more prominent

[LorenzMeier]

The user experience dramatically depends on a few core settings to be correct, including the hover throttle. We should take a pass at the QGC dialog and make sure that it captures the important aspects.

[LorenzMeier]

@MaEtUgR @Stifael Would be great to have your input here. The sliders are controlled by meta data in PX4 if no extra min/max are provided, so adjusting the min / max values in params should change them.

https://github.com/mavlink/qgroundcontrol/blob/master/src/AutoPilotPlugins/PX4/PX4TuningComponentCopter.qml

The idea behind the roll / pitch sliders is to give users a tiny bit of wiggle room without needing to explain PID params to them. We might be able to come up with something better now. https://github.com/PX4/Firmware/blob/8d39f4e4a167150c8904bbd6b389828c1e78cb8a/src/modules/mc_att_control/mc_att_control_main.cpp#L514-L524

First step should be to validate that ALL the important params are on here and that their min and max make sense. We also should consider adding a scale to these sliders.

[sanderux]

Couldnt we deduce hover throttle?

[LorenzMeier]

Not in a safe way. It will take many months to devise any sort of automatic approach that is reliable. If you get this wrong you make the drone completely ballistic and the user has no idea what is going on.

[sanderux]

not even when an actual hover is detected?
(vz = 0)

[dagar]

• abandoned QGC tuning widget effort: [WIP] PID tuning v2 mavlink/qgroundcontrol#5070
• my own wishlist: Add controller tuning widget mavlink/qgroundcontrol#2878 (comment)

[LorenzMeier]

@sanderux Let's not clutter this here with the discussion, but I'm not talking about the average setup. Think of a racer that has vibration issues and where the auto-tune slowly creeps away. It's these corner cases that are problematic.

[MaEtUgR]

Most importantly the sliders need a scale and it should be possible to clearly see the exact value even for a non-developer. In my experience a lot of people in the community are focused on exact numbers after they tuned to be able to reproduce and compare (even in cases whaere it makes no sense at all).

I don't know what parameters roll and pitch sensitivity map to but the parameters I tune first "to get stable flight" are the roll and pitch rate P gains (MC_ROLLRATE_P, MC_PITCHRATE_P) and I set both to the exact same value even if the frame is not exactly symetric. In my opinion asymetric frames should be handeled by the mixer because to generate the mixer you can use exact length mesurements of the frame geometry. Would be nice to have UI for that in the future. And even if this is not done I would rather set roll and pitch to equal values first e.g. locked sliders and then if necessary add an offset for assymetric moment of inertia distribution e.g. option to adjust only one of them. In any case it's important to have a feel for how much you are actually changing the value, small increments are ususally what you end up doing. If you have a high vibration vehicle it's a good idea to also adjust the rate D gains (MC_ROLLRATE_D, MC_PITCHRATE_D) because they can amplify the noise to high frequency oscillations.

About the hover throttle I think it could make sense to generate a suggested value. It should be rather easy to read it during the first hover flight. We recently flew a racer with the default hover thrust (50%) and the tuned value ended in the range of ~20-25%. The only "real" problem we had with the default value was first stage landing detection in flight and no landing detection when landing.
How I find the exact hover thrust:

• fly stabilized mode with the average expected payload
• put the throttle stick exactly to the middle while hovering
• if the vehicle accelerates up, decrease hover thrust
• if the vehicle accelerates down, increase hover thrust

[Stifael]

The idea behind the roll / pitch sliders is to give users a tiny bit of wiggle room without needing to explain PID params to them

I think it is also important to clearly specify what effects the pitch/roll slider has. I fear that the user ends up using the slider to achieve a less aggressive flight performance instead of adjusting higher level parameters that control acceleration and brake, which are on by default.
I think the sliders make sense if slewrate and any other higher level tuning are off by default. Once the lower level tuning are correctly set and adjusted, the user can then move on to a second tuning page (or below the current), where higher level tuning parameters can be set.

[LorenzMeier]

Very good points. Let's see what we can do quickly. @Stifael Could you provide a list of parameters that we should incorporate?

[Stifael]

MPC_ACC_HOR_MAX:
defines the maximum allowed change for velocity setpoint in xy. This value is always used in auto and only used in manual controlled position mode during hover.

MPC_ACC_HOR:
defines the maximum allowed change for velocity setpoint in xy during fast forward flight and manual position controlled mode. This value is also used in auto to accelerate from 0 to cruise speed.

MPC_DEC_HOR_SLOW:
defines the maximum allowed change for velocity setpoint in xy in manual controlled mode when the user demands to decelerate but not to brake.

MPC_JERK_MAX / MPC_JERK_MIN:
Only for manual controlled position mode and when the user demands brake. The jerk defines how fast the velocity setpoint can accelerate from MPC_DEC_HOR_SLOW to MPC_ACC_HOR_MAX.
Example: the vehicle flies in manual controlled mode with X m/s. At this velocity the accepted acceleration is somewhere between MPC_ACC_HOR and MPC_DEC_HOR_SLOW and lets call it A (A is found from linear map between these two parameters and maximum cruise speed). If the user demands a brake (0 velocity setpoint), instead of jumping directly from A to MPC_ACC_HOR_MAX, the acceleration is adjust based on jerk starting from MPC_DEC_HOR_SLOW and then increased to
MPC_ACC_HOR_MAX with each iteration. This ensures a smooth brake. The jerk used is again fround from linear map of MPC_JERK_MAX / MPC_JERK_MIN and velocity of vehicle.

MPC_ACC_UP_MAX:
defines maximum change in velocity setpoint in upward z-direction

MPC_ACC_DOWN_MAX"
defines maximum change in velocity setpoint in downward z-direction

Probably it make sense to add it to documentation together with graphs.

[LorenzMeier]

Could you send a PR for docs and we take the QGC UI from there?

[Stifael]

I am working on a document that covers position control details. I would like to finish that first, otherwise I have to redo it twice.

[LorenzMeier]

@Stifael How do we stand there?

[Stifael]

https://docs.px4.io/en/advanced_config/advanced_mc_position_tuning.html
Its just about higher level position control related tuning. I think those are also the parameters that can be adjusted by any user.

[Stifael]

I think this issue here becomes even more important with this feature addition

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.