* RTL Direct: fix rlt time prediction in final lanidng phase
It was previously checking if RTL was already running through
active(), which though actually is coming from the mission mode
that rtl_direct inherits from.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL Direct: remove unnecessary active() check
As the method setRtlPosition() is anyway not called when RTL is active,
plus it checks the wrong thing, as it is the active() method from
the Mission mode.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL Direct: remove unnecessary land_detector_sub.update()
It is already getting updated just before the .get()
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL time estiate: do not distinguish land from sink for MC
To avoid rtl time prediction jump when entering LAND phase due
to no correct handling of loiter altitude (LAND phase doesn't
have to start only when lower then RTL_DESCND_ALT).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Revert "RTL Direct: remove unnecessary active() check"
This reverts commit d5165ba902e65839e792cc13197761c7f77748f9.
* Revert "RTL Direct: fix rlt time prediction in final lanidng phase"
This reverts commit 5af7c928fbf86d560dcd35dd9aea3e38f1e4c735.
* RTL: Make sure to call the initialilze function of the Navigator RTL modes
* RTL: use the navigator_mode run function instead of the on_xxx function directly
* RTL: Make sure that for vtol the right vehicle type is used for each RTL state
* RTL: move to loiter distance estimate should substract the loiter radius for fixed wing
* RTL: time prediction: do not assume VTOL is in FW at start of RTL
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL: time estimation: fix is_in_climbing_submode
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL: time estimation: subtract loiter radius from distance in rtl_direct_mission_land
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* RTL direct: poll important topics also on_inactive such that time estimate is correct
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* navigator rtl: fix setter spacing
* navigator rtl: check pointer before dereferencing
* RTL: only subract loiter radius when in FW
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: Konrad <konrad@auterion.com>
Co-authored-by: Matthias Grob <maetugr@gmail.com>
* AUTOPILOT.capabilities includes gimbal manager protocol bit
Sets MAV_PROTOCOL_CAPABILITY_COMPONENT_IMPLEMENTS_GIMBAL_MANAGER bit in AUTOPILOT.capabilities
* mavlink: update submodule
* mavlink: only set gimbal flag if gimbal param set
We should probably only set the flag if the gimbal manager is actually
set up using the MNT_MODE_IN parameter.
* mavlink: make param optional
If the gimbal module is not built in we don't have the MNT_MODE_IN
param, so we need to deal with that.
* gazebo-classic: update submodule
---------
Co-authored-by: Julian Oes <julian@oes.ch>
This fixes the SITL tests that fail in CI because we catch NAN as non
zero after cast to int. To fix this I've added the check whether they
are finite at all.
The checks for param5 and param6 would be a bit trickier because they
can be int or float, so I have omitted them for now.
* Use target camera in image capture start/stop messages
* Add support for MAV_CMD_SET_CAMERA_SOURCE
* Add target ID for NAV_CMD_SET_CAMERA_MODE
* Run make format
This happens when BAT_CRIT_THR allows arming with a critical battery level. With this change it still fails the checks but only warns instead of doing the failsafe action because that would immediately land the vehicle before it has taken off.
Airspeed sensor failures are crucial to catch early during catapult/hand launches,
as otherwise the large airspeed error can lead to the vehicle diving. Thus the
_in_takeoff_situation flag, which tells the validator when to enable the checks,
is already set to false when !landed and launched.
For runway takeoffs the logic in unchanged.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- in the special case of bad vertical acceleration detected
(bad_acc_vertical) only allow overriding rejected GNSS 3D velocity
if horizontal innovations are accepted
- replace hardcoded 1000 m/s velocity state constraint with new EKF2_VEL_LIM parameter (default 100 m/s)
- new velocity limit also used for GPS checks and external vision velocity
* Added retries if uxrce_dds_client fails during setup
* Break timesync endless loop in case of agent reset
* ORB unsubscribe, to avoid too many open fails with multiple reconnects & format
* Added review feedback
Range does not provide a direct terrain observation but a measurement
relative to the height state. Correlation between height and terrain
must be set properly.
This was already done before the refactor and was assumed to not be necessary.
The problem is that these mission items result in a strang looking vertical slow down directly followed
by an acceleration during the landing phase.
