The mission logic depends in a number of locations on being able to calculate the direction from one waypoint to another. Missions that have waypoints that are in the same physical location do not make sense and need to be rejected (the GCS / SDK generating them needs to be fixed). By enforcing this we can work with a reasonable and simpler state machine while executing the mission.
A mission with zero elements is invalid but should not lead to a warning. Previously a fixed wing aircraft without a mission did emit warnings about a missing land item.
This enables the navigator to wait for a specific gate coordinate to pass orthogonally to the current trajectory. This is particularly helpful for payload / camera handling in missions and avoids a dependency of payload handling on navigation waypoints.
Prior this fix VTOL missions get rejected if they have a DO_LAND_START marker, but then do
not end with a LAND waypoint but a VTOL transition and land.
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
This avoids premature state machine execution, most notably for missions.
In particular this fixes these issues:
- when landed, and the vehicle has a valid mission: switching to mission
would execute the first item.
- after executing a mission with a land waypoint, the mission is reset
and the first item is executed.
In case the first waypoint is a takeoff, it would print a user message:
"Takeoff to x meters above home.". If it was a vehicle command, it would
execute that.
Note that because the vehicle is disarmed, the vehicle would not actually
do anything (except for commands that are accepted while disarmed).
* Treat UAVS diffrently from manned aviation
* Added fake_traffic testing functionality,
* Added NAV_TRAFF_AVOID Hold and Landmode
* Added Behavior: HOLD Position to collision avoidance mode and implemented Landmode to collision avoidance.
Boards where no Hardware GUID is defined will send 0 as GUID.
Right now collision avoidance for more than one FMU without Hardware GUID is not possible.
We should consider adding a randomly generated HW GUID as a placeholder for legacy Boards
- rename of flag in position sp: from allow_weather_vane to disable_weather_vane
- flag now doesn't have to be set for all auto modes, meaning that weather vane is also active outside of mission
- flag is set before front transition to align with wp, and unset after alignment is over
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
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.
Lorenz Meier