This adds a flight task to catch the case where we want to do an
emergency descent without GPS but only a baro.
Previously, this would lead to the navigator land class being called
without position estimates which then made the flight tasks fail and
react with a flight task failsafe. This however meant that landed was
never detected and a couple of confusing error messages.
This applies if NAV_RCL_ACT is set to 3 "land".
The asinf function is NaN outside of -1 to 1. Therefore, it probably
makes sense to constrain the input to prevent NaN setpoints further down
the line.
A NAN is interpreted in the FlightTaskAuto as a non-valid global coordinate and sets a local position.
If a zero is sent instead, the global coordinate is recognized as valid and will be executed.
This is a problem when the global position is gained for the first time after takeoff and that a valid global reference did not exist before
- user defines a cone half angle which defines the RTL altitude behavior
- if vehicle is outside the cone it will climb until it intersects the cone
and then return at this altitude.
- if vehicle is inside the cone or above the predefined return altitude (RTL_RETURN_ALT)
then it will return at the current altitude
Signed-off-by: RomanBapst <bapstroman@gmail.com>
By declaring the params above the navigator modes inheriting from
mission block we make sure the params in navigator are set before
read in the constructor of mission block.
changed: "Mission rejected: land start required."
to: "Mission rejected: landing pattern required."
This new message is more clear to the average user. When using RTL_TYPE = 1, mission feasibility checker adds the requirement of a landing sequence beginning with a MAV_CMD_DO_LAND_START and ending with a MAV_CMD_NAV_LAND with at least 1 other waypoint prior to the land waypoint. The warning message "Mission rejected: land start required." is a common warning to trigger whenever the mission is blank or the mission is uploaded without a landing pattern. The wording in this message confusing to the average user as they usually do not know the inner workings of the "landing pattern" that their planning software helps them make (e.g. Qgroundcontrol). The only users who would know what a "Do_Land_Start" mission item is are advanced users already and this new message should work equally well for them as well as the non-advanced user.
- also applies to mission_stats_entry_s, mission_fence_point_s,
mission_save_point_s
- -Wpadded warning is disabled by default because the snapdragon
toolchain doesn't respect the pragma pop