rov-autonomy/docs/failsafe_design.md

# ROV Failsafe & Safety Behaviour Design
**Project:** Argonaut 3 — Autonomous Inspection System
**Version:** 2.0
**Date:** May 2026
**Status:** Design — pre-implementation

---

## Version History

| Version | Date | Changes |
|---|---|---|
| 1.0 | May 2026 | Initial design |
| 2.0 | May 2026 | Revised per operational review: continuous self-assessment, breadcrumb path reversal, tethered vs untethered exit modes, 2s comms timeout, battery config via web UI, depth as soft limit, Gemini sonar roadmap, thruster health via power consumption |

---

## 1. Design Philosophy

**Asset preservation over mission completion.** A recovered vehicle can repeat a mission. A lost vehicle cannot.

**Conditional response over fixed response.** The system assesses its own capability before choosing a response. Hard-coded reactions are inappropriate for a vehicle operating inside structures where "surface immediately" may cause the exact loss it is trying to prevent.

**Safety is continuous, not reactive.** The system monitors its health at all times, not only when a failure occurs. By the time a failsafe triggers, the vehicle already has a current picture of its own state.

**Tethered and untethered operation are fundamentally different.** Exit behaviour, path planning, and safe zone definitions differ between modes and must be explicitly configured at mission start.

---

## 2. Continuous Self-Assessment

Self-assessment runs continuously throughout all operations — not only when a failure occurs. This eliminates the lag between trigger and response that would otherwise occur if assessment only started at fault detection.

### Assessment rates

| Mode | Rate | Rationale |
|---|---|---|
| Normal operation | 5 Hz | Low overhead, sufficient for trend detection |
| Any parameter degraded | 20 Hz | Faster response as situation develops |
| Failsafe active | 50 Hz | Maximum responsiveness during critical phase |

### Parameters assessed

| Parameter | Source | Healthy threshold |
|---|---|---|
| Attitude stability | Xsens IMU | Roll/pitch error < 5°, rate < 10°/s |
| Depth hold | Pressure sensor via MAVROS | Depth error < 0.5m from setpoint |
| Structural clearance | Obstacle sensors (see Section 6) | > 1.5m clearance in primary travel direction |
| Path to safety | Breadcrumb buffer + dead reckoning | Valid path calculable to entry point |
| Battery reserve | Dynamic return budget (see Section 5) | > 15% above minimum return estimate |
| FCU connection | MAVROS heartbeat | Heartbeat received within 2s |
| Thruster health | ESC power consumption | No thruster drawing > 150% of peer average |

### Assessment states

Three states, consistent with DP (Dynamic Positioning) reference system conventions:

| State | Definition | Minimum conditions |
|---|---|---|
| **GREEN** | Vehicle capable, all systems nominal | All parameters healthy, 5+ parameters assessed |
| **AMBER** | Vehicle functional but degraded | Core navigation intact, ≤ 1 parameter marginal |
| **RED** | Vehicle incapable of safe autonomous action | Navigation sensor failure, or ≥ 2 parameters marginal, or any safety-critical sensor lost |

---

## 3. Path to Safety — Breadcrumb System

### Concept

"Return to safe" does not mean surface from current position. Inside a jacket structure, surfacing from current position could drive the vehicle into a structural member or wrap the tether around a node.

Safe return means retracing the path taken since the designated entry point, in reverse.

### Entry point designation

At mission start, the operator designates:
- **Entry point** — the position at which the vehicle entered the structure or began the mission. Stored as a 3D position in the mission YAML.
- **Safe zone** — a volume (not a point) beyond the structure perimeter where the vehicle can safely ascend. Defined as a radius around the entry point (default: 5m radius, 0m to surface).
- **Operation mode** — `tethered` or `untethered`. This changes the exit strategy fundamentally.

### Breadcrumb buffer

From the moment of entry point designation, the system logs position estimates every 2 seconds to a circular buffer. Buffer size: 1,800 entries = 1 hour of operation. Older entries are discarded as new ones are added.

