Copter is taking too long to arm

I just built my first copter and is having problems on arming the motors. Here’s my harware setup:

  1. Flight Controller - Kakute H7 V2
  2. GPS - GPS & Compass M8Q-5883 – Matek Systems
  3. ESC - Holybro Tekko32 F6 60A running on BLHeli.
  4. Motors - Racestar AirA 2508 1200KV
  5. Firmware - V4.3.0 Beta 4

After I plug the batteries, until I am able to arm and spin the motors takes about 3-10min. Here’s my observations: A minute or even faster after I plug the batteries, I push the rudder stick to the right to try to Arm it. A beep sound will be played but the motors won’t spin. In the HUD it will display Armed. But during that minute or so, the motors did not play their chime to tell the pilot that they are ready to spin. This playing of the motor chime will take 3-10mins. Only by then when I push the rudder stick to the right will the motor start spinning.

My suspect is the flight controller has already completed the ARMING_CHECKS but for some reason, it is not telling the ESC’s that its ready to take off. This step to inform the ESC’s to spin after arming the quad takes about 3-10min. Here’s the current settings of the ESC.

Can somebody check the ESC configuration and figure out what parameters needs to be coordinated with the flight controller parameters in order for the ESC’s to be informed that Arming is ready.

Here’s one BIN file.

In the Auto Analyzer there are some failures. Is this something that needs to be addressed?



I think I found the root cause of why its taking too long to Arm and spin the motors. It looks like I have solved the problem but theoratically it should Arm the motors with the current settings. So I’m not that 100% happy.

Here’s what I found.

  1. The Motor PWM Min/Max of the BLHeli ESC was originally set to 1040/1960 respectively.
  2. The flight controller Motor PWN Min/Max is set to 1000/2000.

So I recon the ESC is waiting for the flight controller to send a minimum throttle of 1000 which is lower that the expected PWM Min of the ESC which is 1040. I would expect it will arm but it takes a lot of time. So what I did is to changed the ESC Motor PWM Min/Max to 1000/2000 and wah lah the waiting time it takes to arm and spin the motors is less than a min. I was happy with that but all the while, I thought that as long as the Flight Controller is sending a PWM signal lower or equal to what the Motor Min PWM signal, it will arm. 1040 PWM expected by the ESC is higher compared to what the FC is sending which is 1000 but it looks like a difference of 40 will take a long long time for the ESC to Arm. I hope this will help others troubleshoot this issue if it happen to them. Any reactions from from the deveopers would be appreciated.

Unfortunately that log doesn’t show why it takes so long to Arm, because it only starts logging from when you arm.
Set LOG_DISARMED,1 for one session and try to arm a couple of times, wait till it does arm (and maybe fly) then you can set LOG_DISARMED,0

I suspect one of the problems will be GPS fix, use GPS_GNSS_MODE,65 and let’s see how that goes in subsequent flights.

The minimum and maximum throttle values should not matter since you are using DSHOT, and of course there’s no need to “calibrate” the ESCs for like we did with old fashioned PWM. It cant hurt to set them like you have though.
In the BLHELI32 suite, set the temperature protection down to 100, 140 is just crazy - no idea why it is the default.

I would change MOT_PWM_TYPE,4 to 6 for DSHOT600, some ESCs dont like DSHOT150.

You need to use MissionPlanner motor test to get this as low as possible:
MOT_SPIN_ARM,0.1 could probably be about 0.06 just so props spin up reliably
MOT_SPIN_MIN,0.2 needs to be about 0.1 probably

Set INS_LOG_BAT_MASK,1 for the next flight and also
INS_HNTCH_ENABLE,1 ← set this then refresh params to see the rest

You can set BATT2_MONITOR,0 since it’s the same as BATT params.

Also Pitch attitude control is doing very well but roll is poor
Copy all your pitch values to roll

and you can probably set

You can adjust these compass settings too
Since you had plenty of yaw changes in that log, I ran mavexplorer magfit over it.

Hi @Shawn

I have followed all the parameter changes including the compass. Here’s the Log after the flight. I only did the test at my backyard so the manoeuvrers are not as aggressive as the first log you’ve seen.

Kindly let me know if you are happier with this log. Otherwise let me know any improvement and I will be happy to test.

I can still see failures on the Log Analyzer.


LOG_DISARMED wasnt set so we cant see how long it took to arm or why it might have failed.
What were your observations?
Also GPS_GNSS_MODE,65 could be set

Attitude control is very good. No need to change anything there :slight_smile:
Movements dont need to be too aggressive, even though that’s valid testing for a small quad.

Leave all the other HNOTCH params as they are now.

Hi @Shawn,

Sorry about that, I missed the most important parameter. Here’s the log once again with LOG_DISARMED = 1.

