AquaChat++: Multi-ROV Aquaculture Inspection

• AquaChat++ is a hierarchical LLM-driven framework that autonomously inspects offshore aquaculture net pens using coordinated multi-ROV strategies.
• It integrates natural language mission specification with symbolic planning, battery-aware task allocation, and thruster-fault-tolerant low-level control.
• Simulation results in ROS/Gazebo demonstrate robust planning and execution under battery and actuator constraints, ensuring safe docking and collision-free navigation.

AquaChat++ is a hierarchical, LLM-driven framework for autonomous inspection of offshore aquaculture net pens using multiple ROVs, combining natural-language mission specification with symbolic multi-ROV planning, battery-aware task allocation, and thruster-fault-tolerant low-level control in a high-fidelity Gazebo/ROS simulation of a fish farm (Saad et al., 6 Aug 2025). In the broader research landscape, the name also denotes a design trajectory that extends earlier work on water-information chatbots, LLM-mediated underwater simulation, underwater mobile-device messaging, IoT aquarium monitoring, and modular AUV water-quality sensing into increasingly integrated aquatic cyber-physical systems (Lourens et al., 2018).

1. Origins, scope, and problem setting

AquaChat++ emerged in response to the operational requirements of offshore aquaculture, where large net pens must be inspected for structural integrity, biosecurity, and sustainable operation. The immediate motivation is that failures such as holes, tears, or structural fatigue can cause mass fish escapes, environmental contamination, and regulatory violations. The framework therefore targets regular inspection of nets, moorings, and rings under real-time constraints including energy consumption, hardware faults, and dynamic underwater conditions (Saad et al., 6 Aug 2025).

The system is positioned against three established inspection modes: divers, single-ROV missions, and scripted autonomy. Divers are described as expensive, risky, weather-dependent, and limited in duration. Single-ROV or pre-programmed systems are described as difficult to adapt to battery depletion, actuator faults, and new inspection requests, and they typically scale poorly because planning and coordination require expert operators (Saad et al., 6 Aug 2025). AquaChat, the immediately preceding single-ROV framework, had already identified the limitations of manually piloted ROVs and fixed trajectories for aquaculture net inspection, and introduced a three-layer architecture linking natural-language commands to symbolic tasks and low-level control (Akram et al., 19 Jul 2025).

A broader historical precursor is the South African conversational system for water-quality dissemination, which sought to apprise users with limited access to computational resources about water quality and real-time accessibility for a given location through natural-language understanding, entity recognition, and external data integration (Lourens et al., 2018). That work addressed fragmented environmental information and low-resource deployment, whereas AquaChat++ addresses multi-robot inspection in a physics-based marine environment. This suggests a continuity in aquatic conversational systems: language interfaces are used not only for information retrieval but also for operational decision support and autonomous execution.

2. Architectural organization

AquaChat++ uses a two-layer hierarchy consisting of a high-level plan generation layer and a low-level plan execution layer (Saad et al., 6 Aug 2025). At the high level, an LLM such as GPT-4o receives a structured prompt containing user intent, cage geometry, docking stations, ROV states, battery levels, thruster status, the thruster configuration matrix, and operational rules. It outputs a symbolic plan in JSON, partitioned by ROV, with sequences of function calls, predicted BatteryStatus, and ThrusterStatus. At the low level, symbolic actions are parsed into motion plans, helical inspection trajectories, PID-based tracking commands, and adaptive thrust-allocation commands, all executed in ROS/Gazebo with a BlueROV2 dynamic model (Saad et al., 6 Aug 2025).

The system prompt defines a constrained API consisting of move_to(target, {'x': value, 'y': value, 'z': value}) and inspect_net(target, {'direction': 'top-to-bottom'/'bottom-to-top', 'method': 'standard', 'distance': 3}). The prompt also encodes explicit rules: maintain exactly 3 m radial distance from cage center, assume each cage inspection consumes approximately 25% battery, require docking before battery falls below 10%, and inspect only if remaining working thrusters can span surge, sway, heave, and yaw (Saad et al., 6 Aug 2025). The symbolic plan is therefore not free-form text; it is a constrained program-like artifact.

