3689620192?profile=original

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.

3689620069?profile=original

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

3689620210?profile=original

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

Comments

  • @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.

  • 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.

     

    Thanks.

  • @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. 

  • Yeah Russell. "Being Gentle" helps. But sort of sucks LOL.

    Just yesterday, I hovered mine about 15 meters in front of me on my right. Then beelined heavily to the left. Looking at the logs I had it going near 7m/s Then I let go of the stick.

    She reared back like a horse coming to a fast stop and stopped within what seemed to be about 3 meters. If anything it gained about a half a meter. WOW. From where it was before to this, my jaw was on the ground. I had a great time.

  • @Euan,

    In the tests that I have done, and from other cases I have heard, it flies level and then looses height when it stops.

    I tried straight  legs, accelerating, then maintaining a constant velocity. You can see the unit correcting to maintain altitude as it accelerates, but it flys pretty much level. Then holding velocity it flies a flat as a pancake. But as soon as you stop, Boom. The bottom falls out.

    It may be possible that maybe a very specific orientation could allow some kind of ram effect to build pressure up insade a case or something. In a more normal situation like mine, the pressure increases, but slowly enough that the PID adjusts. But the quick pressure change doesn't let the PID keep up.

    I would think though, if it were this special case, and the leg were long enough that with constant velocity it should probably correct itself before very long. (5 to 10 secs constant velocity).

    In my tests I really didn't have much more time than that with constant velocity. I had about 60m of straight line space to accelerate, maintain and then stop.

  • @Artem,

    I'm couldn't say exactly why the simplest naza is not effected. Maybe firmware, maybe physical design. Our biggest problem I would guess, is with custom configurations. Production units should be design tested, and very likely have the problems resolved in the physical configuration.

    The X8 pictured above is production, and really didn't have the problem until I started hanging extra batteries and other pieces here and there. My stock Iris flies "no problem". In my case anyways, only my custom units have the problem axagerated.

    The same would go for hanging a Pixhawk on a frame purchased separately, depending on where you put the Pixhawk, and what else you hang on the frame etc, would require a bit of adjustment to "get the kinks out".

  • Francesco.

    There are a couple of things that can be done I think.

    On the mechanical side, just puting a dome may or may not work. If you look at the pressure diagram above, it's a matter of rigging the dome so that pressure equalizes. For instance, if you have more opening in the front, the tendency would be to pressurize the dome..... WORSE. On the other hand if it's open only at the back, the pressure would go more negative, also worse. Someone had success puting a dome AND firmly covering the sensor with foam to act as a sort of filter. I think he tried dome/foam, just dome and just foam, and only the combination helped.

    Depending on your configuration the pressure gradient may not be 100% symetrical. But likely with some trial and error you could get it working well. As long as you don't crash first :) When it's bad it can be really bad. I've got a big octo with a lot of frontal area, and even in loiter with gusty winds, it gets almost uncontrollable.

    Another thing you can do, (When 3.2 comes out, which should be very soon) is adjust EKF_ALT_NOISE parameter to give more weight to the GPS alt reference. Increasing that parameter by a couple of points helps a lot. If you don't have EKF you can adjust  INAV_TC_Z . You have to do this with a little care.... too much and it gets a bit unstable in altitude. I set mine to a max of about 7 (I think 9 is the limit).

  • I was hesitant to mess with the pressure sensor, it can be so sensitive. I wanted to seal it with silicone, but wasn't sure if the acetic acid could do damage to the sensor. In the pixhawk, the good news is that there is a plastic border all the way around the sensor which makes it easier to seal.

    On an APM, I'm not sure how I would do it. I'll have to take a closer look. I'll do that and see if I can come up with any ideas.

  • I have the same issues but inverted. I loose hight(~3-5m) in fast forward flight because I have mounted my APM below a H shaped copter in the low pressure area.

    So the copter need some time for waypoints because it has to climb several meters to complete it.

This reply was deleted.