Each breadcrumb entry stores:
```
timestamp, x, y, z, heading, confidence_score
```

`confidence_score` reflects the quality of the position estimate at that moment — entries with low confidence are flagged and the system may skip them during path reversal in favour of the next reliable entry.

### Tethered exit (path reversal)

On a failsafe exit trigger in tethered mode:

1. Halt all forward motion immediately
2. Load the breadcrumb buffer in reverse order
3. Navigate waypoint-by-waypoint back along the recorded path
4. On reaching the entry point, move laterally to the safe zone
5. Ascend vertically to surface

**Critical constraint:** The tether exit path must follow the vehicle entry path exactly. Any deviation risks wrapping the tether around a structural member. If position uncertainty at any breadcrumb point exceeds a threshold (configurable, default 0.5m), the vehicle halts and holds, awaiting operator instruction or comms restoration.

### Untethered exit (direct to safe zone)

On a failsafe exit trigger in untethered mode:

1. Halt all forward motion
2. Use current sensor data to assess the most direct obstacle-free route toward the safe zone
3. Navigate toward the safe zone boundary
4. On entering the safe zone, ascend vertically to surface

**Advantage over tethered:** The untethered vehicle is not constrained to its entry path. It can take the most efficient route to the safe zone perimeter using live obstacle sensor data.

### Safe zone verification

Before ascending, the vehicle performs a brief check (default 5 seconds):
- Obstacle sensors confirm clearance above
- Attitude is stable
- No new failsafe conditions have triggered

If verification fails, the vehicle holds at the safe zone boundary and re-attempts after 10 seconds. After 3 failed attempts, emergency surface is triggered.

---

## 4. Failsafe State Machine

### States

```
NORMAL ──[trigger]──► ASSESSING ──[GREEN/AMBER]──► HOLD_AND_RECOVER
                                │                       │
                                │                  [recovery fails]
                                │                       │
                                └──[RED]──────────► RETURN_TO_SAFE
                                                        │
                                              [path blocked / RED worsens]
                                                        │
                                                EMERGENCY_SURFACE
```

| State | Description |
|---|---|
| NORMAL | Mission executing, all systems nominal |
| ASSESSING | Failsafe triggered, assessment resolves in < 0.2s (data already current) |
| HOLD_AND_RECOVER | Station-keeping, monitoring for recovery condition |
| RETURN_TO_SAFE | Executing breadcrumb reversal or direct route to safe zone |
| EMERGENCY_SURFACE | Maximum ascent, no navigation — last resort only |
| MISSION_COMPLETE | Normal end state |
| ABORTED | Mission ended safely, vehicle at surface |

**Note on EMERGENCY_SURFACE:** This state is explicitly the highest-risk action the vehicle can take. It surfaces without regard for surroundings. It exists because there are conditions where all other options have been exhausted and certain loss is the only alternative. It must never be the first response to any condition.

---

## 5. Trigger Conditions and Responses

### 5.1 Comms loss

**Definition:** No FCU heartbeat received for > timeout period.

**Default timeout:** 2 seconds. Configurable per deployment.

**Rationale for 2s default:** In high current conditions, 5 seconds of unchecked drift may place the vehicle in an unrecoverable position relative to its tether or the structure. 2 seconds is a practical lower bound given normal comms latency.

**Response — conditional on assessment state:**

| State | Action | Hold limit |
|---|---|---|
| GREEN | Hold position, attempt reconnection | 60s then RETURN_TO_SAFE |
| AMBER | Hold position, attempt reconnection | 30s then RETURN_TO_SAFE |
| RED | RETURN_TO_SAFE immediately | — |

**Recovery condition:** Comms restored AND assessment returns GREEN → resume mission. If interrupted mid-panel, restart that panel from the beginning. Incomplete panel data is discarded — partial coverage is worse than no coverage for inspection reporting.

### 5.2 Low battery

**Definition:** Dynamic threshold based on battery profile (see Section 5 — Battery Management).

**Response — tiered:**

