PIXHAWK motors do not spin when ARMED

ArduCopter Copter 3.2
1

Arming works fine, get a solid green light, but motors do not spin. After 5 seconds the unit goes back to DISARM. If I ARM the unit and then give 1 click or more of throttle, 2 of the 4 motors spin up rapidly and the other 2 do not move.

I am running a large quad with 29" props and KDE motors and speed controllers. RC_MAX and RC_MIN are set to 1900 and 1100 for channel 3 (throttle) as stated on the wiki and as advised from KDE. No comment on either about the RC_TRIM param and what that should be and its effect (if any) on the throttle function.

Have all 3 wires from ESC plugged into pixhawk and have BEC power applied to the servo rail independent from the motors/esc’s.

Motor ARM issue:
Have set all variations of MOT_ARM and THR_MIN (THR_MIN always greater than MOT_ARM)… no change. Prior to arming the RC in on channel 3 is showing 1098 and the RC_out on channel 3 is showing 1100. After Arming the RC_out for channel 3 goes to 1167. It doe not matter what I change the MOT_ARM to after arming the RC_out for channel 3 always goes to 1167 and then when nothing happens after 5 seconds it disarms and goes back to 1100 for RC_out.

When I move the throttle up 1 click after arming… the 2 motors start to spin and if I give stick input (pitch/roll) the other 2 start spinning and seem to be responding normally, but unless I add a click of throttle the motors do not spin at all when armed. When adding 1 click of throttle, the RC_out for channel 3 jumps to 1348 and the motors spin. Even at MOT_ARM of 150 and THR_MIN at 300 the motors do not spin when armed.

MOTOR NOT SPINNING TOGETHER ISSUE:
I believe this to be a non-issue maybe… What it looks like to me is that at 0 throttle, the only signal sent to the motors is a “arming/spin-up signal” based on MOT_ARM param. The flight controller is not active and trying to level copter. However, I think once I move 1 click up, not the THR_MIN is engaged and the flight controller takes over and is trying to level the copter.

My theory is that this is why once I add throttle the motors start spinning and then by adding roll/pitch inputs I can get the props to all spin and act somewhat normal. With DJI they have a MANUAL mode where the stabilization control is always off and you can test running motors up from idle to full throttle without any “interference” from the flight controller.

I feel like if I were to test fly and just throttle up it would tilt a little as it lifted off, then break ground and right itself and fly fine. However, on other setups I have done with the pixhawk, once armed all the motors spin slowly and make take-off smoother/more table and would like to get it ironed out.

