-
Notifications
You must be signed in to change notification settings - Fork 510
Attitude estimation doesn't start without baro sensor #876
Comments
A source of vertical position and/or velocity is required to estimate the Z accel bias but not having a baro shouldn't block the whole EKF. Same for the mag: #800 |
Actualy if you hasn't a baro sensor,you can make a fake baro always witch 0 height,And you can get a attitude. |
Yes, this is a workaround, but not the solution. By the way for SYS_HAS_BARO and SYS_HAS_MAG parameters description says: |
It doesn't, those drones are usually racers and use the "Q estimator" instead. |
This will be fixed by #931 <= edit: the baro part didn't get merged in that PR |
use-gps-as-height-on-ekf-to-init (PX4#876) use-gps-data-with-increased-precision never-turn-off-yaw-fusion (PX4#905) do-not-use-mag_heading_noise-as-gps-yaw-variance EKF-allow-ekf-init-without-magnetometer control-fix-to-startGpsHgtFusion-again-after-timeout (PX4#951) allow-EKFGSF_yaw-to-work (PX4#902) remove-default-15-m-s-airspeed
We should fake a constant baro measurement with a larger uncertainty and set validity of vz and z to false so control loops don't try to use the height estimate. |
@priseborough, I don't know if it is a suitable solution in general case (I'm working with rovers), but I workaround this issue by using gps height instead of baro (so no initialization until gps is valid) in Line 172 in b3fed06
Of course it would better to check SYS_HAS_BARO instead. |
For now baro data is essential to initialize height in Ekf::initialiseFilter() before switching to another source (GPS, etc.)
https://github.com/PX4/ecl/blob/5356077a3244a9a29adfae4aeaaab900cd28e9e8/EKF/ekf.cpp#L193
But it looks not really adoptable because filters will never get initialized for rovers that could have no baro sensor at all so the attitude estimator will not work (I don't dig enough yet - does attitude estimator itself needs height data?).
The text was updated successfully, but these errors were encountered: