---
id: safety-limits
title: "Safety & Operational Limits"
status: established
source_sections: "reference/sources/official-user-manual.md, reference/sources/paper-safe-control-cluttered.md, reference/sources/paper-getting-up-policies.md"
related_topics: [hardware-specs, joint-configuration, equations-and-bounds, deployment-operations, push-recovery-balance, whole-body-control]
key_equations: []
key_terms: [e_stop, safety_limits]
images: []
examples: []
open_questions:
  - "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
1. **Simulate first** — Validate all new behaviors in unitree_mujoco or Isaac Lab
2. **Cross-validate** — Test in a second simulator (Sim2Sim) for robustness
3. **Low-gain start** — Deploy with reduced PD gains initially
4. **Tethered testing** — Use a safety harness/gantry for first real-world tests
5. **Clear area** — Ensure at least 2m clearance around the robot
6. **Spotter present** — Always have a human spotter ready with the remote/e-stop
7. **Battery check** — Verify sufficient charge before testing (>30%)
8. **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
1. Always simulate first in MuJoCo or Isaac Lab
2. Cross-validate in a second simulator (Sim2Sim)
3. Use a safety harness for all real-robot tests
4. Start with standing only, then walking, then with perturbations
5. Have a spotter with e-stop at all times
6. 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)