AquaChat, the predecessor framework, used a related but more explicitly layered architecture: a high-level LLM planner, a mid-level PDDL-style task manager with predicates and actions, and a low-level motion-control layer (Akram et al., 19 Jul 2025). AquaChat++ differs in replacing the single-ROV mid-level symbolic executor with multi-ROV allocation logic and explicit battery and fault constraints. The architectural shift is from adaptive inspection of one cage by one ROV to coordinated inspection of multiple cages by multiple vehicles under discrete resource limits.

A relevant comparison point is ChatSim, which integrates ChatGPT with the Blender-based OysterSim through a constrained function library and regex-based code extraction. There the LLM is restricted to output code calling approved functions; simulation state is not fed back to the LLM during a run, creating a closed perception-action boundary (Palnitkar et al., 2023). AquaChat++ adopts a similar design principle of restricting the LLM to a controlled symbolic interface, but applies it to underwater inspection planning rather than scene editing. A plausible implication is that both systems treat the LLM as a high-level symbolic reasoner while preserving deterministic execution layers beneath it.

3. High-level planning and coordination mechanisms

The core planning problem in AquaChat++ is the translation of a natural-language instruction such as “Inspect all fish nets” into coordinated multi-ROV plans subject to geometry, energy, and fault constraints (Saad et al., 6 Aug 2025). The initial planning relation is expressed as

$$P_{\text{initial}} = \mathcal{F}_{\text{LLM}}(S_t, I_u, C_b, F_t),$$

where $S_t$ denotes system state, $I_u$ user instructions, $C_b$ battery constraints, and $F_t$ thruster status. In the Human-in-the-Loop Adaptive Planner, user feedback further refines the plan according to

$$P_{\text{final}} = \mathcal{F}_{\text{LLM}}(P_{\text{initial}}, F_{\text{user}}).$$

Three planning architectures are evaluated. The Central LLM Planner (CLP) uses a single LLM call with global state. The Human-in-the-Loop Adaptive Planner (HAP) iterates through validation, visualization, human feedback, and replanning. The LLM-coordinated Multi-Agent System (MAS) assigns each ROV its own LLM agent, with coordination through shared context or a central planner, and may require multiple planning rounds (Saad et al., 6 Aug 2025). These variants correspond to different trade-offs between autonomy, latency, and robustness.

The battery model is discrete and prompt-encoded: each cage inspection consumes approximately 25% battery, and an ROV must dock before battery falls below 10%. The prompt also instructs that ROVs do not have to inspect the same number of cages and should be assigned cages based on proximity to minimize total distance. Inspection direction is alternated between top-to-bottom and bottom-to-top to reduce vertical motion overhead (Saad et al., 6 Aug 2025). There is no explicit MILP or cost-optimized scheduler in the formulation; planning remains LLM-based, with constraints enforced by prompt design and post hoc validation.

Thruster feasibility is similarly encoded at planning time. The LLM is instructed to use the $6 \times 6$ thruster configuration matrix and the fault vector to determine whether the remaining thrusters can still support the four required DOFs: surge, sway, heave, and yaw. If not, the ROV must dock immediately for repairs and not inspect (Saad et al., 6 Aug 2025). This is a notable difference from AquaChat, where replanning is triggered by feedback predicates such as replan_needed and feedback_received, but battery- and fault-aware allocation across vehicles is not central (Akram et al., 19 Jul 2025).

Earlier aquatic conversational systems reveal a different planning substrate. The South African water-information model used Rasa NLU, a tracker, dialogue policies, and actions such as utter_water_quality and utter_water_availability, driven by intent classification and entity recognition (Lourens et al., 2018). That framework performed language identification, intent detection, entity extraction, and external data lookup. AquaChat++ preserves the high-level idea of translating natural language into actions, but the action semantics have shifted from information dissemination to multi-agent mission generation.

4. Low-level control, path generation, and fault tolerance