| Threshold | Action |
|---|---|
| Warning (25%) | Alert published to web UI. Continue current waypoint. No new panels started. |
| Return threshold (20%) | Complete current panel capture then RETURN_TO_SAFE |
| Critical (12%) | Abandon current task immediately. RETURN_TO_SAFE. |
| Emergency (8%) | EMERGENCY_SURFACE. No other action. |

**Note:** Critical and Emergency thresholds trigger RETURN_TO_SAFE and EMERGENCY_SURFACE respectively — not an uncontrolled shutdown. The vehicle uses remaining power to reach a safe position before ascending.

### 5.3 Depth exceeded

**Definition:** Measured depth exceeds configured limits.

**This is a soft limit, not an emergency.** Depth exceedance during a structured mission likely indicates a navigation error, not a catastrophic failure.

| Depth | Action |
|---|---|
| > Design depth (200m) | Log event, alert operator, continue — may be intentional |
| > Warning depth (250m) | Halt downward movement. Hold current depth. Alert operator. Await instruction. |
| > Safety limit (300m) | RETURN_TO_SAFE. Hardware safety limit — do not exceed. |

**Note:** Standard BlueROV2 Heavy depth rating is 100m. Operating beyond this requires a pressure-rated enclosure upgrade. The 200m/300m values above are design targets for a hardware-upgraded configuration and must be validated against the actual build specification before field use.

### 5.4 Obstacle detected

**Definition:** Object detected within configured standoff distance in the direction of travel.

**Default standoff:** 1.0m. Configurable per deployment (tighter in confined structures, looser in open water).

**Response — conditional:**

| Condition | Action |
|---|---|
| GREEN, stationary obstacle | Halt. Hold position. Re-plan path around obstacle. Resume. |
| GREEN, moving obstacle | Hold position. Wait up to 30s for clearance. Re-plan if not cleared. |
| AMBER | Halt. Hold. Alert operator. Await instruction. |
| RED | RETURN_TO_SAFE |

**Tethered note:** Obstacle detection in tethered mode must also consider tether routing. The re-planned path must not create tether entanglement risk even if it is geometrically clear of obstacles.

### 5.5 Manual abort

**Definition:** Operator sends abort command via web UI.

**Response — conditional:**

| State | Action | Wait limit |
|---|---|---|
| GREEN | Hold position. Await operator instruction (resume or surface). | 120s then RETURN_TO_SAFE |
| AMBER | RETURN_TO_SAFE | — |
| RED | RETURN_TO_SAFE | — |

**Rationale:** An operator abort near a structure may be a precaution, not an emergency. Holding position gives the operator the opportunity to assess and instruct next steps. If no instruction arrives within 120 seconds, the vehicle proceeds to RETURN_TO_SAFE autonomously.

### 5.6 Thruster anomaly

**Definition:** Any thruster drawing > 150% of the average power consumption of its peers over a 5-second window, or all thrusters drawing > 130% of baseline simultaneously.

**Interpretation:**
- Single thruster anomaly: possible mechanical obstruction, debris ingestion, or thruster failure
- All thrusters elevated: high current/drag environment — mission difficulty has increased

**Response:**

| Condition | Action |
|---|---|
| Single thruster > 150% peer average | Alert. Downgrade to AMBER. Increase assessment rate. |
| Single thruster drops to zero output | Alert. Re-assess station-keeping ability. May trigger RED. |
| All thrusters > 130% baseline for > 30s | Alert. Reassess mission feasibility. Notify operator. |

---

## 6. Battery Management

Battery thresholds are not hardcoded. All parameters are configurable via the web UI and stored in `battery.yaml`. When a new battery type is fitted, only the configuration changes — no code changes required.

### Battery configuration (web UI + battery.yaml)

```yaml
battery:
  label: "BlueRobotics_4S_15.6Ah"
  capacity_wh: 388.8
  warning_percent: 25
  return_percent: 20
  critical_percent: 12
  emergency_percent: 8
```

### Dynamic return budget

