ardupilot
ardupilot copied to clipboard
ArduPilot
Support MAV_CMD_EXTERNAL_WIND_ESTIMATE
When flying without a GPS receiver, drift correction does not work properly because the autopilot does not have information about the wind speed and direction. I can get wind information using online services (e.g. windy.com) and with this command set a custom wind speed and direction, which will greatly improve drift correction.
This is very important when flying without GPS.
Should we have a timeout on the use of this wind estimate?
IMHO it is likely that the estimate will be closer to truth than 0 wind velocity unless the wind is rapidly changing which will mess with dead reckoning no mater what you do.
Playing with MAVProxy command: long EXTERNAL_WIND_ESTIMATE 10 0 30
AHRS_EKF_TYPE of 0 (DCM)
On ground With AIRSPEED_USE of zero:
On ground With AIRSPEED_USE of one:
In-flight when loitering with a 5m/s wind from 180 (with airspeed)
In-flight when loitering with a 5/m/s wind from 180, without airspeed:
@priseborough I notice in your branch here: https://github.com/priseborough/ardupilot/commits/pr-ekfWindStateUpdate-rebase04/ that you seem to be doing the same thing, but with EKF3 instead of DCM how close is that to being ready? Should we merge the DCM only PR first and then layer yours on top?
@tridge do you want to try Pauls branch in SITL, with DCM fallback disabled?
@python36 what sorts of boards are you running this on? We're wondering how to guard the feature compilation-wise, whether to say >1024MB instead of DCM (need to change the latter when EKF3 supports it).
@priseborough I notice in your branch here: https://github.com/priseborough/ardupilot/commits/pr-ekfWindStateUpdate-rebase04/ that you seem to be doing the same thing, but with EKF3 instead of DCM how close is that to being ready? Should we merge the DCM only PR first and then layer yours on top?
@tridge My branch is very close. I'm in the process of finalising autotests. I vote we merge this first and I'll rebase and deal with the AHRS library conflicts.
FYI the https://github.com/priseborough/ardupilot/commits/pr-ekfWindStateUpdate-rebase04/ branch bundles a few dead reckoning inprovements:
Enables a VTOL to fly using dead reckoning when GPS is unavailable provided the origin is set before flight. Keeps the last known local position after dropping out of dead reckoning when going from forward flight to VTOL modes. Uses MAV_CMD_EXTERNAL_POSITION_ESTIMATE messages to update the wind estimate. Uses MAV_CMD_EXTERNAL_WIND_ESTIMATE messages to update EKF3 wind estimates also using the accuracy fields to set the wind state covariances. Vehicle velocity is also updated to be consistent with the wind and airspeed.
@python36 what sorts of boards are you running this on? We're wondering how to guard the feature compilation-wise, whether to say >1024MB instead of DCM (need to change the latter when EKF3 supports it).
I am using fmuv3 board so I have 2MB of flash on board. I created a new commit.
This is a very interesting feature but one question I have about the implementation is why was MAV_CMD_EXTERNAL_WIND_ESTIMATE used? It's really not a command so it probably should have been provided using a new mavlink message.
