What is now public
The Berkeley Humanoid Lite deep profile audits 52 selected rows from the public BOM sheet—26 Humanoid rows plus 13 rows in each actuator tab—and now carries a nine-node, ten-relation system map built from the official documentation. The ten relations cover the host-to-hub USB surface, the hub-to-adapter fan-out, 1 Mbit/s CAN control and feedback to each actuator bank, the two alternative IMU paths, and four power relations: main-bus feeds to each actuator bank, the protected feed into the named conversion and monitoring surface, and the low-voltage path to the on-board computer.
Every relation restates responsibility-party statements at an identified revision, keeps its unresolved list and carries a physical-validation state of none. The machine layers are robots.json and the interface-relation CSV; the documentation-versus-release separation and the US/China procurement-column boundary are recorded relations in the lifecycle CSV.
The nine nodes
| Node | Kind | Selected boundary |
|---|---|---|
| On-board NUC / Mini PC boundary | Compute | Current guide identifies a BeeLink N95-class NUC on Ubuntu 22.04; the live BOM row stays generic “Mini PC” |
| Two generic USB hubs | Control | Hub models, port counts and upstream/downstream assignment unpublished |
| Four USB-CAN adapters | Control | Two arms and two legs expected as Linux ports can0–can3; adapter identity and port mapping not frozen |
| M6C12 actuator bank | Actuation | Ten positions: eight leg and two arm, with per-module B-G431B-ESC1 and AS5600 boundaries |
| 5010 actuator bank | Actuation | Twelve positions: four leg and eight arm, with per-module B-G431B-ESC1 and AS5600 boundaries |
| Original BNO085 + Arduino Nano IMU path | Perception | IMU reaches the host through an Arduino Nano; alternative to IM10A, not additional |
| Recommended IM10A direct-USB IMU path | Perception | Recommended for its direct USB connection; marked as the alternative option in the live BOM |
| 6S LiPo, breaker and main power bus | Power | Generic 6S pack and circuit breaker feeding an XT60 trunk with XT30 actuator branches |
| 24→12 V / 12→5 V conversion and monitoring | Power | One converter per named transition plus voltage and current monitors; ratings and rail allocation unpublished |
The two IMU nodes are alternatives, not a dual-IMU design. The original path routes a BNO085 through an Arduino Nano to the computer; the currently recommended path is an IM10A connected directly over USB. Absent one as-built selection, the profile refuses to count both as simultaneously installed.
Live documentation is not the frozen BOM
The platform's release v1.1.0 is a tagged, dated boundary. The BOM, however, lives in a public spreadsheet and GitBook documentation that can change without changing the release tag—rows, links, formulas and recommendations included. No immutable public sheet revision is cryptographically bound to v1.1.0, so the profile treats the live surfaces as an observation layer with observation dates, kept separate from the release. This is also why the compute node carries two identities at once: the current guide names a BeeLink N95-class NUC while the live BOM row remains generic.
The converter row named “24 V” is a product label at a named voltage transition. It is not a measured 6S pack voltage, and RCI has not applied power to any rail.
What this is not
- Not an as-built inventory. No serialised robot, module set, CAN ID map, calibration record or harness is bound to the map.
- Not a compatibility or performance claim. Actuator position counts are published configuration quantities, not RCI-verified installed banks or torque results.
- Zero RCI physical tests. No USB tree enumeration, CAN frame capture, IMU stream or power measurement exists.
- Open unknowns stay open: hub-to-adapter pairing, limb-to-port mapping, adapter and converter models, pack identity, breaker behavior, shunt placement and the host's exact supply rail are all unpublished in the selected surfaces.
Corrections
If a node boundary, relation, count or the release-separation reading above is wrong, use the corrections process. Corrections are logged; prior states are not erased.