Humanoid Robot Half Marathon Rules: A Deep Technical Breakdown

1. Introduction: Rules as an Engineering Requirements Document

The 2026 humanoid robot half marathon will begin on April 19. On April 14, the Beijing Economic-Technological Development Area (Beijing Yizhuang) officially released the competition rules. The rules cover multiple dimensions, including the track environment, race procedures, fall and collision handling, and results and awards. They encourage robots to navigate autonomously and impose stricter requirements on human intervention, aiming to promote the integration of technology and sports through rule innovation.

For participating teams, the competition rules should not be treated as a document to be read once and set aside. They should be treated as an engineering requirements specification that needs to be decomposed item by item. Only by mapping each rule to concrete metrics in perception, decision-making, control, energy, and validation can teams determine where technical investment should be directed.

The table below shows this mapping:

Rule item	Key requirement	Corresponding engineering capability
Track and terrain	21.0975 km; ecological route introduced for the first time; more than 10 terrain types; 12 left turns, 10 right turns, and bends close to 90°	Long-distance terrain-adaptive walking, precise localization, global and local path planning
Autonomous navigation	Autonomous navigation is encouraged, with stricter requirements for human intervention	Multi-source fusion localization, environmental perception, real-time replanning, autonomous failure handling
Robot replacement	At most 2 replacements during the full race; 15-minute penalty for the first replacement and 20-minute penalty for the second	Whole-robot reliability, core-module redundancy, fast power-cycle recovery
Battery swapping	No penalty for swapping inside a station, but the time counts toward total race time; outside-station swapping is limited to emergencies, with penalties accumulating	Energy efficiency optimization, endurance calibration, battery-swap strategy modeling
Fall, collision, and fault	Graded handling; minor imbalance or stalling must be recovered autonomously; human assistance is strictly prohibited	Balance recovery, fall detection and self-rescue, fault grading and safe stopping
Results and cutoffs	Full-course cutoff is 3 hours 40 minutes; checkpoint cutoff points are enforced; overtime is recorded as DNF (Did Not Finish)	Time-budget management, dynamic pacing, state telemetry, and early warning

This article is based on the publicly announced track and rule information. For specific race details, intervention criteria, and segment cutoff times, participating teams should refer to the official competition regulations.

2. Breaking Down the Track Terrain and Technical Responses

1. From a Half Marathon to a Composite Terrain Testbed

The standard distance of a half marathon is 21.0975 km. For human athletes, the main challenges on such a course are endurance management and pacing control. For humanoid robots, the problem is much more complex. A robot must walk continuously for more than two hours while maintaining stable posture, accurate localization, and controllable energy consumption under constantly changing terrain, frequent turns, limited passage space, and natural environmental factors that may degrade perception.

This edition introduces an ecological park section for the first time, increasing the number of terrain types to more than 10. These can generally be grouped into five categories:

• Flat and undulating pavement: This terrain offers the most stable gait, but over long distances, joint heating, reduced motor efficiency, and battery endurance degradation gradually accumulate.
• Slopes: When climbing, the hip and knee joints require greater output torque, and energy consumption increases significantly. When descending, the robot must control descent speed and reduce foot impact.
• Turns: There are 12 left turns, 10 right turns, and some bends close to 90°. The robot must change heading while preventing its center-of-mass projection from leaving the support region and causing instability.
• Narrow sections: The effective walking width is limited. A reduced step width directly weakens lateral stability, so footholds and gait parameters must be replanned.
• Ecological sections: The ground may consist of grass, gravel, rubber track, or other materials, while non-structured factors such as sudden lighting changes and vegetation occlusion may also be present.

2. Terrain and Technical Challenges

