Robot competition with zero teleoperation begins: Want to build one? Start by understanding this final

Conclusion first: Achieving fully autonomous operation without teleoperation is harder than winning the championship.

Today, the national finals of the humanoid robot special event at the 28th China Robot and Artificial Intelligence Competition kicked off at Beijing Shougang Park, with over 200 teams competing for the title. I checked the rules; the core highlight is "fully autonomous without teleoperation"—robots see, walk, and judge on their own, with no humans controlling them via joysticks from the backend. In the startup circle, this is an extreme test of "removing manual intervention."

As a hardware entrepreneur who returned from Silicon Valley, last year I was still messing with SaaS. This year, I spent two weeks intensively testing Moore Threads' inference cards, Megvii's vision solutions, and just started using Anduril less than a week ago. But what excites me most is the leap of humanoid robots from "remote-controlled toys" to "autonomous agents."

Preparation: Understanding What "No Teleoperation" Really Means

If this is your first time hearing the term "fully autonomous without teleoperation," don't panic. Plain explanation: The robot walks itself, sees the road itself, decides where to run itself; there are no humans in the backend using remotes to adjust direction or speed.

This is fundamentally different from remote-controlled toy cars. With RC cars, if you move your left hand, it turns left; right hand, right turn. If something goes wrong, blame your clumsy hands. If a non-teleoperated robot fails, you can only blame itself—or the team writing the code.

Preparing a robot for competition requires solving three things:

1. Hardware Body: Motors, batteries, joints, structural parts. This thing burns money. A decent bipedal robot chassis costs roughly 200,000 to 500,000 RMB. I used CATL batteries for 3 weeks; energy density is sufficient, but fitting them into a humanoid robot still requires calculating volume.

2. Perception System: Cameras, LiDAR, Inertial Measurement Units (IMU). The robot needs to know where it is and if there are obstacles ahead. I tried Megvii's vision solution for two weeks; honestly, it performed well in indoor stable lighting, but drifted easily in outdoor strong light.

3. Decision Algorithms: This is the hardest part. After seeing a pile of data, the robot must calculate "Should I step left or right first?" "There's a hole ahead, should I go around?"

Most common mistake for beginners: Thinking you can just modify an off-the-shelf robot. Actually, 90% of participating teams build their own underlying control systems. Using existing frameworks (like ROS 2) and tweaking parameters before entering is basically sending yourself to slaughter.

Steps to Start: From Watching the Match to Building a Test Environment

I suggest starting by "watching the live stream," not directly buying a robot. Figure out how others run first, then decide if you want to enter the arena.

Step 1: Find match recordings or live streams. Today's finals are at Beijing Shougang Park, a 2,800 sqm venue accommodating nearly 350 robots. If you aren't on-site, search for "CRAIC 2026 Finals Live Stream" or "Humanoid Robot Games" to find material. Focus on three types of competitions:

• Sprint (100 meters): Tests gait algorithms and stability. Last month at the World Humanoid Robot Games, Tiangong Ultra ran 100 meters in 21.50 seconds, fully autonomous without human intervention, relying on visual perception and environmental sensing for autonomous navigation.
• Obstacle Course: Tests obstacle avoidance and terrain adaptability. Robots need to judge obstacle position and height themselves, deciding whether to step over or go around.
• Combat (e.g., Football): Tests multi-robot coordination and real-time decision-making. Tsinghua Fire God Team used domestic Accelerate Evolution robots and won the World Cup.

Step 2: Build a simple simulation environment. You don't need a real machine. Install a Gazebo simulator and download an open-source humanoid robot model (like the open-source version of Unitree H1). Set up a straight track, add some static obstacles, and train the robot to walk from Point A to Point B.

• Install ROS 2 Humble (Robot Operating System, easiest to install on Ubuntu 22.04)
• Download open-source gait controllers (MIT's Cheetah or domestic open-source team solutions)
• Write a simple "straight + stop" logic, let the robot run 10 meters

Step 3: Real machine testing. If you have the budget, rent a Unitree H1 (rental approx. 3,000 RMB/day), take it to an open area for testing. Common pitfalls for beginners:

• Incorrect sensor calibration. Camera and LiDAR coordinate systems aren't aligned; the road the robot sees differs from actual position by 20cm, leading to wall collisions. Solution: Use calibration boards (checkerboards) for extrinsic parameter calibration; recalibrate every time you change venues.
• Overly aggressive gait parameters. To run fast, you increase stride length, resulting in the robot stumbling and falling, destroying joint motors. Conservative strategy is safer: Start at 0.5 m/s, then gradually speed up.
• Ignoring ground friction. Concrete, grass, and rubber tracks have different friction coefficients. If the robot's feet slip, the algorithm thinks it's running, but it's actually stepping in place. Stick anti-slip silicone pads on the feet, or add IMU for slip compensation.

The Real Hard Part: Not Running Fast, But Running Stable

Last week I wrote a post about AI Agent jailbreaking, with the core point being "engineering problems are more fatal than model problems." Applied to robots, this statement holds doubly true.

Robots in non-teleoperation competitions are essentially AI Agents operating in the physical world. They must solve three problems; failure in any one causes total collapse:

• Visual Perception: Convert camera images into digital info like "Obstacle 2 meters ahead, height 0.3m, width 0.5m"
• Autonomous Decision-Making: Based on perception, choose "stop and detour" or "lift leg and step over"
• Physical Control: Turn decisions into precise motor commands, determining how high to lift mechanical legs and how much force to apply

If latency in any of these three links exceeds 50 milliseconds, the robot falls. In the match videos I observed, 70% of errors occurred in scenarios where "visual delay caused reaction lag."

If you're starting a business in this direction, team execution is key. Don't try to write the whole system yourself. Use open-source solutions for secondary optimization, focusing energy on "extreme stability in a single scenario." For example, first only do "indoor flat-ground straight walking," stabilize that, then move to slopes and turns.

Conclusion: Advice to Save You Half a Year of Detours

The fastest path from watching matches to building an environment is "Copy then Surpass." Find an open-source fully autonomous navigation solution (like the Tiangong solution from Beijing Humanoid Robot Innovation Center), run it through in the simulator, fine-tune parameters on the real machine, and finally walk the course in the real arena.

After mastering this, next try: Port the same autonomous navigation logic to a wheeled robot (like modifying Xiaomi's CyberDog to wheels) and demo "non-teleoperation delivery." This is an order of magnitude simpler than doing bipedal directly, but the commercial monetization path is clearer—material handling in factories is a huge rigid demand.

One-sentence summary: Non-teleoperation robot competitions aren't tech shows; they are stress tests for the entire industry moving from "remote control" to "autonomy." Understand this, and you'll understand where the true ceiling of this wave of humanoid robot startups lies.