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
And another PR for BetaFlightXReversed (FRAME_TYPE=18):
copter: add bf-reversed-x to connect-escs-and-motors by yuri-rage · Pull Request #5131 · ArduPilot/ardupilot_wiki (github.com)
@hwurzburg pointed out that if we include one, we should include the other.
Rather than a wall of images, it might be nice to include dropdowns and a little JavaScript to select frame class and type, and then display a dynamically generated image/canvas with the motor numbering, directions, and letter representations. I dunno if I have the motivation to create that…
You should probably add a note to describe when the betaflight mode should be used, ie when using a stackable 4-in-1 esc. Otherwise its not clear why it exists.
I have 4in1’s that don’t have the typical BF orientation. And, the mounting orientation can change this. Sure, the battery lead exiting to the rear is typical but not a given. I really don’t get the effort here or when it has come up before, and it has many times. And when using individual ESC’s it doesn’t matter.
Run Motor Test. If it’s wrong then fix the assignments. What is wrong with this simple process for ANY Frame type or class?
1 Like
I’m not inclined to make any more wiki edits unless I decide to clean up the entire page in favor of a more intuitive/interactive drop-down interface.
It was missing the BF frame types, which is now fixed.