Numbers Every Roboticist
Should Know

For a robot moving at 1 m/s, a 33 ms camera frame equals 3.3 cm of blindness. At 2 m/s it's 6.6 cm. A useful change in perspective for me came when I stopped thinking in milliseconds and equated it to distance unseen between vision signals.

The MIT Cheetah's foot is in the air for ~85 ms — fewer than three 30 fps frames. Your control loop has this long to decide what to do when it lands. Human voluntary reaction time floors at ~250 ms. It is not a coincidence that this is where network teleoperation becomes unstable.

A common rule of thumb is that each control layer must run ~10× faster than the layer above it. This is why robotic stacks have 1 kHz current loops under 100 Hz position controllers under 10 Hz planners. For example, a VLA at 5–50 Hz commands a manipulator executing at 50 Hz with action chunking, so the policy recomputes every 73 ms but the robot fully executes the pre-predicted chunk between recomputes. Slow policy, fast execution.

Bandwidth matters in robotics because you cannot do math on bits that haven't arrived yet. If your model has 70 GB of weights and your memory bandwidth is 3.3 TB/s, the minimum time to read every weight once is 70/3300 = 21 ms. A useful intuition is HBM bandwidth on a top-end GPU or TPU is roughly the same as moving a Christopher Nolan 4K movie every second. It sounds absurd until you realize a 70B-parameter model wants to be read end-to-end every few milliseconds during inference.

Precision matters here. A FLOP at FP32 and a FLOP at FP4 are not the same physical operation. FP4 works on 8× less data than FP32 and usually 10× less energy, so when NVIDIA says Blackwell does 20 PFLOPS, they could mean FP4 with sparsity tricks.

I prefer listing arithmetic operations in picojoules (pJ) because energy is what matters. A DRAM read costs 200× more than a floating-point multiply on the same chip. Accelerators do trillions of FLOP/s, so picojoules-per-FLOP multiplied by FLOP/s gives you watts of power consumed. A 3.7 pJ multiply × 1 trillion = 3.7 watts. This tiny per-operation number done over and over is what determines whether your robot needs a fan.

For AI serving, you usually choose the opposite trade-off. Batching improves throughput at the cost of latency. If you wait until 64 inference requests arrive before processing, you spread the cost of reading the weights across all 64, but the first request waited for the other 63 to show up.

For robots, latency is non-negotiable. A controller that processes 10,000 sensor readings per second on average but occasionally takes 50 ms to respond to one of them will break.

Thor is the first edge SoC where running a 7B-parameter VLA above 10 Hz is comfortable. This matters: at <10 Hz a policy must chunk aggressively to maintain 50 Hz arm execution. Orin and Thor both ship hardware video encoders, vision accelerators, and ISP pipelines to offload video encoding to dedicated hardware blocks.

36-DOF actuator state at 1 kHz × 32 bytes = 1.2 MB/s. Four 4K cameras raw = 6 GB/s. These differ by more than 5,000×. Design the buses accordingly — one is trivially served, one requires on-sensor encode to be feasible at all.

Action chunking: π₀ predicts 50 future actions per 73 ms inference. The robot executes the chunk at 50 Hz and the policy recomputes in parallel. Original ACT imitation success jumps from 1% at chunk=1 to 44% at chunk=100. The bottleneck isn't GPUs. Figure, Pi, and Tesla all internalized this in 2024–25: teleop data collection costs 10–100× more than the compute to train on it.

Humans run a slow conscious loop (~5 Hz) over a fast reflex layer (~25 ms).