Right dialog flow confusion

[LorenzMeier]

@DonLakeFlyer As discussed: The dialog should be top-aligned, with a flow from top to bottom. It should either change background color or have a separator to indicate where the content ends.

Desktop users looking for a "next" button at the bottom would then not find anything and start to look somewhere else. We should also avoid in general putting optional buttons on the very bottom as a design rule. If they are down in the dialog, there should be explanatory text below them, so the user does not perceive them as dialog controls.

[LorenzMeier]

Fixed for params:

[LorenzMeier]

Matching PR: #2869

But other dialogs, like the Firmware dialog, still need fixing.

[kd0aij]

OpenPilot groups all of the "map to RC" controls into one menu which also has "tooltips" that fully explain how to use each field. And, of course, your settings are persistent. With QGC, one has to traverse the menus for each parameter, typing values into 5 separate fields for each parameter on every boot. PX4 has a more general mechanism, but I've only used it once due to the awkward implementation. QGC could do a much better job of facilitating parameter tuning than this.

[DonLakeFlyer]

As far as I know QGC is exposing exactly what is capable in the firmware. If the firmware has a new/better mechanism then please explain. I've never heard about it.

[kd0aij]

@DonLakeFlyer How do you do use QGC to do PID gain tuning? Perhaps I'm just ignorant.

[DonLakeFlyer]

@kd0aij It's simple. I don't. All of my stuff uses off the shelf settings. Should probably add I don't know much about this stuff since I didn't implement any of it.

@LorenzMeier Is there some new PID tuning thing in the firmware. As far as I know there is only the single RC to Param setup capability.

[LorenzMeier]

We don't have bandwidth right now for PID DIY dialogs. Independent of that: I fundamentally don't think this is something our users should be doing - I would prefer the effort to be spent on auto tune.

I'm not opposing the addition per se, it's just something we don't have resources right now, nor do I think it's the main issue from a user perspective.

[kd0aij]

But you still want me to work on better gains for acro mode.

[kd0aij]

QGC/PixRacer doesn't compare well with OpenPilot or Cleanflight for tuning a racing quad, because it offers zero support for tuning via RC. And no serious racing user is going to be satisfied with "off the shelf" settings.

[dagar]

I can tell you first hand that PID tuning for a regular user is a pretty miserable experience and should probably be avoided if at all possible.

For those of us that need to though, it would be really slick if we could bring all the pieces together on a single screen. For example you select roll tuning and only relevant params (roll/rollrate) and a preconfigured plot (roll/rollrate setpoint and actual) would be displayed on the same screen. We could even annotate the plot with param changes.

[DonLakeFlyer]

We've talked about that before. It's doable over the current RC to Param firmware stuff to some extent. But is hasn't popped to the top of the priority stack yet. Can someone carry across the information from this Issue into a new one dedicated to this topic? I think there may even be a really old issue in there somehwere already.

[LorenzMeier]

@dagar I can relate a lot to your proposal and its the best (outside of auto-tune) what I could come up with. It could also have the RC mapping like proposed by @kd0aij.

@DonLakeFlyer The tuning UI @dagar is proposing would be appealing to prosumers, professional users, developers and the racing community. It could plot only two lines initially, so maybe a good initial case for the QML plotting tools. I've filed #2878 for this.

In general we're not trying to become the 10th racing project. Its perfectly fine if the hardcore racing community thinks it needs something else. There is no way we'll ever beat a specialised board, nor do I want to steal the users of those thriving communities. We rather want to cover a range they do not cover yet.

What we set out to is to allow users who are "casual racers" to get a racer (think of it as a small, low-cost Pixhawk) which also does great GPS based flight. Part of that promise is to not make users tune PID gains. It should just not be part of what we consider the normal setup process.

I'm even happy to go as far as to add a praising comment of Cleanflight and Betaflight and links to it to our user documentation, pointing anyone who is a tuner and DIY person to the projects doing only that and nothing else.

@kd0aij Back to your personal need: I'm open to the concept of "fixing" the RC param mapping, I just have no-one right now I could ask to lend you a hand. So if this is blocking you, could you would picking up the work on the Firmware side for RC mapping? It would be entirely doable to add what's missing here then.

[kd0aij]

#1740
What I asked for there would be simple to implement on the QGC side.