Humanoid Robot Half Marathon Rules: Autonomous Navigation Engineering Challenges

1. The Rules Shift: Evaluation Moves from “Fast” to “Stable” and “Autonomous”

The course rules for the new humanoid robot half marathon were officially released before the race. The race is scheduled for April 19 at Beijing E-Town (the Beijing Economic-Technological Development Area, also known as Yizhuang). Compared with the first edition, the most notable change is not the added distance, but the restructuring of the evaluation criteria: a more complex course, stricter requirements on human intervention, and the first introduction of a segmented course-cutoff system and a unified robot-retrieval system.

For engineering teams, this amounts to a wholesale shift of the optimization objective. In the first edition, “finish time” was almost the only metric, and teams could trade frequent human intervention for steady progress. This year’s rules close that shortcut with three layers of constraints:

1. Autonomy constraint: a mild balance loss that causes the robot to stall must be recovered autonomously by the robot itself. Human assistance is strictly prohibited.
2. Intervention-cost constraint: at most two robot replacements are allowed for the entire course. The first incurs a 15-minute penalty and the second a 20-minute penalty.
3. Time-window constraint: the whole-course cutoff is 3 hours 40 minutes, with cutoff points at several checkpoints. Robots that fail to pass a cutoff on time are recorded as DNF (did not finish).

Layered together, the three constraints produce one effect: technical debt can no longer be masked by operations manpower. A perception false detection that makes the robot spin in place, or a planning oscillation that sends it back and forth along the same path, translates directly into cutoff risk. This rule-design philosophy is becoming increasingly common in embodied-AI competitions. It takes “human on-the-spot reaction” out of system capability, so that evaluation results sit closer to real deployment scenarios.

2. Course Complexity: How Many Variables Hide in 21.0975 km

The course is 21.0975 km long. For the first time it includes an ecological section of Nanhaizi Park and combines more than 10 terrain types, including flat ground, slopes, bends and narrow passages. It also has 12 left turns, 10 right turns and a number of hairpins approaching 90°.

These figures are not decorative. Each one maps onto specific requirements in the algorithm stack:

Course element	Direct impact on the system	Primary failure modes
Ecological section (grass / dirt road)	Uncertain foot–ground friction coefficient; gait must adapt	Slipping, feet sinking, gait instability
Slopes	Shifts in the center-of-mass projection; higher torque demand	Stalling on climbs, insufficient braking on descents
Near-90° hairpins	Small turning radius; speed must drop sharply	Steering overshoot, foot interference
Narrow passages	Passable space narrower than the robot’s turning diameter	Getting stuck, repeated replanning
Alternation of 10+ terrain types	Frequent terrain transitions; the state estimator must converge quickly	Lagging height estimation, misjudged passability

The turn count deserves special attention. With 22 turning points (12 left, 10 right), a turn is more than mileage decoration for a legged robot. Each one means a full speed-profile reset: decelerate into the turn, adjust the support polygon, complete the yaw, then accelerate out of the turn. If a turn costs 3–8 seconds on average, turning alone can eat up 1–3 minutes of the total time budget. This is why path planning cannot optimize only for “shortest distance.” It must optimize for “shortest time,” with turn count as an explicit penalty term.

3. Three Design Principles Under the “Limited Human Intervention” Constraint

The rules grade intervention levels (a mild balance loss that stalls the robot must be self-recovered; human assistance is strictly prohibited). In practice, this defines the boundaries of the system’s state machine. Teams should follow three principles when designing.

Principle 1: Self-recovery takes priority over conservative stopping.
Many control systems default to “emergency stop and wait for an operator” when they detect abnormal posture. Under the new rules, this is the wrong default. A sound design attempts graded recovery first:

• ankle-joint torque compensation
• hip posture adjustment
• a single recovery step to regain the support surface
• the stand-up procedure

Only on an explicit hardware-level fault (overcurrent, temperature limit exceeded, joint stall) should the robot enter a stop-and-wait state.

Principle 2: The basis for judging intervention must be observable.
How do judges determine “human assistance”? In practice, they rely on the correlation between the external command channel and the robot’s motion state. The system therefore needs to:

• disable the teleoperation channel, physically or logically, in competition mode;
• keep complete decision logs, including timestamps, perception input summaries, planning outputs and execution feedback.

These logs both serve as proof of compliance and make post-race review easier.

Principle 3: Fallback paths must be rehearsed in advance.
Every degraded mode must be validated on both the simulator and the physical robot. Examples include:

• falling back to a slow conservative gait
• falling back to pure odometry dead reckoning
• falling back to constant-speed cruising

Switching to a degraded mode that has never been rehearsed fails at a very high rate.

4. Battery Swaps and Penalties: Turning Engineering Reliability into Score

This year’s rules handle energy replenishment with real precision, which makes this the most engineering-actionable part of the rule set:

• At most two robot replacements are allowed for the whole course.
• The first replacement costs a 15-minute penalty; the second costs 20 minutes.
• In-pit battery swaps are carried out under judge supervision. They carry no penalty, but the time spent still counts toward the total.
• Out-of-pit battery swaps are allowed only in emergencies such as a sudden battery fault. The penalty for each one accumulates.

Compared side by side, the costs are clear. Swapping the whole robot carries a fixed, heavy penalty (15/20 minutes). An in-pit swap carries no penalty but still consumes real time. An out-of-pit swap is a “fault backstop,” not a strategic option. Battery management is therefore no longer a logistics problem but a core strategic problem: one wrong swap decision can be the difference between finishing and DNF.

The decision can be modeled as follows: whether to swap depends on a probabilistic estimate of whether the remaining charge can carry the robot to the next swap point, or to the finish line. Illustrative pseudocode:

def should_swap(state, route, config):
    # state.soc: current state of charge; state.eta_min: remaining distance
    soc_needed = predict_energy(route.remaining_segments)  # energy consumption prediction model
    margin = config.min_soc_margin                        # safety margin
    if state.soc - soc_needed > margin:
        return False  # do not swap; keep moving
    # Low charge but short remaining distance: estimate total time for each strategy
    t_swap = config.station_swap_time          # in-pit swap time (penalty = 0)
    t_degrade = estimate_degraded_speed_time(  # time at the low-power conservative gait
        route.remaining_segments, low_power_profile=True
    )
    # If the conservative gait is much faster than swapping, keep going
    return t_swap < t_degrade

Everything hinges on the accuracy of predict_energy. Energy prediction takes terrain type, slope grade and robot mass as inputs. That is also why the model must be calibrated before the race with a sufficient volume of real measurements, not simulation values alone. The per-kilometer energy difference between grass and paved surfaces usually far exceeds what engineering teams would intuitively expect.

5. Energy Budget and Thermal Management: The Physical Ceiling on Finishing

The 3-hour-40-minute cutoff implies an average-pace requirement: 21.0975 km must be covered within 220 minutes, which means an average speed of at least about 5.75 km/h. That figure is net of all the deceleration, turning, battery swapping and recovery actions along the way.

This pace is demanding for a humanoid robot, and it pulls the design constraints back to physics:

• Top walking speed: stable walking speed for most bipedal platforms lies in the 3–7 km/h range. The robot must therefore run for long stretches close to its speed ceiling, with almost no margin.
• Joint thermal accumulation: sustained high load raises motor temperatures, which can trigger derating or a protective shutdown. Thermal management is no longer a “lab problem.” It is a prerequisite for finishing.
• Battery energy density: the whole race must be completed on a limited charge, and the rules cap whole-robot replacements at two. Single-charge range is therefore a hard requirement.
• Mechanical efficiency: foot slip, backdriving losses at the joints and wasted oscillation in the control loop all get amplified into minute-level gaps over 220 minutes.

In practice, build the energy budget table in at the design stage. Allocate mileage and energy quotas by terrain type, reserve a 10%–15% emergency margin, and recalibrate before the race with measured data from the full course length.

6. Perception, Localization, Planning and Control: Four Links That Must All Clear the Bar

Localization and mapping. The ecological section is a long, feature-weak environment. Repeating grass textures, drastic lighting changes and tree-shadow occlusion can cause scale drift in visual odometry. The usual engineering approach is multi-source fusion:

• visual or LiDAR odometry supplies high-frequency relative pose;
• satellite positioning supplies a low-frequency global constraint;
• leg odometry and the IMU fill short gaps;
• a factor graph or filter then optimizes everything together.

Fusion is not a matter of simple weighting. Each source’s uncertainty has to be estimated online. Otherwise, one failed source will corrupt the entire state estimate.

Environment perception and traversability. On slopes, narrow passages and irregular ground, the key question is not “what class of object is this?” but “can I step on this patch of ground?” An elevation map combined with a local traversability cost map expresses this need more directly.

Path planning. The global planner must trade off “shortest distance” against “shortest time.” Its cost function should explicitly include turn penalties, terrain penalties and congestion risk:

cost = (
    w_dist * length
    + w_turn * turn_count * turn_penalty      # time cost of turns
    + w_terrain * terrain_difficulty(seg)     # weighting for grass / slopes / narrow sections
    + w_risk * slip_probability(seg)          # slip and instability risk
    + w_energy * energy_per_meter(seg)        # energy cost
)

The local planner handles dynamic obstacle avoidance and traversal of narrow spaces. Its focus is oscillation suppression. When the cost map changes frequently, the planner can keep flipping between two feasible solutions, and the robot appears to jitter in place. Under a timed format, this is pure score loss.

Motion control and whole-body control. Complex terrain demands:

• adaptive foothold selection;
• torque allocation under support-polygon constraints;
• real-time balance correction based on state estimation.

