When position control is disabled, clear the setpoint properly to prevent stale values. This fixes a bug where switching to position mode in the same control loop as a hover thrust estimate update could fill up the velocity integrator.
In cold weather, fuel engines need to be warmed up. Currently, this is done by switching to stabilized mode and throttle up. The issue is that when not using GNSS data, the vehicle is not detected as "at rest" due to vibrations and cannot switch into auto/takeoff modes.
If EKF2_ENGINE_WRM is enabled, and if the vehicle is armed and landed, constant position fusion is enabled.
When operating fully autonomously (i.e., without manual control or a guaranteed link to the ground station), tuning a vehicle can be difficult since the current autotune process requires either RC input or a GCS command. For these scenarios, it it useful to be able to start autotune inside a mission.
Increases signal ampltiude on a 1Hz sin input until a target rate (R/P/Y = 0.8/0.5/0.5 rad/s) is reached. Identification signal is then scaled with this ampltitude instead of the user-defined parameter.
* MulticopterPositionControl: Add timeout before triggering emergency setpoint on invalid TrajectorySetpoint
* Apply suggestions from code review
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
* Cleanup & address review comments
* Safegaurd against using old setpoint if states aren't valid anymore
---------
Co-authored-by: Jacob Dahl <37091262+dakejahl@users.noreply.github.com>
For delivery use-case, the mission contains a land item followed by other mission items. For the
section after the land, the current sequence number is greater than the land start index. If an RTL
is triggered, then isLanding returns true and the vehicle continues with the mission instead of
executing the RTL.
The land index marks the actual landing. So, is landing should only be true for the items between
land_start_index and land_index. If there are items after the land index, then they don't belong
to the landing anymore.
code was checking for an updated MissionResult twice in a row, leading to _mission_state
not being set correctly when the second check had no new message.
Switched to SubscriptionData to safely retrieve the latest message using .get().
Replaced the local variable landed_amid_mission with the class member _mission_in_progress for consistency and to reduce redundancy.
No functional change.