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!
Comments
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.
And how about yaw? I loose hight when yawing on the same spot!
I have the same problem and am pretty sure you are on the right track.
An empirical test would be to fly backwards (not practical) but what if you slowed before turning ?
Better still a test flight at slow speed = no pressure build up .....
Currently, I get around this issue by keeping the turns gentle.
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.
Just to be clear - is this the same thing as when the copter loses height consistently over the length of a "leg" or does it fly level, then lose height?
-
2
-
3
-
4
-
5
-
6
of 6 Next