Support MAV_CMD_EXTERNAL_WIND_ESTIMATE

[python36]

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.

[python36]

@peterbarker I make a new commit taking into account your proposals.

[peterbarker]

Should we have a timeout on the use of this wind estimate?

In your testing, how long does the use of this estimate last during a flight?

An autotest for this would be nice.

[LupusTheCanine]

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.

[peterbarker]

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:

[peterbarker]

Solid autotest.

Needs to be broken into several commits, one-per-subsystem with appropriate commit commits.

See https://ardupilot.org/dev/docs/git-interactive-rebase.html and Tools/gittools/git-subsystems-split

[peterbarker]

Why this reboot?

[python36]

Without rebooting it crashes with the problem:

2024-09-02T10:59:42.8273703Z AT-1454.7: mavproxy_start was called 3 times
2024-09-02T10:59:42.8274525Z AT-1454.7: Supplied terrain data to autopilot in 1176 messages
2024-09-02T10:59:42.8275279Z Had to force-reset SITL 1 times
2024-09-02T10:59:42.8276256Z AT-1454.7: Writing test result in jUnit format to autotest_result_ArduPlane_test.Plane_junit.xml
2024-09-02T10:59:42.8277039Z 
2024-09-02T10:59:42.8277325Z >>>> FAILED STEP: test.Plane at Mon Sep  2 10:59:42 2024
2024-09-02T10:59:42.8277981Z Failure Summary:
2024-09-02T10:59:42.8278383Z   test.Plane:
2024-09-02T10:59:42.8278959Z     TakeoffAuto3 (Test the behaviour of an AUTO takeoff, pt3.
2024-09-02T10:59:42.8279511Z 
2024-09-02T10:59:42.8279661Z         Conditions:
2024-09-02T10:59:42.8280127Z         - ARSPD_USE=1
2024-09-02T10:59:42.8280609Z         - TKOFF_OPTIONS[0]=1
2024-09-02T10:59:42.8281646Z         ) (Wrong value) (see /tmp/buildlogs/ArduPlane-TakeoffAuto3.txt) (duration 1.3573386669158936 s)
2024-09-02T10:59:42.8284539Z     MAV_CMD_EXTERNAL_WIND_ESTIMATE (test MAV_CMD_EXTERNAL_WIND_ESTIMATE as a mavlink command) (Failed to set wind speed or/and direction: speed != 1 or direction != 45) (see /tmp/buildlogs/ArduPlane-MAV_CMD_EXTERNAL_WIND_ESTIMATE.txt) (duration 0.09662985801696777 s)
2024-09-02T10:59:42.8286841Z FAILED 1 tests: ['test.Plane']
2024-09-02T10:59:42.9402933Z ##[error]Process completed with exit code 1.```

[tridge]

@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]

@tridge do you want to try Pauls branch in SITL, with DCM fallback disabled?

[peterbarker]

@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]

@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.

[priseborough]

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]

@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.

[peterbarker]

Merged, thanks!

[python36]

Merged, thanks!

🎉🎉🎉 Thanks all.
@peterbarker Thank you very much

[rmackay9]

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.