DINOS-R: Autonomous Underwater Cognitive System

• The paper presents DINOS-R, a new mission planning framework that integrates symbolic reasoning with teleo-reactive execution for deep-sea AUVs.
• It details a modular architecture with plugin-based core systems and centralized knowledge stores, enabling real-time retasking and adaptive sampling.
• Field trials demonstrate that DINOS-R reduces operator workload and enhances safety through continuous monitoring, explainable decision-making, and dynamic behavior switching.

Overview and motivation: DINOS-R as an Autonomous Underwater Cognitive System (AUCS)

• Goals and scope: DINOS-R is a new mission planning and execution framework for AUV Sentry that replaces the legacy Mission Controller (MC). Its primary goal is to enable interpretable, resilient, long-horizon autonomy with real-time retasking and adaptive behaviors in deep-sea deployments. It targets both standard survey missions (e.g., lawnmower coverage) and mission modalities requiring online decisions and changes (adaptive sampling, abort-and-recover, failure mitigation).
• Why replace MC: MC reliably executes scripted “go-to” sequences, but it is rigid, not scalable to new mission types, cannot retask mid-mission, lacks interpretable reasoning (operators cannot query “why”), and offers no formal or verifiable safety guarantees. DINOS-R addresses these gaps by unifying cognitive decision-making (symbolic, explainable) with teleo-reactive execution for field-ready deep-sea autonomy, while reducing operator workload and risk.
• Cognitive and teleo-reactive principles: DINOS-R takes inspiration from cognitive architectures (e.g., DIARC) for symbolic reasoning, interpretability, and modular knowledge organization, and from teleo-reactive frameworks (e.g., T-REX) for layered, reactive behavior sequencing. It fuses:
  • Symbolic orchestration of behavior for understandable, repeatable, and provable reasoning.
  • Reactive execution to maintain robustness under environmental change.
  • A unified planning/execution loop to support real-time retasking and adaptive sampling at depth.

Architecture and modules

• Software stack: Implemented primarily in Python 3. Middleware-agnostic (can run with ROS 1, ROS 2, or none). Monolithic process for simplicity and reliability, with multiple threads in parallel (behavior execution, self-monitoring, self-assessment).
• Plugin-based core systems: DINOS-R is a toolkit whose core functionality is provided as plugins to a central orchestrator (deliberator). This enables swapping and extending implementations per platform or mission.
• Separation of definition vs implementation: Behaviors are defined (preconditions, effects, interfaces) separately from hardware-specific implementations. Python function annotations tag implementations to behavior definitions. This supports platform portability and reasoning about behaviors even if not yet implemented on the robot.
• Central knowledge stores (databases):
  1. Behavior database: Available behaviors, their preconditions/effects, and how to call them.
  2. Belief database: Symbolic facts about the world and robot state (some inferred from behavior completion, some observed from sensors like dead reckoning and DVL).
  3. Numerics database: Maps symbolic entities (e.g., “survey zone A”) to concrete data (coordinates, depths), enabling abstract planning with runtime grounding.
  4. Self-assessment database: Tracks behavior performance metrics (time, battery use, success rates) for runtime checks and to inform future planning.

• Deliberator (planning/execution manager): Monitors goals, selects and sequences behaviors, prioritizes operator-specified behavior but can switch to self-directed behavior (including self-preservation) when safety triggers fire. Continuously evaluates safety parameters (max depth, keep-out zones) and behavior-specific termination.

