Demystifying Multirotor Motor Numbering

ArduCopter
1

I’ve been frustrated a time or two on multirotor builds when attempting to decipher ArduPilot’s motor numbering scheme, so I created a couple of infographics that will hopefully help others avoid confusion when wiring their own Copters.

Refer to the following graphic for the example that follows:

image
image672×692 154 KB

ASSUMPTIONS:
I have a 4-in-1 ESC depicted, which is impossible to orient such that ESC motor numbering conveniently aligns with ArduPilot’s output scheme. To keep the wiring tidy, we will assume that each set of ESC pads is wired to the nearest motor on the respective “corner” of the frame. We will also assume an autopilot that requires this ESC’s protocol to be connected on the “AUX” ports (as in BlHeli_32, DSHOT, and most H743-based autopilots).

WIRING:
While wiring, ignore the motor letters - they are only really useful when using Mission Planner’s “Motor Test” function as verification that you have things connected correctly.

Starting in the upper right of the graphic, we can see that the ESC pads labeled “M2” are closest to ArduPilot’s “Motor 1.” Therefore, when wiring, we should connect the ESC’s “S2” wire to “AUX1” on the autopilot.

Unfortunately, there is one more complication: most autopilots of this variety refer to AUX1 through AUX6 as SERVO9 through SERVO14 in the parameters, adding a bit of fuel to the helmet fire we’ve already created. It may help to create a matrix like this for reference during the build and wiring:

image

Connect the remaining motors similarly.

TESTING:
To verify the wiring is correct, we can use Mission Planner’s “Motor Test” page, which makes use of letter order vs any numbering.

REVERSING A MOTOR:
Let’s assume that while testing, you discovered motor C needs reversing. With BlHeli_32 ESCs, this can be accomplished one of three ways:

So long as the numbering scheme is understood, the easiest method is via the SERVO_BLH_RVMASK parameter. Motor C corresponds to AUX2, and therefore servo/channel 10 in the example. In Mission Planner, put a checkmark next to “Channel 10” in the SERVO_BLH_RVMASK parameter (setting bit 9 of the mask, corresponding to a raw value of 512). Be sure to set SERVO_DSHOT_ESC appropriately when reversing motors with this bitmask.

Alternatively, use the BlHeli_32 configuration software of choice and a passthrough connection to reverse ESC motor number 3.

Lastly, you can swap any two motor wires connected to the corresponding pads on the ESC, requiring further soldering, which is probably ill-advised, as multiple attempts at de-soldering and re-soldering pads on a printed circuit board can result in damage.

11 Likes
2

I would like to add that if you are using controllers from Matek and others that run Dshot protocols on all the outputs you won’t see AUX channels. In that case the motors can be connected to the any Servo output, as long as you identify it in the setup.

Great write up! I think a lot of people will find the graphic useful.

1 Like
3

Thanks, Allister - a fair point for sure.

I’m fairly certain that I captured the most confusing example (at least for a quadrotor!).

2 Likes
4

I think so. This needs to find it’s way into the wiki.

1 Like
5

Looks good! Just one point.

Chances are if you select BetaflightX as the Frame Type it will align. All but one of my 4-in1’s do. Of course this is up to the manufacturers to decide but they lean towards Betaflight as a much larger target market. Note that in your illustration that ESC is aligned with the Betaflight motor order.

6

I always use the default frame type, as I expect most newer users might. There isn’t much in the documentation to lead anyone to select the Betaflight config, though I see its practical use now!

7

Based on common questions on the forum here you are right about the Type selection. Many probably read the Wiki entry on this which references the Mission Planner Frame Type page and click the box not knowing there are many other Type options available.

1 Like
8

I have been meaning to look into automatically showing the correct numbering/ordering for the selected frame type on the mission planner motor test page. We should be able to automatically fix ordering by getting feedback from the user on what motor actually span when A ect was clicked.

3 Likes
9

That sounds cool. So make a default connection, run the test, answer some prompts and it’s then ordered?

10

Exactly. If we do a test-in-sequence and get the actual sequence the motors span in from the user we can swap round all the servo output functions to fix the ordering. Does not fix CW/CCW of course, but we could show the expected rotation directions, so it should be clear if its wrong.

5 Likes
11

Nice work @Yuri_Rage!

1 Like
12

Hello,

Thank you first off. S1 on the flight controller is number four on the receiver. Phew. You just saved my year!

Seth

P.S. Off to try and build for the blue again!

1 Like
13

Omg, it’s like 5 years now?

14

@ppoirier ,

Me? Yes, I know. I still have not got it to work yet. It seems I keep getting further and further away of a workable image and use case. I stopped for some time b/c I am a terrible loser. I quit basically.

Boo to me, I know. But…I will retry since I saw this idea: BeagleBone Blue — Copter documentation (ardupilot.org)

Seth

P.S. I am, well it would seem, a very slow learner. Too much to soak in!

2 Likes
15

A little update on this, I have done a PR but need to fix up some issues.

1 Like
16

Instead of the iterative approach to ordering motors (like mentioned in your git post) - would it be faster/easier for the motor test to simply spin each motor sequentially for a couple of seconds and then ask the user to enter in the order in which the motors spun? You could even have the process prompt the user for the motor that spun after each spin - and then make all parameter changes after going through all motors.

The way you specified would definitely work - but I can see the time needed to get the order right scale exponentially with the number of motors you have (if for some reason all the motors were incorrect).

2 Likes