My observations are:

  1. Arming the motor now has improved a lot. I don’t know which parameter has done this but I am very happy with the result. I even try to restore the Min/Max of the ESC but as you said it does not matter. I will not be pissing people in the flying site anymore waiting for the copter to arm. Thank you very much.
  2. Before your last changes (GPS_GNSS_MODE, INS_HNTCH_FREQ and INS_LOG_BAT_OPT), I find that the copter is sluggish when it lifts off the ground. But after its on the air, that sluggishness disappears. After the last changes, it looks like take off is better.
  3. Pitch is good but Roll looks like there is oscillation when I rock the aileron left and right. After the last changes, the oscillation has improved but I can still feel some. I don’t know if its my fingers causing it.
  4. Throttle is a bit jumpy on Stabilize mode. But I can live with this by applying a throttle curve to flatten the center a little bit to reduce jumpiness. In saying that, throttle control is very good on AltHold, Loiter and Position hold. Break is a bit slow. Is there a way to make the break stop the copter faster? I mean can the software compute the speed and apply the proper lean angle and prop RPM to stop it and then level the copter at the end? Might be too ambitious but I better ask just in case it can be done.
  5. Overall, the copter is less agile compared yesterday but I cannot confirm this as I only did the test at my backyard. I will inform you once I can find some time to go to the flying site. But with regards to stability and control, this is better. Is there a way to maintain the stability and control but make it agile?
    Best Regards,
  1. it might have been the DSHOT600 and MOT_SPIN params ?? unsure
  2. that might be because of ATC_THR_MIX_MAN,0.5
  3. You could try running Autotune. RC sticks can be a bit sensitive too - you can try adjusting ATC_INPUT_TC upwards for a softer feel (0.3 is very sluggish, 0.2 is what I use, 0.15 is default) or change the deadzone for pitch and roll sticks RCx_DZ
  4. Stabilise is always like that. Try these Loiter prams
    LOIT_BRK_DELAY,0.3 (or keep your other Loiter params but try setting this low)
    It’s far more configurable than poshold and much newer
  5. Autotune should produce the best possible PIDs (in theory) then there’s a few things to do to reduce sensitivity if required. There’s numerous discussions on tuning small quads.

Be sure to set LOG_DISARMED,0
The harmonic notch filter is working well, you can set these to reduce the logging

I think you are sending this to the wrong person. I don’t have anything to do with Ardupilot other than using it in one of my planes.

Hi @xfacta

I noticed that when the GPS Lock is ON in the ARMING_CHECKS, the time it takes for the motor to arm depends on the GPS signal. Sometimes its quick and sometimes its fast. If I turn it off, it is fast so its confirmed that the waiting time is because of the GPS. But I don’t want to disable the GPS Arming check. Will it help if I install a second GPS unit? Is there a separate parameter settings for the second GPS? I’ve read somewhere that the two GPS units must be identical. I am using Matek GPS & Compass M8Q-5883. Does that mean that for the second GPS unit, I will only have to wire the Rx and Tx and leave the SCL and SDA not connected? Or can we also connect two compass as well. If yes, how will the two compass address be setup so that they are not the same on the I2C bus.


I do not think adding a second GPS (or compass) will help. It will still take at least the same amount of time to arm.
My preference is to enable the FENCE and then it can take a long time to arm - BUT then you know that there’s a GPS 3D Fix and Home has been set. If that’s not working you also know there’s something wrong and you probably should not fly anyway.
In my experience there’s rarely a race to arm, but there’s always concern over what RTL will do when there’s a battery failsafe.
If the copter is small and close to the ground this can make it take longer.

What’s the compelling reason you want it to arm fast?

Hi @dkemxr,

When you are at the flying site, its annoying to others that you put your copter at the center of the runway and wait a long long time to arm. As I have observed, sometimes its quick and sometimes its fast. And turning off the GPS arming check makes it fast. So its confirmed that the copter sometimes cannot get a good GPS signal. But i’t not a good idea to turn off the GPS Arming check so I am looking for solutions. The time I am talking when its slow to get a good GPS signal is from 3mins to 10mins. When GPS signal is good, it only takes less than a min.


Is there a better GPS unit compared to the M8Q-5883 that I can use?

Can you power up before going to the launch position? Even if you have to power down again before moving out of the pit area…
If the GPS has recently had a fix it should be very quick to be ready.
Also increasing the GPS (mast) height makes a difference.

In one of your recent logs the IMU position and GPS position never align on the map, primarily because you’ve armed and flown before there’s a good enough 3D fix. I’d say this is exacerbated because of the density of housing and reflections during this test.

Yes FENCE_ENABLE,1 will have an increased time to arm (at least the first time for the session) but there is also much increased safety and reliability.

You should set INS_HNTCH_REF,0.1

Similar to what Shawn suggested you could also connect a USB power brick to keep it hot. Assuming your FC powers the GPS from USB that is.

Regarding another GPS unit, one with a larger patch antennae may be faster.

Yeah, larger patch antenna (the ceramic looking square) or even add a ground plain underneath.

If you stay with Matek options are an M10 with a bit bigger antennae or an M10 with a really big antennae.

Can you show how to investigate the IMU position against the GPS position?

In MissionPlanner, Review A Log, select “Map”

This is yours

This is someone elses but you can clearly see the blue and red lines are not quite aligned, this is not the worst, but not ideal.

This what it should look like