Open peterbarker opened 6 years ago
I need to work through the code to understand how the ground speed estimate is being used, however it looks like is is still being used for L1 guidance loops as indicated by https://github.com/ArduPilot/ardupilot/commit/b63d0969b76fe42612289771795f57b1d3e8220f then using airspeed only will not work well and GPS should be preferred. The fusion of airspeed, GPS and yaw were used to get around he problem of the 200mec delay associated with GPS measurements that could destabilise the L1 guidance loops.
If it is still being used by L1, then we should fix the dt.
L1 has been replaced with s-curves. is this one still relevant?
L1 is still used in plane. Would be nice to know if this was ever looked at though. Seems a bit serious.
On Wed, 22 Sep 2021, Tom Pittenger wrote:
L1 is still used in plane. Would be nice to know if this was ever looked at though. Seems a bit serious.
This should get fixed as part of my AHRS rework.
Issue details
The "getter" for
groundspeed_vector()
(https://github.com/ardupilot/ardupilot/blob/master/libraries/AP_AHRS/AP_AHRS.cpp#L189) also happens to feed low-pass and high-pass filters for the GPS and airspeed sensor data.This feeding involves a parameter
beta
which expects adt
of 0.1 seconds. Considering that this "getter" is called in many, many places (including when sending mavlink messages (https://github.com/ardupilot/ardupilot/blob/master/ArduPlane/GCS_Mavlink.cpp#L268)), this is probably not good.Note that the EKF overrides these functions, so they're only called when initialising, if EKF is disabled or if we've fallen back to DCM for some other reason.
@priseborough should we just eliminate the filtering here and just prefer airspeed sensor over GPS? I expect the "fix" is to scale beta based on a true dt measurement.
Version
master (and everything since ~2013)
Platform
[ ] All [ ] AntennaTracker [ X ] Copter [ X ] Plane [ X ] Rover [ X ] Submarine
Airframe type
All
Hardware type
All
Logs
n/a