VideoMimic: Humanoid Robot Control via Visual Imitation

repository·main·Indexed 21 days ago

https://github.com/hongsukchoi/videomimic

A research framework for transferring human motion from single-camera videos to humanoid robots (such as the G1). It features a complete pipeline consisting of Real-to-Sim (3D environment and pose reconstruction), Simulation training (motion capture pretraining, scene-conditioned tracking, distillation, and RL finetuning), and Sim-to-Real deployment using torchscript-exported checkpoints and ROS 1 Noetic.

Tokens
33.9K
Snippets
120
Records
152
Agent score
74%

What's inside VideoMimic

  1. Overview of VideoMimic

    main
    VideoMimic is a framework for visual imitation that enables contextual humanoid control. It provides a complete pipeline for transferring human motion from single-camera videos to humanoid robots through three main stages: Real-to-Sim, Simulation training, and Sim-to-Real deployment.
  2. Overview of VideoMimic Real-to-Sim

    main

    VideoMimic Real-to-Sim is a vision pipeline designed to reconstruct 3D environments and human motion from single-camera (monocular) RGB videos. The system extracts human poses in world coordinates and retargets that motion to humanoid robots (such as the G1) for imitation learning.

    Key Capabilities:

    • 3D Reconstruction: Generates dense 3D scene geometry (pointclouds and meshes) from video.
    • Human Motion: Extracts accurate 3D human poses aligned with a scaled environment.
    • Multi-Human Support: Tracks and reconstructs multiple people simultaneously using detection and re-identification.
    • Robot Retargeting: Performs collision and contact-aware human-to-humanoid motion retargeting.
    • Simulation-Ready: Produces datasets containing environment meshes and robot configurations ready for simulation.
  3. Unitree G1 Robot Descriptions (URDF & MJCF)

    main

    This package provides universal humanoid robot descriptions (URDF and MJCF formats) for the Unitree G1 robot. It includes various configurations varying by degrees of freedom (DOF), waist locking, and hand inclusion.

    Key configuration parameters include:

    • mode_machine: An integer identifier for the specific configuration.
    • Hip roll reduction ratio: The gear reduction ratio for the hip roll.
    • dof#leg, dof#waist, dof#arm, dof#hand: The number of degrees of freedom for each body part.

    Available models include versions like g1_23dof, g1_29dof, g1_29dof_with_hand, and g1_dual_arm.

    | MJCF/URDF file name           | `mode_machine` | Hip roll reduction ratio | Update status | dof#leg | dof#waist | dof#arm | dof#hand |
    | ----------------------------- | :------------: | :----------------------: | ------------- | :-----: | :-------: | :------: | :------: |
    | `g1_23dof`                    |       1        |           14.5           | Beta          |   6*2   |     1     |   5*2   |    0     |
    | `g1_29dof`                    |       2        |           14.5           | Beta          |   6*2   |     3     |   7*2   |    0     |
    | `g1_29dof_with_hand`          |       2        |           14.5           | Beta          |   6*2   |     3     |   7*2   |   7*2    |
    | `g1_29dof_lock_waist`         |       3        |           14.5           | Beta          |   6*2   |     1     |   7*2   |    0     |
    | `g1_23dof_rev_1_0`            |       4        |           22.5           | Up-to-date    |   6*2   |     1     |   5*2   |    0     |
    | `g1_29dof_rev_1_0`             |       5        |           22.5           | Up-to-date    |   6*2   |     3     |   7*2   |    0     |
    | `g1_29dof_with_hand_rev_1_0`  |       5        |           22.5           | Up-to-date    |   6*2   |     3     |   7*2   |   7*2    |
    | `g1_29dof_lock_waist_rev_1_0` |       6        |           22.5           | Up-to-date    |   6*2   |     1     |   7*2   |    0     |
    | `g1_dual_arm`                 |       9        |           null           | Up-to-date    |    0    |     0     |   7*2   |    0     |
  4. What is Sequential Multi-Video Processing and when to use it

    main

    Sequential processing in the VideoMimic Real-to-Sim pipeline processes multiple videos one after another rather than in parallel. This approach is specifically designed to:

    • Amortize model loading time: Models and checkpoints are loaded once and reused across all videos.
    • Share JAX compilation: JAX optimization code is compiled once (during the first video), making subsequent videos significantly faster.
    • Maintain stable memory usage: Prevents GPU memory overflow by processing one video at a time.
    • Build datasets efficiently: It is the recommended method for creating large training datasets for policy learning, as it reduces the per-video overhead from minutes to seconds after the first video.

    Note: This is NOT batch/parallel processing. It is a sequential loop designed for efficiency and stability.

  5. Understand the VideoMimic reinforcement learning workflow

    main

    The standard workflow for achieving motion control using reinforcement learning in this project follows these four stages:

    1. Train: Use the Gym simulation environment to train a policy that maximizes designed rewards. Note: Real-time visualization is not recommended during this stage as it reduces training efficiency.
    2. Play: Use the Play command to verify the trained policy and ensure its behavior meets expectations.
    3. Sim2Sim: Deploy the policy trained in Gym to different simulators to verify that the policy is robust and not overfitted to Gym-specific characteristics.
    4. Sim2Real: Deploy the policy onto a physical robot to achieve actual motion control.
  6. Enable Multi-Human Processing

    main

    By default, the pipeline only processes the largest person (by average bounding box area). To process multiple humans, use the --multihuman flag along with --top-k N to specify the number of largest humans to process.

    Warning: Memory usage scales with the number of humans processed.

    # Example for Stage 0
    python stage0_preprocessing/vitpose_2d_poses.py ... --multihuman --top-k 3
    
    # Example for Stage 2
    python stage2_optimization/megahunter_optimization.py ... --multihuman --top-k 3
  7. How data loading works in VideoMimic

    main

    The system supports two types of motion data loaded via replay_data.py:

    1. VideoMimic data with terrains: Located in ../data/videomimic_captures. These are paired with random terrains.
    2. Other motion capture data (without terrains): Located in ../data/unitree_lafan.

    Key Implementation Details:

    • Terrain Concatenation: To allow different terrains for different environments efficiently, the system concatenates terrain meshes into one and uses a global env_offsets variable (managed by DeepMimicTerrain) to align clips with their respective terrains.
    • Handling Robot Overlap: To prevent Isaac Gym performance degradation caused by overlapping robots, the n_rows parameter is used to create multiple rows of terrains, effectively expanding the terrain count and reducing robot density in a single area.
    • Motion Types:
      • AMASS: Enabled via use_amass. Uses amass_replay_data_path.
      • Human Video: Enabled via use_human_videos. Requires folders containing both .pkl and mesh information. Specified via human_video_folders.
  8. Understand the VideoMimic dual-environment architecture

    main

    The VideoMimic Real-to-Sim pipeline requires two separate Conda environments due to conflicting dependency requirements (specifically regarding CUDA versions and xformers).

    • vm1rs (Main Environment): Uses Python 3.12 and CUDA 12.4+. It is used for human preprocessing, optimization, and motion retargeting.
    • vm1reocn (Reconstruction Environment): Uses Python 3.10 and CUDA 11.8. It is used for MegaSam reconstruction, NKSR meshification, and GeoCalib operations.

    Mental Model: Always activate the specific environment required for your current task. Use vm1rs for most operations and vm1reocn only when performing reconstruction or postprocessing.

  9. Understand how multi-human tracking and ranking works

    main

    The pipeline ensures consistent person tracking through the following mechanism:

    1. Detection: SAM2 detects all humans and calculates their bounding box area per frame.
    2. Ranking: An average bounding box area is computed for each person across all frames. Humans are ranked by this average area (largest first).
    3. Metadata: This ranking is stored in meta_data.json (under sorted_by_avg_area) and per-frame JSON files (under area_ranking).
    4. Selection: Subsequent stages (ViTPose, VIMO, MegaHunter) use this ranking to select the top-k humans, ensuring the same person ID is tracked throughout the pipeline.

    SAM2 meta_data.json structure:

    {
      "all_instance_ids": [1, 2, 3],
      "sorted_by_avg_area": [2, 1, 3],
      "avg_areas": {
        "1": 15234.5,
        "2": 18956.2,
        "3": 12456.8
      },
      "frame_counts": {
        "1": 95,
        "2": 100,
        "3": 87
      }
    }
  10. Understand the VideoMimic directory structure

    main

    The project is organized into several functional stages and data directories:

    • demo_data/: Contains input data (images, masks, 2D/3D poses, contacts) and pipeline outputs (output_smpl_and_points/, output_calib_mesh/).
    • assets/: Stores model checkpoints, configs, body models, and robot assets.
    • stage0_preprocessing/: Scripts for segmentation, 2D pose, 3D mesh, and contact detection.
    • stage1_reconstruction/: Scripts for MegaSam and Monst3r reconstruction.
    • stage2_optimization/: Scripts for SMPL shape optimization and MegaHunter optimization.
    • stage3_postprocessing/: Scripts for mesh generation and gravity calibration.
    • stage4_retargeting/: Scripts for robot motion retargeting.
    • sequential_processing/: Sequential versions of the processing stages.
    • visualization/: Tools for visualizing results at various stages.
    • utilities/: Helper scripts for frame extraction, filtering, and rendering.
    • process_video.sh: The main orchestration script for the entire pipeline.
  11. Run SLOPER4D Evaluation

    main

    Navigate to the sloper4d_eval_script/ directory to run the evaluation. You must provide the path to the predicted SMPL data, the output directory, and the ground truth .pkl file path.

    Arguments:

    • --pred_smpl_path: Path to the .npy file containing predicted SMPL data.
    • --output_dir: Directory where evaluation results will be saved.
    • --gt_pkl_path: Path to the ground truth .pkl labels file.
    cd sloper4d_eval_script/
    
    # Example evaluation for sequence 008
    python run_eval_sloper4d.py --pred_smpl_path ../results/sloper4d_seq008/hps_combined_track_0.npy --output_dir ../results/sloper4d_seq008 --gt_pkl_path ../demo_data/sloper4d/seq008_running_001/seq008_running_001_labels.pkl