CAN Identifier Allocation¶
This document is the central registry of CAN identifier ranges of the Kiwi Robot. It applies the identifier scheme of ADR-001. It is a living document: it grows with every subsystem.
Audience and Purpose¶
Read it before you define a CAN message. Every subsystem team uses it to obtain a subsystem number and to check that its identifiers do not collide. The detailed messages stay with the subsystem, in its own machine-readable specification.
Subsystems¶
| Subsystem number | Subsystem | Owner artifact | Message specification |
|---|---|---|---|
| 0 | System-wide | Mono-repo root | This document, section System-wide messages |
| 1 | Drive | Mono-repo root, implemented by the Motor Controller Bridge | drive.dbc |
| 2 | Battery management | Not yet assigned | Not yet defined |
| 3 | Distance sensors | Not yet assigned | Not yet defined |
| 4–31 | Reserved | — | — |
Instance 0 addresses all instances of a subsystem. The subsystem defines what its instance numbers stand for.
System-Wide Messages¶
Messages of subsystem 0 concern the whole robot, for example an emergency stop. No system-wide message is allocated yet.
How to Obtain a Subsystem Number¶
- Open a merge request against this document with the next free subsystem number, the owner artifact, and the location of the message specification.
- Define the messages of the subsystem in the specification named there.
- Use only identifiers that follow ADR-001 and carry the number of your subsystem.
A subsystem number is never reused. A retired subsystem stays in the table, marked as retired.
Rules¶
- Each message has exactly one owning subsystem.
- A subsystem allocates message numbers within its own specification, not in this document.
- Subsystems that need low latency receive low numbers, because subsystem numbers decide arbitration between messages of the same priority class.