System architecture: from battery to policy

Stage 1 · Foundations · ~30 min · Before this: 01 Degrees of freedom, 02 Balance · numbers from the repository as of 2026-11-02

A walking humanoid is a stack of machines inside one another: a battery feeds small motor controllers that correct each joint thousands of times a second, a computer runs a neural-network “policy” (the learned controller) fifty times a second, and a training computer elsewhere produced that policy in simulation. This page lays the whole stack out, then follows one control tick (one 20 ms round of sense, decide, act) from a gyro sample to motor torque and asks whether it fits.

You will learn

• What each layer of Marvin Bot does, from the aluminium frame and the 48 V battery to the Jetson AGX Orin and the training desktop, and which page covers it in depth.
• Why control is split into loops at very different rates (a vision-language-action model a few times a second, the policy 50 times a second, each motor’s own joint controller thousands of times a second; 1 hertz, Hz, is once per second, 1 kHz a thousand) and why that split works.
• How to add up a latency budget (the delays, added up, between something happening and the motors responding) for one control tick, and how it relates to the 0–20 ms sensor and 0–10 ms motor delays the policies were trained with.

The idea in one picture

Think of the robot as a company with managers at different speeds. A slow, clever manager (a vision-language-action model, VLA: a large AI model that looks through the camera and reads an instruction, or a person with a gamepad) decides what to do: “walk to the table”, “pick up the cup”. A quick, practised supervisor (the policy, a small neural network) turns that into joint targets for every joint, 50 times a second, while keeping the robot balanced. Fast workers on the shop floor (the motor drivers) hold each joint at its target thousands of times a second by pushing current through the motor windings. Underneath it all is the plant: a battery, wires, a frame and 27 powered joints.

Each level only works if the level below is much faster than itself. The policy can treat “set the knee to 20°” as almost instant because the motor driver’s loop settles in a few milliseconds; the VLA can treat “walk forward” as instant because the policy handles every step. This is the classic control hierarchy, and learned humanoids use it too: in an open research humanoid the policy runs at 50 Hz and the joint controller at 25 kHz on the motor driver.^[12]

Why a newcomer should care. When a robot wobbles or falls, the cause can sit in any layer: a weak motor, a slow sensor, an overloaded data cable, a badly trained policy. Knowing the layers tells you where to look, and which later page to read.

Words you will meet on this page

• PD control (proportional-derivative): each motor pushes towards its target angle in proportion to how far off it is (P) and resists moving too fast (D), like a spring with a shock absorber. Page 15.
• IMU (inertial measurement unit): a chip with a gyro (how fast the body is turning) and an accelerometer (which way is down). Marvin Bot’s sits in the pelvis. An AHRS (attitude and heading reference system) is an IMU sold with its own filtering built in.
• CAN (Controller Area Network): a shared two-wire data cable, invented for cars, that the computer uses to talk to a chain of motors. A frame is one message on it; a bus is one such cable with its motors.
• ROS 2 (Robot Operating System 2): not an operating system but a widely used set of software libraries that let robot programs pass messages to each other.
• ONNX (Open Neural Network Exchange): a standard file format for a trained neural network, so it can be run by software other than the one that trained it.
• ms = millisecond (a thousandth of a second); µs = microsecond (a millionth). Latency = delay; jitter = how much that delay varies from one time to the next.

Playground 1: the layered architecture

Click any block for what it does, how fast it runs, the repository file or decision behind it, and the page that covers it. The buttons beside the diagram highlight one path through the stack; start with One control tick.

How to read this picture: each horizontal band is one layer, slowest and furthest from the hardware at the top (training) down to the metal frame at the bottom. Arrows show which way data or power flows. Bright blocks are on the highlighted path; dimmed ones are not. On a phone, swipe the diagram sideways.

Highlight a path

One control tick Camera to VLA Power Training to robot None

Rates in the stack

Loop	Rate	Period
VLA (GR00T N1.7)	~1–4 Hz	250 ms+
Policy	50 Hz	20 ms
Leg CAN commands	500 Hz	2 ms
Arm CAN commands	250 Hz	4 ms
IMU	≥500 Hz	≤2 ms
Driver PD, current	kHz	<1 ms

From docs/requirements.md R42–R43 and description/robot.yaml. The driver loop rate is not in the RobStride manuals; it is a bench-test item.

Playground 2: follow one control tick

