Contact us

Legged-platform technical dossier · 02

Solo 12: reconstructing an open torque-controlled research stack

Treat Solo as a graph of hardware, motor-control, robot-interface, configuration and simulation repositories—not as one self-contained download.

Evidence statusEstablished academic platform · distributed dependency graph · exact revision compatibility must be reconstructedSources checked 4 August 2026
Read the engineering asset map ↓Back to legged references ↗

Identify platform and generation first

A project name cannot replace exact mechanical, electrical, firmware and simulation revisions.

Solo emerged from the Open Dynamic Robot Initiative’s modular torque-controlled robot architecture. Public materials span the Solo 8 and Solo 12 generations and multiple hardware and software repositories maintained across participating research organisations.

Engineering asset map

Put mechanism, electronics, actuation, control and simulation back onto one system map.

01

Open hardware

Publicly available

The initiative links mechanics, electronics, modular actuator, legged robot and foot-sensor drawings through its hardware repositories.

Verify before adoption

Identify the exact Solo generation, actuator/electronics revision, fabrication method, board version and every cross-repository dependency.

02

Robot description

Publicly available

Solo 8 and Solo 12 URDF, meshes, configuration files and PyBullet wrappers in robot_properties_solo.

Verify before adoption

Check generated geometry, inertial properties, joint limits and compatibility with the physical hardware revision.

03

Control interfaces

Publicly available

Low-level Solo interfaces, robot_interfaces driver and related real-time motor-control packages.

Verify before adoption

Freeze repository commits, compiler, real-time environment, master-board or TI-board path, firmware and bus configuration.

04

Simulation & examples

Publicly available

PyBullet loading, demos and examples distributed across Solo packages.

Verify before adoption

Re-identify actuator response, friction, contact and latency before using simulation results on a physical robot.

Layered licence reading

Code, drawings, PCBs, models and vendor parts may carry entirely different rights.

Asset layerKnown statusAdoption decision
Project software

Core Solo configuration and interface repositories identify BSD-3-Clause.

Preserve notices and inspect every dependent repository, generated file and bundled component separately.

Hardware drawings

The initiative describes its open hardware and software as BSD-3-Clause, but individual repositories remain authoritative.

Record the source repository and file-level terms for mechanics, electronics and actuator assets before reuse.

Toolchains & vendor code

MotorWare, board support, CAD tools and vendor components can carry separate or restrictive terms.

Do not infer rights or redistributability from the BSD licence of a neighbouring repository.

This table is a source-navigation and engineering-decision aid, not legal advice. Use original licence texts and qualified advice for an actual decision.

High-energy system validation gates

From one actuator to dynamic gait, expand energy and motion envelopes one controlled gate at a time.

  1. 01

    Dependency manifest

    Evidence to preserve

    Every repository URL and commit, board and actuator revision, toolchain, firmware, generated file and configuration.

    Stop condition

    Stop if documentation generations or hardware revisions cannot be made internally consistent.

  2. 02

    Single-actuator bench

    Evidence to preserve

    Direction, encoder alignment, torque/current conversion, limits, thermal response, watchdog and communication-loss tests.

    Stop condition

    Do not assemble a powered robot around an uncharacterised actuator chain.

  3. 03

    Supported whole-robot test

    Evidence to preserve

    Joint indexing, gravity compensation, state estimation, safe stop, log integrity and fault recovery on a support rig.

    Stop condition

    Stop if any fault produces unbounded torque or an uncommanded restart.

  4. 04

    Reproducible locomotion

    Evidence to preserve

    Protected test space, declared controller, terrain, trials, failures, interventions and maintenance condition.

    Stop condition

    Do not generalise a laboratory gait to homes, public spaces or unsupervised service.

FUURAA analysis

The value of open material is knowing what the engineering team must prove next.

01

Best use

Understanding modular torque-controlled robot design and constructing repeatable academic locomotion experiments from an explicit dependency graph.

02

Main risk

A configuration repository or working simulation can be mistaken for a complete, mutually compatible hardware and software release.

03

FUURAA judgement

Solo’s strongest lesson is dependency discipline: reproducibility belongs to a frozen multi-repository configuration, not to the project name alone.

Applicability boundary

A research platform can teach evidence-building; it does not automatically become a saleable product.

Can support

  • Torque-controlled locomotion research
  • Open actuator and robot-description study
  • Cross-laboratory reproducibility planning

This page cannot replace

  • A maintained single-source build release
  • Verified compatibility across every dependent repository
  • Product safety, reliability and field-support evidence
Continue into the robot product development pathFrom energy architecture and verification to controlled release →