Terrain type	Main engineering challenge	Technical response direction
Flat and undulating pavement	Long-distance gait stability, joint thermal management, endurance degradation	Periodic gait optimization, online gait parameter adaptation
Slopes	High torque demand uphill, high impact load downhill	Foot force control, leg stiffness adjustment, forward or backward center-of-mass shift
Turns	Instability during heading changes; difficult gait switching on sharp bends	Turning gait (adjusting step length, step width, and yaw angular velocity), foothold sequence replanning
Narrow sections	Limited step width reduces lateral stability	Lateral walking strategy, precise foothold planning, local obstacle avoidance
Ecological sections	Uncertain ground parameters, perception degradation, lighting changes	Terrain semantic segmentation, multi-source fusion localization, robust perception algorithms

3. Long-Distance Walking: Balancing Gait Stability and Energy Efficiency

1. Basic Principles of Dynamic Balance

The essence of humanoid robot walking is to keep the center of mass in a controllable state. At any moment, the robot is supported by one leg or two legs. The contact area formed between the feet and the ground is called the support polygon. As long as the projection of the center of mass falls inside the support polygon, the robot is stable in a quasi-static sense. When the robot alternates between legs, this projection area continuously contracts and expands, so the concept of dynamic stability is needed.

• Zero Moment Point (ZMP): This is a point on the ground. When the moment generated at this point by the resultant of inertial forces and gravity has zero horizontal component, the robot will not tip over around that point. A basic goal of walking planning is to keep the ZMP inside the support polygon and as close to its center as possible.
• Capture Point: This is a foothold derived from the inverted pendulum model. If the robot places its next step at this point, it can return to a stable state.

A simplified expression is:

capture_point_position = com_position + com_velocity * sqrt(com_height / gravitational_acceleration)

In more intuitive terms, after the robot is pushed, this tells it where to place the next step so that it can “brake” using that single step.

2. Gait Parameters Must Be Adjusted Online Based on Terrain

A fixed-parameter gait cannot adapt to more than 10 terrain types. A more practical approach is to build a closed loop of “terrain perception → gait generation”:

1. Terrain perception: Use depth cameras, LiDAR, and foot force sensors to identify terrain type and slope.
2. Gait parameter generation: Adjust step length, step height, step width, support time, and joint stiffness according to terrain type and the robot’s current state.
3. Closed-loop correction: Use a whole-body dynamics controller or a reinforcement-learning-trained gait policy to correct joint commands in real time and suppress disturbances.

On uphill sections, the robot needs longer support time and greater hip and knee torque. On downhill sections, it must decelerate the swing leg before touchdown to reduce impact. For sharp bends close to 90°, the robot usually needs to switch from a straight-walking gait to an in-place or low-speed turning gait and recalculate footholds.

3. Practical Points for Reinforcement-Learning Gaits

In recent years, reinforcement learning has become one of the mainstream directions for motion control in biped and humanoid robots. A typical approach is to let the robot interact with the environment millions of times in simulation and learn control policies that walk robustly across different terrains. To transfer a policy trained in simulation to a robot on a real track, teams usually need to focus on the following points:

• Domain randomization: Randomly vary ground friction, robot mass, motor delay, and sensor noise during training so that the policy is less sensitive to differences in the real environment.
• Historical observations: Feed recent joint states and external commands into the policy together to mitigate noise and latency in real observations.
• Hardware-in-the-loop validation: First reproduce various terrain types on a real robot in a restricted area, then gradually extend to full-track conditions.
• Stability fallback: If the reinforcement-learning policy outputs abnormal commands, the system should be able to fall back to a model-based traditional controller or enter a safe-stop state.

4. State Estimation: Knowing Where the Robot Is and How It Is Postured

Reliable state estimation is a common prerequisite for both navigation and balance control. A common solution is to fuse data from an inertial measurement unit (IMU), joint encoders, foot force sensors, and visual or LiDAR odometry using an extended Kalman filter or factor-graph optimization.

The following code is illustrative pseudocode. Interface names do not represent any specific product.