A gyro notices the pelvis tipping. How long until a motor pushes back? Each stage below adds a delay. Press Marvin Bot today first, then change one slider at a time. “Average” uses half of each waiting period (an event lands at a random moment); “worst case” uses whole periods. The dot replays the chain in slow motion.

How to read this picture: time runs left to right in milliseconds; each coloured block is one delay, in order, and the vertical lines mark the start of each 20 ms policy tick. Readout values turn green when comfortably inside the range the policy was trained with (or the bus limit), amber near its edge and red outside it.

Presets

Marvin Bot today USB backup IMU (AHRS) Arm bus (6 motors, 250 Hz) Heavy policy on the CPU 100 Hz policy

Loop rates

Policy rate

How often the policy runs. Sets the tick length (1/rate).

CAN command rate

How often the controller sends each motor a frame (legs 500 Hz, arms 250 Hz).

Motors on the bus

Each takes a command and a reply frame of up to 160 bits at 1 Mbit/s.

IMU sample rate

Requirement R42: at least 500 Hz.

Delays

Sensor transport delay

IMU filtering, USB or serial transfer and driver buffering before the reading is usable.

Inference time

Building the observation (the list of numbers fed to the network) and running the network. A small network like Marvin Bot's takes well under 1 ms.

Driver loop rate

How many thousand times a second each motor's own controller corrects the joint. Not published for RobStride; open-source drivers run 10–40 kHz.

Case Average (half of each wait)Worst case (whole waits)

Pause animation

Event to torque

–

Tick start to torque vs tick

–

Sensor-side delay (trained 0–20 ms)

–

Action-side delay (trained 0–10 ms)

–

CAN bus load (limit 0.6)

–

Try this

1. Load “Marvin Bot today”. The event-to-torque total is around 15 ms, and most of it is the wait for the next policy tick, not the electronics. That wait exists in simulation too, so it is not a sim-to-real gap.
2. Load “USB backup IMU (AHRS)” and switch Case to worst case. The sensor side approaches the top of the 0–20 ms range the policy was trained with. This is why the repo wants a 500 Hz, low-latency IMU as the primary.
3. Load “Arm bus” (six motors at 250 Hz: load 0.48). Now raise the CAN rate to 500 Hz, as the legs need: load 0.96. Push the motors to 8 and the frames no longer fit in the 2 ms cycle. This is why each leg gets two buses.
4. Load “Heavy policy on the CPU” and raise inference time to 12 ms. The policy still fits in the tick, but the action side leaves the trained 0–10 ms range: a policy trained with up to 10 ms of motor delay would now meet more lag than it ever saw.

From first principles

The plant: mechanical and electrical

The body is a machined 6061 aluminium frame (7075 at the most loaded flanges) with printed shells, carrying 27 powered joints: 6 per leg, 6 per arm, waist yaw and two neck joints. Each big joint is a RobStride quasi-direct-drive actuator: a motor, a 9:1 or 10:1 planetary gearbox, an absolute encoder (14-bit on the RS04^[10]) and a driver board in one housing. The small joints (neck, wrist pitch) and the fingers are serial-bus servos.

Energy comes from a 48 V nominal 13S3P lithium-ion pack (about 630 Wh). It passes through a Class-T fuse, a precharge circuit and a contactor that the e-stop opens. DC-DC converters make 19–20 V for the computer (taken before the contactor, so an e-stop never reboots it), 12 V for the serial servos, and 5 V at each wrist for the hand servos. A small keep-alive battery holds the computer up during a pack swap.

Communication: CAN and serial buses

CAN (Controller Area Network) is a two-wire bus (the two wires carry opposite signals, which cancels electrical noise) where every node hears every frame and a number at the start of each message, its identifier, decides which goes first when two talk at once.^[11] RobStride actuators use classic CAN 2.0B at 1 Mbit/s with 29-bit identifiers.^[10] A frame with 8 data bytes takes at most 160 bits on the wire (131 bits plus up to 29 extra “stuff” bits the hardware inserts to keep the receivers in step; description/robot.yaml), so 160 µs. Every motor needs a command and a reply each cycle, so the bus load is

load = n_motors × 2 frames × 160 bits × f_cycle ÷ 1 000 000 bit/s

where n is the number of motors on the bus and f the command rate. Three leg motors at 500 Hz give 3 × 2 × 160 × 500 / 10⁶ = 0.48, which is the repo’s 48%. A load of 0.48 means the wires are busy 48% of the time. Marvin Bot keeps every bus at or below 0.6 so that resent messages and timing wobble have room. Page 10 goes deeper.

