What is the betaflight/X ordering? Do you mean you have betaflight in X configuration? Or that you have in hardware the motors mapped how betaflight expects them?
Motor numbering as follows in the image (front is toward the top). Motor ordering for ArduPilot remains correct with respect to A/B/C/D in an X config.
Because my servo outputs 1-4 correctly correspond to motors 1-4, I strongly suspect that should mean that the hwdef is correct for all possible quad configurations (at least on servos 1-4). Board is KakuteH7Mini-Nand.
So you have it set up as betaflight motor ordering. The hardware is setup that way (probably for fully assembled drones). This isnât the ordering expected by the ardupilot X Frame class but because the hwdef is setup to match the betaflight config it works.
However if you were to follow the ardupilot esc motor order, such that youâre not using the stackable ESC, you will run into problems. Its a different hardware setup.
I would suggest that a new board configuration is probably preferable for those not using the ESC Stack, the alternatives are list in the documentation a motor ordering for each model of FC â this is not really practical.
Alternatively theres a new frame class called betaflight/X that can be selected, but that will probably break current implementations of people using it in your case.
Thatâs why I think a new, separate hwdef is required for people using this flight controller without an ESC stack.
Unless you can think of a different way.
I have FRAME_TYPE=12, which intentionally maps to the Betaflight/X orderingâŚthatâs not ânew.â
FRAME_TYPE=1 should therefore work without hwdef changes.
That was what I was asking before regarding the meaning of betaflight/X. After switching to FRAME_TYPE=1, are you still using your ESC stack?
Yes, which means the motor order changed wildly but logically. It wonât fly, but it does show the effective change.
Iâm not going to completely rewire my copter just to prove a point.
Okay thanks,
Well with a direct connection to Holybro KakuteH7Mini-Nand to escs and motors, using the Ardupilot X frame motor ordering I got the following relationships that resulted in a flyable aircraft:
Output Number : Motor Number
M1 : 1
M4 : 2
M2 : 3
M3 : 4
I would have expected the outputs to line up with the motors. I hope your logical mental computation is correct, but it doesnât marry up with what I am seeing out of the FC.
If anyone has a similar setup, please let me know. @andyp1per please let me know about the hardware defs if you can point me to an appropriate page that explains the mapping.
If Iâm reading your chart correctly, that would correspond to a Betaflight-ready ESC oriented 90 degrees counterclockwise.
What ESC(s) are you using?
I am using indvidual ESCs not a stack, so the ESCs correspond to the motors
I think the hwdefs take into account the use of a stackable ESC module. And thats why I question your logical appreciation as it is hard to do and easy to make a mistake. Possibly ⌠its just not working in my case
Question away. It wasnât just a mental exercise. Here is the result when I switch to FRAME_TYPE=1. It is correct and double checked.
You may wish to read a topic I authored on the subject:
Demystifying Multirotor Motor Numbering - ArduCopter - ArduPilot Discourse
So I see that youâre doing a bunch of mixing on the outputs. Can you share the values for:
SERVO1_FUNCTION
SERVO2_FUNCTION
SERVO3_FUNCTION
SERVO4_FUNCTION
Do you know what their default values should be? I haventâ changed them, but they arenât a straight mapping. Does setting the Frame class change these values?
Iâm not doing any mixing. Thatâs the FRAME_TYPE parameter taking effect.
SERVO1_FUNCTION through 4 are set to Motor1 through 4 in order, per defaults.
I might see your confusion - you may be conflating the letters A-D with the motor numbering. In other words, if I slightly reorganize your chart, it suddenly makes sense:
M1 : A
M4 : B
M2 : C
M3 : D
Read that page I linked. It might help a lot.
Cool I meant in your linked document where you are mixing the outputs from a Pixhawk.
However those parameters seem to be the issue, somehow mine have become changed and are not straight mappings. The mappings that are there map to the motor outputs I provided. So Iâll probably just reset them to straight mappings. Changing the frame class didnât affect the values of those parameters in my case.
Cheers @Yuri_Rage thanks for your help, I think this issue is solved.
Changing the FRAME_TYPE does not change the servo output parameter values. Rather, it internally changes the âmeaningâ of the motor numbers to match the physical layout expectation (among a few other things not germane to the topic at hand).
In other words, FRAME_TYPE=1 sets the following relationships:
M1: A
M2: C
M3: D
M4: B
While FRAME_TYPE=12 results in this:
M1: B
M2: A
M3: C
M4: D
So, the motor test page will give wildly different results with no other parameter changes.
Yeah I guess the new thing I learnt was the existence of betaflight/X. I think the param config was a result of copying params from a setup that used an TMotor F45 4-in-1 esc and I think my solution then was to modify the servo functions to suit with a FRAME_TYPE=1.
I stand corrected - thanks for checking. It probably makes sense to put this in the config as a parameter, I think this wonât break most people but weâll see what Randy and Tridge think
1 Like
Could it go in for new builds but leave existing/user-set params alone?
That is, no conversion during firmware upgrade.
It would only set the defaults so any explicitly set parameters would be left alone
Made a PR to add a Betaflight/X image to the wiki.
1 Like