This is a contradiction. You are suggesting that we should use the baro as our height reference because “more trustworthy altitude measurement”. But then correct the ground pressure reference so our altitude matches the gps altitude.
If you have a better altitude reference just use that as the altitude reference.
Air pressure suffers from:
Poor measurement due to the lack of a static port on most aircraft
Height error due to pressurisation of the internal cavity of the aircraft (I have see more than 30m)
Varying atmospheric conditions
Complex pressure vs height calculation
With a high quality gps the only real reason is to use baro as the primary height reference is to line up with manned aviation pracises.
Thanks @Eosbandi I was looking for that to post but couldn’t find it. I think this is basically what is being asked for here.
Thanks leonard, I will try that with Here3+ and come back with results.
Questions:
1- If I set GPS as primary height sensor, will i get “Little Jumps in altitude” frequently?
2- I suppose EKF estimates altitude using all the sensors like it does with horizontal position and Primary SRC is just the most weighted sensor, is this correct? Is there a parameter to tell EKF how much each sensor should be weighted?
I have heard and read many many post about the here3+ not being a very good solution for gps and had some major accuracy issues. You may want to look into a F9P gps. there are better options that are using gps chips that are a much better choice.
One option is to get a GNSS unit that has both slightly improved GPS chipset AND a barometer.
This improves the baro readings since it is most likely up out of the prop wash (on the GPS mast).
That obviously doesnt solve all baro issues, but it could improve the situation.
No. This is the long term reference. The accelerometers are the short term altitude source.
Primary is not the best term. It is the long term reference that is used to correct the accelerometers so that when the EKF adds up all the accelerometer readings to produce an altitude it gives the same as the baro or gps. Yes there are parameters in the EKF that control this but I would not suggest you mess with them or be confident to offer advice on how to do that.
Ok ok I understand better now, from what i can hear I definately prefer to use GPS as source, I think its very dangerous to have that much Drift over time or even because of pressure building up (up to 30m wow!)
I will change source to GPS, do some tests soon and report how it went! Thanks for the feedback everybody.
Hi. I have had the same problem of altitude drifting on a long flight with a 1000 m climb. The drift was even worse (up to 50 m).
I’ve found the parameter EK3_OGN_HGT_MASK to do exactly what @ddomit propose.
I tried setting it to 1 and the flight is stable, it doen’t have glitches in altitude. Haven’t tried yet on a long flight.
Does this mean, if I set the “primary source” to gps for altitude, the drone will still use the accelerometers for rapid and small movement?
How short is the short term reference it uses the accelerometers for? And I’ve noticed in the past that GPS altitude can drift some, why is this not filtered out by the added measurements from the accelerometers?
It would be really interesting to know more about this!
Yes it does. The primary source refers to the primary source of long term corrections. Accelerometers are the only source of fast corrections.
I am not sure but I am guessing it is in the order of seconds. But if you loose gps and baro you have about 10 seconds before you start to see errors.
Because the accelerometers can’t correct position as they only measure acceleration. We must integrate them to get velocity then again to get position. So any small offset in the accelerometer quickly builds up position error. This is why we need gps or baro to remove that offset in acceleration.
If I use the barometer as primary and it suddenly reads a pressure change the FC will trust the barometer?
For example, if forward flight causes a pressure change within the fuselage that change will be detected short term but the FC will trust the barometer over the accelerometers in this case and cause an ascend or descend?
Similarly if I fly under a bridge or close to a forest line which causes the gps to get a bad reading a sudden change in gps altitude would cause an ascend or descend?
If the change isn’t consistent with other sensors you will get an upset EKF. If you have two baro sensors (and only one glitched) it will likely switch to the other lane, otherwise it will slowly correct the perceived altitude error.
PS common mode error across all barometers will cause actual altitude change in the opposite direction of the error. If you have a barometer exposed to induced pressure you should use baro compensation to decrease velocity effects and if that isn’t enough further limit copter velocity to decrease the effect.
I believe this solution is the best solution suggested at the moment. @Yuri_Rage@dkemxr do any of you have an example of this Lua Script or know where i could find one? So i can test and come back with results
That would be greately appreciated, if there is none out there, I need to find the time to create one.
Is there any way to simulate Altitude Drift Over Time with SITL? @Leonardthall
It depends on how much and how fast it changes. If it is outside “normal” variation then the EKF will detect it as a bad sensor and switch to a secondary sensor or wait for it to come back into the “normal” window. If that doesn’t happen for a while you get either an EKF failsafe or EKF reset.
I am not overly familiar with the operation of the EKF in this case but there is only so much you can do. The information must be “observable” meaning you must have enough information to mathematically derive the measurement of interest.
The FC doesn’t trust the accelerometers over the barometer as they measure different things. The EKF will see the baro jump from the expected value and assume that is noise or a glitch. If it is small enough the EKF will continue to fuse the baro data and will change the height estimate to match the baro over the next 5 to 10 seconds.
I assume so but can’t tell you how off the top of my head.
The log below is a nice example. We’re talking about a 35kg MTOW hexa flying at 50km/h in a roundtrip mission.
The body is almost fully enclosed so the EKF was definitely not happy with the baro readings, specially during the return leg, because of the nose-wind.
I think this example is more of a short term wind gusts variations instead of a long term altitude drift, correct me if im wrong. I think you could try to fix this with Windspeed estimation and Baro Compensation
