Bipedal robot experiments and the conditions behind a walking result

Check the research interface before the movement video

Unitree's SDK2 repository provides manufacturer software and examples for supported hardware. It is a starting point for checking available interfaces, build requirements and license terms. The presence of example code does not mean every product variant permits the same development access. [1]

Write down whether the experiment commands a walking velocity, joint positions or another supported action. These choices leave different amounts of control inside the manufacturer's software. A paper testing a high-level navigation policy should not be described as replacing the full balance controller.

The experiment record should name the robot variant, firmware, SDK revision and control interface. Retain sensor timestamps and the rate at which commands are actually applied, rather than reporting only the rate at which a program calculates them.

Treat simulation parameters as part of the experiment

MuJoCo's modeling documentation describes configurable contact, friction and actuator behavior. These are choices in a model. They are not measurements of the physical robot unless the experiment supplies a corresponding identification procedure. [2]

For an illustrative walking study, vary one known condition at a time. Compare a level surface with a defined slope, or compare the same surface with a changed carried load. A simultaneous change in mass, friction and sensor delay can produce a failure without revealing which mismatch caused it.

Publish the model files with the trained policy when licensing permits. A video of the simulation omits settings that another researcher needs to reproduce the motion.

Describe the support system and the stop rule

A safety tether may be slack, catch a fall or carry part of the robot's weight. Those situations have different implications for interpreting a trial. State which occurred and how it was observed. A frame alone may not settle the question.

Define the end of a trial before testing. Falling, leaving the permitted corridor, exceeding a time limit and requiring operator assistance can be distinct outcomes. Use the laboratory's approved protection and recovery procedures; a benchmark is not a reason to remove them.

Scroll sideways for all columns.

A distance record and a completion rate can disagree

Suppose a hypothetical experiment contains ten 20 m trials. Eight finish and two stop after 5 m. The completion rate is 8/10, or 80%. Total distance is 170 m across the ten attempts. Reporting only the longest 20 m run would conceal the two interruptions.

Now report the time spent resetting after each stop. A method that travels faster during successful motion may still require more laboratory time per completed trial. Keep this information alongside the motion results rather than mixing it into an unexplained average.

These teaching numbers are unrelated to the performance of a particular robot. A genuine comparison would also need repeated runs and uncertainty reporting under matched conditions.

Choose the next experiment from the failure

A perception error calls for different evidence than an actuator limit or a missed command deadline. Keep the observation immediately before failure, the requested action and the measured response. That record can distinguish a mistaken target from a controller failing to execute a valid target.

A two-legged platform is useful for investigating these questions, but a single walking experiment cannot establish readiness for public operation. Keep the paper's task and environment attached to any summary of its result.