Improve trigger control for survey applications #11878
Commits on Mar 14, 2020
-
Vehicle command: Add mission item to gate mission execution on line o…
…rthogonal to current trajectory
-
-
MAVLink: Add support for new gate command
This enables the vehicle to be able to wait with executing the next item until a position has been passed.
-
Navigator: Add ability to wait for a position gate with executing the…
… mission 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.
-
-
POSIX SITL: Enable trigger control in plane model
This allows to test plane survey missions with the camera trigger included in SITL.
-
Add dedicated survey camera plane model
This is to allow us to test triggering properly in SITL
-
Mission block: Style improvement
Boolean logic improvement to avoid double assignment of true
-
Mission feasibility checker: Handle mission with zero elements silently
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.
-
-
Camera trigger: Improve code readability
This helps to trace the code, no functional changes.
-
Gazebo plane model: Enable tighter turns
This helps to fly smaller / faster test missions.
-
Navigator: Warn only for non-zero missions
Previously a zero-length mission that failed checks (e.g. because a mandatory element was not present) would lead to a warning.
-
Navigator: Improve code readibility
This diff does not contain any functional changes but just makes the code more readable and adds comments.
-
Navigator: Improve documentation of mission block
The default for the gate check condition is to pass and this needed to be explicitly documented
-
Mission block: Gate math cleanup and checks
This change simplifies the gate calculation.
-
Mission feasibility checker: Prevent zero-length trajectories
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.
-
SITL plane: Do not configure trigger
We have a plane_cam configuration for survey applications instead.
