When Is an Open-Source Humanoid Actually Reproducible? A Bridge Evidence Audit

The short answer

An open-source humanoid becomes reproducible when an outside team can identify, build, calibrate, control, and test the same version without private instructions. A paper, a video page, and a promise to release code are useful signals. They are not yet a reproduction package.

Bridge, released as a September 3, 2026 preprint, is a valuable case study. The authors describe a compact 21-degree-of-freedom humanoid whose body and controller were designed together. They report better simulated human-motion tracking than Bumi, K1, and ToddlerBot, then show physical demonstrations of balance, dancing, a backflip, and teleoperation.

The paper also calls Bridge open source and reports a parts price of about $1,500. During our September 4 review, however, the official project page linked to a generic GitHub profile rather than a versioned Bridge repository. We could not verify a complete bill of materials, CAD package, assembly guide, controller implementation, policy checkpoint, training environment, safety specification, or Bridge-specific license from the official surfaces.

That does not make the research invalid. It changes the status of the release. Bridge currently provides an author-reported design and evaluation with physical demonstrations, while its claimed open reproduction package remains unverified.

This guide has two purposes:

1. audit exactly what the Bridge paper establishes;
2. define the evidence needed before any humanoid should be called reproducible.

For commercial access and operating status, use our humanoid availability tracker. Open files, product availability, and deployed work are separate claims.

The five levels of an open humanoid claim

“Open source” often compresses several different release states. Keep them separate.

Level	Public evidence	What it permits
1. Described	paper, dimensions, architecture, selected component specifications	technical reading and critique
2. Inspectable	versioned code, CAD, robot descriptions, checkpoints, licenses	artifact review and modification
3. Buildable	bill of materials, sourcing, assembly, wiring, calibration, known issues	a serious outside build attempt
4. Reproducible	independent build, declared deviations, matched tests, failure record	evidence that the release transfers beyond its authors
5. Maintainable	releases, migration notes, issue handling, spare parts, compatibility policy	continued use as hardware and dependencies change

A project can be strong at one level and weak at another. An excellent control paper may stop at Level 1. A complete repository may reach Level 3 but still lack an independent build. Commercially sold hardware can be available without being open at all.

The label should name the achieved level. “Repository announced,” “files released,” and “independently reproduced” are more informative than one undifferentiated open-source badge.

What Bridge contributes

Bridge begins with a reasonable engineering observation: humanoid hardware and whole-body control are often optimized in sequence, even though each constrains the other.

A mechanically convenient body can make human motion difficult to retarget. A controller can compensate for some mismatches, but it cannot create missing joint range, remove actuator packaging, or overcome a genuine torque-speed limit. Bridge therefore treats morphology and control as coupled design variables.

The process has four main stages:

1. Compress human joint structure. Candidate waist configurations are screened by human-motion retargeting error, then the remaining one-axis waist options are compared under closed-loop control.
2. Instantiate real actuators. Candidate models include physical envelope, mounting clearance, mass, inertia, reduction ratio, and torque-speed behavior.
3. Test motion feasibility. A policy tracks reference motions in simulation with the selected morphology and calibrated actuator limits.
4. Use failures to revise hardware. Repeated joint saturation must appear across seeds and disappear when limits are relaxed before an actuator is upgraded. The body model and policies are then regenerated and retested.

This is stronger than optimizing a geometry against static poses. The design loop asks whether the proposed body can execute the target motion under modeled physical limits.

It also creates a reproducibility obligation. If calibrated torque-speed curves, candidate actuator sets, morphology parameters, seeds, thresholds, and policy budgets are unavailable, an outside team cannot replay the design decision. The paper can explain the method without making the resulting platform independently reconstructable.

The Bridge hardware record

The paper describes Bridge as a 21-active-degree-of-freedom compact humanoid. Its actuator table assigns:

• 10 Nm-class actuators to upper-body joints;
• 55 Nm-class actuators to hip-pitch and knee-pitch joints;
• 25 Nm-class actuators to the remaining joints, including the parallel ankle mechanisms.