• Interfaces and data flows:
  • Planning layer: Symbolic task planning over goals and behaviors, using PDDL-like preconditions/effects provided in Python.
  • Reactive control layer: Executes behaviors; each behavior can be composed from lower-level behaviors (e.g., descent comprises fin orientation, depth waiting, DVL altitude checks, vertical thrust, drop-weights).
  • Perception/learning: Observations update beliefs; developers can integrate behavior trees (BTs), reinforcement learning (RL), finite-state machines (FSMs) inside behavior implementations. DINOS-R orchestrates them symbolically.
  • Mission manager and executive: The deliberator doubles as the executive, unifying “planning” and “execution” phases. Any operation possible on land can be injected subsea in real time.
  • Arbitration/supervisor: The deliberator arbitrates between operator commands and autonomous decisions; safety rules preempt ongoing tasks and trigger self-preservation behaviors.
  • Safety/fault handling: Global constraints are monitored continuously; behaviors halt and switch to safe modes when violated. Failure identification and self-assessment are integrated to mitigate faults.
• AUV Sentry integration specifics:
  • Sensors and actuators accessed by behaviors (e.g., DVL altitude, thruster orientation, drop-weights). Tracklines and waypoint pathing generated at runtime from symbolic goals and numerics.
  • ROS is supported but not required; Sentry’s ROS-based subsystems can be leveraged by behavior implementations.
  • Acoustic interface: High-level goals can be modified during the dive (e.g., “ready for recovery”), prompting immediate replanning and safe recovery sequencing.

Cognitive integration: symbolic decision-making unified with ML and reactivity

• Knowledge representation: DINOS-R uses Python as a domain-specific language for mission/behavior specification. The system represents:
  • Goals as symbolic predicates (e.g., did_survey(zone_a), at_depth(surface)).
  • Facts in the belief database; predicates are updated by sensory observation or inferred via behavior completion.
  • Behavior models with preconditions and effects (PDDL-like), enabling long-horizon reasoning and sequencing.
• Planning formalism: Planning is symbolic and rule-based, with PDDL-like constructs encoded in Python. The paper does not specify MDPs or probabilistic planners. DINOS-R can seamlessly switch between:
  • Real-time task planning (automatic plan synthesis from goals, constraints).
  • User-specified scripts (hard-coded sequences injected by operators), with DINOS-R still enforcing safety and consistency.
• ML and reactive behaviors: Integration points allow BTs, RL policies, and FSMs to be wrapped as behaviors with declared interfaces, enabling DINOS-R to call them within symbolic plans while preserving explainability at the mission level.

Teleo-reactive behaviors: formal description

• DINOS-R follows teleo-reactive principles, sequencing reactive behaviors toward goal achievement under changing conditions. A generic TR rule schema consistent with DINOS-R’s design is:
  • TR rules: For ordered rules i = 1..n,
  • (g_i ∧ c_i) ⇒ a_i,
  • where g_i encodes a goal condition, c_i encodes current context/guard (sensor-derived, belief-derived), and a_i is the action/behavior to execute.
• Execution semantics:
  • At each cycle, select the highest-priority applicable rule (first rule whose g_i ∧ c_i holds).
  • Persistency: If conditions change, control immediately shifts to the highest applicable rule without re-planning.
  • Reactivity: Sensor inputs update beliefs; rule guards c_i reflect those beliefs, ensuring rapid adaptation.
• In DINOS-R, these rules are realized as behavior preconditions/effects, goal monitoring, and safety overrides within the deliberator’s continuous loop.

Planning and decision-making

• Task planner: Online generation of plans at runtime; there is no strict separation between planning and execution. Plans are synthesized from symbolic goals and the behavior database, then grounded with numerics when executed.
• Search/scheduling: The paper emphasizes symbolic sequencing and runtime grounding rather than specific search algorithms. Sequence generation for surveys includes automatic trackline planning for full coverage of specified zones.
• Constraints: Global safety constraints (max depth, keep-out zones) and behavior-specific termination conditions are enforced during execution. Preliminary integration of linear temporal logic (LTL) constraints is underway to formalize safety (e.g., “always keep battery above x%,” “never enter zone Z”).
• Decision-theoretic elements: Not specified in the paper. Probabilistic verification (PRISM) and model checking (SPIN) are under evaluation for future formal guarantees rather than for online decision-making.

Reactive control and low-level behaviors

