RCI 053 · System-topology field note

Five configurations, one derivation rule.

The five pinned ToddlerBot profiles publish 30, 30, 32, 32 and 14 active actuator positions. Every count comes from one mechanical rule—deep-merge the pinned YAML, filter against the fixed XML—and stops at the actuator family, never at an order code.

Published 2026-08-185 min readRobot System Index v0.8.21

What is now public

Five ToddlerBot configuration profiles are public as separate boundaries: 2×M, 2×C, 2×M gripper, 2×C gripper and the teleoperation leader. Each combines an immutable configuration file tree with bounded system rows—actuator composition, recommended compute, an eight-channel communication-board boundary, dual BNO08X-family sensing, stereo fisheye camera paths and the battery/Distro Board v8 power boundary—all pinned to one repository commit, e337f3b177b4b53abff70b31d1695a7b66cc6d2e. The shared engineering library and the Distro Board v8 fabrication BOM remain their own profiles rather than being counted into every build.

Each full-body profile carries a six-node, six-relation topology and the leader carries a four-node, three-relation topology: CH9344-backed serial fan-out, Dynamixel Protocol 2.0 control, I²C sensing at addresses 0x4A and 0x4B, two V4L2 camera paths and separate compute and actuator power branches. The machine layers are robots.json and the interface-relation CSV.

The five configurations

ConfigurationActive positionsFamily-level composition
2×M full body306 XC330, 4 XM430-W350, 4 XM430-W210, 4 XC430, 12 2XC430
2×C full body306 XC330, 4 2XC430, 4 XM430-W210, 4 XC430, 12 2XL430
2×M gripper32The 2×M bank plus two XC330 bilateral gripper-rack positions
2×C gripper32The 2×C bank plus two XC330 bilateral gripper-rack positions
Teleoperation leader142 XC430, 12 2XL430; software assigns motor IDs from 16 upward

The derivation rule, stated plainly

The counts above are derived only one way: deep-merge the pinned default configuration YAML with each configuration's own robot YAML, then keep only the positions that survive filtering against that configuration's fixed XML—all at the single pinned commit. Nothing is taken from mutable documentation, and no variant is merged into another. The result is a set of family-level assignments: an entry reads "XM430-W210 family," not a complete order-code suffix, and the teleoperation leader's IDs-from-16 offset is a software assignment, not a physical EEPROM observation.

Recommendation rule

The compute row stays at recommendation level. The pinned guide recommends a Jetson Orin NX 16GB via the reComputer J4012 flashing path; this fixes a documented intent, not a purchased SKU, carrier revision, module serial or installed computer.

What this is not

  • Not an as-built inventory. No serialised robot, motor bank, EEPROM state, calibration record or powered acceptance binds any configuration to a physical unit.
  • Not order codes. Family names are configuration assignments after merge and filtering; complete orderable suffixes are not published in the selected surfaces.
  • Not a compatibility or performance claim, and zero RCI physical tests: no bus read, IMU stream, camera frame or energized power branch exists.
  • Open unknowns stay open: port-to-body-group allocation, assembled baud rates, camera SKUs, exact communication-board revision and the battery pack identity behind the mutable procurement sheet are all unresolved.

Corrections

If a composition, count, derivation step or boundary above misreads the pinned repository, use the corrections process. Corrections are logged; prior states are not erased.