Fall-recovery logic should exist as an independent sub-state machine that has been heavily tested, not as emergency code.

7. Software Engineering: Simulation, Data Loops and a Cloud Toolchain

Once the rules raise the weight on autonomy, the bottleneck in R&D shifts from “can we write the algorithm correctly?” to “can validation cover enough scenarios?” This is where cloud resources deliver the most value.

• Elastic compute for simulation backfill: gait training and scenario simulation for a legged robot need intensive, highly variable compute. On-demand elastic compute that is scheduled in batches by task fits better than long-term, dedicated occupancy.
• Object storage for datasets and model versions: course-collected data, simulation scenarios and weight files need unified version management and low-cost archiving.
• Logging with monitoring and alerting: during on-site debugging, reporting key metrics in real time (joint temperature, current, SOC, localization covariance, planning latency) and configuring threshold alerts can significantly shorten fault localization.
• Message queues for data return: asynchronous upload, cleaning and re-ingestion of data between the venue and the training site can be decoupled with a queue. This keeps network jitter from destabilizing the on-site system.

As an example, basic cloud capabilities such as those in Baidu AI Cloud, including elastic compute, object storage, logging with monitoring and alerting, and message queues, can be combined into a complete closed-loop pipeline: collect → label → simulate → train → feed back. The core idea is to cover the uncertain cost of validation with elastically scalable compute, rather than gambling on pre-race overtime.

The same point applies to team capability. When teams bring in AI-assisted coding tools, the gains show up mainly in the throughput of repetitive engineering work. Examples include data pipelines, evaluation scripts, logs and dashboards, and simulation configuration generation. Algorithm strategy choices, failure-mode judgment and in-race decisions all require domain expertise and should remain human responsibilities. A sensible approach is to position AI assistance as a way to “raise the team’s engineering throughput,” while treating code review, regression testing and simulation validation as mandatory gates. Code that has been generated should never go straight into the on-robot control loop.

8. Pre-Race and R&D Checklist

Before the race, confirm each item below:

• A pace table derived from the course cutoff has been generated and allocated to specific segments by terrain type;
• The energy prediction model has been calibrated with measured data, and the battery-swap strategy has passed offline replay validation;
• The self-recovery state machine has been implemented in tiers and tested on the physical robot against common instability modes;
• The teleoperation channel is disabled in competition mode, and the decision logs are complete and exportable;
• Every degraded mode has been validated on the physical robot, with no unrehearsed code paths;
• The planning cost-function weights have been tuned, and planning oscillation has been suppressed at narrow passages and hairpins;
• The joint temperature-rise curve has been measured in a continuous run close to race duration, with no derating triggered;
• On-site monitoring metrics and alert thresholds are ready, and the fault-localization path has been rehearsed.

9. Beyond the Race: How to Substantiate the Originality of an Agent Architecture

The industry has recently seen public disputes over similarities between agent architectures. One side responded that it had “not heard of the relevant team” and that “the comparison lacks any basis.” From an engineering perspective, this kind of debate boils down to a more general question: how do you demonstrate and articulate the originality of your own design?

The valuable move is not a war of public opinion, but an argument built on verifiable technical material:

1. Design evolution records. Keep the iteration history from v1 to the current version, and explain which concrete problem drove each change (for example, “layered memory was introduced after long tasks overflowed the context window”). Independent discovery of similar designs is common, and an evolution trail is the strongest independent evidence.
2. Reproducible baselines. Publish or keep internal baseline experiment setups so that performance comparisons are on equal footing. This heads off the fair challenge that “the parameters are not comparable.”
3. Technical difference statement. Compare along capability dimensions (context management strategy, tool-calling protocol, state persistence, failure-retry semantics) rather than code-text similarity, and point out the real differences in design trade-offs.
4. Attribution conventions. Explicitly list ideas borrowed from public research, along with their sources. Acknowledging borrowing does not undermine originality; concealing it does.
5. Discipline in dispute response. In external communications, state only verifiable facts (timelines, design documents, evaluation setups). Do not extend the discussion to unverified allegations.

For agent R&D teams, this material matters beyond dispute response. It is itself a measure of architectural maintainability: a system whose designers cannot explain why it is built the way it is will usually struggle to evolve safely, too.

10. Conclusion

The rules of this humanoid robot half marathon are essentially a stress test of “real deployment capability”:

• complex terrain tests the robustness of perception and control;
• limited intervention tests autonomy;
• penalties and course cutoffs test strategy and energy management;
• together, they test the team’s engineering validation system.

The takeaway for developers is clear: in systems where the weight on autonomy is rising, validation coverage sets the ceiling on reliability. Move validation earlier into simulation and data loops, trade elastically scalable compute for scenario coverage, and treat degraded and recovery paths as first-class citizens to be implemented and rehearsed. That is the real reason a system like this can finish the course reliably.