11 KiB
| id | title | status | source_sections | related_topics | key_equations | key_terms | images | examples | open_questions |
|---|---|---|---|---|---|---|---|---|---|
| safety-limits | Safety & Operational Limits | established | reference/sources/official-user-manual.md, reference/sources/paper-safe-control-cluttered.md, reference/sources/paper-getting-up-policies.md | [hardware-specs joint-configuration equations-and-bounds deployment-operations push-recovery-balance whole-body-control] | [] | [e_stop safety_limits] | [] | [] | [Official safety certifications (CE, FCC, etc.) Exact temperature and humidity operating ranges IP rating Software e-stop API call sequence Low-battery cutoff voltage and automatic shutdown behavior] |
Safety & Operational Limits
Safety systems, operational limits, emergency procedures, and compliance for the G1.
1. Emergency Stop
The G1 has emergency stop capabilities: [T1 — User manual, developer experience]
- Hardware e-stop: Physical button on the robot (location per user manual)
- Software e-stop: Available via SDK API (exact call sequence to be documented)
- Wireless remote: The included wireless remote has emergency stop functionality
- Recovery: After e-stop, the robot must be explicitly re-enabled before resuming operation
Kinect teleoperation safety: The kinect_teleoperate system includes a "wake-up action" detection (forearm forward, arm at 90°, hold for several seconds) to prevent accidental activation. [T0 — kinect_teleoperate README]
2. Joint Limits & Protections
Software Joint Limits
The locomotion computer enforces joint position limits: [T0]
| Joint Region | Known Limits |
|---|---|
| Hip yaw | ±158° (±2.758 rad) |
| Hip roll | -30° to +170° (-0.524 to +2.967 rad) |
| Hip pitch | ±154° (±2.688 rad) |
| Knee | 0° to 165° (0 to 2.880 rad) |
| Waist yaw | ±155° (±2.705 rad) |
| Ankle | Not yet documented |
See equations-and-bounds for full numerical joint limits table.
Collision Avoidance
Research-level collision avoidance has been demonstrated: [T1]
- Projected Safe Set Algorithm (arXiv:2502.02858): Enforces limb-level geometric constraints for self-collision and external collision prevention in cluttered environments. Validated on G1. [T1]
- SHIELD (arXiv:2505.11494): Safety framework using stochastic dynamics residual models and Control Barrier Functions for layered safety. [T1]
Whether the stock firmware includes collision avoidance is not confirmed. [T3]
3. Torque & Current Limits
| Property | Standard | EDU | Notes | Tier |
|---|---|---|---|---|
| Max knee torque | 90 Nm | 120 Nm | Highest-torque joint | T0 |
| Other joint torques | — | — | Not published per-joint | T3 |
| Thermal protection | Yes | Yes | Per-motor temperature sensors | T0 |
| Torque limiting | Yes | Yes | SDK supports torque saturation | T0 |
The SDK MotorCmd_ structure includes a mode field (0=Disable, 1=Enable) that can be used to cut motor power. The tau field allows explicit torque limiting. [T0]
4. Fall Detection & Recovery
Stock Behavior
The stock firmware detects falls and can attempt to protect the robot during falling. Specific behavior not fully documented. [T3]
Research-Validated Recovery
Multiple RL-based fall recovery approaches have been validated on real G1 hardware: [T1]
| Approach | Paper | Key Feature |
|---|---|---|
| Two-stage RL | arXiv:2502.12152 | Supine and prone recovery without hand-crafted controllers |
| HoST | arXiv:2502.08378 | Multi-critic RL, curriculum training, diverse postures |
| Unified fall-safety | arXiv:2511.07407 | Combined prevention + mitigation + recovery, zero-shot sim-to-real |
5. Operational Environment Limits
| Parameter | Value | Source | Tier |
|---|---|---|---|
| Verified surfaces | Tile, concrete, carpet | Testing reports | T1 |
| Operating temperature | Not documented | — | — |
| Operating humidity | Not documented | — | — |
| IP rating | Not documented | — | — |
| Max wind speed | Not documented | — | — |
Recommendation: Until environmental limits are confirmed, operate indoors in controlled environments (temperature 15-35°C, dry conditions). [T3 — Inferred best practice]
6. Security Vulnerabilities & Telemetry
Known Vulnerabilities
Multiple security researchers have disclosed critical vulnerabilities in the G1: [T1 — arXiv:2509.14096, arXiv:2509.14139]
| Vulnerability | Severity | Status |
|---|---|---|
| Hardcoded BLE AES encryption keys (identical across all units) | Critical | Partially patched (Oct 2025) |
| BLE command injection (UniPwn) — grants root on locomotion computer | Critical | Patch status unclear |
| WiFi password field injection (FreeBOT) | Critical | Patched in firmware 1.1.8+ |
| Wormable BLE exploit (one robot can infect others) | Critical | Reported |
| Static FMX encryption keys in configuration | High | Not patched |
UniPwn exploit (Bin4ry/UniPwn on GitHub): Exploits hardcoded AES keys and unsanitized BLE input to achieve root-level command execution on the RK3588 locomotion computer. Affects G1, H1, Go2, R1, B2.
Telemetry — Data Sent to External Servers
The G1 sends telemetry data to external servers approximately every 5 minutes: [T1 — Security research]
| Data Type | Sent? | Destination |
|---|---|---|
| Audio (microphone) | Yes | External servers (China) |
| Video (camera) | Yes | External servers |
| LiDAR point clouds | Yes | External servers |
| GPS location | Yes | External servers |
| Robot state | Yes | External servers |
Known server IPs: 43.175.228.18, 43.175.229.18, 8.222.78.102 (port 17883 MQTT)
Mitigation: If this is a concern, you can block outbound traffic from the robot at your network firewall, or disconnect the robot from internet-accessible networks entirely (the 192.168.123.0/24 subnet doesn't need internet for SDK operation).
7. Safety Certifications
No safety certifications have been confirmed in available documentation. This is an open question. [T4]
8. Safe Development Practices
Best practices for testing new behaviors on the G1: [T2 — Community experience + RL deployment papers]
Pre-Deployment Checklist
- Simulate first — Validate all new behaviors in unitree_mujoco or Isaac Lab
- Cross-validate — Test in a second simulator (Sim2Sim) for robustness
- Low-gain start — Deploy with reduced PD gains initially
- Tethered testing — Use a safety harness/gantry for first real-world tests
- Clear area — Ensure at least 2m clearance around the robot
- Spotter present — Always have a human spotter ready with the remote/e-stop
- Battery check — Verify sufficient charge before testing (>30%)
- Record everything — Log all sensor data for post-hoc analysis
Common Pitfalls (from Community Reports)
- Motion state topic issues: Some community developers report unexpected behavior with motion state topics (Robonomics experience report) [T2]
- CycloneDDS version mismatch: Using a DDS version other than 0.10.2 causes silent communication failures [T1]
- WiFi latency: Wireless control introduces variable latency — use wired for safety-critical tests [T2]
9. Control Barrier Functions for Balance Safety
CBFs provide formal safety guarantees for balance — a mathematical guarantee that the robot won't fall (subject to model accuracy): [T1 — Control theory, validated on G1]
Concept
Define a safety function h(x) such that h(x) > 0 means "safe" (e.g., CoM projection within support polygon). A CBF controller ensures this constraint is never violated:
Safety filter QP:
minimize || u - u_desired ||^2 (stay close to desired action)
subject to ḣ(x,u) + α·h(x) ≥ 0 (CBF: safety maintained over time)
u_min ≤ u ≤ u_max (actuator limits)
G1 Applications
- Balance safety: h(x) = distance from CoM projection to edge of support polygon
- Joint limit safety: h(x) = distance from current joint angle to limit
- Collision avoidance: h(x) = distance from robot links to obstacles (arXiv:2502.02858 — validated on G1)
Pros and Cons
- Pro: Formal guarantee — if the model is accurate, safety is provably maintained
- Pro: Minimal modification — acts as a "safety filter" on any controller
- Con: Requires accurate dynamics model (link masses, inertias)
- Con: Computationally expensive real-time QP (must solve within 2ms at 500 Hz)
- Con: Conservative — may reject valid actions near the safety boundary
See push-recovery-balance §3c for detailed application to push recovery.
10. Fall Risk Assessment for Custom Low-Level Control
WARNING: Bypassing the stock locomotion controller to send raw joint commands via rt/lowcmd introduces significant fall risk. [T1]
| Risk Level | Scenario | Mitigation |
|---|---|---|
| Low | Overlay approach — stock controller handles legs, user controls arms only | Stock balance maintained |
| Medium | GR00T-WBC — trained RL locomotion policy replaces stock | Validate extensively in sim |
| High | Full custom policy — all joints controlled by user code | Safety harness mandatory, extensive sim2sim validation |
| Critical | Untested low-level commands to leg joints | DO NOT do this without simulation validation |
Required Precautions for Custom Balance
- Always simulate first in MuJoCo or Isaac Lab
- Cross-validate in a second simulator (Sim2Sim)
- Use a safety harness for all real-robot tests
- Start with standing only, then walking, then with perturbations
- Have a spotter with e-stop at all times
- Consider a CBF safety filter as an additional layer
Key Relationships
- Constrains: joint-configuration (joint limits, torque limits)
- Constrains: locomotion-control (safe operating speeds, fall protection)
- Constrains: deployment-operations (environmental limits, pre-op checks)
- References: equations-and-bounds (numerical bounds)
- Informs: learning-and-ai (safety wrappers for policy deployment)
- Protects: push-recovery-balance (safety layer for balance enhancement)
- Protects: whole-body-control (safety constraints for WBC)
- Protects: motion-retargeting (feasibility checking before execution)