Move() ignored for several seconds (up to 10s+) after StandUp() with no readiness signal in SportModeState

[chaerinn97-ctrl]

Environment

• Robot: Go2
• unitree_sdk2py version: 1.0.1 (editable install)
• Network: eth0 (wired)
• Python: 3.8

Summary

After calling SportClient.StandUp(), Move() calls return ret=0 (success) immediately,
but the robot does not physically rotate/move for a variable, unbounded amount of time
(observed anywhere from ~4s to 10s+ across different runs). None of the SportModeState
fields (mode, progress, error_code, gait_type) change during this "dead" window,
so there is no way to detect readiness from telemetry before sending Move().

This reproduces with the official high_level example pattern (StandUp then Move in a loop).

Observed

• error_code transitions from 1001 (pre-StandUp) to 1002 immediately after StandUp(),
  and then stays at 1002 for the entire test (10s+), even while the robot is not moving.
• mode, progress, gait_type never change during this window.
• yaw stays flat (no rotation) despite continuous Move(0,0,1.5) calls with ret=0.
• In a separate run, the same pattern eventually started working around t≈4.3s; in another run
  it still hadn't started by t≈10s. The dead-window length appears non-deterministic.

Expected

Either Move() works immediately after StandUp() (per the official
example/go2/high_level/go2_sport_client.py, which does not wait at all), or there should be
a documented/observable readiness signal (e.g., a SportModeState field, or a client method)
we can poll instead of guessing a timeout.

Question

1. What does error_code on SportModeState actually represent, and what values are "normal"?
2. Is there a proper way to know when the robot is ready to accept Move() after StandUp(),
   other than an arbitrary sleep/retry loop?