# Simplified pseudocode for the state estimation module: fuses IMU, joint, and visual/LiDAR data to output pose and velocity
class StateEstimator:
    def __init__(self, imu_noise, joint_noise, visual_noise):
        self.imu_noise = imu_noise
        self.joint_noise = joint_noise
        self.visual_noise = visual_noise
        self.state = {
            "position": [0.0, 0.0, 0.0],          # Global position
            "orientation": [1.0, 0.0, 0.0, 0.0],  # Quaternion orientation
            "linear_velocity": [0.0, 0.0, 0.0],
        }
    def predict(self, imu_reading, dt):
        # Propagate the state using IMU acceleration and angular velocity
        pass
    def update(self, joint_angles, odom_source):
        # Use encoders and foot contact states for odometry; this can also be completed within predict
        # Use visual or LiDAR odometry to correct accumulated drift
        pass

In a practical system, the predict step is usually driven by high-frequency IMU data. Proprioceptive odometry computed from joint encoders is used to estimate gait phase and foot slip, while visual or LiDAR odometry provides lower-frequency global correction.

4. Autonomous Navigation: A Closed Loop of Localization, Mapping, and Path Planning

1. Localization: GNSS Is Unreliable, so Multi-Source Fusion Is Required

The robot will spend much of the race in tree shade, near buildings, or inside narrow passages. Satellite positioning signals are easily blocked or affected by multipath reflection, so the robot cannot rely on GNSS alone. A more robust approach includes:

• Using LiDAR or visual odometry as the primary dead-reckoning source;
• Using track features such as curbs, route signs, and light poles for map matching to suppress accumulated error;
• Using satellite positioning only as a low-weight auxiliary observation in areas with good signal quality.

2. Mapping and Planning: A Two-Layer Global and Local Structure

Engineering practice commonly adopts a hierarchical planning architecture:

• Global planner: Searches for the optimal route on a cost map with known track topology, commonly using Dijkstra, A*, or incremental improvement algorithms. Since the number of track turns is known, it can be used as a map prior to check whether localization results are reasonable.
• Local planner: Performs real-time obstacle avoidance on a local cost map, commonly using methods such as the dynamic window approach or time elastic bands. Local planning must respect dynamic constraints such as minimum turning radius, maximum speed, and maximum acceleration, and must output a kinematically feasible path.

# Simplified pseudocode for the navigation decision module: two-layer global and local planning
class NavigationStack:
    def __init__(self, track_map, config):
        self.track_map = track_map
        self.config = config
        self.state = "FOLLOW_ROUTE"   # Possible states: FOLLOW_ROUTE / LOCAL_AVOID / SAFE_STOP
    def step(self, localization, local_obs, robot_state):
        if robot_state.emergency_stop or self.must_stop(local_obs):
            self.state = "SAFE_STOP"
            return None
        if self.is_blocked(localization, local_obs):
            # If a local obstacle exceeds the current safety corridor, request replanning
            self.state = "LOCAL_AVOID"
            global_path = self.global_planner.replan(localization, local_obs)
        else:
            global_path = self.global_planner.follow(localization)
        trajectory = self.local_planner.compute(
            global_path, local_obs, self.config.max_speed, self.config.max_angular_speed
        )
        return trajectory

3. Special Challenges Introduced by Ecological Sections

• Perception degradation: Grass has limited texture, gravel lacks stable features, and LiDAR point clouds may become sparse, all of which can cause odometry drift.
• Sudden lighting changes: When moving from an open area into tree shade, the camera may experience brief overexposure or underexposure, requiring automatic exposure control and image enhancement.
• Dynamic obstacles: Other participating robots, staff members, or spectators may suddenly enter the planning corridor, so the local planner must have sufficient response speed and prediction capability.

5. Energy Management: Optimizing Time and Battery Under Battery-Swap Rules

1. Where Energy Consumption Comes From

Energy consumption during long-distance walking mainly comes from four sources:

• Actuation system: Joint motors perform mechanical work, which is closely related to robot mass, gait efficiency, slope, and ground material.
• Computing and sensing: The onboard computing unit, LiDAR, and cameras operate continuously.
• Cooling: After long operation, active cooling is required, and devices such as fans also consume electrical power.
• Auxiliary systems: Communication, lighting, and other subsystems.

The actuation system usually accounts for the largest share. Energy fluctuation caused by climbing and descending slopes is far greater than the difference introduced by the computing platform.

2. Mathematical Modeling of Battery-Swap Rules

The battery-swap rules can be summarized as follows:

• The robot may be replaced at most 2 times during the full race; the first replacement incurs a 15-minute penalty and the second incurs a 20-minute penalty.
• Battery swapping inside a station does not incur a penalty, but the time spent counts toward total race time.
• Battery swapping outside a station is allowed only in emergencies such as sudden battery failure, and penalties accumulate with each occurrence.

Let D be the distance a single battery can support, as determined by measured calibration, and let n be the total number of replacements required. Then:

n_min = max(0, ceil(21.0975 / D) - 1)

• If n_min = 0, no battery swap is needed for the full course, and total time is determined only by walking speed and stability.
• If n_min = 1, only the 15-minute penalty is triggered.
• If n_min > 1, the requirement exceeds the allowed maximum of 2 replacements, meaning the robot does not have the basic ability to finish on this track and must be optimized in terms of energy efficiency, weight reduction, or hardware.

It should be emphasized that the ceiling function only gives a theoretical lower bound. In actual competition, additional consumption from climbing, deceleration at sharp bends, temporary avoidance maneuvers, and similar events must also be considered, so real battery-swap needs are usually higher than the theoretical value. In addition, between two whole-robot replacements, processes such as whole-robot state recovery, sensor reinitialization, and localization re-convergence must also be included in the time budget.

The following code is an illustrative implementation.

import math
RACE_DISTANCE_KM = 21.0975
PENALTY_MIN = [15, 20]   # Penalty minutes for the first and second robot replacements
def plan_race_pace(total_energy_wh, capacity_wh, race_limit_min, setup_min=5.0):
    """
    Plan the walking time budget and replacement count based on total energy and battery capacity.
    All parameters must be calibrated through testing or simulation before the race.
    """
    if total_energy_wh > 2 * capacity_wh:
        return {"feasible": False, "reason": "Exceeds the two-replacement limit"}
    min_patches = max(0, math.ceil(total_energy_wh / capacity_wh) - 1)
    if min_patches == 0:
        return {
            "feasible": True,
            "patches": 0,
            "penalty_min": 0,
            "walking_budget_min": race_limit_min,
        }
    penalty = sum(PENALTY_MIN[:min_patches])
    return {
        "feasible": True,
        "patches": min_patches,
        "penalty_min": penalty,
        "walking_budget_min": race_limit_min - penalty - setup_min * min_patches,
    }

Example calculation: Assume a robot consumes 0.5 kWh/km on the track and a single battery has 2 kWh of usable capacity. These values are hypothetical and are used only to explain the calculation method. According to the theoretical lower bound, completing the full course would require at least ceil(10.55 / 2) = 6 batteries, meaning 5 replacements, far exceeding the allowed maximum. If the number of replacements is to be compressed to 1, a single battery must support about 10.55 km, implying roughly a 2.6x improvement in energy density. Achieving such a large improvement in a single step is usually unrealistic. A more practical path is to combine multiple measures:

• Reduce energy consumption per unit distance by optimizing gait and reducing payload;
• Improve battery energy density through advances in battery chemistry;
• Improve electrical energy utilization by increasing motor-drive efficiency and recovering energy during downhill or deceleration phases, depending on whether the drive system supports it.

Therefore, the essence of battery-swap strategy is to find the optimal energy-efficiency solution under the constraint of a time budget.

3. Time Budget Table

Assume the robot’s actual walking time accounts for 85% of the cutoff time, with the remaining 15% reserved as a safety margin. With a full-course cutoff of 3 hours 40 minutes, or 220 minutes, the following segment budget can be established:

Race segment	Cumulative distance (km)	Cumulative time budget (min)	Segment time budget (min)	Required average speed (km/h)
Quarter	5.27	47	47	About 6.7
Half	10.55	94	47	About 6.7
Three-quarter	15.82	140	46	About 6.9
Finish	21.0975	187	47	About 6.8

This calculation assumes a constant speed. In actual competition, battery-swap stops, slope and sharp-turn deceleration, fall recovery, and other events will consume part of the budget. A more practical approach is to allocate remaining time dynamically based on remaining distance and to set earlier internal warning lines at each checkpoint.

6. Falls, Collisions, and Faults: Graded Handling and Safety Design

1. What Graded Handling Means

The competition rules apply graded handling to falls, collisions, and faults: minor imbalance or stalling must be recovered by the robot autonomously, and human assistance is strictly prohibited. This means the robot must have a complete chain of “fault detection → state judgment → autonomous handling.”

Event level	Typical behavior	Handling requirement	Technical support
Level 1: Minor imbalance or stalling	Brief side tilt, a missed step, or a short pause	Recover autonomously and continue walking	Balance controller, capture-point planning, self-recovery gait
Level 2: Collision	Contact with another robot, an obstacle, or a guardrail	Detect collision location and force, assess structural damage, replan path if necessary	Joint torque observation, collision detection algorithms
Level 3: Fall	The whole robot falls to the ground	Stand up autonomously or stop safely and wait for officials to judge according to the rules	Fall detection, self-rescue stand-up strategy, impact protection
Level 4: Hardware fault	Joint failure, sensor failure, or abnormal battery behavior	Stop safely and report status	Fault detection and isolation, redundancy design, watchdog mechanism

The grading and handling methods above are an engineering interpretation of this article; final decisions should follow the official competition rules.

2. Implementation Ideas for Balance Recovery

A common recovery strategy is a step-by-step process centered on the capture point:

1. Detect imbalance: When the center-of-mass projection approaches the boundary of the support polygon, or when IMU tilt angle and angular rate exceed thresholds, the robot is judged to be in an imbalanced state.
2. Take a quick step: Compute the robot’s instantaneous capture point, select a foothold within the reachable range, and shorten the support time of that step.
3. Adjust the center of mass: Use upper-body actions such as torso posture and arm swing to adjust whole-body angular momentum and assist balance recovery.
4. Return to normal: After tilt angle and angular rate return to a safe range, smoothly switch back to the normal gait to avoid secondary instability caused by abrupt state changes.

# Simplified pseudocode for imbalance detection and recovery triggering
class BalanceSupervisor:
    def __init__(self, tilt_threshold_deg=10.0, angular_rate_threshold=60.0):
        self.tilt_threshold_deg = tilt_threshold_deg
        self.angular_rate_threshold = angular_rate_threshold
        self.mode = "NORMAL"   # NORMAL / RECOVERING / SAFE_STOP
    def evaluate(self, estimator, planner, gait_controller):
        tilt = estimator.tilt_angle_deg()
        tilt_rate = estimator.tilt_rate_deg_per_s()
        if self.mode == "NORMAL":
            if tilt > self.tilt_threshold_deg or tilt_rate > self.angular_rate_threshold:
                self.mode = "RECOVERING"
                # Use the instantaneous capture point as the target foothold and shorten the support time of this step
                target_step = planner.compute_capture_step(estimator)
                gait_controller.switch_to_recovery(target_step)
            return
        if self.mode == "RECOVERING":
            if tilt > 3 * self.tilt_threshold_deg:
                # Beyond autonomous recovery capability: protective stop; officials intervene according to race rules
                self.mode = "SAFE_STOP"
                gait_controller.emergency_stop()
            elif tilt < 2.0 and tilt_rate < 10.0:
                self.mode = "NORMAL"
                gait_controller.restore_normal_gait()