It also publishes actuator mass, physical dimensions, reduction ratio, rotor inertia, rated and peak torque, and rated and peak speed by actuator class. These are useful engineering details.

The public record contains two internal specification differences that a build release should resolve:

Source location	Height	Weight
abstract and Figure 1 caption	88 cm	13 kg
platform comparison table	0.8 m	12.5 kg

These may reflect rounding, a design revision, or a table inconsistency. The sources reviewed do not say which. A versioned hardware release should provide measured as-built dimensions and mass, plus a mapping from paper figures to a tagged design revision.

The paper’s platform comparison reports 21 active degrees of freedom, 6 TFLOPS of compute, and an estimated price of $1,500 for Bridge. It does not provide the itemized basis, region, purchase date, taxes, shipping, fabrication equipment, assembly labor, spares, or replacement rates behind that price.

The price should therefore be read as an author-reported platform estimate, not a verified total cost to reproduce the robot.

What the 94.83% result means

Bridge is compared with Bumi, K1, and ToddlerBot in a common simulation study. The authors train SONIC policies and evaluate a merged LaFAN1 and bones seed motion benchmark in MuJoCo.

A motion is counted as successful when the rollout:

• remains stable;
• completes the target motion;
• stays below a predefined dynamic tracking-error threshold.

The paper reports:

Platform	Motion success rate	Mean joint-position error	Keypoint-position error
Bumi	91.87%	0.1366	44.89
K1	92.66%	0.1108	42.15
ToddlerBot	88.23%	0.1571	49.33
Bridge	94.83%	0.0711	38.43

Bridge also reaches 95.00% on balance motions, 94.50% on highly dynamic motions, and 94.99% on daily-motion sequences in the paper’s three-way categorization.

These results support the authors’ claim that the selected morphology is compatible with their motion-tracking pipeline. They do not establish the same ranking on physical hardware. The comparison is author-run, simulator-based, and evaluated with the paper’s own combined human-likeness metric and success threshold.

Important missing details include:

• the number of motion clips in each category;
• the exact predefined success threshold value;
• evaluation seed counts;
• confidence intervals;
• training compute and convergence criteria for every platform;
• sensitivity to simulator and actuator-model error;
• matched physical trials across all four robots.

Our guide to robot benchmark success rates explains why task identity, denominator, stopping rules, and physical protocol must stay attached to a percentage.

What the physical videos establish

The Bridge paper and project page show qualitative physical demonstrations including single-leg balance, a Charleston dance, a backflip, and teleoperation sequences.

That evidence establishes that at least one physical system executed the displayed behaviors under the authors’ setup. It does not reveal:

• how many attempts produced each selected clip;
• how many falls or protective stops occurred;
• whether clips contain edits or resets;
• how much human control each sequence used;
• payload, runtime, thermal limits, or battery state;
• damage and repair history;
• repeatability across units;
• whether the public policy and configuration can reproduce the same motion.

The paper explicitly identifies two design limits. Rotary actuators increase joint volume and limb mass compared with possible tendon-driven designs. The compact platform also limits workspace and payload for complex manipulation.

Those are appropriate research boundaries. They further show why a backflip video should not be translated into a broad claim about manipulation, durability, or general humanoid capability.

The artifact audit

We reviewed the official paper and project page on September 4, 2026.

Artifact	Publicly verifiable from official surfaces?	Why it matters
paper and method description	yes	explains the design objective and evaluation
project video page	yes	provides qualitative physical evidence
Bridge-specific versioned repository	no	anchors every file to an inspectable revision
CAD and printable parts	no	permits mechanical reconstruction
itemized bill of materials	no	makes component identity and cost testable
wiring and electronics schematics	no	supports safe assembly and debugging
assembly instructions	no	exposes sequence, tooling, tolerances, and labor
calibration procedure	no	aligns encoders, joints, IMU, frames, and controllers
URDF, MJCF, and inertial parameters	no	connects simulation to the physical body
low-level control and safety limits	no	defines real command and protection behavior
training environment and configuration	no	permits policy retraining and comparison
policy checkpoints	no	permits direct evaluation before retraining
Bridge-specific software and hardware licenses	no	defines actual reuse rights
trial-level physical results	no	exposes attempts, failures, resets, and variation
independent outside build	not located	tests whether the package transfers beyond the authors

