I agree with Wes, it might be possible to modelise the stuff in the soft with maybe one or two variables ("gain", and maybe "delay" or "Accel" for example to tune the smoothness of the compensation).
Ok it is always risky to add variables as it depends on the shape of each drone, but we can see that the behaviour is more or less always the same. If you drift for 10 meters, you see a loss of altitude a bit delayed, then a few seconds later it climbs again. So it is directly (and only?) linked to ACC values.
For what it is worth.... Knowing hover throttle level and frame angle + duration + initial acceleration it should be possible to estimate current speed rather accurately. Combinig the speed + experimantal baro degradation data it should be possible to calculate offset for a given frame angle and speed...
Oh you're right, it is air speed estimation that is relevant and not ground speed. So there are lots of inputs :-( that is hard to develop.
If only acceleration was the case, we would se the copter change altitude right away (upon acceleration) but we usially see it after a certain speed is reached. As illustration, compare the pressure on your arm.if you stick it out of a moving car at 20mph and at 80mph.... Big difference. Not quite the same, bur similar thing is happening with our copters. Also, this offset is not linear and will vary greatly with speed and frame angle at which this speed is sustained. Another experimental point: naza will drop a little altitude when abraptly removing pitch angle and letting it drift. But the drop is negligible compard to AC... a mere. 10-20cm ... I do believe they rely a lot on IMU data for level flight instead of baro. The key there is good vibration filter, so when the change is abrupt, vibrations go outside the filter ability and naza drops a bit falling back to baro data.
For anyone still interested, I received the barometer inlet that I had 3D printed. I don't yet have the rest of the kit to make a permanent installation, but I was able to cobble together a temporary mast for testing.
The result is fantastic. The new inlet and its revised placement almost completely eliminate the aerodynamic effects that I was experiencing. I had two problems. First, there was a steady, shallow descent in horizontal flight, at anything more than the slightest movement. Second was the sudden drop in altitude at the end of a horizontal run as others experience. This mod cures the former and greatly reduces the later.
It looks like there are two factors involved in my case. I think my earlier attempt failed because I didn't get the remote inlet outside of the airframe's pressure envelope. I was essentially using a remote inlet to sample the same pressure as the internal inlet. The other important aspect is using an inlet that is immune to the pressure changes caused by rapid fluid flow, which the Gill inlet does.
The before and after logs show the difference in barometer altitude vs. GPS altitude, during horizontal runs. The middle of the first screen shot shows a long horizontal run. You can see the barometric altitude steadily increase and surge at the end while the GPS altitude drops off rapidly and comes back up and the end.
The second image includes GPS latitude, so that you can see the horizontal displacement. In this image you can see that the barometric altitude tracks GPS altitude much more closely.
I don't think that the tall mast will be a permanent feature on the F450 airframe. It's kinda impractical. I'll probably switch to a flight controller without barometer and GPS dependency and just fly it for fun. I'll save future barometer adventures for my 750 build, in progress now.
It's good to finally contribute something of substance to this discussion! I hope that someone finds my non-scientific fumbling useful.
you can easily correct and control altitude via a simple AltHold
energy consumption test.
Power meter can give you highly reliable energy consumption vs. altitude (air pressure) at AltHold chart, you can use to support EKF.
If energy consumed by motors and hardware to stay in AltHold mode
at altitude 10m is E10, so if energy consumption starts to grow suddenly you can can expect error in bar, GPS, IMU altitude calculations.
Alt control via power consumption exactly resembles manual mode control with joystick.
Saving power consumed data to logfile may give better insight into Drone Fly-away Syndrome, since if energy consumption is steady, all you can expect from your drone is a horizontal drift in Stabilize mode.
Awesome work Chris! Thanks for sharing. I'd love to see how that would work if the mast was no higher than the gps.
Thank you for the suggestion, though I'm not entirely sure that I follow. Are you saying that I may be experiencing voltage droop to the IMU due to motor current surges? If that's the case, I'm pretty sure that my power supply regulation is good. If I had such a problem I would be seeing other issues as well.
I am aware that I can tweak EKF_ALT_NOISE to gain a small amount of immunity to small altitude changes, but this isn't a good option for me as I am currently fighting vibration issues as well.
Maybe I just don't understand what you mean.
I'm willing to try, though I suspect I would have the same issue as in previous experiments, wherein the inlet was still inside the airframe's pressure envelope and didn't accomplish anything. That's the reason for the tall mast. I also have the propeller flow-fields to contend with. There is a low-pressure gradient above each prop that changes with RPM. There isn't much room to work with on this airframe.
I'll see if I can get in a flight with a shorter mast this week, but it may have to wait until the weekend.
calibrated power meter can be used to control altitude alike barometer.
For the set altitude in AltHold mode, energy consumed can be constant
- if you notice energy drop, you can expect drone altitude to drop
- for altitude to rise more energy is consumed
so I would suggest implementation of power meter into Pixhawk
as a sensor of special importance to control uncontrolled fly-aways
and have power meter values saved to log file for post mortem analysis.
That presumes a stationary hover. Any directional motion would show up in your 'power meter' as an increase in altitude...