In real engineering, thresholds must be extensively calibrated according to hardware parameters. For example, if the center of mass height is about 0.8 m in the upright state, the critical tilt angle is approximately arctan(0.2 / 0.8) ≈ 14°. Therefore, engineering thresholds are usually set more conservatively to account for model error and external disturbances.

3. Safety Design Principles

• Protective design: Add cushioning structures at vulnerable joints, and prioritize protecting the head, computing unit, and battery during a fall.
• Redundant power supply: The computing platform, communication module, and critical sensors should have independent power supplies to prevent loss of control caused by a single power failure.
• Watchdog mechanism: If the control loop times out or becomes abnormal, the system should automatically enter a safe-stop state.
• Collision safety: The local planner should define a “safety corridor,” maintain a safe distance from pedestrians and other robots, and reduce speed when collision risk is detected.
• Status reporting: Within the communication range allowed by the competition, continuously report battery level, temperature, position, and fault codes so that the support team can analyze trends and anticipate risks in advance.

7. Cutoff System and Time-Budget Modeling

The full-course cutoff time is 3 hours 40 minutes, and multiple checkpoints have segment cutoff points. Failing to pass a checkpoint on time is recorded as DNF. This effectively creates a time constraint that is visible in real time and becomes progressively tighter.

1. Basic Conversion

The total cutoff time is 3 × 3600 + 40 × 60 = 13200 seconds. At a constant speed, the required average speed for the full course is:

v_min = 21097.5 m / 13200 s ≈ 1.60 m/s ≈ 5.75 km/h

If a track segment has a planned cutoff time T_c and a planned length L, the minimum speed for that segment is v_c = L / T_c. The later a segment cutoff is placed, the smaller the margin left for earlier segments, so speed requirements differ by segment. For example, if a 3 km ecological section has a 35-minute cutoff, the average speed for that section must be at least about 5.14 km/h, or about 1.43 m/s.

For comparison, standard half marathons governed by World Athletics usually have a cutoff time of 3 hours, subject to the event technical handbook. This competition extends the cutoff by 40 minutes, indicating that the organizers have a clear understanding of the current capabilities of humanoid robots. However, according to public reports, top teams in the previous edition already achieved finish times at the 2-hour 40-minute level. This suggests that the 3-hour 40-minute cutoff is more like a participation threshold than a competitive target. For teams aiming for rankings, the real challenge is to compress the time budget as much as possible without sacrificing stability and energy efficiency.

2. Dynamic Pacing Strategy

During the race, the robot should continuously adjust its target speed based on “remaining time” and “remaining distance”:

• Ahead of schedule: The robot may reduce speed appropriately to save battery and lower the risk of falling.
• Behind schedule: The robot may increase step frequency without endangering stability, but it must watch for increased energy consumption and higher fall probability.
• Approaching the cutoff line: The priority is to reach the next checkpoint; if necessary, reduce speed to prioritize stability.

The following code is an illustrative implementation.

class PaceController:
    def __init__(self, checkpoints):
        # checkpoints: [(cumulative distance in km, cutoff time in seconds), ...]; exact values follow official regulations
        self.checkpoints = checkpoints
    def target_speed(self, distance_km, elapsed_s, v_nominal, v_min):
        """Output a recommended speed based on remaining distance and remaining cutoff time."""
        for dist, deadline in self.checkpoints:
            if distance_km < dist:
                remaining_dist_km = dist - distance_km
                remaining_time_s = deadline - elapsed_s
                if remaining_time_s <= 0:
                    return 0.0   # Current cutoff time has passed; immediately evaluate whether to abandon this segment
                required = remaining_dist_km * 1000.0 / remaining_time_s  # m/s
                # Take the larger of nominal speed and required cutoff speed, then cap it by the configured limit
                return max(v_nominal, min(required, v_min))
        return v_nominal

8. Data Closed Loop and Engineering Validation System

On-track performance comes from pre-race data accumulation. It is recommended to build a closed loop of “simulation training → real-robot validation → data feedback → model iteration.”

