ArduPilot / ArduPilot/ardupilot
AP_AHRS groundspeed_vector() filters run at incorrect frequency
- Dominant language
- C++
- Stars
- 15.9k
- Forks
- 21.4k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 119
Description
#### 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 a `dt` 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
Contributor guide
Research direction
Start in libraries/AP_AHRS/AP_AHRS.cpp at the groundspeed_vector() getter and compare its filter updates with the beta value's expected 0.1-second interval. Review the call from ArduPlane/GCS_Mavlink.cpp and other callers to establish how often the getter runs. Done means the GPS and airspeed filters no longer depend on incidental getter frequency, with the chosen behavior validated for the listed fallback cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- embedded-iot, robotics
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100