Humanoid robotics - typical onboard computation architecture

Scope: common patterns used in modern humanoid / legged robots to enable perception (navigation), whole-body motion (balance + manipulation), and communication. This is a practical, vendor-neutral summary.

1) Why humanoids are typically distributed (not monolithic)

Humanoids combine several workloads that have conflicting requirements:

• Hard/firm real-time control (balance, torque/current loops, safety interlocks): deterministic timing, low jitter, often 1 kHz or higher.
• High-throughput perception (cameras, depth, LiDAR, learned policies): benefits from GPUs/NPUs, tolerates some latency but needs bandwidth.
• Planning / navigation (SLAM, footstep planning, task planning): variable compute, often multi-threaded, may be intermittent.
• Comms (Wi-Fi/5G/Ethernet, fleet management, teleop): non-real-time, security considerations.

A single computer can run all of this for small robots, but as DoF counts rise, designers typically split the system into layers so that real-time control cannot be disrupted by perception/planning load spikes or OS scheduling noise.

2) Typical layered architecture (primary node + multiple secondary nodes)

A common arrangement is:

                     +--------------------------------+
                     | High-level compute ("Robot PC")|
                     | - ROS 2 graph (nodes)          |
Sensors --> drivers->| - perception, SLAM, planning   |--> Wi-Fi/5G/Ethernet -> operator/cloud
(cams/lidar/imu)     | - behavior, autonomy, logging  |
                     +-----------------+--------------+
                                       |
                                       | deterministic control link
                                       | (often 1GbE physical layer)
                                       v
                     +--------------------------------+
                     | Real-time motion controller     |
                     | - runs 0.5-5 kHz control cycle  |
                     | - publishes joint commands      |
                     | - reads encoders/torque/IMU     |
                     | - may be part of Robot PC, or   |
                     |   a separate CPU/SoC            |
                     +-----------------+--------------+
                                       |
                                       | Fieldbus: EtherCAT (common)
                                       | or CAN/CAN-FD (common in smaller systems)
                                       v
   +------------------+   +------------------+   +------------------+
   | Joint module #1  |   | Joint module #2  |   | Joint module #N  |
   | - drive+MCU      |   | - drive+MCU      |   | - drive+MCU      |
   | - local loops    |   | - local loops    |   | - local loops    |
   +------------------+   +------------------+   +------------------+

           +--------------------------------------------+
           | Independent safety chain (recommended)      |
           | - E-stop, STO (Safe Torque Off), contactors |
           | - safety MCU / safety PLC / safety IO       |
           +--------------------------------------------+

2.1 High-level compute ("primary node")

Role: world perception and state estimation, mapping/localization, whole-body planning, task logic, UI/teleop, logging, and system orchestration.

Typical hardware:

• x86_64 industrial PC or SBC (Intel i7/i5 class) and/or embedded ARM SoC.
• GPU/AI accelerator: NVIDIA Jetson class modules are common for onboard inference.
• Storage: NVMe SSD for datasets and logging.
• Networking: 1GbE/2.5GbE internal, plus Wi-Fi/5G for external comms.

Typical software:

• Linux, often with tuning for latency (PREEMPT_RT or low-latency kernel) when it hosts control.
• ROS 2 is common in R&D and increasingly in production for the high-level stack.

2.2 Real-time motion control (sometimes separate)

Role: run the “servo cycle” that must be deterministic (read joint sensors, compute commands, write commands) and synchronize many axes.

• May run as a privileged real-time process on the main computer, or on a dedicated controller (separate CPU/SoC/FPGA).
• Interfaces to the joint network via EtherCAT master or CAN master.
• Feeds high-rate state estimation (IMU + kinematics) and sends targets to drives (position/velocity/torque modes).

2.3 Joint-level embedded controllers ("secondary nodes")

Role: close the fastest loops near actuators (current/torque/velocity), manage encoders, local sensing, thermal protection, and sometimes impedance control.

• Often implemented inside integrated actuators (motor + gearbox + encoder + drive + MCU).
• Communicate via fieldbus to reduce wiring: typically only power + data to each joint chain.
• Local watchdog behavior: if communication is lost, enter safe state (stop/hold torque off, etc.).

2.4 Safety subsystem (independent path)

Safety is typically designed to remain functional even if the main computer crashes. Common elements:

• Physical E-stop button(s) and remote E-stop.
• STO lines to drives, safety-rated contactors, and power distribution supervision.
• A dedicated safety controller (safety MCU / safety PLC) supervising interlocks and timeouts.

3) Communication inside the robot

4) Typical onboard computer configuration (practical examples/patterns)

• 1 - 3 onboard computers is common for larger humanoids: e.g. separate compute for control vs perception vs estimation, or redundancy/segmentation.
• Dual CPUs + optional third computer is a known pattern in commercial humanoid platforms (to separate platform functions from user development payload).
• GPU/AI accelerator is increasingly standard (Jetson Orin class) to run perception and learned policies onboard with low latency.

