Add param to adjust motor ordering

[bkueng]

Useful for 4-in-1 ESCs such as the Hobbywing XRotor Micro 40A 4in1 where the FC can be directly plugged on top.

[LorenzMeier]

Ok as MVP, but already clear right now that this will be hard to maintain. Let's get it in under the assumption that we will only ever need it for racing quads.

[dagar]

The main issue I see with this is that it breaks the generated metadata that we could be using within QGC for airframe setup, motor testing, etc.

There's also no reason it needs to be FMU specific, which we'd mostly get for free if handled by a separate mixer or with this same logic in the MulticopterMixer itself.

[MaEtUgR]

I've seen a very useful solution on a different flight controller (I think it was some DJI Naza):

• You hook up all the motors to any of the available output ports
• You open the UI and select what type of frame you have
• You run motor tests which are by default just small twitches to have it safe because some people leave on their propellers no matter what you tell them.
• For each motor that twitches you select which number of motor that is according to the airframe picture.

This helps a lot in the building process because you don't have to worry which one you plug where on the board let alone looking up some hardcoded non-intuitive number scheme online.

[dagar]

Motor test (integrated with QGC) is a frequent request. It would be great to finally get it in place, and I think we almost have most of the pieces.

The only reason I haven't already implemented what's missing PX4 side is I haven't figured out a good workflow with respect to arming and general safety.

MAV_CMD_DO_MOTOR_TEST is the Mavlink command which QGC already supports.
https://mavlink.io/en/messages/common.html#MAV_CMD_DO_MOTOR_TEST

I think we should have some kind of special arming state for this that the user has to enter before these commands are respected. I also want it implemented more like a dead man's switch, perhaps requiring the user to hold the slider in QGC which will then continuously send the test value, rather than sending it once to start, and once to stop.

Thoughts?

[MaEtUgR]

should have some kind of special arming state for this that the user has to enter before these commands are respected

makes sense

perhaps requiring the user to hold the slider in QGC which will then continuously send the test value

you mean for the case where connection is lost in the moment something bad happens? Command stream should be necessary and I think holding some key or button to keep it the motor test running would definitely increase safety. And as I wrote I would support a short motor twitch.