Sensors

The policy only sees what the robot can measure: the pelvis IMU (gyro and accelerometer, giving angular velocity and the direction of gravity), every joint’s position and velocity from the actuators’ encoders, and, for perception, the head’s Orbbec Gemini 335L depth camera. Page 11 covers them.

Onboard compute and software

The computer is a Jetson AGX Orin 64 GB developer kit, a palm-sized NVIDIA board built for robots: a 12-core Arm Cortex-A78AE CPU and a 2048-core Ampere GPU sharing 64 GB of memory, 15–60 W.^[1] It runs JetPack 7.2, NVIDIA’s Linux and driver bundle for Jetson.^[2] On top of that the software splits in two:

• A real-time control process, outside ROS. One program owns the CAN buses, reads the IMU, runs the policy at 50 Hz, applies the safety layer (joint, velocity and torque clamps, a command timeout, fall detection into a damping mode, where the motors only resist motion so the robot slumps instead of thrashing) and sends joint targets. Keeping it outside ROS keeps the hard-timed path short and easy to reason about.
• ROS 2 Jazzy around it for everything that can tolerate a few milliseconds of jitter: the camera driver, logging, teleoperation and later the VLA bridge.^[4] Isaac ROS 4.6 adds NVIDIA’s GPU-accelerated ROS 2 packages; 4.6 is the release that brought JetPack 7.2 support to Orin.^[3]

The common ROS alternative is ros2_control, where a controller manager calls a hardware interface’s read and write functions in a real-time loop and loads controllers as plugins.^[5] It is a reasonable design; the repo chose a plain process first because the loop is small (read, infer, clamp, write) and the bench tests must show the CAN timing before anything else is layered on.

The control hierarchy

1. High level, about 1–4 Hz. A vision-language-action model (GR00T N1.7, NVIDIA’s open model: one part reasons slowly about images and words, a second part outputs short chunks of motion^[15]) or a human teleoperator (a person steering it remotely) sets goals: a walking velocity, arm targets. On an AGX Orin with TensorRT (NVIDIA’s tool for running networks fast on its chips), one 16-step action chunk took about 0.28 s in one published deployment,^[16] so the VLA runs on the desktop GPU first.
2. Policy, 50 Hz. A small multilayer perceptron, MLP, the simplest kind of neural network (layers of 256, 128 and 128 “hidden units” for flat walking, 512-256-128 with the terrain map) maps the observation (gyro, gravity direction, command, joint positions and velocities, last action, and on rough ground a height map) to joint position targets for the 12 leg joints. Its output is a target, not a torque.
3. Joint PD, in the motor driver. PD stands for proportional-derivative. Each driver computes τ = k_p(q_target − q) + k_d(0 − q̇) many times per millisecond, where q is joint angle, q̇ its velocity, and k_p, k_d the stiffness and damping gains sent with the command. Page 15 explains the gains.
4. Current loop, tens of kHz. The torque request becomes a current request (τ = K_t × I × gear ratio, K_t the torque constant), and field-oriented control (FOC) switches the driver’s transistors on and off thousands of times a second to hold that current. Open-source quasi-direct-drive drivers run this loop in the tens of kilohertz.^[19]

Why the timing budget matters

A policy trained in simulation learned to act on observations of a certain age. If the real robot’s observations are older, the policy reacts to a pelvis tilt that has already grown; feedback with extra delay starts to overcorrect and oscillate, like adjusting a shower whose hot water takes too long to arrive. Latency was one of the first identified causes of the sim-to-real gap for legged robots, and modelling it in training fixed walking that otherwise failed.^[14][13] Marvin Bot’s walking tasks give every simulated robot a random delay of 0–20 ms on its IMU and joint readings and 0–10 ms on its motor commands, so the policy is robust across that range. Playground 2 checks whether the real chain stays inside it:

sensor side = IMU sample hold + transport delay
action side = inference + wait for CAN slot + frames on the bus + driver loop
event to torque = sensor side + wait for policy tick + action side

The “sensor side” is how old the reading is when the policy sees it; the “action side” is how long the policy’s answer takes to become torque. In the average case each wait is half its period (½ × 1/f, where f is that loop’s rate); in the worst case a whole period.

The training side and sim-to-real at a glance

