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.
This change limits all mission items to the maximum flight altitude. The mission will still be executed and flown,
but the vehicle will never exceed the mission altitude. This ensures the vehicle can always reach the mission
items. Wether or not the entire mission should be rejected if it falls outside of the fenced area is enforced
in the mission feasibility checker function.
* FW actuators fully on the entirety of front and back transition
* back transition ramp up to full MC weight half way through back transition
* increase maximum front and back transition times
* navigator don't reset transition altitude
If the vehicle was already in air on takeoff and the waypoint gets converted to a regular waypoint the wait / delay time does not get reset to zero. This change ensures the next mission item is approached immediately.
- weathervane on takeoff
- separate cruising speeds for VTOL in MC and FW
- cruising speed resets
- mission work item logic is more clear
- fixed double execution of certain work item states
- enable cruise speed change on the fly by command
- moved VTOL transition target position generation to mission code and set always
This reset the cruise speed which can be set by mission items/waypoints
to set a custom speed. Once, switched out of mission, it makes sense to
use the speed set by the param again.
* navigator/mavlink: always send last reached item
Since we can't rely on mavlink that every message arrives, it makes
sense to continuously send the last reached waypoint.
* navigator: don't report reached for takeoff
If a takeoff waypoint has been inserted, we should not report that we
reached a mavlink mission item because we actually have not.
The mission feasability checker was called with the same arguments
twice which made it hard to understand when a mission is marked valid.
The mission check should run in these two cases:
- When initializing (if home comes up) if there is already a mission saved.
- When the mission gets updated.
The mission feasability checker was called with the same arguments
twice which made it hard to understand when a mission is marked valid.
The mission check should run in these two cases:
- When initializing (if home comes up) if there is already a mission saved.
- When the mission gets updated.
Daniel Agar