The SARLACC protocol

The SARLACC Protocol

Protocol specification in Excel format: https://sourceforge.net/p/astromech-ros/wiki/The%20SARLACC%20protocol/attachment/SARLACC%20v3.xlsx

The SARLACC protocol (short for Serial Astromech Remote Link for Adequate Command and Control :-)) is a protocol specification that allows simple linkage between a PC and a microcontroller board such as R-Series, Arduino, or J.E.D.I.

It has been designed for extreme compactness so transmission of a full state packet can be integrated into a robot control loop. It is easy to transmit over a serial link but can also be transmitted over Ethernet or other transport methods.

[Discussion New Protocol]

Implementation

A full implementation of the packet format is contained in the SARLACC subdirectory of the astromech-ros repository. It contains the packet format as a fully documented C library for PCs and Arduino, as well as example programs for Unix PCs and Arduinos. Please see the attached PDF for documentation.

Features

• Transmission Performance:

  • Error checking by packet checksum and sequence number
  • Easy synchronization through clear Start-Of-Transmission and End-Of-Transmission markers
  • 2.5ms for a full transmission at 115.200bps
  • C/C++ interface (done), Python interface (planned)

• State Introspection:

  • OK flag for communication with remote control, motor controller, display, and PC
  • Activation flags for ground motion, dome motion, collision avoidance and autonomous operation
  • Timing info for two different loops

• Command Interface:

  • Communication with two clients
  • Set and query register (4-bit register, 2x 8-bit args)

• Remote Control:

  • OK flag
  • 4 axes (8 bits)
  • 3 switches

• Specific Sensors:

  • battery voltage (4 bits + OK flag)
  • 2 wheel encoders (11 bits + OK flag)
  • dome rotation (10 bits + OK flag)

• General-Purpose Sensors:

  • 7x high precision sensors (8 bits + OK flag)
  • 5x mid-precision sensors (7 bits + OK flag)
  • 2x low-precision sensors (3 bits + OK flag)
  • 8x switches

Protocol Specification

The current data packet specification (in MS Excel table format) is attached to this Wiki article.

How it works

The server (usually the low-level droid controller) sends the state packet as often as reasonably possible. A good example would be to send it every 40ms, or 25 times per second.

The client (high-level controller etc.) sends command packets setting or requesting register values. The server encodes the answer to a command packet (a copy in case of a set, the requested values in case of a get) in the next state packet. In case of command packets from several clients, the server keeps a reply queue and sends one reply from the queue in turn. If the queue is empty, the state packet has a NOP as a reply and all-bits-one as reply address.

Over I2C, the server (I2C master in this case) sends the state packet to the I2C broadcast address (0x0). Since the I2C slaves cannot simply send commands but need to be queried, in this case the server needs to poll the clients by sending them a signal over I2C. How it does this is implementation dependent.

Register map

Dome motion
Feet speed / turn
Servos
...