The sensor and command data is transferred via specifically allotted network ports:

• The video port communicates the live stream via a TCP connection.
• The command port is used to send commands to actuate the motors and drive the robot.
• The sensor port is used to send telemetry data to the client.
• The GPS port sends the location coordinates to the client.

• Packets are framed with data from sensors/commands, with extra attributes of date-time and key.
• The server does not broadcast the sensor packets, rather waits for the client to send a query, which is then modified to include the sensor information.
• Each packet is bundled with a timestamp as mentioned above which is used by the client to calculate the packet travel time, thus giving us the value of the latency.

• This server has a main server thread and a sub I2C polling thread that runs on the SOC computer on the robot.
• The I2C polling thread polls the individual sensors on the I2C bus and keeps the sensor data ready for the server thread.
• When the server thread receives a query from the client requesting the sensor data, this thread takes the current data (from the sensor polling thread) and sends to the client.

• Runs as a sub-thread inside the PyQt GUI.
• Queries the server for the sensor data continuously.
• On receiving a reply it sends the sensor data to the main thread bundled as a signal.
• It also calculates the travel time of the packets to give the latency.

• This server has a main server thread and a sub SPI commanding thread that runs on the SOC computer on the robot.
• The SPI commanding thread sends commands to the motor/actuator micro-controllers continuously.
• It employs error correction by sending random values and checksum values bundled with the data to be written.
• The controllers verify the integrity of the data by checking the checksum received and the calculated checksum.
• The main server thread updates the command variables when it receives command packets from the client. These are immediately reflected on the robots movement as the SPI thread continuously writes them to the controllers.
• The received command packet is sent back as an acknowledgement by the server thread.
• Whenever a connection is lost a timeout is issued which halts the robot in its position thus preventing any damage due to disconnections.

• Runs as a sub-thread inside the PyQt GUI.
• Captures the keyboard key positions (or joystick positions) .
• Depending on the key combinations (or joystick positions), it sends the appropriate commands to the server.
• It checks for the received acknowledgement packets and calculates the time difference to give us the latency.

• Client runs as a sub-thread inside the PyQt GUI.
• Server runs run on the SOC computer on the robot. It has 2 threads.
• GPS thread (server) gets GPS data from the sensor and keeps it ready for the main server thread.
• The main server thread sends this GPS data when queried.
• The Client queries the server for GPS data and calculates the travel time.
• Very similar to I2C server/client operation.

• Uses TCP as video data is serially sent and continuity is important.
• The server gets H.264 muxed raw stream from the Camera connected to the SOC computer.
• It pipes it via a TCP connection to the client.
• The client receives the connection and demuxes the H.264 stream to play it on the GUI.

• The above mentioned servers run parallel as multiple processes.
• This improves the speed and reliability of the robotic system.
• Makes the system near real-time.

• The above mentioned servers/clients are non-blocking.
• They reconnect as and when there is a timeout.
• They are designed to move on in case of error and not stop the process.
• This makes them robust.