Some of you may have noticed that your multi-copter will lose from 1.5 to 3 or 4 meters at the end of a horizontal run when in any of the Altitude Stabilized modes, like Alt Hold, Loiter (and PosHold for 3.2 candidates) or Auto.

Several heated debates have considered the reasons and possible causes, until finally a more demonstrative test was undertaken, using the 3DR X8 above with Pixhawk

But first some ground data:

The following graph shows how the altitude influence is directly affected by velocity (especially forward velocity), but to a lesser extent latteral velocity.


A general conclusion is that a "pressure bubble" forms in front of a moving object:


This is an image of a pressure gradient around a sphere moving towards the left of the image. This gradient is greater or less depending on the physical configuration of the vehicle. The vehicles that are most effected by the altitude drop tend to be less streamlined, with greater frontal area, and therefore a greater pressure buildup.

As the vehicle accelerates, the pressure starts to rise slowly and the forward tilt of the vehicle moves the higher pressure area more directly into contact with the altitude sensor. Then with sudden slowing, quick pitch changes and dropping pressure simulates that the vehicle is rising. Altitude controllers react to counter the effect and the vehicle drops..... sometimes like a rock.

So whereas the debate postulated that software should be able to resolve this problem the problem remains that, if it's really true that the cause of the problem is the "pressure bubble", then the software can only react to what it "sees and feels". If you make the assumption that it is possible to generate a countering force at the end of forward travel, you may end up sending the vehicle into space if the wind is from behind. The processor doesn't know any more than it can "feel".

So I built the testbed above to test the theory. You'll see a tube coming out of the front of a Pixhawk, just about where the altitude sensor is. There's a hole in the Pixhawk cover, and the altitude sensor is sealed with Plastecine, so that the outside air pressure from the "static sensor" is fed directly into the altitude sensor.

The white plastic rectangle on the other end of the tube has a tiny hole (not very visible in this photo, but about 1.5mm diameter) drilled from side to side, and then another hole of the same diameter leads from those holes to the tube. In this way, forward movement does not exert any pressure into the tube, furthermore, as the vehicle pitches forward, the static sensor holes move down into a lower pressure area outside the bubble. Pitching back up, if anything the static holes move into a slightly higher pressure area. the end result is ZERO DROP in altitude.

Lateral movement has no effect, as the side to side holes let flow pass though unrestricted and no pressure gain is seen.

This baby flies as flat as a pancake!

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • I see.. when I use my hexa the drop is very evident... at least 3meters when I'm pushing forward... which caused me a crash when i was flying only at 4/5meters high... I had same problem with NAZA Lite & NAZA v1... 

  • I guess with a smart phone I could show what it's doing now. I'd have to see how the vibrations/jello are. Visually the sink isn't as obvious from the camara as it is watching from outside. 

    I'll see if I can find a piece of video that shows the sink at the end of a run from my bigger octo. I might have one where it drops about 3 meters and comes quite close to the ground.

  • @JoeBob,

    I opened an APM2.6, and the sensor does look a little tricky. I'm not sure when I'll use this one again, but if I had to do this mod here, I would probably find a piece of polyethelene and cut out a rectanglular depression as exact as I could to fit snuggly over and around the sensor. You'd have to use something like a Dremmel tool and have a steady hand. Then on the top of the rectangular piece I'd drill a hole the diameter of the tubing, and run the tubing out the top through the case to the static adaptor.

    Fit it all onto the sensor and carefully seal from outside, with plastecine or something similar. Maybe could even use some kind of glue, in this case, there shouldn't be a risk of clogging the holes if the fit is tight.

  • Dont you have  a smartphone to show how good/bad is the stabilzation?

  • Unfortunately I don't have much video data. My camara stabilization system is on another octo I have. The other octo is bigger and suffers more from this problem. So I may be able to take before and after video when I install the mod on that one.

    I'll pick out some graph data, but this has been all hashed out over on the devs forum, so they are up on all of this.

  • David,

    Would you post some video data showing the effect before and after your sensor mod? Also like the graph data to see what you are seeing.  Maybe the DEVS can digest your logs as well as the information I mentioned and come up with a solution to the alt/press issues.



  • Hi David! it happens in any mode with alt_hold involved!

  • Very good David! there are other improvements but this is a great first step in solving that alt issues!

  • @AS,

    No, yaw different issue. This happens in an althold mode or any mode? I think I've heard of some possible causes for this, but don't really remember any details. 

  • I always thought it was because to go forward, a copter basically lifts its back and drops its forward arms. The faster it goes the more the angle. This angle must cause some loss or height difference.

This reply was deleted.