The trained policy performs reasonably well when tracking motion samples from the training distribution. However, it performs poorly in the next stage of our pipeline: PICO VR teleoperation for VLA fine-tuning. During teleoperation, the robot is unstable and frequently falls, even though offline motion tracking looks acceptable.
Context: Training setup: 288 hours of BONES-SEED dataset, ~142k retargeted motions, 7,000+ iterations, 1× RTX PRO 6000 Blackwell, env 8,192. Suspects the default SONIC reward configuration and domain randomization are tuned for Unitree G1 and don't transfer to a robot with different morphology/dynamics/actuators/joint limits.
Our reading: Offline motion tracking passing is not the same as teleop robustness. If you port SONIC to a new robot, budget time for reward/domain-randomization re-tuning — the G1-tuned defaults are a starting point, not a drop-in.
Where to start: See our /new-embodiments/ guide (KP/KD tuning, body-name compatibility, PKL data format) — the config files referenced there are exactly where #252's symptoms live.
Three actuator-related values in gear_sonic/envs/manager_env/robots/h2.py disagree with the H2 model files released alongside them. Every actuator group in h2.py is g1.py's value times exactly 3. Those disagree with h2.urdf and mjcf/h2.xml, which agree with each other on all 31 joints, and with Unitree's published specs.
Context: Concrete example from the issue: ankle_roll is 19.00 in h2.urdf/h2.xml but 150.0 in h2.py (~7.9x over); waist_yaw 120.00 vs 264.0 (2.2x over). The porting example shipped in daf3899 works end to end, but the actuator values look like placeholders scaled from G1.
Our reading: If you port to H2 (or any robot), trust the URDF/MJCF joint limits over the robot .py actuator values — and verify effort limits match the real motor specs (Unitree publishes 360 N·m leg / 120 N·m arm for H2).
Where to start: This is exactly the class of bug a config-vs-model consistency check catches. We built scripts/check_actuator_params.py in the official repo (see PR #XXX) to flag these automatically.
During SONIC teleoperation, the G1 occasionally announces “robot data late”. The robot motion can also become progressively more delayed over time. When triggering episode recording, the response between pressing the controller button and receiving confirmation can sometimes reach approximately 6 seconds.
Context: Setup: G1 wired → router → laptop (RTX 5090), Pico 4 Ultra wireless. Tested with camera service and data exporter stopped — the warning and latency still occur.
Our reading: “robot data late” indicates the control loop isn't receiving robot state in time — a network/system issue, not a model issue. Wired robot→PC is the reliable baseline; wireless VR adds a second hop that can starve the control loop.
Where to start: Our /teleoperation/ page covers the ZMQ ports and deploy topology; the data-exporter and camera-server offload recommendations in /data-collection/ directly apply to freeing bandwidth for the control loop.