I’m working on a hexacopter with the following setup:
Matek H743 Mini running 4.3.7
1 x 4-in-1 ESC (BLHeli_32)
2 x separate ESC’s of similar specs (also BLHeli_32)
6 x EMAX 2306 1700Kv with 5" props
The copter weighs 2.4kg and should take off at around 50% throttle based on static thrust tests of the motor/prop combo.
When I attempt to take off, the copter pitches slightly backwards and is unable to take off properly. Judging by the log, there is a significant imbalance in the motor output, i.e., it prioritizes certain sets of diagonal motors (3 and 4 highest, then 1 and 2, then 5 and 6).
Different frame types (I normally run a dynamic matrix, tried normal hex)
Various motor output protocols (PWM, DSHOT150, 300…)
I should also note that it has previously flown with a very similar setup running Arducopter. However, since it has been under constant development, I have not been able to track back to a working version of the setup.
I hope someone can point me in the right direction.
Yes, all motors are mapped correctly. When I test the roll and pitch movement on the ground before take-off, the correct motors spin up. I have tried standard hex frame and my own dynamic matrix, they yield same result.
What @amilcarlucas is asking is if you’ve used the motor test function in mission planner. Motor A should run the right front right motor, then B is the next going clockwise and so on. Good to double check in this situation.
Yes, I am aware, apologies for the unclear answer. I have performed the motor test and they all spin in the correct direction and in the correct sequence as per the ABC motor “numbering” (A = front right, B = mid right, C = rear right, etc…)
Typically a split like this (assuming motors are in the right location, spinning the right direction, and the props are on correctly) then it could be a twist in the airframe, or some how the C of G is offset or incorrect.
When you did this test, was the drone outside with the props on? Or was it secured to the ground with no props?
HydroHex is just the name I’ve given the drone. It’s a bit unusual in that it is meant to operate in water as well (hence the “Hydro” in the name)… In any case, I have tested it with the standard Hexacopter X frame with the same result.
I am following the motor mapping as per your first image. The reason for the irregular motor positions is simply due to cable management (4-in-1 ESC’s come with a bundled signal wire). That and due to the physical placement of the ESC’s meant that it was more convenient to run certain motor cables to certain motors.
There is no visible twist in the airframe, nor CG offset; the only notable mechanical “feature” is that the rotors are angled slightly inward (by design).
I tested in a large indoor space with props, not secured to anything.
As the throttle goes up, there is a pitch input requesting a nose down attitude. The FC is responding by speeding up the rear motors to near max, and the front motors to near min value. To me it looks like it’s responding properly, in that it’s doing what is being asked (even if what you’re asking isn’t what you want)
Check the RC inputs in Mission Planner. When you push the pitch stick forward the green bar should move towards a lower value. You can reverse it in the radio or using RC2_REVERSED,1
I did reverse the pitch channel on the radio, and the value does reduce when I push the stick forward. When I test the axis on the ground before taking off (arm, low throttle, pitch/roll to make it tilt), it also pitches forward correctly. In this particular test shown in the log, I actively tried to pitch it forward upon take-off to keep it level.
The issue only seems to start when I provide it with more throttle and try to take off. It starts to take off around 40-45% throttle, then gradually pitches backwards, and any attempt to pitch it forward again or make it hover by providing more throttle is in vain. This can be seen in the graph as well; here’s how I experienced it:
17:00:49: The front started to lift at ~40% thr
17:00:50: I applied forward pitch correction to keep it level while keeping a constant throttle
17:00:53: I increase the throttle in an attempt to spin up the rear motors
17:00:54: The drone almost tumbles backwards, so I cut the throttle soon after
As you run up the throttle, and pitch forward the drone is demanding a forward pitch as seen by ATT.DesPitch going to a negative value. The log also showed motors 4 and 6 going to higher power, indicating the motors at the back are trying to pitch the drone forward. That all checks out. So if you’re saying the drone is going in the other direction (and looking at the log again, I believe you) then something else has to be backwards. Motor spinning in the wrong direction, prop on backwards, motor mapping. The only other thing to double check is the drone moving the correct direction in the HUD on mission planner. When you pitch it up does the horizon go blue?
If you in fact have the motor order right, which is often not the case even when people say they have triple checked it, give it a burst of throttle to get it off the ground.
Thank you for your inputs - I found the culprit, and I am back in the air! TL;DR: temp. protection of ESC 4 and 6 kicked in prematurely.
I performed motor tests at higher throttle ranges (10, 20, 50, 80 and 100%) and noticed that ESC 4 and 6 consistently reduced their output after ~2 seconds when the applied throttle was 50% or higher. This explains why I could test the pitch/roll movement on the ground and not notice any issue - they worked fine at 10-20% throttle.
The only setting I had recently changed on the ESC’s were the temperature protection. I had set this to 160 deg. for both the 4-in-1 ESC and the two individual ESC’s, which were assigned output 4 and 6. When I disabled temp. protection, they worked flawlessly, and the drone could once again take off!
Obviously, the ESC’s do not reach 160 deg. after 2 seconds of 50% throttle, so I assume there is a fault in the ESC firmware or hardware that makes the temp. protection kick in prematurely. In any case, I’m happy to find that, once again, ArduPilot was not to blame for the issue…
