I cannot agree more and considering this topic comes up quite often that should tell you something is not working properly or not reading clearly. For a new user it is very clear as mud and not all of us go on
I don’t like probably when it comes to a flying vehicle very dangerous attitude.
Right now I do not have a log at hand to confirm what I remember but the motor numbers in the logs use a 3rd variation and I have several times had doubts how to map this to 1, 2, 3, 4 or A, B, C, D (for a quad). So (if I remember right) there is yet another option for confusion.
Logs use the same numbered indices as the outputs. That shouldn’t be a source of confusion unless you’re doing log analysis before the motor order is correct.
I thought about items like C1, C2… for RCOU and 0, 1, … for rpm of ESC. I think there are more but none pops up in my mind right now.
Just to chime in. This has been one of my pet peeves for about a decade, and basically comes down to the fact that the default motor order is nonsensical. In my view the solution is to make the default motor orders match the motor test order, or even better make the BetaFlight motor order default, and adjust motor test to match (there’s already an enum in the command to indicate sequence/order). Neither of those things is technically difficult, the roadblock is concern over impact to existing systems. I think those concerns are misplaced and far easier managed than some think.
Improving the documentation and interface is great, but is just a bandaid.
" 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.