The low-level layer of AquaChat++ uses a full 6-DOF marine dynamics model in the Fossen framework for BlueROV2 (Saad et al., 6 Aug 2025). The state variables are

$$\eta = [x, y, z, \phi, \theta, \psi]^T, \quad \nu = [u, v, w, p, q, r]^T,$$

with kinematics

$\dot{\eta} = J(\eta)\,\nu.$

The dynamics are written as

$$M_{RB}\dot{\nu} + M_A\dot{\nu} + C_{RB}(\nu)\nu + C_A(\nu)\nu + D(\nu)\nu + g(\eta) = \tau_{\text{thrust}} + \tau_d.$$

The paper further specifies added-mass and damping structures and provides BlueROV2 parameters in a table (Saad et al., 6 Aug 2025).

Thruster forces $S_t$0 are mapped to generalized forces through

$S_t$1

where $S_t$2 is explicitly given (Saad et al., 6 Aug 2025). Faults are modeled either as full failures, by setting maximum capacity to zero for selected thrusters, or as partial degradations through a factor $S_t$3. Adaptive thrust allocation is posed as the constrained optimization problem

$S_t$4

This replaces simple pseudo-inverse allocation and enforces fault-aware limits at each control step (Saad et al., 6 Aug 2025).

Trajectory tracking for surge, sway, heave, and yaw is handled by PID controllers:

$S_t$5

with error vector

$S_t$6

A Lyapunov-based argument in the paper states

$S_t$7

implying asymptotic stability under bounded disturbances (Saad et al., 6 Aug 2025).

Above the controller, AquaChat++ uses RRT* for collision-free navigation between waypoints and helical trajectories for net coverage. For a cylindrical cage centered at $S_t$8, the helical path is

$S_t$9

with $I_u$0 and parameters chosen so the ROV remains approximately 3 m from cage center while covering depths from 0 m to $I_u$1 m (Saad et al., 6 Aug 2025).

AquaChat had already used helical and zig-zag patterns for inspection, but with a simplified kinematic model,

$I_u$2

and waypoint-level PID tracking rather than explicit optimization-based fault compensation (Akram et al., 19 Jul 2025). AquaChat++ therefore represents a substantial increase in low-level control realism and fault accommodation.

5. Evaluation and empirical performance

AquaChat++ is validated in ROS-Gazebo using UUV Simulator, a BlueROV2 simulator, and an aquaculture model with five cylindrical cages arranged at $I_u$3, $I_u$4, $I_u$5, $I_u$6, and $I_u$7, each of diameter 5 m and depth 0 to $I_u$8 m, together with two docking stations (Saad et al., 6 Aug 2025). Two ROVs are used, often with different initial battery states, and fault scenarios are introduced by disabling selected thrusters.

The prompt-based evaluation uses five planning cases and compares CLP, HAP, and MAS in terms of Planning Success Rate, Execution Success Rate, and plan generation time. Execution success is reported as always 100% given a valid plan. CLP is fastest, at approximately 3–4 s, and performs well on simple prompts, but it fails completely in constraint-heavy cases such as both ROVs limited to 50% battery or a failed vertical thruster on one ROV. HAP achieves the highest robustness, with Planning Success Rate up to 100% in most cases and 95% or 85% in the most complex cases, but requires approximately 50–105 s because of iterative feedback. MAS achieves 80–100% Planning Success Rate across all cases and requires approximately 9–18 s, making it a compromise between CLP speed and HAP reliability (Saad et al., 6 Aug 2025).

Scenario-based evaluation further distinguishes battery-sufficient, battery-constrained, partial-fault, and critical-fault conditions. Under battery-sufficient conditions, all planners generate valid plans. Under battery-constrained conditions, CLP often fails to schedule intermediate docking, whereas HAP and MAS do so more consistently. Under critical faults, only HAP and MAS consistently generate valid plans that skip inspections and dock immediately; CLP may still assign inspection tasks when thruster configuration is insufficient for safe 4-DOF control (Saad et al., 6 Aug 2025).

