* Commander: make low remaining flight time configurable and do not clear
- add _ACT param to disable/warning/RTL this feature
- publish rtl flight time estimate also in RTL, and thus fix re-validation
- make failure message clearer, distinguish from battery low
* battery check: add hysteresis for declaring battery_low_remaining_time false again
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: KonradRudin <98741601+KonradRudin@users.noreply.github.com>
Remove option to track from previous wp to reduce complexity and fix
case where prev=current point and the line following broke down.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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 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>
-remove RTL_HDG_MD
-only set heading setpoint in Navigator::RTL once above landing point,
or when RTL is triggered close to it
-never set a heading during RTL if weather vane is enabled
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Instead of directly setting the attitude setpoint for usage inside the same module
only publish it to the uorb topic, which is subscribed to in the same module.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* TECS: reduce default of FW_T_I_GAIN_THR
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* TECS: reduce default of FW_T_THR_DAMP
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* TECS: improve param descriptions and meta data of some params
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Pos C: rename FW_T_THR_DAMP to FW_T_THR_DAMPING
Rename wihtout param translation as the interpretation of this param has changed
recently (a bug was fixed that caused the damping to have a much lower effect than
it should). We want to avoid that users keep the previously tuned value (with the bug)
and do not update the tuning when using the fixed version (v1.14.0 and later).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Pos C: rename FW_T_I_GAIN_THR to FW_T_THR_INTEG
Rename wihtout param translation as the interpretation of this param has changed
recently (a bug was fixed that caused the damping to have a much lower effect than
it should). We want to avoid that users keep the previously tuned value (with the bug)
and do not update the tuning when using the fixed version (v1.14.0 and later).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This check gave a warning when one or more mission items were below the
Home altitude. As it is a valid usecase to plan missions below Home,
those warnings were too often seen as a inconvenience and are thus
removed here.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
That enables us to update the pitch setpoint in Stabilized mode
in the VTOL controller (pitch ramp for transition).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
With this margin it is made sure that if the loiter is not perfectly tracked,
(vehicle outside of path setpoint) a wp just at the border of the loiter
is still reachable.
It should though be as small as necessary, as otherwise, with good
loiter tracking, waypoints that are close but not right on the loiter
radius are not enforcing the exit course neither.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* PositionSetpoint: remove yaw_valid field
* Navigator: set yaw setpoint to NAN for Takeoff
Don't set a yaw setpoint for takeoff, as Navigator doesn't handle the yaw reset.
The yaw setpoint generation is handled by FlightTaskAuto.
* PositionSetpoint.msg: remove disable_weather_vane and instead only use the yaw field
Strictly follow the concept that if the position_setpoint.yaw is set, then
follow it the controller, and otherwise let the controller set it as it
thinks it's best.
* Navigator: remove logic that sets yaw to be accepted in TAKEOFF
No longer needed as during Takeoff we anyway don't set a yaw setpoint.
* PositionSetpoint.msg: remove yawspeed_valid
* PositionSetpoint.msg: remove yawspeed
* Navigator: set yaw setpoint to NAN instead of current
In set_takeoff and set_land_item, as well as for VTOL transition.
The flight tasks then set the yaw corresponding to the current yaw.
* Navigator: change get_yaw_acceptance into a bool
* PositionSetpoint.msg: improve comment for yaw
* MissionBlock: remove unnecessary code from set_vtol_transition_item
* Navigator: clean up calculate_breaking_stop(), set yaw to NAN
* Navigator: set yaw to NAN in variouls places where not specifc setpoint is desired
* Navigator: set yaw to NAN in reset_position_setpoint()
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Co-authored-by: Matthias Grob <maetugr@gmail.com>
1s gives some false positives at boot up, as the airspeed selector only
starts publishing 2s after its startup.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
-remove dedicated vtol transition airspeed init logic
-init airspeed setpoint on first usage of tecs
-init to max of current airspeed and min airspeed
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The _control_mode_current wasn't updated otherwise, and only done so by luck
because we already set the current type to SETPOINT_TYPE_POSITION.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
-remove external init, and instead always (but only) init when dt is too large
-init the controller params correctly
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
The control params (eg min/max pitch) are used before they are
correctly set by TECS::update(). While this is an issue we should fix,
it also doesn't hurt to set them to more reasobale values (eg 30° limit).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
It is generally preferred to have the camera pointing forward on pause,
e.g. to use the camera for Navigation.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Otherwise if is set to Offtrack, which in turn leads to weird behavior.
E.g. when triggering Land while flying fast forward, the vehcile doesn't
descned to the land point it keeps getting a velocity setpoint from the
smoother that pushes it away from the land point.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Only re-evaluate if no longer in GF when flight mode is changed or
Loiter position was changed (eg through goto).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- check if Home would breach it (we do not want to upload GF that
do not allow to return to Home)
- check if the current vehicle position isn't contained in the GF
if armed (as then it would immediately trigger)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- do reporting of breaching in-air only in geofenceCheck
- remove geofence_violation_reason_t
- replace geofence_breached field in GeofenceResult.msg with 3 fields
(one for each GF type: max dist, max alt, custom geofence)
- the warning message after breaching a GF is only done by Commander,
and it's specific to the GF type failure
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- add functionality to specify world name for simulation in case name
- add test for triggering an airspeed invalidation in case of pitot blockage
- add test for high wind (ramped up wind over short period) to NOT invalidate airspeed in this case
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Increase wind process noise default (ASPD_WIND_NSD) and gate
(ASPD_TAS_GATE) to be able to catch rapid wind increases with
the internal wind estimator of the airspeed validator.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Trust the beta innovations more compated to the TAS innovations.
That should help with detecting real airspeed failures even with
a dynamic wind estimate (as long as vehicle doesn't fly straight)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Increasing the wind process noise results in a more dynamic
wind estimation, which is capable of catching fast-varying
winds. As wind is used in the lateral guidance it's important
that we don't filter it too much.
Furher the gate of the airspeed fusion is increased, to
reduce the likelihood of airspeed fusion stopping due to
dynamic wind conditions. The airspeed is validated in
the airspeed validator (EKF consumes the validated one).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Silvan Fuhrer