Policies are trained on a desktop graphics card (GPU), never on the Orin. The tools have many names; what matters at this stage is what each one does (pages 14, 16 and 17 explain them):

• Walking and stairs: Isaac Lab 3.0, NVIDIA’s robot-learning simulator (running on the Newton or PhysX physics engines), runs thousands of copies of the robot at once, and a learning method called PPO (proximal policy optimisation, from the rsl_rl library) improves the policy by trial and error.^[6]
• Human-like motion: ProtoMotions, on Newton, trains a motion-tracking policy to copy human movements, which are generated from text with Kimodo and fitted to Marvin Bot’s body with PyRoki, following the BeyondMimic method.^[7][18]
• Cross-check: every exported policy is replayed in MuJoCo, a different physics engine, with sensor noise: if it only works in the simulator it was trained in, it has learned that simulator’s quirks.^[8]

As of the latest repo update, flat-ground policy v9, retrained on the current 1.41 m body, passes that cross-check, and the stair policy (rough v9, still trained on the earlier 1.29 m body) passes all 25 stair runs.

The exported network is an ONNX file plus a JSON file describing joint order, default pose, action scale and observation layout; on the robot, ONNX Runtime or TensorRT runs it.^[9] Sim-to-real is then a loop: measure the real actuators on the bench (phase 2), fit the simulated motor model, retrain, and repeat. Page 20 covers it.

How Marvin Bot does it

In the repo

• Stack: Jetson AGX Orin 64 GB developer kit, JetPack 7.2, Isaac ROS 4.6, ROS 2 Jazzy; “a real-time control process (CAN I/O, 50 Hz policy, safety) runs outside ROS” (docs/decisions.md, 2026-10-25, compute and software stack; docs/plan.md, workstreams).
• Rates: policy 50 Hz, leg motor commands 500 Hz, arm ≥250 Hz, IMU ≥500 Hz (docs/requirements.md R42, R43).
• Buses: 6 motor CAN buses (left and right hip, left and right shank at 500 Hz and 48% load; left arm 40%, right arm plus waist 48% at 250 Hz) and a battery bus at 10 Hz (description/robot.yaml). The Orin’s two on-board CAN ports serve the arms, one dual-channel USB-CAN adapter serves each leg, one single-channel adapter the battery; a microcontroller bridge is the fallback if jitter is too high (roadmap open items 4 and 13).
• Driver: robot/drivers/robstride.py encodes RobStride’s CAN protocol from the manuals and is unit-tested but untested on hardware; bench/actuator/bench_robstride.py latency will measure command-to-feedback time on the Orin.
• Delays in training: 0–20 ms on observations and 0–10 ms on commands, per robot per episode (sim/isaaclab/marvin_bot/robot_cfg.py, DelayedDCMotor; docs/decisions.md 2026-10-27).
• Export: sim/isaaclab/export_policy.py writes policy.onnx and policy.json; sim/mujoco/check_policy.py is the cross-check.
• Power: computer supply before the contactor; e-stop and watchdog relay open the contactor (docs/design/assembly_wiring.md, docs/safety.md).

Trade-offs and alternatives

Choice	Picked	Alternatives considered	Why
Onboard computer	Jetson AGX Orin 64 GB dev kit	Jetson Thor T4000 (same module price in 2026)	Already available; Thor is noted for a second robot (docs/decisions.md).
Real-time loop	Own process outside ROS	ros2_control hardware interface	Short, auditable timed path; ROS 2 kept for jitter-tolerant work.
Isaac ROS version	4.6 on Jazzy	5.0	5.0 skipped for now because of reported regressions on Orin.
CAN interfaces	On-board CAN plus isolated USB-CAN (gs_usb, SocketCAN)	Microcontroller bridge; five single-channel adapters	Cheapest path; the bench timing test decides.
VLA placement	Desktop GPU first, Orin with TensorRT later	Onboard from the start	A few hertz on Orin at best; the policy must keep its 50 Hz regardless (open item 10).
Whole-body control	RL lower body plus IK arms, then motion tracking	A large pretrained whole-body controller	Published checkpoints target another robot and need far more compute to retrain.

Where sources and the repo disagree

NVIDIA’s Isaac ROS release notes list 5.0 (September 2026) as the latest release, and it moves Isaac ROS to the ROS 2 Lyrical distribution;^[3] the repo pins Isaac ROS 4.6 on ROS 2 Jazzy. This is a deliberate choice, not an error: 4.6 is the release that added Orin and JetPack 7.2 support, and staying on it keeps the whole stack on Jazzy. But a reader following NVIDIA’s “latest” documentation will land on 5.0, so pin the 4.6 docs.

