The Problem

Building a walking, running humanoid robot from scratch requires integrating mechanical CAD, motor firmware, ROS2 deployment, and reinforcement learning training. Each discipline has its own toolchain and repository, and pulling them together for a single prototype is a multi-week integration effort. roboto_origin aggregates those sub-repositories into one snapshot so a builder can clone once and get the full stack.

What This Does

roboto_origin is a snapshot aggregation of the RoboParty humanoid robot project. The modules/ directory (4,255 files) contains the four core sub-repositories: roboparty_deploy (ROS2 deployment, camera pipelines via RealSense, motion playback), roboparty_firmware (motor control, USB-to-CAN bridge, Orange Pi build system), roboparty_train (Isaac Lab / rsl_rl reinforcement learning), and rpo_hardware (mechanical CAD, BOMs). The root level holds documentation, asset images, and a generate_star_history.py script that renders the star-history SVG.

The README is explicit: this is a snapshot only. Module-level issues and contributions go to the individual sub-repositories; this repo exists for one-stop pulls.

How It Is Wired

Execution starts at a few real entry points. motion_player.py:91 (run) is the primary user-facing one — it reads motion data and drives the robot's motors, reaching 20 functions internally and touching the filesystem via shutil.copyfile. The generate_star_history.py:212 entry (main) reaches 183 functions and makes an outbound network call via requests.get to GitHub's API.

The internal call graph resolves 1,713 edges. The widest blast radius sits in test utilities, not production code: pytest_rs_utils.py is called from 47 other files and defines init, which is itself called from 21 places. minimal_mqtt_client.py and mqtt_client_simulator.py are hubs for MQTT-based camera communication, each called from 41 and 26 files respectively. The motion_player.py script is the production hub, calling into 43 functions — changing it risks breaking the whole deployment path.

The camera pipeline is the most heavily wired subsystem: mqtt_bridge_node.py sets up MQTT connections and topics, camera_node_simulator.py publishes color and depth frames, and rs2_test.py runs external commands for hardware validation. The training side routes through normalization.py (mean called from 34 places) and rollout_storage.py. There is no single control loop — the system is a set of loosely coupled ROS2 nodes, MQTT bridges, and training scripts.

How To Use It

Setup: Clone and check out the modules:

git clone https://github.com/moses-y/roboto_origin
cd roboto_origin
git submodule update --init --recursive

Each module has its own dependency file — modules/roboparty_train/rsl_rl/pyproject.toml (pip), modules/roboparty_firmware/roboto_usb2can/scripts/requirements.txt (pip), and modules/roboparty_xr_teleop/requirements.txt (pip). No root-level install script exists; you install per-module.

Configuration: Camera parameters live in modules/roboparty_deploy/src/camera/configs/realsense_d435i.yaml and parkour.yaml. Motion playback settings are in modules/roboparty_deploy/scripts/config/motion_player.yaml.

Running it: The primary entry point is modules/roboparty_deploy/scripts/motion_player.py. There is no documented CLI command in the README excerpt, so you would invoke it directly:

python modules/roboparty_deploy/scripts/motion_player.py

Real-World Use

A builder assembles the robot from the CAD files in modules/rpo_hardware/V2.0/, flashes the Orange Pi firmware from modules/roboparty_firmware/orangepi-build/, then runs the deployment stack. The camera node publishes depth frames over MQTT, motion_player.py reads motion data and drives motors via the USB-to-CAN bridge (modules/roboparty_firmware/roboto_usb2can/), and a training loop in modules/roboparty_train/ produces new policies that get deployed back through the same pipeline.

Code Health & Issues

Static analysis found 8 issues (0 critical, 3 high, 5 medium):

  • High - No lockfile beside modules/roboparty_train/rsl_rl/pyproject.toml — unlocked dependency ranges mean the tested artifact can differ from the shipped one. Commit the generated lockfile.
  • High - CI exists (.github/workflows) but no workflow invokes the 110 test files. Add a test step to the existing workflow.
  • High - .github/workflows/update-star-history.yml pushes directly to the default branch. Push to a bot branch and open a PR instead.
  • Medium - No Dependabot or Renovate configured for the 3 manifests.
  • Medium - Docker base image ubuntu:22.04 in modules/roboparty_firmware/orangepi-build/external/config/templates/Dockerfile is unpinned. Use a digest.
  • Medium - No dependency vulnerability scan in CI.
  • Medium - 114 blobs over 5MB in the repo, including a 58.4MB SLDASM file. Move to Git LFS.
  • Medium - Dockerfile has no non-root USER directive.

The Bottom Line

This is a genuine, complete open-source humanoid robot — the hardware, firmware, training, and deployment code are all present. The snapshot structure is practical for builders but the lack of root-level setup documentation and the unused CI test suite mean you'll spend time on integration. Use it if you want a real reference implementation for humanoid locomotion; expect to work through module-specific setup yourself.