Feedback

Feedback Message System

During a mission, it is useful for the Ground Operator to know whether a G2A command sent to the aircraft was successfully sent and acted upon. The feedback message system aims to address this requirement.

Algorithm Overview

Feedback is defined in this documentation as a message describing the status of a particular G2A command, which can be one of the following:

• Success: Message successfully sent
• Failure: Message failed to send
• Pending: Message in transit; awaiting a success or failure status.

The feedback message system is designed to give two types of feedback, which is inspired by Telegram's single/double-tick system:

1. Single-Tick Feedback: The command is successfully sent from the GCS on either of the three links, and is in transit to the aircraft
2. Double-Tick Feedback: The command has been received and acted upon by the aircraft.

TO-DO

The current feedback message algorithm only does single-tick feedback. Double-tick feedback is not ready.

Single-Tick Feedback Design

Feedback will be displayed to the Ground Operator on whether a G2A command has succeeded or failed in getting sent out. Two methods are used to detect success or failure

Link-based feedback: Various functions within each link node will provide feedback on status of the command. E.g. in the SMS link node, the send_sms function detects whether the router was able to send an SMS.

Timeout: Each G2A command sent out will be tracked using a countdown timer. When the timer reaches zero, the command is assumed to be lost; hence Failure feedback is displayed to the user.

UUID

Each G2A command needs to be tracked in order to determine the status of that particular command. A Universally Unique Identifier (UUID) is assigned to each command; This UUID is stored in a uuid field in the custom LinkMessage ROS msg.

The uuid field is unsigned 8-bit. It starts from 0; for each successive G2A command sent out, it will increment by 1 until reaching 255, then wrap around back to 0.

Timeout Module

To handle the countdown timers for each G2A command and detect success/failure, a timeout module is used. This module is located in the src folder of the despatcher package, and consists of three main components:

1. Timeout ROS Node: Receive feedback messages from the links, decipher them, and forward them to RQT.
2. MessageTimer Class: A class that is instantiated each time a G2A command is sent out
3. Ack Converter: A function called by the link nodes to generate feedback for each G2A command.

Flow of Feedback

The next few sections describe what happens a G2A command is sent and how its feedback messages are passed from the links, through the timeout node, and finally to the RQT (to be displayed for the Ground Operator)

@TODO: Insert diagram detailing flow of feedback info from links all the way to rqt.

Link Nodes

Within each link node, the respective command sending functions are responsible for handling feedback messages after sending a G2A command;

1. Telegram: Handled by tdlib_topic_cb function.
2. SMS: Handled by send_sms function.
3. SBD: Handled by send_msg in the gnd node. For the server method, feedback is given by _server_send_msg function. For the RB-2-RB method, feedback is given by rockBlockTxSuccess for success, and rockBlockTxFailed for failure.

The general method for receiving and passing feedback messages to the timeout node is:

• When the G2A command is created, a feedback message with "Pending" status is created
• When a success/failure message is received from the hardware (e.g. a "Timeout" message from the router, indicating failure to send an SMS), the corresponding feedback message with "Success/Failure" message is created
• These messages - alongside the G2A uuid and command which they point to - are published to the timeout module via the ogc/to_timeout topic.

Timeout Node

The Timeout ROS Node receives feedback messages from the links, and additionally keeps track of a countdown timer for each G2A command. The node is initiated in the Manager class in the Timeout module.

The node maintains a list of uuids for all G2A commands that are pending feedback. For each incoming feedback from the links, the node responds accordingly:

• When the uuid of the G2A command is not in the list, the node adds it to the list, gives it "Pending" status, and creates a new instance of MessageTimer to begin the countdown for that uuid
• When the uuid is already in the list, the node terminates the timer, marks the message with "Success/Failure" (depending on the feedback received) and forwards the feedback message to the RQT.
• When the countdown timer for a "Pending" uuid reaches zero without receiving any feedback, that uuid is deemed to have failed and the node publishes a "Failure" message to RQT.

RQT

RQT will receive all feedback messages from the Timeout Node and display it on the command window.

Double-Tick Feedback Design

TO-DO: This has yet to be implemented

The projected design for double-tick feedback also aims to let the Ground Operator know if a G2A command was successfully received and acted upon by the aircraft, or failed. As it is more difficult to detect remote success/failure, the following system is proposed:

1. Detecting Success: The air despatchers are designed to send an acknowledgement message when successfully executing a received G2A command. Receiving this acknowledgement message on the ground side indicates success; hence a "Success" feedback will be sent to the Timeout Node and subsequently the RQT. The acknowledgement message will contain the uuid of the original G2A command in the payload.
2. Detecting Failure: The timeout counter will not reset until acknowledgement message for that G2A command is received; a timeout indicates that either the original command or its acknowledgement was lost, and a failure feedback message will be displayed to the user.

Note

The uuid of the original G2A command will be placed in the payload of the acknowledgement message, not the LinkMessage uuid field! The acknowledgement message will have its own separate uuid located in that field.