Waypoint Mission Coverage ability

[AskewParity]

🚀 Feature

Enable the waypoint mission to cover some area where we need to take pictures.

Motivation

Whereas we have a pretty clear idea of what the mission wants the waypoints to be (corners),
Whereas our plane is pretty efficient/fast in forward flight,

we could conceivably augment path planning to deviate slightly from the most efficient path in order to take pictures.

Pitch

We should be able to, along with hitting waypoints, fly into the coverage areas (altitude difference as well), start taking pictures, and communicate with other threads/processes. This should not dramatically compromise the complexity/efficiency of the mission, as we can always do dedicated coverage tasks (we probably will have to do at least one pass of coverage anyways).

Alternatives

Hard Code the current algorithm for competition.

Above is the mapping specifications for 2025.

As seen in the image, the airdrop boundary is a subset of the mapping boundary. Because we are limited in the mission time (30 minutes), we want the ability to optimize our waypoints depending on the current state of our mapping and target detection.

Additional context

The primary changes (most important to least)

1. Deviate a path to fly around a coverage area

• Be able to talk to the camera (not unique to this issue)
• Send messages to CV/mapping (not unique to this issue)

2. Record What areas have been sufficiently covered (not unique to this issue)
3. Path plan within the coverage zone for efficient coverage
4. Able to generate additional waypoints such that the choice for coverage is efficient.
5. Support input from CV Pipeline (TBD) but we will have a state var that waypoint can use to consider how many targets have been detected so far.
6. Support input from Mapping (TBD): Same thing, we want to know how complete our mapping is and determine if our waypoints need to be augmented.

[DOteroCaldwell]

General Planning:

1. Shrinking rectangle to contain unmapped area

• Side of bounding rectangle is equal to lowest/highest point of unmapped area polygon

2. Consider the nearest vertices of the rectangle as candidate intermediate waypoints
3. Compare efficiency of detour "trapezoid" to original path
4. Choose detour if cost threshold is met