“No” means not verifiable from the reviewed official surfaces at that time. It does not prove that an artifact does not exist privately or will not be released later.

The most consequential gap is the repository destination. The project page’s GitHub control resolves to a generic profile rather than a named Bridge codebase. A publication update should add the exact repository URL, tag or commit, release date, and license set.

What better release surfaces look like

Existing projects show how to make an open humanoid claim inspectable without claiming that reproduction is easy.

The public ToddlerBot repository links software, documentation, an Onshape design, setup instructions, real-world deployment paths, tests, and explicit license boundaries. Its code and documentation use the MIT License, while its design uses CC BY-NC-SA 4.0. That distinction matters because open code does not automatically grant the same rights for hardware assets.

The Berkeley Humanoid Lite repository links documentation, releases, policy training, simulator validation, low-level deployment, motion capture, and teleoperation. Its separate asset repository documents generation of URDF, MJCF, and USD descriptions from Onshape, plus frame conventions and joint ranges. The code is MIT licensed and other assets are CC BY-SA 4.0.

These examples do not guarantee a successful build. They show the minimum structure needed to attempt one and report a useful failure. Bridge can reach the same inspectable state by connecting its research results to a tagged artifact set.

For the broader problem of moving a policy between bodies, see our embodiment gap guide. Hardware reproduction and policy transfer meet at calibration, actuator limits, observation interfaces, and control timing.

A complete open-humanoid release checklist

1. Identity and versioning

Publish one canonical project page and named repositories. Every paper, video, dataset, checkpoint, and design file should identify a release tag or immutable commit. State which physical serial numbers used that revision.

A repository that changes after evaluation needs a changelog. Otherwise readers cannot know whether they are testing the paper’s system or a later repair.

2. Mechanical design

Release editable CAD where possible, export formats, printable files, drawings, fasteners, bearings, cable routing, tolerances, material specifications, and print settings. Record measured mass and dimensions for the assembled robot.

Include revision-specific deviations from nominal CAD. A humanoid’s center of mass and link inertia can change when cables, covers, batteries, and fasteners are added.

3. Bill of materials and sourcing

Each line should include manufacturer, exact part number, quantity, supplier, unit price, date, region, lead time, and permitted substitution. Flag custom machining, minimum order quantities, discontinued parts, and components that need firmware or vendor tools.

Report at least four cost totals:

1. core robot parts;
2. fabrication and assembly tooling;
3. compute, batteries, chargers, and networking;
4. spares, failed parts, shipping, taxes, and labor.

A total without scope cannot be compared across projects.

4. Electronics and wiring

Publish schematics, connectors, pinouts, power distribution, fusing, grounding, emergency stop, communications buses, expected current, battery protection, and startup order. Include diagnostic steps for swapped phases, encoder offsets, bus faults, and brownouts.

5. Assembly and calibration

Provide an ordered build manual with tools, torque values, alignment fixtures, expected build time, difficult steps, and acceptance tests. Calibration should cover joint zeros, motor direction, encoder alignment, IMU orientation, kinematic frames, current or torque estimation, feet, cameras, and teleoperation devices.

The first successful stand should not depend on an undocumented call with the original lab.

6. Robot descriptions and simulation

Release the exact URDF, MJCF, or USD used for the reported experiments. Include meshes, collision geometry, joint limits, actuator curves, control rates, latency assumptions, contact parameters, inertias, and identified system parameters.

For Bridge, the experimentally calibrated torque-speed limits are central to the co-design claim. Those curves and the calibration method are therefore essential, not optional implementation detail.

