> Documentation index: https://nao-rs.lukaloehr.com/llms.txt, a list of every page in this documentation. # Chest board link > The USB device, its start-up, the three-step exchange every cycle, the frame format, the message types, the preferences, the motor board handshake and the chest board tools. The chest board is the only USB device nao-rs talks to for the body. It is the hub for everything below the neck. This page describes the link as recorded from the robot and as nao-rs implements it. Parts marked *(inferred)* are read from the traffic and not yet confirmed otherwise. ## The device | Property | Value | | --- | --- | | USB id | `ffff:0006` ("Arm9 v3.3" chest board; `ffff:0005` is the older one, also recognized by the tools) | | Interface | 0 | | Endpoints used | EP1 bulk OUT and IN, 64-byte packets | | Endpoints not used | EP2 isochronous (OUT 400 B, IN 300 B) | | Linux access | usbfs directly, no libusb; udev names it `/dev/chestboard` on HULKs-OS | ## Start-up | Step | Request | | --- | --- | | 1 | Open the device, select configuration 1 | | 2 | Vendor OUT request `0x13`, no data *(inferred: start of the protocol)* | | 3 | Claim interface 0 | | 4 | Vendor IN request `0x02`, answer 4 bytes, `00 02 00 29` on our robot *(inferred: chest board version)* | ## The exchange Every exchange has three steps: 1. **Bulk OUT** on EP1: one frame, 20 ms timeout. 2. **Vendor IN request `0x14`**, 5 bytes: `2a` followed by the CRC of the frame just sent. The chest board acknowledges the frame. 3. **Bulk IN** on EP1, up to 512 bytes, 20 ms timeout: the answer frame. When nothing is ready the read times out, and vendor IN request `0x15` (2 bytes) asks for the chest board's status *(inferred)*. A bulk read takes about 0.7 ms. ## Frames | Direction | Layout | | --- | --- | | To the chest board | `[CRC-32, big endian][messages][length table, last message first]` | | From the chest board | `[messages][length table, last message first][CRC-32, big endian]` | The CRC is the standard CRC-32 (the one zlib computes). A frame holds up to 255 messages and at most 4 KB. A frame whose length table doesn't add up decodes to no messages. HAL's decoder writes past 255 entries without a bound check; nao-rs stops at 255. ## Messages Every message starts with three bytes: kind, bus, address. | Byte 0 | Kind *(inferred from the traffic)* | | --- | --- | | `00` | Request | | `01` | Command (once per board after its configuration) | | `02` | Data from a board | | `03` | Request to the chest board itself | | `04` | Acknowledge from a board (header and one status byte) | | Byte 1 | Bus | | --- | --- | | `00` | Upper body motor boards | | `01` | Leg motor boards and foot boards | | `02` | Devices behind the chest board: inertial unit (`09`), battery (`0b`), sonar (`42`), and `50`, `51` *(not yet named)* | | `03` | The chest board: preferences (`06`), chest button (`05`), id strings (`08`), `2a` | Byte 2 is the board address (see [Boards](https://nao-rs.lukaloehr.com/hardware.md#boards)) or a register. ## Preferences The chest board stores a 4,635-byte preference block, read in 32-byte pieces and checked with a CRC. It holds typed key-value pairs, among them: - the body id and body version; - the stored serial number of every board; - the joint zero positions; - the foot pressure sensors' gains and offsets; - the inertial unit's offsets. `naoctl prefs` prints all of them. nao-rs reads all 76 values HAL logs, and every one is identical to HAL's. ## The motor board handshake 1. nao-rs sends a 4-byte request, `00 20`, to each board. 2. The board answers with 32 bytes: 16 bytes of status, then 16 bytes of configuration: its serial number (equal to its stored serial number in the preferences; the foot boards send 0), the **configuration version**, the hardware revision, the board type and the fields used at run time. 3. The version is checked against the accepted list. A rejected board is asked again, three times in all, and then left uninitialized. 4. An accepted board gets one command afterwards: `01 07` for joint boards, `01 08` for hand and foot boards *(inferred: start)*. HAL does **not** send a configuration table to the boards; it only reads theirs. Every board of a NAO6 updated by NAOqi 2.8.7 reports version 11 (`0b`). HAL 2.8.5 accepts only 10, which is why the motors of such a robot don't start under HULKs-OS. The bytes HAL takes from the configuration after the check have the same meaning in versions 10 and 11. nao-rs accepts `[10]` by default, like HAL; accepting 11 is the motor session's step (**planned**). ## The chest board tools Aldebaran's three chest board tools are ported onto the same link. They need the chest board free: stop `hulk` (or HAL) first. | Tool | What it does | Safe on a running robot? | | --- | --- | --- | | `chest-version [0-3]` | Reads a 20-character id string per slot (slot 3 is the body id) | Yes, read-only; HAL sends the same requests at every start-up | | `chest-mode` or `chest-mode -b` | Asks whether the chest board is in its boot loader | Yes, read-only | | `chest-mode -s`, `-t`, `-f`, `-u`, `-m` | Sets the chest LED state: start, stop, firmware update, unusable, manual | Changes state | | `chest-mode -r` | Resets the LED watchdog timer | Changes state | | `chest-mode -o` | Switches the motors off and on | **No** | | `chest-mode -p` | Switches the head computer off and on | **No** | | `chest-harakiri [-r]` | Powers the robot off, or with `-r` resets it | **No** | None of the tools puts the chest board into its boot loader. They are not in the robot bundle yet; build them from the drivers repository. ## Related topics - [Hardware reference](https://nao-rs.lukaloehr.com/hardware.md) - [Body sensors and units](https://nao-rs.lukaloehr.com/hardware/sensors.md) - [Head devices](https://nao-rs.lukaloehr.com/hardware/head.md) - [LEDs](https://nao-rs.lukaloehr.com/hardware/leds.md) - [Head fan](https://nao-rs.lukaloehr.com/hardware/fan.md) - Previous: [Hardware reference](https://nao-rs.lukaloehr.com/hardware.md) - Next: [Body sensors and units](https://nao-rs.lukaloehr.com/hardware/sensors.md)