Decisions you can make here

• IMU connection: a ready-made USB IMU is quicker to set up; a small microcontroller board reading the IMU chip directly (over serial or SPI) is more work but keeps the sensor side well inside 0–20 ms in the worst case, not just on average.
• CAN adapters: plug-in USB-CAN adapters are cheap and simple; a microcontroller bridge costs design time but gives steadier timing. The bench latency test decides.
• Policy rate: running faster than 50 Hz shortens the wait for the next tick, but the policy must be retrained at that rate and the computer works harder.
• Policy size: a bigger network (a transformer that remembers recent history, for example) may walk better, but each extra millisecond of thinking time eats into the 0–10 ms action-side range the policy was trained with.

Your decision noteCopy

Built from your settings above. Paste it into an issue, a design discussion or an AI assistant session.

Where this leads. This page is the map of the machine; the rest of the guide zooms in. Stage 2 starts at the bottom of the diagram with the motors (page 04) and the loads they carry (page 05); the buses, sensors and power get their own pages in stage 3.

Further reading

• Berkeley Humanoid (Liao et al., 2024): a clear, open description of a learning-based humanoid’s whole stack, with its rates and how it avoids modelling latency.
• Sim-to-Real: Learning Agile Locomotion for Quadruped Robots (Tan et al., 2018): the paper that showed latency and actuator models matter for transfer.
• ros2_control: getting started: the standard ROS way of structuring a real-time hardware loop, worth knowing even if you do not use it.
• MIT 6.832 Underactuated Robotics (Tedrake): course notes on why feedback rates and delays limit what a controller can do.

Sources

1. NVIDIA, Jetson AGX Orin product page and technical brief — used for: CPU, GPU, memory and 15–60 W power range.
2. NVIDIA, JetPack SDK — used for: what JetPack is.
3. NVIDIA, Isaac ROS release notes — used for: 4.6 (August 2026) added Jetson Orin and JetPack 7.2 support; 5.0 moves to ROS 2 Lyrical.
4. Open Robotics, ROS 2 Jazzy documentation — used for: ROS 2 as the middleware for camera, logging and teleoperation.
5. ros2_control documentation (Jazzy) — used for: controller manager, hardware interface and real-time loop concepts.
6. NVIDIA, Isaac Lab documentation — used for: parallel simulation for training on the desktop.
7. NVIDIA, ProtoMotions — used for: the motion-tracking training framework.
8. Google DeepMind, MuJoCo documentation — used for: the second physics engine used for cross-checks.
9. ONNX Runtime documentation — used for: running exported ONNX policies on the robot.
10. RobStride, Product_Information (RS04 user manual) — used for: CAN 2.0B at 1 Mbit/s, 29-bit identifiers, 14-bit absolute encoder.
11. CAN in Automation, CAN knowledge — used for: how CAN arbitration and frames work.
12. Liao et al., Berkeley Humanoid: A Research Platform for Learning-based Control, 2024 — used for: policy at 50 Hz, PD at 25 kHz on the motor driver.
13. Hwangbo et al., Learning agile and dynamic motor skills for legged robots, Science Robotics 2019 — used for: modelling actuator dynamics and delays for transfer.
14. Tan et al., Sim-to-Real: Learning Agile Locomotion For Quadruped Robots, RSS 2018 — used for: latency as a cause of the sim-to-real gap.
15. NVIDIA, GR00T N1: An Open Foundation Model for Generalist Humanoid Robots, 2025 — used for: the dual-system VLA design.
16. Seeed Studio wiki, GR00T N1.7 with TensorRT on AGX Orin (JetPack 7.2) — used for: about 0.28 s per 16-action chunk on AGX Orin.
17. Radosavovic et al., Real-World Humanoid Locomotion with Reinforcement Learning, 2023 — used for: further reading on learned humanoid controllers (a transformer over observation history).
18. Liao et al., BeyondMimic: From Motion Tracking to Versatile Humanoid Control via Guided Diffusion, 2025 — used for: the motion-tracking recipe the repo follows.
19. Katz, A low cost modular actuator for dynamic robots, MIT thesis, 2018 — used for: current and PD loops in an open-source quasi-direct-drive driver running at tens of kHz.