Sudden altitude drop in guided mode



I was doing a scripted flight yesterday. The python script issued a set_position_target_global_int_encode message to move towards a waypoint when suddenly the drone started descending until it landed. However, the motors kept running, not enough to lift off again but enough to make it wobble around in the grass until it flipped over and stopped.
This scripted flight has been executed several times without trouble.
One idea i have would be critically incorrect barometrical values. In fact, it was a sunny day and just before the flight the weather got cloudy, a little windy and colder. Can this have such a large impact on the measurements?
Another possibility: I leashed the drone on a long and sturdy leash. Could it be that the drone wanted to rise but was held back by the leash and interpreted this as a thrust loss (In fact, the debug message Potential Thrust Loss (4) showed up in my DroneKit log when the drone went down)?

If it is any help, here is a video of the problem:

Thanks in advance!


Can you share the .bin file and perhaps we can analyze it? (The video did not work for me.)

Some have reported barometric noise and use sponge to provide a cover from air flow.

The leash should not be a factor.


Of course:
2022-07-04 (3.6 MB)

I’m not exactly great at reading these logs, but I think there is a significant pressure loss at the point where the thrust loss is reported. Also, does Baro->0->Alt give a height of 4-7 metres? The drone never made more than 2 metres.

Btw.: Upon closer inspection, the video doesn’t work for me either, but saving it via right-click and playing that file with e.g. VLC worked. It’s a normal MPEG4 file with H264 encoding.



I am not an expert at analysis either, but here are a few possible observations.

I see your first flight landed due to a power failsafe, then replaced with a fresh battery.

The baro temp was steadily dropping with each flight as the air flow cooled it, causing an estimated baro alt change of 2m. But this would not cause a sudden critical situation.

Here is the GPS.Alt (adjusted) vs BARO.Alt

Although there are no apparent vibration issues, I think I see some discord between one or more of the motors, particularly C3 (yellow). How was this drone tuned? Also, is there a possible weight imbalance or/and poor thrust/weight? There should be sufficient margin in the design so you are not always near max throttle.

A more important issue however, is the significant draw-down in power with throttling up, ie, ‘voltage sag’.

This would account for the drone landing because it could not sustain thrust, but still had enough power to keep the motors going on the ground. Are these old batteries? Battery capacity and ability to provide the power demands needed can change with time and multiple recharging even if the voltage levels appear high. I am not a battery expert, but I think by measuring battery internal resistance would give an indication as to the health of a battery. An improper C rating match can also create issues.

The Potential Thrust Loss could be due to when it was leashed, but I don’t think it was the problem. There was also a moderate change in magnetic field of 25% that might warrant checking if your compass needs re-calibration in the field.

So I would try:

  1. Making sure your drone is properly balanced, not putting excessive demands on one motor.
  2. Not overweighted and good thrust/weight.
  3. Tuning to optimize PID and stability. Use the Mission Planner tuning tools, including autotune.
  4. Using new fully charged batteries and see if it makes a difference.
  5. Compass calibration in the field.

There are a number of discussions about this at where you can get more expert opinions.

Also check out articles on battery maintenance and health.


Well, you seem like an expert to me…

The drone wasn’t really tuned at all, I just followed your courses and calibrated accelerometer, compass and ESC’s. Going through the tuning instructions, I find that most of these settings are already correctly set. I’ll try setting the harmonic notch filters though (whatever that is).

The drone is largely balanced. I moved the battery under the drone and a little to the back but that should not cause a strong imbalance. For this, I mounted a rail system consisting of carbon fiber tubes and 3d printed parts which are balanced and of negligible weight. Other than that, it’s the default setup.
Altogether, It’s not perfectly balanced and since I’m planning on mounting a gimbal on the front, imbalance will problably increase. Are there settings in Ardupilot I need to use in order to account for imbalance?

