Visual SLAM follows a walking G1. What happens when it runs?

In-house Isaac Sim research, September 8, 2026. Pose output continued during running, but tracking from the start produced endpoint errors of several meters along a 30 m aisle. Starting a fresh estimator three seconds into the recording gave endpoint errors of 9.2–16.3 cm with stereo and 5.0–12.7 cm with IMU assistance over a shorter, approximately 23 m interval. Continuous output and accurate localization need separate checks.

White is evaluation ground truth, green is stereo, blue adds IMU, and orange is a new stereo estimator started at three seconds. Image points are a subset of feature observations actually output by the estimator. Trajectories are shown from above, errors are 3D distances, and plot X/Y scales differ.

We put virtual stereo rigs with matching specifications on existing walking and running configurations. This evaluates visual odometry, with and without IMU assistance. It does not test map saving, loop closure or navigation controlled by estimated pose.

More than speed differs

Walking uses Unitree’s matched 29-joint model and public policy at a 0.5 m/s command. Running uses Caltech’s Chasing Autonomy matched 21-joint model and public policy at 2.0 and 1.5 m/s commands. TeamZ did not train the running model further.

We matched warehouse, travel direction, finish line, image dimensions (848 × 480), 87-degree field of view, 5 cm stereo baseline, 25 Hz image rate and 200 Hz IMU rate. Robot model, controller, initial pose and camera height in motion differ. In the second 2 m/s trial, mean torso forward speed after three seconds was 2.0016 m/s. Both feet had contact-force magnitudes below 5 N for about 23.0% of that interval, recorded at 200 Hz. The running description therefore uses contact evidence as well as the command and policy name. This simulation threshold does not establish reproduction of physical G1 running.

The comparison does not isolate speed alone, which is why we also varied speed on the same running model. The shared virtual camera rig avoids robot occlusion but does not reproduce G1’s standard physical mounting. No extra sensor noise or motion blur was added.

Separate pose availability from pose accuracy

We save stereo images, IMU and evaluation ground-truth poses during motion. A separate cuVSLAM process receives only images and IMU; comparison with ground truth happens after estimation. Simulator pose is used for steering correction to keep runs along the aisle, not as estimator input.

Evaluation aligns frames using the first valid camera pose only, with no later whole-trajectory rotation or scale fitting. We count missing pose outputs as well as position RMSE and endpoint error.

Results along the 30 m aisle

The torso reached the 30 m finish line in all three walking trials and all three 2.0 m/s running trials. Actual camera path lengths were 30.92 m for walking and 30.61 m for running. The following results cover tracking from the start.

Both estimators returned poses for every frame in both motion conditions, but running endpoint errors remained substantial. Changing only the command to 1.5 m/s with the same running model and moving initial state caused all three trials to end at 1.085 seconds, when pelvis height fell below 0.45 m. They did not reach 30 m and are excluded from the accuracy table. This does not show that the model can never run at 1.5 m/s.

Start a fresh estimator after the initial transient

Running begins with the public model’s moving pose and initial velocity, not a start from rest. Pose and velocity change during the initial transient. We therefore started a separate, fresh estimator three seconds into each recording. It does not inherit estimates from the first three seconds, and its shorter interval prevents a like-for-like percentage-improvement claim.

The later running interval covers 22.91 m in 10.88 seconds. Walking starts stationary, so its later interval still covers 30.81 m. The 1.5 m/s condition had already ended and cannot be evaluated this way.

The results motivate checking initialization and starting conditions. They do not isolate speed or the presence of an IMU as the sole cause. Download evaluation data for all trials (CSV).

Test the recording implementation too

An initial short test revealed camera positions being recorded at their initial values. We corrected camera motion using the physical body pose and fixed mounting transform, then checked that positions and images changed and stereo/IMU timestamps aligned. Faulty trials were excluded.

An input-recording bug can produce misleadingly favorable estimator numbers. Separating input generation, estimation and evaluation into independently testable stages was part of our implementation work.

Limits and next steps

These are replay results from a specified static warehouse with idealized sensors. Physical robots, moving obstacles, low light, real exposure blur, closed-loop autonomous travel and real-time execution are untested. Three repeats per condition do not establish a general success rate.

At the September 8, 2026 review, our next step was to inspect KILVO’s public sensor recordings and specifications. KILVO combines camera, IMU, LiDAR and leg kinematics; its authors’ code was then listed as forthcoming.

Environment: Isaac Sim 5.1, Isaac Lab 2.3, cuVSLAM 17, NVIDIA L4. Running uses the public work of Caltech’s Zachary Olkin, William D. Compton, Ryan M. Bena and Aaron D. Ames.

NVIDIA cuVSLAM API · Unitree models and walking policies · Chasing Autonomy paper, March 26, 2026 · Running-policy code · KILVO repository

Implementation and evaluation scope (Japanese) · Previous article: running G1 with a public model