This is a check to protect a user from upload a mission which includes a
land_start marker as well as a RTL mission item.
This works around the problem that we experienced where the navigator
would switch to mission mode on RTL and start with land_start, and then
continue to the RTL item. At this point, navigator would send the
vehicle_command for RTL to commander which would deny it because it is
already in RTL mode. Thus navigator won't (re)set any items to actually
do RTL and it means the vehicle will just head to whatever setpoint it
received last.
A VTOL mission can also contain a fixedwing landing. Therefore, I think,
it makes sense to run the fixedwing checks as well, however, don't check
for a landing start necessarily.
This fixes a corner case for VTOL RTL with RTL_TYPE 1.
RTL_TYPE 1 means that the VTOL skips all waypoints on RTL and jumps to
the land waypoint at the end.
During a mission in fixedwing mode it will continue to fly in fixedwing
mode and then do a transition before landing.
However, if RTL is engaged right at the moment of the front transition,
the transition waypoint is not inserted and the VTOL will try to land in
fixedwing mode at the mission land location.
This corner case is fixed in this patch by also considering the
"transition after takeoff" state.
The navigator has a notion of resetting the triplets which means the
triplet setpoints are set to invalid and therefore not to be used by
downstream modules such as flight tasks.
However, before this patch, the triplets were not published if invalid
meaning that a valid triplet would stay the truth until a new valid
triplet would get published.
E.g. this lead to the corner case case where we publish a valid triplet
with an IDLE setpoint on ground in HOLD and then don't update the
triplet while flying in POSCTL mode. Later, when RTL is engaged, the
flight task will use IDLE until navigator (which runs slower) has
published the next triplet.
The fix involves two main changes:
- Publish invalid triplets to avoid stale triplets.
- Avoid publishing the triplet on every iteration in manual modes by not
setting `_pos_sp_triplet_published_invalid_once = false`.
When testing this I realized that a mission upload during RTL would stop
RTL. This is because the mission is updated while the mission navigation
mode is not active and reset_triplets() is called from there. This is
now only done for the case where we are actually in mission navigation
mode. The fact that a mission is updated when not active also seems
wrong and is something to fix another time.
and remove the px4_ prefix, except for px4_config.h.
command to update includes:
for k in app.h atomic.h cli.h console_buffer.h defines.h getopt.h i2c.h init.h log.h micro_hal.h module.h module_params.h param.h param_macros.h posix.h sem.h sem.hpp shmem.h shutdown.h tasks.h time.h workqueue.h; do for i in $(grep -rl 'include <px4_'$k src platforms boards); do sed -i 's/#include <px4_'$k'/#include <px4_platform_common\/'$k/ $i; done; done
for in $(grep -rl 'include <px4_config.h' src platforms boards); do sed -i 's/#include <px4_config.h/#include <px4_platform_common\/px4_config.h'/ $i; done
Transitional headers for submodules are added (px4_{defines,log,time}.h)
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.
Julian Oes