I bought the batteries according to a recommendation from Drone Dojo ( They are hardly 5 months old and received less than 20 balanced charging cycles using the charger from the kit. I cannot imagine they’re already giving in. I’ll order some new batteries to see how they behave.



Optimized flight control uses at least one Inertial Measurement Unit (IMU) and possibly other sensors to detect static and dynamic motion in different axes of space. It feeds this sensory data to the flight controller in order to position the drone to the desired movement, just like our brain uses different sensors (ie, visual, vestibular) to provide stable position in space. Sometimes there are incoming signals that are not relevant to this process and distract from optimization. For example, frame or motor vibrations might create oscillations of a particular frequency that are irrelevant, so a harmonic notch filter would isolate a narrow frequency band and remove that from being used by the flight controller. Of course it is best to first make sure your hardware is not loose, not out of balance, not flexible, etc. Tuning can be complicated so best to just use what Mission Planner offers and perhaps the Autotune.

If you are planning to add a gimbal/camera it would be best to make sure the All-Up-Weight (AUW) doesn’t exceed the thrust capabilities of the drone, and to ensure it is still center-balanced, or else there will be excessive asymmetrical demands on one or more motors. I don’t think there is any ardupilot setting to compensate for a weight imbalance, and if there was, it would be a very power-inefficient vehicle. Gimbal operation and tuning is another whole area of learning.

Yeah, with new batteries should be ok. I’m not sure what other reason to account for this. When this happened, did you try to again manually take off and found it did not have enough power? How long was it flying?


Sadly, I didn’t do another flight at that time. Before that, it flew for maybe five minutes with that battery. However, your sources say that the right storage conditions are also important for batteries. The battery was not charged on the same day but around two days before and lied in a safe bag since then. Maybe that’s a problem, too. I ordered some test equipment to measure the internal resistances of the cells. Maybe this tells me something.

Browsing through the available batteries, I found that my batteries, compared to others, are extremely small and powerful at the same time (according to the manufacturer). Concurrent products are often 2200 mAh and almost double the size. Could it be that the small size combined with a high targeted performance takes it’s toll on durability (remembering Samsung’s Galaxy 7)? I found a lot of tests for this batteries on youtube, but none of them made an extended durability test. Maybe it would be better to buy the 2200mAh variant of these batteries as they might not be as tightly packed as the 3000 variant and problably offer about the same performance (3000 mAh is hard to believe)?
Do you have any experience on this?


Storing the batteries for a few days shouldn’t matter especially if they show a full charge. You might consider ordering several inexpensive LiPo battery testers, and in fact leave them connected to the LiPo while in flight as it will emit a loud alarm when the voltage gets too low.

I routinely use 3S 3000mAh, 3200mAh and even tried 5200mAh on these builds without issue, sometimes after they have been stored for weeks. So I would not try to overthink the battery issue. Just make sure they are relatively healthy and fully charged. But keeping batteries discharged to the storage value is best to prolong longevity.

But getting back to your original problem, you might share your .bin file with some of the arudpilot engineers here and see what they have to say. This is a good place to ask questions in addition to the Dojo forum.


Thanks, I asked on the ArduPilot forum, but did not receive an answer (
However the batteries seem to be the problem. I tried both batteries (Ovonic sells them in packs of 2), and they all showed the same strong voltage sag. The most interesting part is that this battery I bought seems to have the same problems. The voltage drops extremely quick, even under moderate load. The internal resistance of all battery cells is around 3-4 Ohms which should be ok.
I’m using a gimbal which makes the build a little heavier, but if it can take your taco delivery project, it should handle that too, shouldn’t it?

Did you never have any issues like this?

p.s. This thread says that there is the value Bat.Volt, which contains the directly measured voltage and Bat.VoltR, which tries to clean drops due to throttle increase. Could it be we’re just regarding the wrong value here?


But they addressed your other similar question there?

A small gimbal should be ok, though the camera might be too heavy. I would think about upgrading the build if you are going to risk a decent gimbal/camera.

You might do some more searching on voltage sag. And I guess you saw my other message regarding the FrSky current sensor I use.


Currently I’m at a dead end regarding that voltage sag. I invested in a Mauch voltage module, hoping that this magically fixes, or at least improves things. Once it arrives, I’ll see.

Meanwhile, I removed the gimbal (~320g) and balanced the the drone, reducing it’s weight to around 1.55 kg (including battery). However, I still can hardly complete a simple hover flight without thrust losses, as this log of my latest flight shows. It was a simple autonomous hover flight at 2m. The pwm motor values (CTUN.C1-4) are almost maxed out even in hovering. Also, the left motors seem to work harder than the right ones, but that’s hopefully another issue.


FYI: I just mounted Extron 2220/12 motors with 1270KV. RCOU.C1-4 in hover flight look better now. The manufacturer provides maximum load data for the motors, so I may switch to a 4s battery if needed.
That’s my plan for now.

Also, I got my Mauch equipment, consisting of this and this. The voltage sag seems to have gotten smaller.

So I’ve accepted it and set BATT_FS_VOLTSRC to Bat.VoltR.


Are you inclined to now think it was a motor issue and not a battery issue? That the old motor current draws were exceeding the motor capabilities? It is odd as I have not experienced this with my builds with this motor, but I will use this information in the future.


Honestly, I don’t know what to think.
Though the problems seem to have gotten smaller, I still experience sags of about 2 to 2.5V at peaks of 40A occassionally. Since I’m using the sag corrected voltage as reference, this causes no emergency landings anymore, but it shouldn’t be. I’ve been having this problem all the time with different batteries, different motors, different ESC’s, different Pixhawks, different frames (F330 and F450) and different sensors.

Seriously, when it comes to unexplainable, hard-to-debug problems, drones are almost worse than 3D printers. And I have to work with both… :wink:


I am not sure what ‘normal’ sag is.
Regardless, it shouldn’t create an altitude drop.
I will start to log and analyze my flights as well.


Hello @Janis.Blank. I am having the same issue. I think it is because I didnt install the UBEC cord that came with the kit so I will install it and try to fly again. Did you install the UBEC on your build?


@sanperez You mean removing all the UBEC lines but one from the ESCs and using that one UBEC line of the ESC to power the Pixhawk’s servo rail as shown in this video?
Yes, I did it this way.