If I go into “motor/compass calibration” and start calibration… as I slowly increase the throttle the motors (all at the same time" start spinning very slowly and as I increase the throttle slowly it increases all the way to 100% in a very linear fashion… seems perfect… I know this is only used to try and offset interference, but it shows that the speed controllers and motors are synched and configured correctly. As another note, when connected to an A2 they spool fine on “arming” and work normally - more evidence that the motors/speed controllers are fine.

Thoughts on what I need to do to get the motors to spool up on arming?

Thanks in advance!

2

Sounds very much like your ESCs are not calibrated for the 1100-1900 range your have configured. There is an ESC calibration function you can activate through mission planner, see copter.ardupilot.com/wiki/esc-calibration/

When the motors spin up at arming (at long as that function is enabled) it is done by just applying a fairly small increase in throttle, which in your case seems to only be on the verge of starting the motor.

In any case, you should be doing all this testing without props.

Whenever I have have made significant changes to configuration/rebuilt, I like to arm, and increase throttle to mid point (all motors should be spinning - the flight controller is trying to hover), then I pick up the quad/hex and tilt it about to verify that the motors increase / decrease speed correctly (motor going up should slow, motor going down should speed up).

3

[quote=“SuperJim”]Sounds very much like your ESCs are not calibrated for the 1100-1900 range your have configured. There is an ESC calibration function you can activate through mission planner, see copter.ardupilot.com/wiki/esc-calibration/

When the motors spin up at arming (at long as that function is enabled) it is done by just applying a fairly small increase in throttle, which in your case seems to only be on the verge of starting the motor.

In any case, you should be doing all this testing without props.

Whenever I have have made significant changes to configuration/rebuilt, I like to arm, and increase throttle to mid point (all motors should be spinning - the flight controller is trying to hover), then I pick up the quad/hex and tilt it about to verify that the motors increase / decrease speed correctly (motor going up should slow, motor going down should speed up).[/quote]

With KDE motors, you can not calibrate them without a separate programmer and software (advanced programming). They are set by the factory to arm at 1100 and max out at 1900.

I did figure it out, see reply on main thread…

4

SOLVED:

2 main issues and the 2nd one was really what caused the consumption of the most alcohol and loss of time!

Issue #1 - Talked to Patrick at KDE and he said that his speed controllers need to see an increase of at least 170 from pre-arm to post arm. The amount of increase from pre-arm to post-arm is adjusted by the MOT_SPIN_ARM parameter (as I originally thought). However, the standard range is from 0 (disabled) to 150 (very fast). None of those are enough. I thought this might be the case in my original troubleshooting so I raised this to 200 (and THR_MIN to 300) and it had no effect (see #2 issue). No matter what I put in MOT_SPIN_ARM the post-arm “RC3_OUT” was always 67 higher than the pre-arm (RC3_MIN).

So KDE recommended I lower the RC3_MIN to 990 - but that did not work as now the pixhawk/apm thought my throttle was not at ZERO and would not arm (safety). But, knowing that it needed to be a change of 170 or more coupled with “issue #2” below I have it working.

Issue #2 - Apparently, the MOT_SPIN_ARM parameter is only read on power-up of the pixhawk/apm. Even though “write_param” and “refresh_param” showed that the changes were applied, they were not really applied. This is why no matter what I changed MOT_SPIN_ARM to it always just added 67 to the RC3_MIN parameter number.

So, once we figured that out, we set the MOT_SPIN_ARM to 170 and the THR_MIN to 180 - then powered off and back on the pixhawk/apm and everything worked great. On arming the motors start to spin ever so slowly and adding throttle starts a nice gradual increase in motor response as expected.

Although it now seems to work, it is a very un-nerving lesson in the absence of any support for the pixhawk or APM code. As a commercial operator, we need expert and timely support from vendors to ensure any issues can be addressed to ensure revenue/credibility is not lost. This has been an experiment into the open source arena to see if this would allow us a more flexible, cost effective solution from the 75k-200k commercial multi’s we use today. Our findings are that indeed the systems are economical and flexible - but you are certainly on your own unless your issue is a common setup error. Access to development for support and troubleshooting is not available. Confirmed by a couple contacts at 3DR - they want to “get there” as it relates to the commercial market, but their focus right now is on the consumer market as that is where the major market is. Even though we would pay 10,000 for a pixhawk/apm if it came with a direct support link to experts, they are not at a point to provide that type of service - although they plan to get there.

We plan to continue to work through the issues and continue our work to see if with enough effort we can get a stable commercial unit to work with the pixhawk/apm - and hopefully the support options will increase to a point where when we may be ready to use a pixhawk/apm equipped vehicle in production, 3DR (or someone) will have a commercial support offering.

5

So mtndewdewd I have been having the same issue with one motor double the speed of the other 3.

I just played with RC1 and have the front motors spinning the same speed but faster than the now same speed back motors. Am I on to something?

If I mess with the pitch min, max trim settings will I get all motors spinning the same so I can try to get this in the air?

I’m running KDE motors and ESC’s as well. Any help appreciated.

6

I had an issue also with motors not starting. I seemed when even I would do a ESC calibration threw the PixHawk the motors would spin and everything was great. But as soon as I would arm the copter the motors would spin (And is was arming) and mission planner would think it was good to go. Finally I hooked it up to a scope and found that the PWM signal looked strange and after a while I found if the RC_SPEED was set over 100Hz it would change the signal. So I dropped [color=#FF0040]RC_SPEED to 50Hz and BAM the motors started[/color]. I ended up doing some testing and found I could only run max at 85Hz. I was running BlHeli 14.0.0.2.

2 Likes
7

Hye dear. same problem faced. Just check SERVO9_FUNCTION in full parameter list set 33
servo10 - 34
servo11-35
servo12-36

I think your [robem ill be solved

Also you can set the Servo Output , under initial setup

8

This plus ESC calibration, is what fixed issue for me.