7. Control and policy artifacts

Separate:

• motor firmware;
• low-level joint control;
• state estimation;
• safety supervision;
• motion retargeting;
• policy training;
• simulator configuration;
• deployment runtime;
• released checkpoints.

State hardware, operating system, dependency versions, compute target, command frequency, observation frequency, and end-to-end latency. Publish the policy used for each reported video or explain why it cannot be released.

8. Safety envelope

A research release should still disclose practical limits. Publish joint, speed, torque, temperature, battery, workspace, fall, and emergency-stop rules. Describe suspension, tethers, mats, spotters, remote stop, startup tests, and prohibited operating conditions.

Do not call a clip untethered without saying whether a spotter, remote operator, or external safety system remained active. Our robot safety standards guide explains why a research controller is not a certified safety function.

9. Evaluation denominators

For every physical behavior, report:

• task and success definition;
• attempts, seeds, and robot units;
• falls, stops, resets, exclusions, and selected clips;
• autonomy and teleoperation mode;
• intervention count and operator-control time;
• cycle time and runtime;
• battery and thermal conditions;
• damage, repairs, and part replacement;
• trial-level outcomes.

Simulation results need the same discipline around task inventory, seeds, thresholds, early termination, and uncertainty.

10. Outside reproduction

The strongest evidence is a build by a team that did not create the platform. Record its component substitutions, build hours, support received, deviations, failures, final cost, and matched test results.

A failed outside build is useful evidence when the failure is documented. It identifies missing assumptions in sourcing, assembly, calibration, or software. Reproducibility improves when the release can absorb those findings into a new version.

A practical reproduction protocol

An outside lab can test a release in stages instead of attempting a backflip first.

Stage A: artifact freeze

Select a tagged release, archive checksums, resolve license scope, and record every substitution before purchasing. Reject ambiguous files rather than silently mixing revisions.

Stage B: mechanical acceptance

Measure link dimensions, mass, joint range, backlash, and free motion. Compare the as-built system with the released robot description. Update inertial parameters only through a declared deviation file.

Stage C: powered acceptance

Test one actuator class at a time. Verify current limits, thermal behavior, communication loss, emergency stop, encoder direction, and joint limits before connecting whole-body control.

Stage D: static and low-energy control

Begin with supported standing, slow joint trajectories, state-estimation checks, and small balance disturbances. Record frequency, latency, tracking error, saturation, and safety events.

Stage E: matched motion tests

Use a declared subset of released motions and the original success rule. Report every attempt. Compare simulation and hardware trajectories, not only final success.

Stage F: robustness and maintenance

Repeat after battery changes, warm-up, minor falls, part replacement, and software restart. Record calibration drift, repair time, spare usage, and performance decay.

This staged process separates “the files downloaded” from “the robot reproduced the result.”

Evidence boundaries

Claim	Evidence class	Confidence	Boundary
Bridge uses morphology-control co-design	paper method and reported design loop	high for the described method	public artifacts needed to replay the loop were not verified
Bridge is a physical compact humanoid	paper photographs and project videos	high	reviewed sources differ on exact height and weight
Bridge achieves 94.83% motion success	author-run MuJoCo benchmark	high for the reported table	not a physical task, uptime, or outside-reproduction result
Bridge outperforms three comparison morphologies	matched author-run simulation	medium-high	sensitivity, uncertainty, and physical matched trials are not published
Bridge costs about $1,500	author-reported comparison table	medium-low as a reproducible cost	scope, itemization, date, region, labor, tools, and spares are absent
Bridge is open source	paper claim and project-page label	low as a currently inspectable release	no Bridge-specific versioned repository or license was verifiable at review time
Bridge performs balance and dynamic motions physically	selected qualitative demonstrations	medium-high for the shown executions	attempts, falls, intervention, selection, runtime, and durability are undisclosed
Bridge has been independently reproduced	not established	high confidence in the negative boundary	no outside build was located in the reviewed record

