Mission

The mission subprotocols allow the GCS to read and update the stored mission on the UAV.

Mission Read

The mission read subprotocol allows the GCS to read the mission from the UAV, either initiated by the Operator or when a connection is established.

Messages

1. MISSION_READ_REQUEST
2. MISSION_ITEM_COUNT
3. MISSION_ITEM_READ_REQUEST
4. MISSION_ITEM
5. MISSION_ITEM_INVALID

Sequence

sequenceDiagram
    participant GCS
    participant UAV

    loop n

        GCS->>UAV: MISSION_READ_REQUEST
        GCS->>GCS: Start timeout

        alt success

            UAV-->>GCS: MISSION_ITEM_COUNT

            loop item_count

                GCS->>UAV: MISSION_ITEM_READ_REQUEST
                GCS->>GCS: Start timeout

                alt success
                    UAV->>GCS: MISSION_ITEM<br />/MISSION_ITEM_INVALID
                else failure
                    GCS->>GCS: Timeout expires
                end
            end

        else failure
            GCS->>GCS: Timeout expires
        end
    end

1. When the GCS wants to read the stored mission from the UAV, it sends a MISSION_READ_REQUEST to the UAV.
2. The GCS starts a timeout of a fixed duration.
3. If the UAV responds with a MISSION_ITEM_COUNT message before the timeout expires, the operation moves ahead.
4. If the timeout expires before the UAV can send a response, the GCS retries the operation upto n times before the operation is considered a failure, the error is reported and the UAV continues operations.
5. If the UAV responded in time, the GCS sends MISSION_ITEM_READ_REQUEST messages to fetch the waypoints one by one.
6. The GCS starts a timeout of a fixed duration.
7. For each MISSION_ITEM_READ_REQUEST, if the UAV responds with a MISSION_ITEM message, the operation moves ahead. If the UAV instead responds with a MISSION_ITEM_INVALID message (indicating that a corner does not exist for the request index), the operation is cancelled.
8. If the timeout expires before the UAV can send a response, the entire operation is cancelled.

Notes

• The mission in-use by the GCS is not updated before the entire set of waypoints is received from the UAV. If the operation fails midway, the error is reported and the previous mission continues to be displayed.
• If reading a single waypoint fails, the entire operation is cancelled (this is not obvious from the nested loop structure).
• The transmission of the waypoint count and individual waypoints are kept stateless for easy error handling and recovery -
  • If the UAV does not respond with the count/GCS does not receive the count, the GCS retries the operation without affecting the subprotocol state of the UAV, since the count is sent exclusively as a response to the MISSION_READ_REQUEST message.
  • If the UAV does not respond with a specific waypoint/GCS does not receive the corner, the GCS retries the operation without affecting the subprotocol state of the UAV, since each waypoint is sent exclusively as a response to the MISSION_ITEM_READ_REQUEST message.
  • A failure at any stage is immediately made known to the Operator by the GCS so that operations can be ceased, without leaving the UAV in an invalid state.

Mission Write

Messages

1. MISSION_WRITE_REQUEST
2. MISSION_WRITE_REQUEST_NACK
3. MISSION_ITEM_READ_REQUEST
4. MISSION_ITEM

Sequence

sequenceDiagram
    participant GCS
    participant UAV

    loop n

        GCS->>UAV: MISSION_WRITE_REQUEST
        GCS->>GCS: Start timeout

        alt sucess

            loop item_count

                UAV->>GCS: MISSION_ITEM_READ_REQUEST
                UAV->>UAV: Start timeout

                alt success
                    GCS-->>UAV: MISSION_ITEM
                else failure
                    UAV->>UAV: Timeout expires
                end
            end

        else cancelled
            UAV-->>GCS: MISSION_WRITE_REQUEST_NACK
        else failure
            GCS->>GCS: Timeout expires
        end
    end

1. When the GCS wants to update the stored mission on the UAV, it sends a MISSION_WRITE_REQUEST message (includes the number of waypoints) to the UAV.
2. The GCS starts a timeout of a fixed duration.
3. If the UAV responds with a MISSION_ITEM_READ_REQUEST message before the timeout expires, the operation moves ahead.
4. If the timout expires before the UAV can send a response, the GCS retries the operation upto n times, before it is considered a failure.
5. Each time after the UAV responds with a MISSION_ITEM_READ_REQUEST, it starts a timeout.
6. If the GCS responds with a MISSION_ITEM message before the timeout expires, the operation is moves ahead.
7. If the timeout expires before GCS can send a response, the entire operation is cancelled.

Notes

• The mission in-use by the UAV is not updated before the entire set of corners is received from the GCS. If the operation fails midway, the error is reported and the previous geofence continues to be displayed.
• If reading a single waypoint fails, the entire operation is cancelled (this is not obvious from the nested loop structure).