The low-level controller is evaluated under four thruster conditions: normal, F2, F2,5, and F2,4,5. Position tracking errors remain below approximately 0.12 m across all conditions, while yaw error remains near 0.155–0.156 rad under normal, F2, and F2,5, but increases to 1.011 rad in the severe triple-fault case F2,4,5 (Saad et al., 6 Aug 2025). The interpretation given in the paper is operationally important: navigation to a dock remains feasible under severe faults, but heading precision becomes inadequate for high-quality visual inspection. This directly supports the planning rule that critically degraded vehicles should dock rather than inspect.

AquaChat, by contrast, evaluated plan flexibility against a rule-based planner and found that the LLM-based planner handled structured and unstructured inspection commands with much greater flexibility, but incurred plan generation times ranging from 2.7 s to 47.7 s (Akram et al., 19 Jul 2025). The contrast between the two papers is instructive: AquaChat established the utility of LLMs for task understanding, while AquaChat++ demonstrated how that capability can be extended into coordinated multi-vehicle execution under hard operational constraints.

6. Conceptual relations, limitations, and research directions

AquaChat++ sits within a wider body of aquatic AI systems that combine language interfaces, structured control APIs, and environmental sensing. The South African water chatbot used Rasa, a tensorflow embedding policy, LSTM-based dialogue management, and entity recognition to answer questions about water quality and availability from governmental and nongovernmental sources (Lourens et al., 2018). ChatSim used a constrained function library to let an LLM reconfigure underwater simulation scenes and BlueROV trajectories in OysterSim (Palnitkar et al., 2023). AquaApp demonstrated software-only underwater messaging between commodity smartphones and smartwatches using microphones and speakers, with adaptive OFDM in the 1–4 kHz band, 100 bps to 1.8 kbps rates up to 30 m, and 10–20 bps operation up to 100 m (Chen et al., 2022). An IoT smart aquarium system used an ESP32, pH, TDS, temperature, and turbidity sensing, Blynk cloud connectivity, and a 10-minute alert cooldown for real-time monitoring and automated feeding (Ayon et al., 13 Jan 2026). A modular AUV system for sea-water monitoring used the CWolf platform, meander missions, saw-tooth depth profiles, and payload modularity for nitrate, oxygen, conductivity, and temperature mapping near Norwegian aquaculture farms (Eichhorn et al., 2017).

These systems address distinct tasks, but they share several recurrent design motifs: constrained interfaces between language and actuation, modular separation between mission logic and execution, reliance on external sensing or data services, and strong attention to deployment constraints such as bandwidth, robustness, or platform modularity. This suggests that AquaChat++ is best understood not merely as one inspection controller, but as a representative instance of a broader class of aquatic systems in which LLMs occupy the mission or interaction layer while classical robotics, optimization, and sensing remain responsible for physical correctness.

The limitations of AquaChat++ are explicit. Its battery model is coarse, using a fixed 25% cost per cage and a 10% threshold rather than continuous energy estimation. High-level reasoning is entirely LLM-based, without a formal symbolic planner or proof of optimality. Thruster-fault detection is assumed rather than modeled. The framework assumes access to GPT-4o or a similar model, whereas real underwater deployments may face acoustic-modem bandwidth limits and higher latency. All validation is in simulation rather than at operational fish farms (Saad et al., 6 Aug 2025).

The research trajectory implied across the cited papers points toward several converging directions. AquaChat proposed tighter integration of perception and language, multi-ROV coordination, and formal safety constraints on LLM-generated plans (Akram et al., 19 Jul 2025). ChatSim proposed richer toolkits and more real-world data integration for underwater simulation (Palnitkar et al., 2023). AquaApp suggested a practical communication substrate for short underwater messages on commodity devices (Chen et al., 2022). The smart aquarium work proposed edge AI, additional sensors, and more advanced alert management (Ayon et al., 13 Jan 2026). A plausible implication is that future AquaChat++-style systems will combine multi-robot planning, perception-grounded inspection, explicit safety shields, richer energy models, and heterogeneous communication and sensing layers into a unified aquaculture monitoring and intervention stack.