Skip to content
TEAM Z日本語
← All articles

· In-house simulation research

How well does Visual SLAM track a fast-moving G1?

Original experiment footage is shared with the Japanese edition. Some on-screen labels are in Japanese; methods, results and video descriptions are provided in English below.

In-house research in Isaac Sim, not a completed physical-robot or autonomous-navigation demonstration. Feedback on the previous comparison was that G1 looked more like it was walking quickly than running. We raised the forward command from 2 to 3.3 m/s, filmed from the side and recorded camera images and IMU data to evaluate tracking.

Both separately started runs continued for 30 seconds without falling. Average forward speed after the first three seconds was 3.23 m/s. Pose estimates never stopped, yet endpoint error reached 11.25 m.

Trial 1: G1, onboard camera and estimated trajectories. 30 seconds at normal simulation speed.
Trial 2: the second 30-second trial, also shown at normal simulation speed.

What changed

We used the public Chasing Autonomy controller, not a newly trained model. We changed the forward command and recorded a side view at 50 fps, including a 2 m/s comparison from the same angle.

Contact forces and poses were saved at 200 Hz. Both feet had contact forces below 0.5 N for 23.04% of the 12-second 2 m/s test and 33.25% of the 30-second 3.3 m/s test. Median airborne intervals were 70 ms and 100 ms respectively. Thresholds of 1 N and 5 N gave the same results in these tests.

We show normal-speed footage alongside these metrics rather than treating a number as a complete assessment of gait. Runs begin with a moving pose and velocity; starting from rest and stopping were not tested.

A pose output is not necessarily an accurate pose

The torso-fixed virtual stereo rig uses 848 × 480 images at 25 Hz and a 5 cm baseline; the IMU runs at 200 Hz. We first recorded ideal sensors, then processed each recording with stereo alone and stereo plus IMU. The camera trajectory was about 98.73 m over 30 seconds. Both methods returned poses for all 750 frames in each trial.

Full-interval errors against simulator ground truth
TrialInputPosition RMSEEndpoint error
1Stereo0.93 m2.30 m
1Stereo + IMU2.00 m3.48 m
2Stereo4.44 m7.51 m
2Stereo + IMU7.44 m11.25 m

RMSE summarizes squared position error over the evaluation interval. Coordinate frames are aligned using only the first valid estimated pose, without whole-trajectory fitting or scale correction.

In the videos, white is ground truth, green is stereo and blue includes the IMU. Orange shows a fresh estimator started three seconds into the recording, covering a shorter interval of about 89.08 m. Different evaluation distances prevent a direct percentage-improvement comparison. We include the second trial rather than selecting only the better result.

Adding an IMU did not solve this case

IMU-assisted estimation had larger full-interval errors in both trials. This does not establish that an IMU is unnecessary: timing, calibration and initialization need separate investigation.

Robot position, velocity and contact-force logs matched between runs, but estimation results differed. We have not separated rendering differences from estimator variability. Reprocessing identical images is the next test. The warehouse uses repeated assets, so appearance around their seams also needs checking.

Scope of this test

This is offline VO/VIO evaluation of recorded images and IMU data. The estimated pose did not steer G1. Corrections that kept it along the aisle used simulator position and orientation. Map relocalization, loop closure, real camera noise, starting from rest and stopping are outside this evaluation.

We assess sustained running separately from localization accuracy suitable for autonomy. TeamZ works on implementation, measurement and failure analysis as well as public-model integration. Discuss robotics implementation and testing.

Sources

Chasing Autonomy paper · Authors’ code · NVIDIA cuVSLAM

Read the Japanese edition →

LET’S BUILD TOGETHER

What are you working on?

Tell us about the software you need to implement or test. We can discuss the work, the development setup and how we could contribute.

Discuss your development needs