* Mavlink: subscribe to airspeed_validated instead of airspeed topic
This e.g. changes the way QGC displays the airspeed in case of an
airspeed failure (0 instead of the last valid airspeed). It will
always display the airspeed that's used currently in the control
modules.
* FW land detector: move to subscribe to airspeed_validated instead of airspeed topic
- the land detector checks further if the airspeed is NAN, in which case
it sets the airspeed to 0 (min groundspeed, vz and accel checks still
have to pass.
* Fixed-wing land detector use airspeed_vaidated: addressed review comments
- replaced ternary by conditional
- set airspeed to 0 if airspeed_validated stops publishing
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- rename of flag in position sp: from allow_weather_vane to disable_weather_vane
- flag now doesn't have to be set for all auto modes, meaning that weather vane is also active outside of mission
- flag is set before front transition to align with wp, and unset after alignment is over
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Unfortunately this commit contains two things:
1. Some cleanup and renaiming.
2. An additional wait until lockstep has been initialized.
By waiting until HIL_SENSOR messages arrive including timestamps we
stop the startup script and prevent other modules from running until
time is set up. This should resolve some busy waiting by various
modules and prevent races on initialization (e.g. the landing state
being subscribed by mavlink before being published by the land
detector).
The previous boot configuration took at minimum one second to boot. This is in particular significant in tests when the system is often started and stopped
The test was testing the result of 3D float vector operations with binary equality of the floating point numbers, which is not a valid assumption to make for floating point math. This change switches to proper comparisons with float accuracy and compares vectors using the norm of their difference.
This is a check to protect a user from upload a mission which includes a
land_start marker as well as a RTL mission item.
This works around the problem that we experienced where the navigator
would switch to mission mode on RTL and start with land_start, and then
continue to the RTL item. At this point, navigator would send the
vehicle_command for RTL to commander which would deny it because it is
already in RTL mode. Thus navigator won't (re)set any items to actually
do RTL and it means the vehicle will just head to whatever setpoint it
received last.
A VTOL mission can also contain a fixedwing landing. Therefore, I think,
it makes sense to run the fixedwing checks as well, however, don't check
for a landing start necessarily.
Daniel Agar