2024-10-18 | Meeting 07

[olenamolla]

During the meeting, the Infrastructure team reviewed the released RFP.
Here is a short summary of what was discussed:

• General communication design: star topology, where the GCS is the central hub, and the vehicles are the nodes.
• GCS connects to the vehicle via Xbee, and the vehicle confirms that the communication is established.
• If the connection is not established on the first attempt, how does the GCS handle this situation?
• How does the GCS ignore messages sent by undefined systems?
• GCS always listens for telemetry data and is able to identify from which vehicle the telemetry data is received.
• If the vehicle disconnects from the GCS, how does the GCS handle this?
• In what format is the telemetry data received? We receive telemetry data, parse it, and forward it to VI (Vehicle Integration).
• In what format are the commands sent? We get commands from VI, parse them, and send them to the vehicle.
• GCS always listens; when it switches to send a command, it stops listening for a very short period of time.
• GCS sends commands to one vehicle at a time. It receives a message from the vehicle confirming that the vehicle received and executed the command.

These tasks should be completed by the time we get Xbees:

• Learn how to configure Xbees: read about API/AT modes of Xbee.
• Write Python scripts imitating receiving telemetry data and sending commands. Think about how it integrates with RabbitMQ. Don't forget to document your code.
• Research how to implement these RFP requirements:
  • If the connection is not established on the first attempt, how does the GCS handle this situation?
  • If the vehicle disconnects from the GCS, how does the GCS handle this?
  • How does the GCS ignore messages sent by undefined systems?

[olenamolla]

some ideas to consider:

• If the connection is not established on the first attempt, how does the GCS handle this situation? - Retry Mechanism with Exponential Backoff
• If the vehicle disconnects from the GCS, how does the GCS handle this? - The GCS should continuously monitor the connection status with each vehicle. One approach is to use heartbeat signals (regularly sent messages or pings) from the vehicle to the GCS. If the GCS does not receive a heartbeat within a specified timeout period, it assumes the vehicle has disconnected. If the GCS does not receive any telemetry or heartbeat signals from the vehicle within a specified timeout, it should flag the connection as lost. This timeout can be set based on how frequently telemetry or heartbeats are expected from the vehicle. Upon detecting a disconnection, the GCS should attempt to reconnect to the vehicle. Use a retry mechanism with exponential backoff (similar to the initial connection failure handling) to re-establish the connection. During this time, the GCS should continue performing other tasks and logging reconnection attempts. The GCS should log details about the disconnection, including the time, the vehicle ID, and the state of the system when it occurred. The GCS should notify the operator through the user interface (e.g, with a popup, sound alert, or status message) that the vehicle has disconnected. The operator can be given options to manually attempt reconnection, troubleshoot the vehicle, or monitor the retry process.
• How does the GCS ignore messages sent by undefined systems? - Message filtering based on identifiers such as Xbee network IDs, vehicle IDs, or message signatures:
• The GCS should maintain a whitelist (list of known vehicle IDs or addresses) that identifies which vehicles it is supposed to communicate with.
• When the GCS receives a message (e.g., telemetry data, commands), it should inspect the message to determine its sender ID (vehicle ID or Xbee address).
• The GCS checks this sender ID against the whitelist of predefined systems.
• If the sender’s ID is not in the whitelist, the GCS ignores the message and logs the event.
• Optional for security purposes: message signing/checksum validation,