Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

Attitude estimation doesn't start without baro sensor #876

Open
lukegluke opened this issue Jul 27, 2020 · 7 comments
Open

Attitude estimation doesn't start without baro sensor #876

lukegluke opened this issue Jul 27, 2020 · 7 comments

Comments

@lukegluke
Copy link

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?).

@bresch
Copy link
Member

bresch commented Aug 3, 2020

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

@garlinplus
Copy link

Actualy if you hasn't a baro sensor,you can make a fake baro always witch 0 height,And you can get a attitude.

@lukegluke
Copy link
Author

Yes, this is a workaround, but not the solution.

By the way for SYS_HAS_BARO and SYS_HAS_MAG parameters description says:
Disable this if the board has no magnetometer[barometer], such as the Omnibus F4 SD.
I wonder how ekf2 works on Omnibus F4 SD then?

@bresch
Copy link
Member

bresch commented Dec 11, 2020

I wonder how ekf2 works on Omnibus F4 SD then?

It doesn't, those drones are usually racers and use the "Q estimator" instead.

@bresch
Copy link
Member

bresch commented Dec 11, 2020

This will be fixed by #931 <= edit: the baro part didn't get merged in that PR

lukegluke added a commit to lukegluke/PX4-ECL that referenced this issue Feb 22, 2021
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
@priseborough
Copy link
Collaborator

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.

@lukegluke
Copy link
Author

@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 Ekf::initialiseFilter() here.

// accumulate enough height measurements to be confident in the quality of the data

if (_params.vdist_sensor_type == VDIST_SENSOR_BARO) {
    // accumulate enough height measurements to be confident in the quality of the data
    if (_baro_buffer.pop_first_older_than(_imu_sample_delayed.time_us, &_baro_sample_delayed)) {
        if (_baro_sample_delayed.time_us != 0) {
            if (_hgt_counter == 0) {
                _baro_hgt_offset = _baro_sample_delayed.hgt;

            } else {
                _baro_hgt_offset = 0.9f * _baro_hgt_offset + 0.1f * _baro_sample_delayed.hgt;
            }

            _hgt_counter++;
        }
    }

} else if (_params.vdist_sensor_type == VDIST_SENSOR_GPS) {
    if (_gps_buffer.pop_first_older_than(_imu_sample_delayed.time_us, &_gps_sample_delayed)) {
        if (_gps_sample_delayed.time_us != 0) {
            if (_hgt_counter == 0) {
                _baro_hgt_offset = _gps_sample_delayed.hgt;

            } else {
                _baro_hgt_offset = 0.9f * _baro_hgt_offset + 0.1f * _gps_sample_delayed.hgt;
            }

            _hgt_counter++;
        }
    }
}

Of course it would better to check SYS_HAS_BARO instead.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants