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.
@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.....
I'm interested in JoeBob's arrangement. Are you going to give that a try JB?
Theoretically getting the "sensor" up and out of any pressure bubble would be optimum.
Phanivyas,
Definitly not PID problem. With the static system mod, the control is absolutely flat.
Adjustment of a few of the parameters helps to some extent, making the system less responsive to barometric altitude input. But the altitude PID is quite solid.
The problem is that the altitude measurement is incorrect. The fact that the vehicle falls is because the PID is reacting so well.
The Pixhawk already has foam pressed over the sensor.
Adding foam over the baro keeps it away from prop wash. Maybe you have to check PIDs.
http://www.rcgroups.com/forums/showpost.php?p=27054388&postcoun...
Pls refer this link for further info.
Would this help with wind gusts? When I'm hovering in Loiter and a gust hits, I'll lose between 3-4 meters in altitude before it attempts to correct itself. Actually had a crash with my X8 yesterday due to a wind gust forcing the craft down far enough to hit a prop on the ground.
-
1
-
2
-
3
-
4
of 4 Next