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>
Has options *None where the check is disabled, and *Warning, where only a warning is
published (which replaces the high wind warning from the COM_WIND_WARN limit).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This allows to inject an updated ext_autostart folder with the name
ext_autostart_new, and then PX4 takes care of renaming it to
ext_autostart during bootup.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
For FW takeoffs we need to keep the course straight towards the first
waypoint, and not climb in loiter patterns first.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
A setpoint of type IDLE can be published by Navigator without a valid position,
and should be handled in the auto function in FW_POSCTRL_MODE_AUTO. If it wouldn't be
handled there the controller would switch to mode FW_POSCTRL_MODE_OTHER, in which case
no attitude setpoint is published and the lower controllers would be stuck with the
last published value (incl. thrust).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Positon Controller: set altitude_ref to 0 if not provided by GPS
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* FW Positon Controller: set lat/lon reference to 0 if not provided in local_position
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
If no altitude setpoint is specified then takeoff to the default
altitude above the current global position, not above Home.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
when we're in a takeoff situation, we only want to adapt the airspeed to
avoid accelerated stall due to load factor changes. Disable othre logic
like minimum ground speed, wind based adaption and airspeed slew rating.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
During transition to FF, only allow update thrust axis up to 45° as with a high tilt angle
the effectiveness of the thrust axis in z is apporaching 0, and by that is increasing
the motor output to max.
Transition to HF: disable thrust axis tilting, and assume motors are vertical. This is to avoid
a thrust spike when the transition is initiated (as then the tilt is fully forward).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
EffectivenessTiltrotor: link time when to tilt motors to MC position to COM_SPOOLUP_TIME
- remove VT_TILT_SPINUP and special spin up tilt handling form the VTOL module
- now handle the spoolup in the allocation, directly linked to COM_SPOOLUP_TIME
- leave tilts at disarmed value during spoolup
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
* Navigator: DO_CHANGE_SPEED: only store sinlge cruising_speed_current_mode
This stored cruising speed setpoint is reset on mode change and
after a VTOL transition.
* Navigator Mission: replay DO_CHANGE_SPEED items when resuming mission
* Navigator: remove cruising_speed_sp_update()
Speed changes in a mission are handled directly in the position controllers,
and no longer in Navigator.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Some system are able to dead-reckon for a while after losing GPS or
other sources providing positional feedback. If the estimated position
error grows above the failsafe threshold, the system enters a failsafe
mode. As the position error estimate is growing linerly over time, and
it is recommended to take action before entering the failsafe, we here
warn the user about the imminent failsafe and propose to take manual
control.
---------
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Since we changed the threshold for allowing arming from TRIM/2 to AIRSPEED_MAX
is is very unlikely that one needs to disable this check.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Experience from tuning different VTOL backtransitions showed only having a
I controller is beneficial over a combined FF/I breaking controller.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
When switching into Hold mode establish a Loiter around current position,
even if we were before already loitering (eg in Mission mode).
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Instead of hard-coding the tilting duration (from FW to MC tilt),
expose it as a parameter (VT_BT_TILT_DUR). The default is the same
as the hard-coded value previously (1s).
Slower tilting mechanisms need a higher value here, while for smaller
ones a too high value results in unnecessary delays till the motors
are in hover configuration.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This affects how soon after a backtransition the vehicle has the
full hover controller running again. Specifically it reduces the
duration of the ramp down of the motors prior to tilting them.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
set_vtol_transition_item sets the params of the mission item directly
to values that make sense for NAV_CMD_DO_VTOL_TRANSITION, but don't
for other NAV_CMDs. So make sure that whenever we use it, we then in
the next step reset the touched mission_item fields.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
5s is a more reasobale time for tailsitters, which rely differently on this param
than other VTOL types. Tailsitters will ramp the pitch up withing this time,
while for other VTOLS types its only the max transitiont time.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Silvan Fuhrer