In addition to fixed percentage thresholds, the system maintains a dynamic return budget — an estimate of the energy required to return from current position to surface. If the dynamic budget exceeds the return threshold percentage, the dynamic budget takes priority.

**Calculation inputs:**
- Current depth (deeper = more ascent energy required)
- Distance from safe zone
- Observed thruster load over the last 60 seconds (indicator of current and drag)
- Battery discharge curve from config

**Practical effect:** A vehicle at 30m depth in calm water may safely continue at 20% battery. The same vehicle at 80m in high current may need to return at 30%. The system calculates this automatically.

---

## 7. Obstacle Detection — Sensor Strategy

### 7.1 Design principle

Obstacle detection uses a layered sensor approach. Each layer adds capability. The system is designed from the start to accommodate additional sensors as budget allows, without architectural changes.

### 7.2 Sensor layers

#### Layer 1 — IP cameras (current hardware, no additional cost)

Cameras contribute to obstacle awareness via:
- **Optical flow** — detects relative motion toward a surface
- **Edge detection** — high-contrast edges across multiple frames indicate proximity to a structure

**Honest limitations:** Unreliable in turbid water, darkness, or port visibility conditions. Effective as a first warning layer only. Not sufficient as a standalone safety system.

**Verdict:** Use now. Treat as supplementary.

---

#### Layer 2 — Blue Robotics Ping2 Sonar (~$280 USD)

Single-beam echosounder. Serial interface (UART/USB via BLUART adapter, or networked via BlueOS bridge).

| Attribute | Value |
|---|---|
| Range | 100m |
| Beam width | 25° (single direction) |
| Depth rating | 300m |
| Update rate | ~10 Hz |
| Interface | Serial (UART) — network via BlueOS |
| BlueROV2 integration | Native — mounting bracket included |
| ROS2 integration | ping-python library, wrappable as ROS2 node |

**Deployment:**
- Unit 1 (forward): primary obstacle detection in travel direction
- Unit 2 (downward): altimetry — distance to hull/seafloor for standoff control

**Interface note:** The Ping2 is a serial device. It can be accessed over the network via BlueOS as a bridge, but the physical connection is UART. This limits expandability. An Ethernet switch inside the ROV is recommended infrastructure even if the Ping2 is the first sonar fitted — it prepares the system for the Gemini upgrade.

**Verdict:** First acoustic purchase. Phase 3.

---

#### Layer 3 — Blue Robotics Ping360 Scanning Sonar (~$1,200 USD)

Mechanical scanning imaging sonar. 360° coverage.

| Attribute | Value |
|---|---|
| Range | 50m |
| Coverage | 360° mechanical scan |
| Depth rating | 100m standard |
| Update rate | Variable (full scan ~1-2s depending on range) |
| Interface | USB or Ethernet |
| BlueROV2 integration | Native |

**Use:** Full situational awareness. Sees threats from all directions simultaneously. Particularly valuable inside jacket structures where obstacles exist in all planes.

**Verdict:** Phase 4-5. Required before unsupervised field operations.

---

#### Layer 4 — Tritech Gemini 720im Multibeam Sonar (~$8,000–$15,000 USD)

Real-time multibeam imaging sonar. The target long-term sensor for this system.

| Attribute | Value |
|---|---|
| Frequency | 720 kHz |
| Field of view | 90° horizontal |
| Range | 50m |
| Update rate | Up to 20 Hz |
| Depth rating | 300m |
| Interface | Ethernet or Tritech Serial (TSMP) |
| Size | Compact — suited to small ROVs |

**Use:** High-resolution, high-update-rate obstacle and structure detection. Real-time sonar imagery for both safety and inspection. The Ethernet interface makes it architecturally clean to integrate alongside cameras and other network devices.

**Verdict:** Phase 6+, budget permitting. Design the internal Ethernet switch infrastructure now so the Gemini slots in without hull penetration changes.

---

#### Future consideration — Forward-Looking Sonar (FLS)

Purpose-built forward obstacle detection at higher resolution than the Ping360 in the forward arc. Products such as the Tritech Micron and Impact Subsea ISS360 exist in this space. Price range $2,000–$8,000 USD. Evaluate after Gemini decision.