• Controllers are encapsulated inside behaviors (e.g., “go to waypoint,” “set thruster orientation,” “wait until depth,” “vertical thrust stabilization,” “drop weights”). DINOS-R composes them into higher-level procedures (e.g., descent sequence).
• Termination criteria: Behavior-specific observation-based conditions (e.g., waypoint behavior halts when within acceptable range; descent waits until DVL altitude confirms proximity to seabed before initiating vertical thrust and dropping weights).

Mission specification: declarative goals and constraints; example

• Mission specification uses a Python-based DSL:
  • Symbolic goal example: did_survey(zone_a) ∧ at_depth(surface).
  • Numerics binding: zone_a mapped to coordinates; depth constraints mapped to numeric values.
• Example execution (real deployment):
  1. Operator defines high-level goals only; DINOS-R infers required steps (descent, self-calibration, survey tracklines, ascent).
  2. Automatic trackline generation ensures full coverage of zone_a; DINOS-R inserts required supporting steps (e.g., magnetometer calibration before magnetometer use).
  3. For safety predictability during initial deployment, the auto-generated pathing was replaced on-deck with pathing from a previous dive while the vehicle was idling, demonstrating dynamic behavior injection/modification.
  4. Mid-mission retasking: 30 minutes before the end, an acoustic command changed the goal to “ready for recovery.” DINOS-R synthesized a new sequence (drop weights, change thruster orientation, wait for recovery) and prioritized it as operator-originated.

Provable and repeatable behavior

• Explainability: Symbolic plans, goals, and behavior preconditions/effects make decisions understandable and auditable by operators.

• Formal guarantees (in progress): Integration of LTL constraints into the planning system and GUI; testing with PRISM and SPIN aims to provide probabilistic verification and model checking of safety properties.

• Safety enforcement: Continuous monitoring of global safety parameters and immediate preemption to self-preservation behaviors ensures compliance with safety policies even under environmental changes.

Resource and risk management

• Self-assessment: The self-assessment database logs time, battery use, success percentages for behaviors, enabling runtime health checks and informing future planning decisions.

• Budgets and constraints: Planned LTL extensions include explicit battery/time constraints (e.g., “always finish with > x% battery”). Communication constraints are addressed via acoustic goal updates and the ability to retask autonomously without external replanning cycles.

Field trials and simulation

• Digital twin simulation: Prior to live deployment, DINOS-R replicated MC-run missions in Gazebo, comparing simulated behavior to real-world missions to build confidence.

• At-sea deployment: Conducted aboard R/V Atlantis in early March 2025 on Sentry dive 768. Mission type: full-coverage multibeam survey of a predefined region with standard Sentry sensor suite (multibeam, sidescan, CTD, etc.).

• Results:

  • The symbolic task planner generated a valid plan (descent, calibration, survey tracklines, ascent).
  • Automatic trackline generation for full coverage was demonstrated; pathing was swapped with previous-dive pathing for safety predictability.
  • Retasking test: Acoustic goal change to “ready for recovery” triggered immediate replanning and safe recovery procedures.
  • Dive completed successfully; implementation issues (coordinate frame) were noted as non-architectural.
• Quantitative metrics (durations, success rates, energy consumption, latencies) are not reported in the paper. Qualitatively, robustness and operator workload reduction were demonstrated via on-deck planning, runtime modification, and safe retasking.

Comparison to MC and other architectures

• Over MC:
  • Real-time retasking; adaptive sampling; long-horizon planning integrated with execution; interpretable symbolic decisions; failure identification and mitigation; safety monitoring and preemption; reduced operator burden; modular extensibility.
• vs Behavior Trees (BTs) and FSMs:
  • DINOS-R orchestrates BTs/FSMs as behaviors but adds symbolic planning, runtime grounding, safety reasoning, and retasking that BTs/FSMs alone struggle to scale to.
