administrator/rov-autonomy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
master
rov-autonomy/docs/failsafe_design.md

20 KiB
Raw Permalink Blame History

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)

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.