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
Johan, thanks for posting your work-around with adjusting the ekf alt noise setting. I changed mine from 1 to 5 and it seamed to help me as well. I'm guessing this effectively eliminates the barometer from the equation and very heavily weights the GPS (wonder if there is a setting to just use GPS and if this would give similar results). I didn't want to get into the trial and error of a physical solution and this seams to work. I was getting drastic drops when I would set POI waypoints which would cause the drone to strafe... and presumably result in a change in air pressure with the induced cross wind. Thinking of upgrading the GPS if I'm taking more reliance on it or perhaps going to a laser range finding altimeter.
Very interesting thread. Just want so share my experience as well as one simple change solved my nightmare with a powerfull quadcopter. To cut an extremely long story short, after three months, multiple crashes, three new pixhawks I simply could not solve my altitude hold problem. I am not talking about speeds, I am talking about 5km/h type of speeds my quad would drop like a stone from 20m to 5 within 20meter distance traveled.Crazy! Tried foam, total encapsulation covers everything, nada. And then I read about efk alt noise! Changed mine up from 1 to 5 and unbelievably my alt hold is rock solid, not 1 meter drop during my max loiter speed 30km/h. Really dont understand it but this must be shared with more people. Something is seriously wrong with that algorithm. Eitherway I am a happy camper.
I've done this mod and have made improvements especially in forward flight. I do get some altitude in backwards and rolling left to right.
Is there a theory on optimum placement of the static port?
Hi. I'm having the same problem on a smaller scale. I have a custom Spyder type frame 700 between motors.
Its rock solid but dose lose some altitude. My issue is the throttle is very lazy, not very responsive in poshold. Can I adjust some settings to correct this. Cheers in advance.
JB, thatt's a shame. Not quite sure how that mod has affected radio inputs!
What do you mean by radio inputs not working? Are you saying that there is no response to your radio?
How did the radio calibration go? If you can't calibrate the radios, there has to be another problem.
I can understand that if somehow, heat or glue messed up the sensor, that you might have sensor problems, but not radio problems.
Are you going to use another Pixhawk for your NEO 8?
On mine, I adjusted for the baro alt noise, and it helped, but not enough.
What kind of response/problem do you have? I know that a completely blocked sensor will produce unflyable results. But you have to isolate the actual cause. Perhaps a log.
Reporting in: my 'remote pressure sensor' Pixhawk will not be flying. The inputs for radio communication do not work. I don't know if the board was defective before I got it, or if my attaching a cover over the Baro sensor somehow messed up the radio inputs.
$200 and several hours gone. I'll approach this problem from a different angle: Ublox NEO 8 and less Baro input for altitude.
My dome has worked in a variety of configurations. I had an opening for the 910mhz antenna and 3 other holes which at one time had a camera mounted to it. These are now covered with tape since the components are removed. The dome base has a flange that holds it to the frame. There are lots of areas underneath that are open. One could speculate that if the aircraft was flying fast enough the flange could create a vacuum under the dome. I have seen no issues. I plan to have covers of some sort on future aircraft. Not really for this baro issue but for other reasons as well.
@Criterion
My 3DR X8 from the factory didn't seem to be effected by the problem. It's got a fairly slim profile and I don't think the pressure bubble builds up much. When I started adding less aerodynamic stuff, the problem seemed to appear.
That said, I think the dome has great potential, although it may take a bit of trial and error to get the internal static balance right. Modifying the pressure sensor, drilling holes, gluing tubes, is messy, and it really doesn't take much to stuff up an altitude sensor.... and there goes a perfectly good autopilot.
What might be interesting is a dome that has several openings all around the base diameter, and then one experiements, opening and closing different holes to try to find a balance.
It's encouraging that the dome works for you,. Maybe we can get a couple of others to try one out.....
Already modded the Pixhawk. Got the second DiscoPro frame today. Should have it in the air by the end of the week.
Patience, Mastah; patience!
On the 'Wind Gust' front; I rejected the first tubing I selected. I was using phone cable with the wires pulled out to keep weight and diameter down. Since the phone wire sheathing was so flexible, I worried that a wind gust might have the affect of INCREASING the baro sensitivity; by compressing the length of tubing like a bellows. Got some stiffer tubing now.
I have an aircraft with a dome cover. It flies perfectly stable and is my most reliable aircraft (X8 config). If possible, a large semi-sealed volume around the APM seems to dampen the effect. I am sure there are still times when conditions are just right to cause the problem.
-
1
-
2
-
3
-
4
-
5
of 6 Next