• vs BDI/cognitive architectures:
  • More focused on AUV field-readiness and mission deployment than full cognitive HRI; adopts DIARC-style separation of definition/implementation and central knowledge stores for interpretability.
• vs MOOS-IvP/T-REX/ROSPlan:
  • DINOS-R combines three-layer/teleo-reactive strengths with symbolic planning and non-expert usability, avoids niche languages (uses Python DSL), and unifies planning and execution; it does not require middleware and embeds resilience and failure reasoning.

Extensibility and usability

• Modularity: Plugins for core services; behaviors as composable units; Python annotations for behavior interfaces.
• APIs and configuration: Python DSL for missions; operator can inject/override plans on-deck or subsea; numerics/behavior separation enables reuse across platforms.
• Non-expert access: Ongoing development of a web-based GUI for scientists to plan missions and evaluate outcomes using the same tools as operators; planned “backseat driver” API for scientist-authored algorithms to direct behavior within safety envelopes.
• Generalization: Designed to be reusable across oceanographic platforms; open-source release and cross-AUV extension planned.

Limitations and future work

• Learning and HRI: Not prioritized initially (focus on field-ready autonomy); richer learning integration is possible via behavior wrappers.
• Formal verification: LTL integration and PRISM/SPIN testing ongoing; stronger safety proofs and certification workflows are future targets.
• Multi-vehicle coordination: Supported conceptually by architecture; multi-agent deployments are planned but not yet demonstrated.
• Usability tooling: More real-time introspection tools and GUI improvements in progress.
• Implementation robustness: Address coordinate frame and other integration issues; extend self-assessment usage in planning.

Mapping DINOS-R to AUCS capabilities

• Cognition features:
  • Perception–decision–action loop: Sensors and observations update beliefs; deliberator sequences behaviors to achieve symbolic goals; reactive execution adapts in real time; self-assessment monitors outcomes and resources.
  • Knowledge representation: Goals, facts, predicates, preconditions/effects stored in behavior and belief databases; numerics ground symbols at runtime.
  • Explainability: Symbolic decisions and declarative missions make behavior understandable and auditable; operator can query and modify high-level goals.
• Autonomy levels:
  • Long-horizon mission planning from declarative goals.
  • Real-time retasking via acoustic commands or onboard reasoning (safety overrides).
  • Adaptive sampling and dynamic behavior construction (e.g., auto trackline generation).
• Teleo-reactivity:
  • Continuous selection of highest-priority applicable behavior; immediate adaptation to changing conditions while maintaining goal-directed action.
  • Rule-like semantics (g ∧ c ⇒ a) underpin behavior activation, persistence, and safety preemption.
• Provability and field readiness:
  • Safety monitoring and preemption; preliminary LTL, PRISM, SPIN integrations for formal guarantees; demonstrated on Sentry in simulation and at-sea (dive 768).
  • Middleware-agnostic, modular, Python-based tooling supports non-expert use and cross-platform deployment.

Illustrative formal elements (consistent with DINOS-R design)

• Teleo-reactive rule schema: For ordered rules i, (g_i ∧ c_i) ⇒ a_i, where g_i is a goal condition, c_i a context guard, and a_i a behavior. Execution selects the highest applicable rule; switches as beliefs update from sensors.
• Declarative mission example:
  • Goal: did_survey(zone_a) ∧ at_depth(surface).
  • Numerics: zone_a → {polygon coordinates}, surface → {depth = 0 m}.
  • The planner infers steps: descent ⇒ calibration ⇒ survey(tracklines(zone_a)) ⇒ ascent, grounding symbols via the numerics database.

In sum, DINOS-R embodies an AUCS by combining symbolic cognitive planning with teleo-reactive execution, delivering explainable, resilient autonomy for deep-sea AUVs. It unifies mission-level reasoning, reactive safety, and operator retasking in a single Python-based framework, demonstrated in simulation and field trials on Sentry, and designed for extensibility, non-expert usability, and formal verification advances.