4.1 Reference patterns you can copy

5) What runs where (navigation vs movement vs comms)

5.1 Navigation (localization, mapping, obstacle avoidance)

• Runs on the high-level compute (CPU + GPU) because it needs heavy sensor processing (vision/LiDAR) and benefits from large memory.
• Outputs high-level motion goals (desired base velocity, footsteps, end-effector targets) rather than per-motor commands.

5.2 Movement (whole-body control, balance, contact handling)

• Split across layers:
• Whole-body control and dynamics computations often run in the real-time motion controller loop (hundreds of Hz to 1+ kHz).
• Servo control (current/torque loops) typically runs in each drive/joint (kHz to 10s of kHz, depending on actuator electronics).

5.3 Communication (teleop, fleet mgmt, cloud)

• Runs on high-level compute, isolated from control network.
• Typically includes a command gateway, logging uploader, update mechanism, and security controls.

6) Notes for implementers (if you are designing your own)

• Partition your networks: keep motion fieldbus separate from high-bandwidth sensors and external comms.
• Decide the real-time boundary early: either dedicate a controller for the servo cycle, or carefully engineer RT on the main computer.
• Time synchronization matters: consistent timestamps across IMU, encoders, and perception greatly improve estimation/control.
• Fail-safe behavior: each joint should have a safe state on comms loss; safety chain should not depend on ROS.

7) Prototype bill of materials (BOM) - lightweight full-sized humanoid

7.1 Degrees of freedom and actuator counts

7.2 Compute (onboard)

7.3 Binocular vision

7.4 IMU / gyro modules (5x)

7.5 Pressure / tactile sensors (15x)

7.6 Internal network (hub-and-spoke CAT6)

7.7 Interface nodes (Ethernet spoke nodes to local buses)

A practical way to preserve hub-and-spoke Ethernet while keeping motor wiring sane is to place a small controller in each limb/segment, and run local CAN/CAN-FD from that controller to a chain of smart actuators.

7.8 Motor network interfaces (to talk to smart actuators)

7.9 Actuation (motors + controllers)

Prototype-friendly option - integrated actuator modules (recommended for early prototypes): these combine motor + gearbox + encoder + drive/controller, typically with CAN/UART.

Alternative - separate servo drives + motors: higher engineering effort but potentially better mass optimization if you move to frameless motors and custom geartrains later.

7.10 Battery pack (20 6550 cells) + power distribution

7.11 Misc non-structural parts (often forgotten)

7.12 Rough weight + power budget (actuators, battery, compute)

Order-of-magnitude estimates for early feasibility checks. Use this to sanity-check whether your battery and thermal design are even in the right ballpark.

Target total mass budget: 50 lb (22.7 kg).

7.12.1 Actuators (nameplate - rated power; peak power will be higher)

Reality check: you will not run at “sum of rated power” continuously, but this highlights how quickly actuator peak demand can outrun a small battery pack and small DC bus wiring.

7.12.2 Battery pack (20 6550 cells - plug in your cell spec)

• Cell count: 20 cells total. Choose your series/parallel split (NsNp) based on bus voltage + capacity targets.
• Nominal pack voltage (Li-ion): approx (3.7 V - series-count). Full charge is approx (4.2 V - series-count). Example: 20S is ~74 V nominal (~84 V full).
• Energy: Wh - approx (V_nominal - Ah_pack). Example: 74 V - 5 Ah is about 370 Wh.
• Runtime: hours - approx Wh / average-power. (Peak legged motion can be multiple kW; average depends heavily on gait, payload, and duty cycle.)
• Mass: approx 20 - cell-mass + BMS + packaging + wiring. Example: if each cell is 70 g (2.5 oz), cells alone are 1.40 kg (3.1 lb) before BMS/enclosure.

7.12.3 Compute (very rough - depends on your exact modules and cooling)

8) References (starting points)

• NASA Valkyrie paper (mentions distributed control architecture): https://sites.utexas.edu/hcrl/files/2016/01/jfr-nasa-hcrl-final.pdf
• Atlas overview stating three onboard computers (control/perception/estimation): https://en.wikipedia.org/wiki/Atlas_(robot)
• Agility Robotics Digit: torso houses two multi-core CPUs + modular third computer bay: https://www.agilityrobotics.com/content/meet-digit-the-newest-robot-from-agility-robotics
• Example EtherCAT-based humanoid control architecture (MDPI): https://www.mdpi.com/2227-7390/12/9/1405
• micro-ROS overview (ROS 2 to microcontrollers): https://micro.ros.org/
• Unitree H1 product page (example of multiple onboard compute options): https://www.unitree.com/h1/

File generated for: /home/marc/documents/Robot-Project/