#### Future consideration — Laser rangefinding

Effective only in clear water (visibility > 5m). Port environments with turbidity make laser-based ranging unreliable. Not recommended for primary obstacle detection in the target operational environment. Note for reference only.

---

### 7.3 Sensor roadmap

| Phase | Sensors active | Capability |
|---|---|---|
| 1–2 | IP cameras | Basic visual awareness. No safety guarantee. |
| 3 | + Ping2 (×1 forward) | Basic acoustic obstacle detection. |
| 4 | + Ping2 (×1 downward) | Full altimetry. Standoff control from hull. |
| 5 | + Ping360 | Full 360° situational awareness. |
| 6+ | + Gemini 720im | High-resolution real-time multibeam. |

---

## 8. Failsafe Priority Order

When multiple conditions trigger simultaneously, the highest priority wins:

| Priority | Condition | Override behaviour |
|---|---|---|
| 1 | Emergency surface | Always wins. No assessment. Last resort. |
| 2 | Critical/emergency battery | Overrides all responses. Initiates RETURN_TO_SAFE or EMERGENCY_SURFACE. |
| 3 | Safety depth limit exceeded (300m) | Overrides hold behaviours. RETURN_TO_SAFE. |
| 4 | Obstacle detected — RED state | Overrides comms loss hold. RETURN_TO_SAFE. |
| 5 | Comms loss | Assessed response. |
| 6 | Manual abort | Assessed response. |
| 7 | Thruster anomaly | Alert and AMBER downgrade. Informational unless escalates. |
| 8 | Low battery warning (25%) | Informational. Lowest priority. |

---

## 9. Configuration — What Goes Where

| Item | Location | Who changes it | When |
|---|---|---|---|
| State machine logic | `failsafe_monitor.py` | Developer | Code changes only |
| Battery type and thresholds | Web UI → `battery.yaml` | Operator | Per battery swap |
| Comms timeout | `failsafe.yaml` | Operator | Per deployment environment |
| Depth limits | `failsafe.yaml` | Operator | Per hardware configuration |
| Standoff distance | `mission.yaml` | Operator | Per structure type |
| Entry point and safe zone | Web UI → mission plan | Operator | Per dive |
| Operation mode (tethered/untethered) | Web UI → mission plan | Operator | Per dive |
| Sensor enable/disable flags | `sensors.yaml` | Operator | As hardware is added |
| Breadcrumb interval | `failsafe.yaml` | Developer | Tune after pool testing |

---

## 10. Open Items

Items requiring resolution before autonomous pool testing:

| Item | Notes | Priority |
|---|---|---|
| Breadcrumb buffer implementation | Core to tethered exit safety. Phase 2 development. | High |
| Safe zone radius default | 5m suggested. Validate against typical jacket geometry. | High |
| Comms timeout tuning | 2s default. May generate false positives in high-latency tether. Verify in pool. | High |
| Battery discharge curve | Must be measured empirically per battery type. Not assumed. | High |
| Assessment state thresholds | Specific parameter values need pool testing to tune. | Medium |
| Thruster power baseline | Must be measured in calm water to establish normal. | Medium |
| Ping2 ROS2 node | ping-python library wrapper needs implementation. Phase 3. | Medium |
| Ethernet switch inside ROV | Infrastructure decision. Enables Gemini upgrade path. | Medium |
| Path re-planning algorithm | Required for obstacle avoidance in untethered mode. Phase 4-5. | Low (future) |

---

## 11. Archived Items

Items parked for future consideration — not current priorities:

| Item | Notes |
|---|---|
| Tether tension sensing | Surface-side tension sensors measure cable force near the drum. Useful for human operator awareness. Less useful for vehicle autonomy stack as the vehicle cannot directly act on surface-side tension data. Revisit when considering Tether Management System (TMS) design. |

---

*End of document — ROV Failsafe Design v2.0 — May 2026*
*Next revision triggered by: pool testing results, hardware additions, or operational review.*