Questions to ask before calling a humanoid open source

1. What exact repository, tag, and commit correspond to the paper?
2. Which licenses cover code, CAD, meshes, documentation, data, and checkpoints?
3. Are commercial use, modification, and redistribution permitted for each artifact class?
4. Can the complete robot be built from the public bill of materials?
5. Which parts require custom fabrication, private suppliers, or unpublished firmware?
6. What is included in the reported price?
7. How many labor hours and failed parts did the authors’ builds require?
8. Do measured mass, dimensions, inertia, and actuator behavior match the released simulation?
9. How are joint zeros, sensors, frames, and torque limits calibrated?
10. Which controller and checkpoint produced each reported physical result?
11. What safety equipment and human support remained active?
12. How many attempts, falls, resets, interventions, and repairs sit behind each selected clip?
13. Can a new unit reproduce the result after following only public instructions?
14. Has an outside team done so, and what changed?
15. Is the release maintained when parts, dependencies, and firmware change?

Verdict

Bridge presents an interesting morphology-control co-design method and a compact physical humanoid. The author-run simulation comparison is specific enough to inspect: it defines a stability and tracking rule, compares four morphologies, and reports Bridge at 94.83% on the merged motion benchmark. The paper also makes useful actuator and design constraints visible.

The open-source claim is less mature than the research claim. At review time, the official project page did not expose a Bridge-specific versioned repository. The itemized cost, design files, assembly path, calibration, controller stack, checkpoint, licenses, physical trial denominators, and outside builds were not verifiable from the cited official surfaces.

The appropriate status is announced open-source research platform, public reproduction package not yet verified. That status can change quickly. A named repository with tagged hardware and control artifacts would move Bridge from a descriptive release toward an inspectable one. A complete outside build with matched tests would establish the stronger claim.

For readers, the general lesson is durable: openness is a set of testable artifacts, not a label. Reproducibility begins when another team can build the same version, disclose every deviation, and publish every attempt. The open-source robotics project health audit extends that test to software releases, support windows, governance, documentation, integration tests, and update policy.

Frequently asked questions

Is Bridge open source today?

The September 3 paper calls Bridge open source and the project page presents video demonstrations, but the reviewed public link labeled GitHub leads to a generic GitHub profile rather than a versioned Bridge repository. We could not verify downloadable mechanical files, a bill of materials, assembly instructions, controller code, policy weights, training environments, or a Bridge-specific license from those official surfaces. Treat Bridge as an announced open-source release whose reproduction package was not yet verifiable at review time.

What does Bridge's 94.83% success rate measure?

It is an author-reported MuJoCo motion-tracking result over a merged LaFAN1 and bones seed benchmark. Bridge scored 94.83% under the paper's stability and tracking-error rule, compared with 92.66% for K1, 91.87% for Bumi, and 88.23% for ToddlerBot. It is not a 94.83% success rate for physical household tasks, hardware uptime, or independent reproduction.

What must an open-source humanoid release include?

At minimum, publish versioned CAD and printable parts, a measured bill of materials, supplier and substitution information, wiring and assembly instructions, calibration procedures, robot descriptions, low-level control, training environments, policy checkpoints, licenses, safety limits, and trial-level physical evaluation. A useful release also records build time, failures, revisions, and results from outside teams.

Does a low parts price make a humanoid reproducible?

No. A parts estimate excludes assembly labor, fabrication equipment, shipping, taxes, spare parts, failed prints, tools, batteries, compute, calibration, repairs, and engineering time unless those items are explicitly included. Cost is reproducible only when the release states its scope, date, region, quantities, substitutions, and measured build burden.

Why compare Bridge with ToddlerBot and Berkeley Humanoid Lite?

They provide concrete examples of inspectable release surfaces. Their public repositories link software, robot descriptions or CAD, setup documentation, deployment paths, and explicit licenses. This does not prove that every outside build will succeed, but it makes the reproduction claim testable in ways that a paper and video page alone do not.