Motor Mixing on KakuteH7Mini-Nand Correct?

ArduCopter Copter 4.3
1

Hi
Having a problem with the motor output from the KakuteH7Mini Nand. I have confirmed the hardware connections but the logging appears to show that the servo outputs do not match the required servo output. The system is in quadcoper X Frame mode. The FC orientation is None.

For example I arm the device and give it a small pitch forwards in stabilise mode on the bench. I would expect the output from servo 1 and 3 to increase to compensate. However I see that 1 and 2 outputs increase instead which is what I would expect if the aircraft yawed. (The Aircraft is not yawing)

Please see the attached graph of logged data. Let me know if there is something else needed.

image
image1487×370 22.7 KB

image
image1491×370 35.2 KB

The Accelerometer calibration is correct ie VFR follows expectations. Is there some other parameter which transforms things?

2

Use Motor Test in Mission Planner to confirm the correct motor order and direction. If it’s wrong simply re-assign the outputs and make it right. Bench testing it with the Transmitter won’t tell you much.

3

So the above output servos don’t match the motor numbering? Is that correct?
Thats not been my experience previously.
I’m also not bench testing with the transmitter, I am physically moving the body of the aircraft to see what the control response is. That is what is shown in the two graphs above.

4

Is this related to the SERVOX_Function params? I’ve never touched them, but what is the correct setting? Does the number on the SERVO X match the RCOU number?

5

Pretty sure the frame type is correct if you use betaflight/X - this should be the default.

6

Playing musical pins such that the motor ABCD test works, which is fine, but it does not correspond to the output pins on the Kakute H7 Mini v 1.3. That is M1-4 do not correspond to the correct mapping for the X Copter. Could the hwdef for the KakuteH7Mini-Nand be incorrect?

7

Sorry my bad - yes this is a really old config and the hwdef order is incorrect. Unfortunately not something we can change without breaking people’s setup

8

Right, no big deal. I have one of those FC’s. Motor Test is a step in configuration and re-assigning them if it’s wrong is trivial.

9

No problems, I’ve had a look at the hwdef files and am thinking about a producing a new one to fix the problems with the kakuteH7mini* boards ( think this goes at least back to the KakuteH7V2) but can you shed light on the pin mapping procedure, what relates to Ardupilot mappings and what refer to STM32H7 pin mappings? eg.

PB0 TIM3_CH3 TIM3 PWM(1) GPIO(50) BIDIR
PB1 TIM3_CH4 TIM3 PWM(2) GPIO(51)
PB3 TIM2_CH2 TIM2 PWM(3) GPIO(52) BIDIR
PB10 TIM2_CH3 TIM2 PWM(4) GPIO(53) BIDIR

what would I need to change to get the system to correctly map the hardware pins?

10

The order on mine was correct for an AIO ESC using the default Betaflight/X frame, which appears to be exactly what the OP is seeing (motors 1/2 forward). Is this just as simple as selecting FRAME_TYPE=1 to get the default ArduPilot/X motor order?

11

Hi, I’m using the Ardupilot/X default, which assumes 1/3 forward. Is Betaflight/X an option for frame type in ardupilot?

12

Yes, and it is the default selection for the KakuteH7Minis due to the likely inclusion of a stacked ESC in that order.

If you’re not aware of these options, you probably shouldn’t dig into modifying the hwdefs before you fully understand the board options presented.

1 Like
13

Okay I can sort of understand how the that might have come about, then definitely a new hwdef is required for users not using an ESC/FC stack. So where are the board options in Ardupilot params to set the pins up correctly for not using FC stack?

14

FRAME_TYPE=1, as stated.

15

FRAME_TYPE=1 doesn’t match the outputs of M1-4 to the motors as defined in the Ardupilot documentation, if you are not using an ESC Stack.

https://ardupilot.org/copter/docs/connect-escs-and-motors.html

16

Not really seeing the problem here. If one of these doesn’t work:
Frame type

Then configure it manually. Pick X and then fix it if it isn’t right.

17

Completely incorrect.

18

Yes Dave, understand that you can fix things manually and maybe it might work… for this problem. But if you identify an software configuration issue you should try to fix the underlying problem because it may have greater impact elsewhere. And the greater your stack diverges from your documentation then the less useful both become.

19

Okay @Yuri_Rage what is the fix then? That doesn’t include picking X then muddling through the motor mapping manually in hardware.

20

I’m not so sure there isn’t some fundamental misunderstanding regarding motor ordering here.

I just connected my KakuteH7Mini with Betaflight/X ordering and changed it to X. The motors reordered logically (though it is an admittedly confusing exercise).

I know Andy mentioned a possible error in the hwdef, but he also mentioned why any fix would be breaking for future releases. I’m not seeing that error, and I suspect this might be a case of misunderstanding and miscommunication.