Do away with alphanumeric order testing and switch to numbers that correlate with the wikl

Topic: Copter Type Motor configurations

Proposal type: Hardware [ x] , Software , Other : _________________


Can we do away with the Alphabetic motor order testing in the GUI? It is so confusing to see a motor order number on the wiki and then go in and test with alphanumerics.
This causes us to have to go search a bunch of forums to figure out if we’ve done the motor order correctly because abcd(or where it starts) is not the same as 1234 etc. All other firmwares have a basic diagram showing where the motors go, what number they are what direction they spin . This makes it super simple. The alphanumeric ordering on ardu is an expensive accident waiting to happen if not properly done.

Planned amount $$ (USD): $50

Estimated time for completion:

This would be a waste of $50.

1 Like

Is this a dead horse that has been beaten to death? I’m certainly not the only one who has struggled with the motor ordering. Every time I set up a different copter,I have to google and make sure I’m getting the right order. Even then I have to trust that the person who wrote a post 2-5 years ago is right. Every other firmware clearly labels the motor order in the GUI.

It’s a dead horse to suggest a backend code change. And I don’t know who’s expecting $50 here…

But it’d be well worth someone’s time (@Eosbandi ?) to make Mission Planner’s motor test page display expected outcomes (or even help arrive at them). As is, the motor test page is clunky and almost appears an afterthought.


Isn’t this clear?

1 Like

To you and me, yes. To a new user, what if he selects “Betaflight X?” Do just the numbers change? Or do the letters change? Both? Neither?

I know the answer. But the wiki doesn’t exactly make it clear to a brand new user.

I tried to make a comprehensive list of dynamically generated SVG’s that would help a new guy sort that out, but my implementation was criticized for breaking the wiki dev environment, and I ran out of time and steam to make it work the way it was desired.

1 Like

Kind of but not really, it’s not something I’d trust setting up on a $2-3k drone spinning 20" props. I’ve setup multirotors on 5 different firmwares and they were all much more clear than ardu.

That’s also a foolish perspective. Ask for help.

Perfectly and it’s logical.

Right now I’m working on an 8" quad to get my setup skill up to par on ardu. I’m currently using a frame type set to quad and motor mix - BF X Reversed motor order. This is where It becomes unclear with the ABCD.

I have it set up so that on the motor test page it starts with the top right motor(A-clockwise), then back right(B-Counterclockwise), then back left(C-clockwise), then front left(D-counterclockwise). I assume this is ABCD like the wiki shows but it’s not clear if f that order changes for betax reversed. It It flies but vibrates badly, it shoots up and loses control which causes me to disarm only to watch it come crashing down. I tried cutting pid’s in half and that seems to have no impact on flight performance. It’s not stable enough to start an autotune either.

I have seen how well ardu does on stock pid’s on other platforms so I’m guessing there is something wrong with the order. Any thoughts?

In my opinion we need @Yuri_Rage SVGs and my howto.

Combine them and throw it at the users for feedback.

This order doesn’t change. It’s consistent across all frame types. That’s why the scheme is logical.

If it flies the order and direction are probably correct. I would suggest a new post with link to a flight log.

simpliest would be to modify MP to do like QGC and have the drone schematics with motors order and rotation direction. That way no issues possible. It would be a bit of works on MP but nothing big normally.

The whole motor test sequence is coming from the way how the DO_MOTOR_TEST mav command is working. DO_MOTOR_TEST is using the same sequential numbering as mission planner now and it is completely detached from the servo output numbering. In the specification of the DO_MOTOR_TEST command there is a parameter to do the test in pwm output order, but this is ignored by the AP.

BTW, In 1.3.81, there is a clear indication of the PWM output number and the rotation. Do we really need graphics ?


That looks like a good solution to me.
Combined with the link to the graphics that should be enough.

It could be a lot simpler IF we were only dealing with quadcopters, but there are so many possibilities I think this is the only effective way.


Much better than previous. I hadn’t seen the newer display yet.

I disagree graphics are non optional if MP is to be sane and be improved.

The numbering order annoys me dearly. The reasons for mixing # vs letters are silly and confusing.

We keep far too many kludgy old behaviors because it might be a breaking change.

Order of good motor setup
1.) px4 1.14 with QGC
#2 betaflight configurator
#5 AP MP

QGC’s screen on PX4 1.14 is insanely easy to setup motor numbering and reversals. This is because it is graphical. “Clicking which motor is spinning sets the order. Then there are buttons to reverse each motor.


Pretty sure @iampete has suggested that exact graphical approach for MP before.

I think graphics would be great, especially a “order fixer” where you it does a test in sequence and you click the order that it actually did and it swaps all the motors round so it comes out correct.

We now have the file that tells MP where all the motors should go, but a interactive diagram is beyond my C# skill level, so we currently just use that file to give the motor numbering and rotation direction.