Skip to content

Capability 003: Forward Motor Status

Status: Accepted

Context

To the robot, the Drive is one virtual drive board with three channels, one per Motor. It is built from two Motor Controller Boards (capability 001, Decision 1). Each board reports the battery voltage and its own temperature over UART, once per second. The Bridge forwards these values on the CAN bus, per Motor, so that the Superordinate Controller sees the three channels and not the two boards.

References

Mapping

Board frame CAN messages
Board 1 status Motor 1 status and motor 2 status, same values
Board 2 status Motor 3 status

Each Motor Status carries the Supply Voltage and the Controller Temperature of the board that drives the Motor. Instance n of the identifier is Motor n.

Functional Requirements

  1. The Bridge receives the frames of both boards on their UARTs.
  2. It recognizes a status frame by its start marker and a valid checksum.
  3. It translates each status frame into the Motor Status messages as mapped.
  4. It passes values on unchanged: no checking, limiting, or scaling.
  5. It forwards no other frame of the boards as Motor Status and does not report them as discarded, because they are valid frames.

Non-Functional Requirements

  1. At most 10 ms from the complete reception of a status frame to the start of the CAN transmission.
  2. Load: per board, one status frame per second and one odometry frame every 10 ms on the UART.

Error Handling

  1. Bytes that do not form a valid frame are discarded; the Bridge resynchronizes on the next start marker. Discarded frames are counted per board and reported over USB serial with the other errors, at most once per second (capability 001, Error Handling 1).
  2. When the CAN transmit queue is full, the new message is discarded, counted, and reported the same way.
  3. After a bus-off, the Bridge restarts the CAN controller at most once per second and reports the bus-off.
  4. Before its initialization is complete, the Bridge sends nothing.

Solution Constraints

  1. UART reception is interrupt-driven, one byte at a time.
  2. The UART receive interrupt assembles the frame, translates it, and puts the messages into the CAN transmit queue of the controller. It never waits for free space.
  3. Interrupts never write to USB serial. They count errors, and the main loop reports them.

Out of Scope

  • Odometry and the state frame of the boards
  • Supervising whether the boards still send: the Superordinate Controller detects a silent Drive through the timeout of the cyclic messages
  • Toggling the activity LED on UART reception or CAN transmission (capability 002, Out of Scope)

Acceptance Criteria

  1. Board 1 status (36.00 V, 30 °C): Motor Status of motors 1 and 2 with these values.
  2. Board 2 status (36.50 V, 31 °C): Motor Status of motor 3 with these values.
  3. Status frame with an invalid checksum: no CAN message; the discarded frame is reported over USB serial.
  4. Garbage before a valid status frame: the frame is forwarded; the garbage is reported as discarded.
  5. Odometry frame: no Motor Status, no report.
  6. Full CAN transmit queue: the new message is discarded and reported over USB serial.
  7. Bus-off: reported over USB serial; the Bridge sends again after the bus recovers.

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

Criterion Board (UART) CAN (identifier: payload)
1 1: ce ab 10 0e 1e 00 c0 a5 0C210003: 10 0e 1e 00, 0C220003: 10 0e 1e 00
2 2: ce ab 42 0e 1f 00 93 a5 0C230003: 42 0e 1f 00

Decisions

  1. The Drive appears as three channels, one per Motor. Board 1 values therefore appear twice, for motors 1 and 2. A later drive board with three outputs fills the same messages without a change to drive.dbc.
  2. Motor Status is telemetry: priority class 3, subsystem 1, instance = Motor, message number 3. Message numbers stay unique within the subsystem, so a number names one message regardless of class.
  3. Frames are synchronized by start marker and checksum, not by pauses on the line, because the protocol has no delimiters.
  4. A full transmit queue discards the new message instead of the oldest one, unlike capability 001, because it is the simplest option: the CAN controller owns its queue and rejects new messages on its own. The queue fills up only while the bus is blocked, for example when no other node acknowledges. Consequence: once the bus recovers, the Bridge first sends the outdated messages still in the queue, at most one per transmit element; fresh values follow within a second. Replacing the waiting message of the same identifier would avoid this, but it is not worth the code for a Bridge that a drive board with CAN is to replace.
  5. The Bridge deviates from the CAN bus guideline as in capability 001, Decision 4. In addition, the UART receive interrupt translates and enqueues instead of handing over to the main loop, because translation is short and bounded.