1. Simulation and Training

• Scenario simulation: Reproduce the track’s terrain combinations, turn distribution, and lighting changes in a simulation environment to batch-test navigation and gait policies.
• Elastic computing: Training workloads have peaks and valleys and are suitable for cloud platforms with containers and elastic computing resources, allowing capacity to be scaled on demand instead of permanently provisioning hardware for peak load.
• Data management: Sensor data and simulation replay datasets can be stored centrally in object storage, making version retrieval and traceability easier.

2. Data Feedback and Monitoring

• During the race, wireless network bandwidth and stability are limited. A practical strategy is “local full storage + event-triggered upload,” uploading only abnormal segments and key metrics.
• On the platform side, message queues can be used to smooth traffic peaks. Logging services and monitoring alerts can then monitor metrics such as battery level, temperature, and localization error in real time, notifying the support team immediately when anomalies occur.

3. Key Evaluation Metrics

Metric	Meaning	Purpose
Average speed	Distance traveled per unit time	Evaluate whether the time budget is being met
Energy consumption per unit distance	Energy consumed per kilometer	Evaluate endurance and battery-swap strategy
Localization error	Deviation between estimated pose and ground truth	Evaluate localization reliability
Imbalance recovery rate	Proportion of imbalance events recovered autonomously	Evaluate balance-control robustness
Number of human interventions	Number of manual interventions during the race	Evaluate autonomy against rule requirements
Fault-stop duration	Time from fault detection to recovery or stop	Evaluate fault-handling efficiency

These metrics should be analyzed by race segment to determine whether problems occur in ecological sections, slopes, sharp bends, or other specific areas.

9. Common Pitfalls and Pre-Race Checklist

1. Common Pitfalls

• Over-pursuing peak speed: In long-distance races, the marginal benefit of stability and energy efficiency is often greater than that of peak speed. The total time lost from one fall may far exceed the gain from increasing speed across the whole course.
• Over-relying on a single sensor: GNSS, vision, or LiDAR may all degrade in ecological sections, so multi-source fusion is necessary redundancy.
• Evaluating outdoor performance with indoor data: Test data from flat indoor floors cannot reflect slip and impact on complex surfaces such as grass or gravel.
• Ignoring the battery-swap process: Even if battery capacity is sufficient, whole-robot state recovery and localization re-convergence after replacement should be included in the time budget.
• Ignoring communication limitations: Real-time remote control cannot be relied upon during the race, so the robot must have complete autonomous decision-making capability.

2. Pre-Race Checklist

1. Complete terrain classification for the track and build test scenarios for each category.
2. Calibrate the actual endurance distance of a single battery and clarify the number of battery swaps and their time cost.
3. Complete failure analysis and autonomous recovery validation to ensure minor imbalance can be recovered autonomously.
4. Build a segment cutoff budget table and set internal warning lines for each checkpoint.
5. Set up an in-race data feedback, monitoring, and alerting system.
6. Prepare contingency plans and rehearse scenarios such as failed fall self-recovery, sensor failure, and communication interruption.

10. Conclusion

From the perspective of the competition rules, the humanoid robot half marathon is no longer merely a demonstration event about whether a robot can complete the course. It is a systematic assessment of the robot’s overall capabilities. The track combines more than 10 terrain types and dozens of turns, the rules encourage autonomous navigation and strictly limit human intervention, falls and collisions are handled through graded procedures, and the 3-hour 40-minute cutoff tests four levels of capability: robot control, environmental perception and planning, safety management, and energy efficiency optimization.

For technical teams, the preparation process itself is a complete systems-engineering exercise: translate rules into metrics, decompose metrics into modules, and continuously iterate through simulation, real-robot validation, and data closed loops. As track difficulty increases, robots that can finish reliably under long-distance, complex-terrain, and limited-intervention conditions will also be better prepared for broader real-world deployment scenarios.