Skip to content

Capability 004: Forward Odometry

Status: Accepted

Context

The Superordinate Controller computes the kinematics of the robot and needs the measured speed of each Motor. Each Motor Controller Board reports the measured speeds of its two outputs over UART, every 10 ms. The Bridge forwards them on the CAN bus, per Motor, as it forwards the Motor Status (capability 003).

References

  • CAN messages: drive.dbc
  • UART protocol, frame Serial_Feedback_Odometry: hoverboard-firmware v1.0.0, command_api.md

Mapping

Board frame CAN messages
Board 1 odometry Motor 1 speed = left, motor 2 speed = right
Board 2 odometry Motor 3 speed = left; right is dropped

Each Motor Speed carries the Measured Speed of one Motor. Instance n of the identifier is Motor n.

Functional Requirements

  1. The Bridge recognizes an odometry frame by its start marker and a valid checksum.
  2. It translates each odometry frame into the Motor Speed messages as mapped.
  3. It forwards every odometry frame: no averaging, no reduction of the rate.
  4. It passes values on unchanged: no checking, limiting, scaling, or change of sign.

Non-Functional Requirements

  1. At most 10 ms from the complete reception of an odometry frame to the start of the CAN transmission.
  2. Load: per board, one odometry frame every 10 ms, which yields 300 Motor Speed messages per second, about 3 % of the bus at 1 Mbit/s.

Error Handling

As for the Motor Status (capability 003, Error Handling); a full transmit queue discards the new Motor Speed.

Solution Constraints

As for the Motor Status (capability 003, Solution Constraints).

Out of Scope

  • The state frame of the boards
  • The right output of board 2: no Motor is connected to it
  • Converting the Measured Speed into a physical unit, or computing distance or position from it

Acceptance Criteria

  1. Board 1 odometry (300, −300): Motor Speed of motor 1 with 300 and of motor 2 with −300.
  2. Board 2 odometry (100, 7): Motor Speed of motor 3 with 100; the right value 7 is dropped.
  3. Odometry frame with an invalid checksum: no CAN message; the discarded frame is reported over USB serial.
  4. 100 odometry frames per board within one second: 300 Motor Speed messages, none discarded.
  5. Under the load of NFR 2: at most 10 ms delay.

Test vectors for criteria 1 and 2, in hexadecimal bytes as they appear on the wire:

Criterion Board (UART) CAN (identifier: payload)
1 1: cd ab 2c 01 d4 fe 35 54 0C210004: 2c 01, 0C220004: d4 fe
2 2: cd ab 64 00 07 00 ae ab 0C230004: 64 00

Decisions

  1. One Motor Speed message per Motor, as for the Motor Status (capability 003, Decision 1).
  2. Motor Speed is telemetry: priority class 3, subsystem 1, instance = Motor, message number 4. It is cyclic with 10 ms and a receive timeout of 30 ms.
  3. Every frame is forwarded, because it is the simplest option and the bus has room for it. Reducing the rate would need a timer or a counter in the Bridge and would delay the values.
  4. A full transmit queue discards the new message, as for the Motor Status (capability 003, Decision 4). Consequence: once the bus recovers, outdated speeds may be sent first; fresh ones follow within 10 ms.
  5. The Measured Speed has no unit in drive.dbc, because command_api.md specifies none. The Bridge passes it on as the board reports it, including its sign.