" the BetaFlight motor order default"
As more hardware goes 4 and 1 esc’s this make sense.
One thing i not liking is the hardware placement for mot 1234 for a 4 and one ESC is setup for betaflight. this requires the wires to be placed in a way that loops over the esc for a ardupilot build unless it changes in the params.
Where this file comes from ? Is it auto generated from the source ?
To use it for graphics, one parameter is missing, motor vertical position on coax configurations.
I’m not a big fan of “order fixing”, indeed it helps for lazy builders, but adds an extra easy to overlook step to log analysis.
Obviously there’s room for different perspectives and priorities here, but I lean towards fixing the motor order because the experienced users/devs doing log analysis are better placed to adjust than a new user. It should be as simple and intuitive as possible for a new user to set up our most basic configuration, and it isn’t. Fixing that should be an obvious priority in my view.
The motor auto detect function in betaflight works awesome. Not only can you have bf spin a motor but it will also auto remap the input once you tell it which one is spinning. The input becomes arbitrary because the software only needs to know which one it’s actually spinning. It does away with trying to plug them in, in a specific order.
Ok start from the scratch:
The motor test order is ALWAYS ABCD…So, for example if you want a servo order that matches motor order, you have to select QUAD CW_X Frame type.
– OK I’was wrong you can add another layer of complexity to change the servo output/motor number assignments…
That is absolutely possible. You derive the motor numbering based on physical setup (as the user clicks) and adjust the servo output parameters accordingly.
Are you suggesting that a builder is lazy if he orients the ESC to fit it most efficiently into the frame and then wires everything most efficiently to avoid loops and crossed paths? Doing so certainly doesn’t adhere to a specific frame type with respect to numbering, but it would definitely qualify as good practice. Having ArduPilot’s configuration tool abstract away any frustration with output ordering doesn’t seem like a band-aid in this case…
Yepp I was wrong…
The only thing is that it adds another level of abstraction to the configuration…
motor order → motor number (where motor number == servo number)
versus
motor order → motor number → servo number
isn’t it more confusing ?
It’s not confusing if it’s transparent to the user.
As it stands, I see the beauty in what AP has done to achieve standard motor indexing in the source code. And I understand the method to the madness quite well.
But I also understand the new user frustration. And he shouldn’t have to care that there’s an elegant code construct behind the thing he’s struggling to grasp.
Actually, dynamically assigning the outputs should be easy. The frame type basically just sets the defaults for servo functions, but you can change them any time you want. Doing that via a UI makes some sense, and would make frame type irrelevant for most people.
OK, I don’t want to be the one who is complaining about everything, just one last issue :
Changing SERVOx_FUNCTION requires reboot, that will decrease the user experience.
I don’t think you’re complaining at all. No harm in a dissenting point of view!
Changing servo function doesn’t always require a reboot, does it?
It is flagged as @rebootrequired in the source. Need to check if how it behaves in a real world… but given the number of different flight controllers/io processor/without io processor etc. etc. i think it will need a reboot on some of them at least.
Fair enough. And certainly some changes will require reboot (like configuring for GPIO if previously used for DSHOT - pretty sure that’s a must).
I’m trying to remember if the pin is already configured for DSHOT (the most likely use case here) if a reboot is required to simply renumber.
Yeah, its generated from the AP motors example,
As far are the flight code is concerned it makes no difference which is on top, so it does not have that information either. So we can’t get that from source, but the convention in the diagrams is that the motor test index top first then bottom. A is top B is bottom ect, so you could apply that convention in the code, for co-located motors. @Yuri_Rage has a great example of generating diagrams from the same file. Copter Wiki Motor Diagram Overhaul? - #24 by Yuri_Rage
Changing motor function at run time works. As you say some functions do require a reboot. Changing frame type eg from X to + also works fine on copter without reboot (not quadplane).
The reason were stuck with so many odd frame types is a legacy from before it was possible to fix the motor ordering by changing the servo functions, so we had to use the ordering that was “baked into” the hardware.
We do have frame types for most of the classes that fix the issue, “CW X” these have the motor ordering and test ordering the same, A = 1, B = 2 ect. If your setting up from scratch that makes it much less confusing, that is what I use for my builds.
If we made “CW X” the default 90% of the confusion would be resolved.
However if we just change the default everyone’s existing vehicles that are flying using the current default value would crash when they update. We possibly could work out some scheme for param conversion, but it would be quite complex. The problem is that if they were using the default value the param is not saved into the eeprom, if your doing a new setup the value is also not saved into the eeprom, so we can’t tell the difference. We could probably overcome this issue by looking at other params to try and judge if its a update or a new build. Its hard to say how fool proof we could make it, we might end up with some crashes after updates.
I get it: not the first time I’ve had this discussion 
I think it’s time to shift the thinking from focusing on the “why not’s” to “how do we fix this”. With parameters, it’s easy enough to use an existing parameter (hover throttle, rc ranges, a bunch of options) as a marker for indicating that a vehicle has been configured previously, and then not touch the servo functions in an update.
What would you propose?
Just change the default to CW X, its more intuitive.
Remove all the current frame types and start over. For example X, Betaflight X, DJI X and CW X are all the same motor layout with different ordering. So we could remove all of those and just have X. Like wise Betaflight X reversed is the same as H. So for quad we could go from 12 frame types to 8 (X, H, +, + rev, V, V tail, A tail and Y4A). The param conversion here would be more complex as we would have to shuffle the output functions to get the new frames to come out the same as the old ones. This would also mean its harder to config if you are using a config where one of the old types was correct. For example coming from Betaflight you have motors 1,2,3,4 and use Betaflight X and your done. The new scheme would be frame type X and you would have to work out the motor ordering of 2,1,3,4.
something else
Ultimately I think wherever we end up a interactive GCS helper would be useful even if all the frame types are standardised. The tool works just the same with the none-standard frame types so there is no need to remove them. But once we have the tool we can remove the none standard ones from the main wiki page and direct users to frame class X and use the tool. Once we have the tool users don’t need to interact with the numbering/ordering directly anymore so it doesn’t mater that it is confusing.
The other firmware does have auto ordering with QGC. You have to manually enter your motor mixer weights tho, so I think we still have the edge.
I think it’ll need to be a two step process: first, get motor test and default motor order to match, and then get a ui and dynamic allocation implemented.
To me it makes sense for the default to match the most likely configuration, which is a 4-in-1 esc using the BF order, but I could live with CW-X.
For frame like Y6B absolutely not, doc present numbers and MP shows magic letters
Try the beta:
