This includes the following:
- Remove warning/throw_error flag as it is always !home_alt_valid.
- Remove impossible code path when home_alt_valid = false and
throw_error = false.
- Add home_alt_valid check in second check before using home_alt.
- Only use warning for the second check to allow waypoints below home.
- Don't return early when only warning.
This reverts the addition of a check against mission items that have the
same position. This breaks existing MAVSDK implementations where a
LOITER_TIME item is set right after a WAYPOINT with the same
coordinates. It is an interim hack to allow the vehicle to hold still
during a photo is captured.
This leaves the check in place for gates where we need to be able to
calculate the direction between gate and waypoint.
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 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.
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.
Fixes these invalid format strings:
- A `%d` for a pointer (replaced it by `%p`)
- A 0x%08x (and a 0x%0x8!) for a pointer (replaced by %p)
- 2 cases of `%d` for a `ssize_t` (replaced it by `%zi`)
- 1 case of a %u for an `int` (replaced by %i)
- 3 cases of %d for a `long` (replaced by %ld)
- 19 cases of `%d`, `%i`, `%u` or `%lu` for a `size_t` (replaced it by `%zu`)
- An unused formatting argument (removed it)
- A missing `%d` (added it)
- A missing `%s` (added it)
- 2 cases of `%llu` for a `uint64_t` (replaced it by `"%" PRIu64`)
- 6 cases of giving a string directly as format string (replaced it by `("%s", string)`)
- 2 cases of %*-s, which should probably have been %-*s.
(Looks like NuttX accepts (the invalid) %*-s, but other platforms don't.)
- A %04x for a `uint32_t` (replaced by "%04" PRIx32)
This was wrong, instead of warning at 2/3 of the max distance as
mentioned in the comment, we would start to warn at 3/2 of the distance
which would then never actually happen.
When checking a mission, the takeoff altitude is being checked
against the waypoint acceptance radius to ensure the MAV being
clear from ground before heading to the next waypoint.
However, until now the _horizontal_ acceptance radius was being
used, instead of the altitude reference value.
Targets PX4/Firmware/#7379
Instead of just checking whether the first waypoint is too far away from
home it makes sense to also check between waypoints.
This can prevent
- flyaways due to user errors, or
- catch the corner case where a takeoff waypoint is added to a mission
and therefore the first waypoint is not too far away, however, the
subsequent waypoints are still too far away.
Beat Küng