# protocol specs
under construction!
the included wixel is used for bidirectional wireless serial data transfer. it
has built-in error correction and other features that make sure data gets to
the robot losslessly, so data loss is not accounted for.
## important constants
|property|value|unit|
|-|-|-|
|baud rate|9600|bit s⁻¹|
|max byte timeout|5|ms|
|byte order|big-endian|-|
## commands
each command consists of a start byte, opcode, and a payload. each opcode
defines logic to handle payload length, so certain commands might expect a
fixed-length payload, a variable-length payload, or none at all. the start byte
is `0xff`, and because most data sent is in binary format, if the data contains
an `0xff` byte, it will be escaped by replacing it with two `0xff` bytes. this
is converted to a single `0xff` on the receiving end, so these duplicated bytes
and the starting byte don't count towards message length.
opcodes are picked sequentially, but the direction bit (LSB) is reserved to
indicate a transfer from robot to client (`tx`). this means that the opcode for
a sensor data request would be `0x12`, but the response opcode would be `0x13`.
these opcodes are stored as enum constants inside sercomm.h for code
readability.
|code|name|implemented|directions|full name|
|--:|---|:-:|:-:|---|
|`0x00`|[PING](#ping)|no|`r <=> c`|ping
|`0x02`|[EXPT](#expt)|no|`r --> c`|exception
|`0x04`|[MODE](#mode)|no|`r <=> c`|mode
|`0x06`|[SPED](#sped)|no|`r <-- c`|speed
|`0x08`|[DIRC](#dirc)|no|`r <-- c`|direct control
|`0x0a`|[CORD](#cord)|no|`r <=> c`|coordinate
|`0x0c`|[BOMD](#bomd)|no|`r <=> c`|backorder modify
|`0x0e`|[SRES](#sres)|no|`r <-- c`|soft reset
|`0x10`|[MCFG](#mcfg)|no|`r <-- c`|map config
|`0x12`|[SENS](#sens)|no|`r <-> c`|sensor data
|`0x14`|[INFO](#info)|no|`r <-> c`|info
|`0x16`|[DISP](#disp)|no|`r <-- c`|display control
|`0x18`|[PLAY](#play)|no|`r <-- c`|play midi
|`0x1a`|[CLED](#cled)|no|`r <-- c`|control leds
the DISP, PLAY, and CLED commands have low implementation priority, and should
be considered extra features
a double stroke arrow means that the command can be initiated from either the
robot or the client, while a single arrow indicates a request-response
structure.
### PING
#### ping (`r <=> c`) (2 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x00 + 0` or `0x00 + 1`)|
|`uint8_t`|ping id|
**ping** sends back an identical message either way with the direction bit
toggled. _ping id_ is a random 8-bit value that makes sure the same ping
doesn't keep bouncing back and forth indefinitely.
### EXPT
#### exception (`r --> c`) (3+ bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x02 + 1`)|
|`uint8_t`|error code|
|`uint8_t`|length|
|`uint8_t[length]`|message contents|
the **exception** instruction is used by the robot to send errors, warnings,
and other messages back to the client. an error can also optionally contain a
message between 0 and 255 characters long. message length is sent before the
message, and can be 0 in case of no message.
### MODE
#### set mode (`r <-- c`) (2 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x04 + 0`)|
|`uint8_t`|mode code|
when initiated from the client, the **mode** command forces the robot to change
execution mode. the mode codes are undetermined as of now.
#### get mode (`r --> c`) (2 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x04 + 1`)|
|`uint8_t`|mode code|
the **mode** command is send by the robot when it switches into another mode.
the mode codes are undetermined as of now.
### SPED
#### set speed modifier (`r <-- c`) (2 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x06 + 0`)|
|`uint8_t`|speed modifier|
scales motor output power from 0% (0x00) to 100% (0xff).
### DIRC
#### set motor speed (`r <-- c`) (5 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x08 + 0`)|
|`int16_t`|left motor speed|
|`int16_t`|right motor speed|
directly set left and right motor speed values. only works in direct control
mode (unimplemented!). motor values range from -255 to 255. speed is sent as a
signed 16-bit integer (`short`).
### CORD
#### set position (`r <-- c`) (6 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x0a + 0`)|
|`uint32_t`|position|
|`uint8_t`|orientation|
manually correct robot position and orientation in grid portion of the map.
_position_ = y * width + x
_orientation_:
- 0: west
- 1: north
- 2: east
- 3: south
#### get position (`r --> c`) (6 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x0a + 1`)|
|`uint32_t`|position|
|`uint8_t`|orientation|
sent by the robot in the grid portion of the map when a transition to a new
_position_ is finished.
_position_ = y * width + x
_orientation_:
- 0: west
- 1: north
- 2: east
- 3: south
### BOMD
#### append order (`r <-- c`) (9 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x0c + 0`)|
|`uint32_t`|order identifier|
|`uint32_t`|position|
add a new order to the backorder list (queue).
_position_ = y * width + x
#### order status (`r --> c`) (6 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x0c + 1`)|
|`uint32_t`|order identifier|
|`uint8_t`|status|
sent by the robot in the grid portion of the map when the status of an order
changes. also used to confirm orders are received successfully.
_status_ is one of:
- 0: received
- 1: processing (begin)
- 2: reached
- 3: finished
### SRES
#### soft reset (`r <-- c`) (2 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x0e + 0`)|
|`uint8_t`|type|
_type_ is one of:
- 0: reinitialize all global state
- 1: reset emergency mode
### MCFG
#### configure map (`r <-- c`) (4+ bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x10 + 0`)|
|`uint8_t`|width|
|`uint8_t`|height|
|`uint8_t`|length|
|`feature[length]`|features|
> _feature_ is a struct containing:
>
> |type|description|
> |-:|-|
> |`uint16_t`|position|
> |`uint8_t`|kind|
>
> where _position_ = y * width + x
> and _kind_ = 0bXXYYYYYY where X = _orientation_ and Y = _type_
>
> _orientation_:
> - 0: west
> - 1: north
> - 2: east
> - 3: south
>
> _type_:
> - 0: entrance / exit
>
sends the map layout to the robot. the map is an automatically generated grid
of the specified size, starting at coordinates (1, 1) to keep a margin around
the grid for the maze-grid transition.
example hexdump of 5x5 map with a north-facing entrance/exit at (3, 0) for
later reference:
```
10 05 05 01 00 03 40
```
### SENS
#### request sensor data (`r <-- c`) (1 byte)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x12 + 0`)|
requests sensor data
#### sensor data response (`r --> c`) (??? bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x12 + 1`)|
|`???`|???|
sensor data response. contains all sensor data (distance, ir, buttons) in one
packet. format yet to be determined.
### INFO
#### request robot info (`r <-- c`) (1 byte)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x14 + 0`)|
requests robot info
#### robot info response (`r --> c`) (41 bytes)
|type|description|
|-:|-|
|`uint8_t`|opcode (`0x14 + 1`)|
|`uint8_t[32]`|build string|
|`uint8_t`|errcatch module cycle time (ms)|
|`uint8_t`|io module cycle time (ms)|
|`uint8_t`|sercomm module cycle time (ms)|
|`uint8_t`|modes module cycle time (ms)|
|`uint32_t`|total robot uptime (s)|
robot info response