Find out more about how this fits into the overall design by reading about the Software_Design.

What is it?

The backend interface, is the interface between the Body and the Backend. We communcate over UDP using a custom protocol (defined below). The purpose of the backend is to send commands to devices and to retrieve information from devices.

Overview

The purpose of the backend inteface is to control devices (such as motors) and retrieve data from sensors (encoders, battery meters, etc.). We also want to be able to seamlessly substitute a simulator for the devices, and we want to be able to easily monitor device data using a transparent third party. For these reasons, we chose UDP as the communication method of choice

On one side of the backend is the backend_decoder in the main block, and on the other end is a series of devices. Devices can be the simulator or actual hardware devices. When using hardware, each 'device' consists of a driver controlling a hardware element (details on the Backend page).

The backend uses a very simple communication protocol consisting of data packets, and command packets. Packet structures can be found here. There is only one command packet that is sent to all devices (particular devices are selected within the packet). The main purpose of the command packet is to start/stop the device. The data packets send specific device information (motor speeds, encoder counts,...). All data is timestamped and checksummed to provide some level of integrity checking.

Communication Protocol

UDP

All data sent over the backend interface is sent over UDP. UDP is similar to TCP in that it is a common internet protocol, built into standard libraries. It does not provide the reliability of TCP, but it does make it easy to receive large amounts of data where any particular piece of data is unimportant. And it makes it easy to broadcast that data to multiple recipients.

Data Packets

The data packets are very straight-forward. The contain the data relevant to a particular hardware element (motor values, encoder counts, ...) in addition to a header, timestamp and checksum. Details of these packets are on the IGVCstructs page. Data packets are sent as new data arrives (i.e. they are not periodic). Packets are not guaranteed to be unique (you might get the same data twice). However, non-unique packets will have the same timestamp and can be filtered out.

Command Packets

The main purpose of command packets is to start and stop devices. Command packets contain a destination bit vector, to address particular devices, in addition to a variable length command string (a maximum size string is always sent, with zero bytes for unused values). The first byte in the command string determines the type of command (start, stop, quit...). Some values are global (can apply to all devices), and some values are device specific (local).

Global Command Packet Types

Start
Tells the driver to start communicating with the actual device

Stop
Tells the driver to stop communicating with the device, but to stay alive and communicate with the main block

Quit
Tells the driver to shut itself down and end the process

Emulate
Puts the driver in emulation mode. The driver doesn't execute any hardware level commands, but sends back fake data. Good for testing, when you don't actually have the hardware connected, but don't want to run the simulator.

Local Command Packet Types

Reset Encoder Counts Encoders
Sets encoder counts to 0

Code Documentation

Doxygen Files
The backend files are listed under the Doxygen Files, if you really want to understand the structure use Visual Studio to browse the backend project