We had a special handling for RTL triggered in vtol_takeoff state.
The idea is to wait until the VTOL Takeoff is completed and only
then switch to RTL. On a second thought this special handling isn't
really necessary and for the sake of simplicity should be removed.
This also removes the side effect of the indicated flight mode
after RTL being set to VTOL_Takeoff again.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Position Control: some cosmetical changes
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Position Control: disable roll constraining warning in VTOL transition
In transitions it is expected that the roll is constrained, and
instead of defining an aribitrary threshold let's rather disable
the user warning in that case.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Pos C: define magic numbers for roll constraining warning as constants
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The gyro bias estimate from EFK2 is really good when at rest and should
be used by the yaw estimator to prevent heading drifts due to poor
heading observability.
The main problem was that during initial negotiation the client would
request the gimbal_manager_information from px4 but px4 would never send
it because in this configuration the device_compid was set to 0.
`estimator_baro_bias` requires to have GNSS and baro hgt active and GNSS as the reference. This is quite restrictive. Instead, we can simply use a high-passed version of the baro error.
MissionBase did not initialize its mission data, thus could enter an
infinite loop in updateDatamanCache() if the initMission() failed to
read the mission off, for example, due to the SDCard storage task taking
longer than the timeout to respond.
This change constrains the loading loop and resets the mission data even
if the data write failed.
The setpoint.yaw can be NAN, and this made the calculated land point NAN
as well. Looking at the current yaw is anyway a better way to approximate
the course over ground that fundamentally should be used.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
ADd a new misison feasiblity checker option to check if a proper landing approach is defined when in air. There must be at least a mission landing or a VTOL approach defined in order for the mission to be accepted. Else, use the same logic as in MIS_TKO_LAND_REQ=4
* publish the global groundtruth from the navsat callback and rearrange the local groundtruth as the altitude reference now has a dependency on the global groundtruth being initialized
---------
Signed-off-by: frederik <frederik.anilmarkus@gmail.com>
