Marine Vehicle Packages (MVP) Framework

• Marine Vehicle Packages (MVP) are an open-access modular framework that unifies hardware drivers, power distribution, and ROS-based guidance to support various AUV designs.
• MVP enables reconfigurable integration across different vehicle platforms by using uniform source code and configurable interfaces rather than requiring unique hardware designs.
• MVP balances cost-effectiveness and robust functionality through modular electronics, articulated thruster allocation, and a comprehensive control and autonomy stack.

Marine Vehicle Packages (MVP) is an open-access, modular framework for building and operating autonomous underwater vehicles (AUVs) in which embedded electronics, power distribution, communication interfaces, sensing and computing infrastructure, and a ROS-based guidance-navigation-control stack are packaged into a reusable hardware/software system that can be installed on different vehicle forms with only configuration changes (Zhou et al., 29 Sep 2025). In the specific formulation introduced in "Towards Modular and Accessible AUV Systems" (Zhou et al., 29 Sep 2025), MVP is aimed at the small-to-medium AUV regime, with enough payload and endurance for scientific missions but at an approximate cost of about $20k per AUV rather than the $100k scale associated with small/medium commercial off-the-shelf systems. A broader package-oriented reading is also suggested by adjacent marine robotics literature, which repeatedly treats operational capability as the composition of vehicle platform, payload, communication, localization, power, autonomy, and support infrastructure rather than as a hull alone (Xu et al., 2024).

1. Definition, scope, and systems rationale

MVP is defined as both a hardware and software accessibility response to a persistent gap in marine robotics. On the hardware side, many AUVs are either tightly integrated around a specific hull and thruster arrangement or too space-constrained to support a meaningful research payload. On the software side, the paper situates MVP against the small number of broadly used AUV autonomy and GNC frameworks, explicitly noting that MOOS-IvP assumes lower-level localization and pose control already exist, while COLA2 is a ROS-based AUV GNC architecture that is licensed and tied to IQUA platforms (Zhou et al., 29 Sep 2025). MVP is therefore positioned as a ROS-native, open-source alternative intended to unify the stack from hardware drivers through guidance and autonomy while remaining general enough to support different AUV geometries and actuation layouts.

The framework’s main distinction is not a single new algorithm but a coherent end-to-end package architecture. This package logic is central: the same source code and hardware are intended to run across multiple vehicles, with differences represented mainly through configuration files, frame definitions, and interfaces rather than through code forks (Zhou et al., 29 Sep 2025). A common misconception is that MVP denotes a single vehicle design. In the primary source, however, the framework explicitly does not prescribe a single mechanical hull shape; it is instead a reusable package that can be installed across different AUV structures (Zhou et al., 29 Sep 2025).

This systems rationale connects MVP to a wider Smart Ocean interpretation in which vehicles are understood as integrated assemblies of platform, payload, communication stack, navigation and localization capability, power system, and support infrastructure (Xu et al., 2024). That broader literature does not standardize the term “MVP” in the narrow sense of the 2025 AUV framework, but it does reinforce the same package-level abstraction.

2. Hardware packaging and vehicle integration

The MVP hardware is compact, expansion-oriented, and explicitly organized around reusable electronics modules. In the reported implementation, the core electronics are arranged in a 300 mm long, 4-inch inner diameter Blue Robotics pressure housing, while batteries are placed in a separate 400 mm long, 4-inch inner diameter housing (Zhou et al., 29 Sep 2025). Three custom boards occupy the electronics pressure vessel. The power manager board distributes battery input to 5 V, 15 V, and raw battery voltage rails, includes current and voltage sensing circuits, and provides three 8 A MOSFET channels using Onsemi FDS8884 devices for software-switchable payload power. This design makes payload addition largely a matter of power-path connection plus driver implementation.

Computation is split into a front-seat/backseat arrangement. A Raspberry Pi 4 serves as the front-seat computer for guidance, navigation, control, and basic sensor drivers such as IMU and DVL, while a Jetson embedded computer acts as the backseat computer for computationally expensive functions such as camera and imaging sonar drivers, sensor-driven path planning, and computer vision (Zhou et al., 29 Sep 2025). Hardware portability is reinforced by a custom single-board-computer hat exposing two I2C buses and eight RS232 ports, with compatibility noted for other boards sharing the Pi GPIO layout. Actuation is handled by an RP2040-based board controlling thrusters and servos and communicating with the Pi 4 using NMEA strings; the MCU implements a safety timeout that stops the motors if the Pi stalls (Zhou et al., 29 Sep 2025).

The interface backbone is unusually rich for an academic AUV package. The vehicle electronics provide two 5-port Gigabit Ethernet switches from BotBlox, eight RS232 ports on the SBC hat, and reserved endcap connectors for USB and 10/100 Mbps devices (Zhou et al., 29 Sep 2025). Communications likewise span several layers: a single-twist-pair tether board, a DoodLabs 900 MHz / 2.4 GHz dual-frequency modem, and the developing mvp_acomm package for acoustic communication-based mission updates and monitoring using DCCL and Goby dynamic buffering (Zhou et al., 29 Sep 2025). The battery subsystem is similarly modular: a diode-array PCB rated at 30 A per channel allows up to four battery packs to be paralleled, and the recommended battery setup is four 18 V, 13.8 Ah Li-ion packs from MaxAmps, yielding roughly 1 kWh, with estimated endurance of about 2 hours at a 30 A current draw and up to 10 hours with moderate payload (Zhou et al., 29 Sep 2025).

This hardware philosophy is best understood as interface-rich packaging rather than hull-centric integration. It exposes a reusable internal backbone for sonars, DVLs, cameras, modems, and custom processors. That distinguishes it from monolithic research AUVs whose internal electronics must often be redesigned for each new payload suite.

3. Software architecture, control, and articulated actuation

The MVP software stack is ROS-based and divided into hardware interfaces, localization, control, guidance, autonomy, GUI tools, and simulation interfaces, with Stonefish used as the simulation backend (Zhou et al., 29 Sep 2025). At the lowest level, the hardware interface layer converts outputs from real sensors and simulators into standard ROS messages. Localization uses the robot_localization package’s Extended Kalman Filter to fuse GPS, DVL, and IMU, with tf2_ros accounting for sensor mounting offsets. The reported underwater position drift rate in field experiments is about 5% when combining DVL and IMU (Zhou et al., 29 Sep 2025).

The control layer, implemented in mvp_control, compares current vehicle pose against desired pose and computes commands using PID control plus quadratic-programming thruster allocation. The generalized wrench mapping is written as

$\boldsymbol{\tau} = \boldsymbol{M}\boldsymbol{F},$

and control allocation is solved by

$$\begin{array}{rl} \boldsymbol{F} = & \arg\min((\boldsymbol{\tau}^*-\boldsymbol{\tau})^T (\boldsymbol{\tau}^*-\boldsymbol{\tau})) \ & \text{s.t. } \boldsymbol{AF}\leq \boldsymbol{B}. \end{array}$$

A practical feature is that tf2_ros is used to automate generation of the thruster allocation matrix from frame definitions and mounting geometry, so thruster relocation or addition can be absorbed largely through frame-tree and configuration updates rather than controller rewrites (Zhou et al., 29 Sep 2025).

Guidance is organized around a finite-state machine in which each state can assign one control mode and multiple plugin-based behaviors such as path following, teleoperation, or surfacing. If multiple behaviors command the same degree of freedom, the higher-priority behavior wins (Zhou et al., 29 Sep 2025). Above guidance sits mvp_autonomy, which creates objectives such as waypoint lists and state changes from user actions or sensor outputs; example functions include path planners driven by sonar and acoustic systems for collision avoidance, coverage seafloor mapping, and AUV following, though the autonomy layer remains under development (Zhou et al., 29 Sep 2025).

One of MVP’s more distinctive technical contributions is its articulated-thruster allocation method. For an articulated thruster, the wrench contribution is modeled as

$$\boldsymbol{\tau}_k = \boldsymbol{M}_k \left[\begin{array}{c} X^k \ Y^k \end{array}\right],$$

with force components defined in the rotating thruster frame itself. The commanded thrust magnitude and angle increment are recovered as

$$F^k = \sqrt{X^k*X^k + Y^k*Y^k}, \qquad \Delta\alpha^k = \tan^{-1}(Y^k/X^k).$$

The paper explicitly motivates this as a tractable alternative to formulations whose forward/reverse possibilities would otherwise create $2^n$ solution cases for $n$ articulated thrusters (Zhou et al., 29 Sep 2025). The tractability gain comes from a positive-thrust-only assumption; this is a deliberate tradeoff rather than an attempt at universal actuation modeling.

The web-based mvp_gui is also architecturally significant. It is designed to eliminate terminal-centric operation and includes six pages for vehicle status, systems and tools, ROS node and topic inspection, power management of MOSFET channels, mission editing, and map-based waypoint interaction (Zhou et al., 29 Sep 2025). In package terms, this moves MVP beyond a code library toward an operator-facing operational stack.

4. Reconfigurability, validation, and demonstrated vehicle classes

The strongest empirical claim for MVP is that three different vehicles use “the same source code and hardware but with different configuration files” (Zhou et al., 29 Sep 2025). One vehicle uses two fixed thrusters plus two articulated stern thrusters. A second uses four thrusters—two vertical, one horizontal, and one main thruster—for hydrobatic or inspection-style motion. A third, configured for seafloor survey, uses a similar four-thruster layout and carries a Blueprint Subsea Oculus forward-looking imaging sonar and a DeepWater Exploration stellarHD machine-vision downward-looking camera (Zhou et al., 29 Sep 2025).

Simulation in Stonefish was conducted on the articulated-thruster vehicle using waypoint following through five 3D waypoints forming five line segments at different depths. The reported result is successful tracking of the waypoint path, with fast rise time and minimal steady-state error while simultaneously controlling surge, depth, roll, pitch, and yaw (Zhou et al., 29 Sep 2025). The paper also reports actuator spikes at line-segment transitions and near-surface oscillations attributed to a buoyancy-related issue when the desired depth was slightly shallower than the vehicle could physically reach.

The indoor tank experiment used the four-thruster hydrobatic vehicle in teleoperation mode. The vehicle tracked commanded surge, depth, heading, and pitch responsively, though the authors note a small steady-state pitch error, likely due to a small integral gain and increasing restoring moments at high pitch angles. Asymmetric pitch limits of approximately 50° nose-up and 80° nose-down were reported, while surge response was intentionally slow because proportional gain was kept low for the limited tank size (Zhou et al., 29 Sep 2025).

The field experiment used the seafloor-mapping vehicle near a shipwreck in Narragansett Bay at roughly 5 m depth. The paper reports effective heading tracking and depth-holding within a 0.1 m depth band while flying at about 0.5 m altitude as measured by the DVL (Zhou et al., 29 Sep 2025). A photomosaic generated in Metashape from downward-looking images, after color correction using a script based on Ancuti et al.’s underwater image enhancement method, also revealed accumulated dead-reckoning drift. An observed coupling in surge during diving was explained geometrically: with non-zero pitch and vertical thrusters producing downward thrust, the thrust vector acquired a forward component, causing non-zero surge (Zhou et al., 29 Sep 2025). This is important because it makes explicit that MVP’s generalized allocator does not eliminate vehicle geometry; it manages it.

5. Broader package-oriented patterns in marine robotics

Although the 2025 MVP framework provides the clearest formal definition, related works show that the package concept recurs across marine robotics. SeaShark, for example, is presented as a modular, one-man-portable micro-AUV built around a central main tube and a head unit of exchangeable, stackable, and 360° rotatable payload sections (Christensen et al., 2020). Its core/base split and mission-specific head configurations illustrate a payload-centric modularity model, albeit with navigation “no better than dead reckoning or relative navigation” (Christensen et al., 2020). At a different scale, the AFRL Jetyak shows a long-endurance ASV package organized as commercial hull plus autopilot layer, companion computing, communications layer, payload/power layer, and safety/fallback layer, with a universal underwater mounting plate and retained manual operation (Moulton et al., 2018).

Package logic also appears in deployment and support subsystems. The remotely-enabled modular release mechanism, or $(\mathrm{RM})^2$, is a low-cost add-on subsystem for autonomously deploying an AUV from an ASV, with a ROS node (RM2Node), serial command path, interchangeable mounting face plate, and a target assembled cost under $1K USD (Kutzke et al., 2024). This suggests that MVP need not be limited to the primary vehicle; deployment hardware can itself be packaged as a reusable marine subsystem.

In simulation and cooperative planning, tethered ASV–AUV work extends the same idea into coupled multi-robot packages. One framework uses GazeboSim, ROS 2, Docker, ArduPilot SITL, MAVLink bridging, and a hybrid catenary-plus-discrete tether model for tethered ASV–AUV simulation (Buchholz et al., 4 Aug 2025). CoralGuide goes further by combining catenary tether modeling, an enhanced A* planner, Bézier interpolation, and synchronized trajectories for tethered ASV–AUV systems, with zero reported collisions in its evaluated scenarios and controlled-tank validation (Buchholz et al., 4 Aug 2025).

Mission-specific package software is likewise emerging. PBACS frames rapid channel identification as a bathymetric package capability built from single-beam acoustic depth sensing, Fast Gaussian Process Regression, decentralized consensus, and path-proposal bidding in MOOS-IvP (Gershfeld et al., 2022). GPU-accelerated MDP planning in stochastic dynamic ocean flows provides another layer: an end-to-end planning package that builds transition models from uncertain flow forecasts and computes finite-horizon policies 600–1000x faster than conventional CPU implementations in the reported experiments (Chowdhury et al., 2021). Taken together, these works suggest that MVP is productively read not only as one AUV framework but also as a design pattern for reusable marine autonomy assemblies.

6. Limitations, misconceptions, and development trajectory

MVP’s accessibility claims are substantial but not unconditional. The primary paper is explicit that it does not provide a full 6-DOF rigid-body dynamic model; localization is described as baseline odometry using GPS, DVL, and IMU; mvp_autonomy and mvp_acomm are still under development; the SBC PCB is under revision; and the articulated-thruster method gains tractability by assuming positive thrust only (Zhou et al., 29 Sep 2025). A common misconception is therefore that modularity implies plug-and-play independence from vehicle-specific tuning. The paper states the opposite in practical terms: controller gains, allocation constraints, buoyancy trim, and configuration files still matter (Zhou et al., 29 Sep 2025).

Another misconception is that package-based marine systems are primarily software abstractions. In the MVP literature, hardware packaging is at least equally central. SeaShark’s rotatable payload sections, Jetyak’s universal underwater mounting plate, and $(\mathrm{RM})^2$’s swappable face plate and cradle each show that interface design, sealing, power distribution, and deployment logistics are part of the package itself (Christensen et al., 2020, Moulton et al., 2018, Kutzke et al., 2024). More broadly, survey work on underwater vehicles and Smart Ocean technologies suggests persistent system-level constraints around energy efficiency, communication limitations, localization, docking, environmental adaptability, and support infrastructure (Xu et al., 2024).

The development trajectory outlined for MVP is consistent with this broader systems view. The authors plan continued development and field validation of autonomy and acoustic communication modules, hardware revision of the SBC board, and a ROS 2 port; at the time of writing, the ROS 2 version is in beta, with a stable release expected for ROS Jazzy and Ubuntu 24.04 (Zhou et al., 29 Sep 2025). A plausible implication is that MVP is less a closed product than a living platform architecture. Its significance lies in showing that an open, ROS-centered, interface-rich AUV package can support multiple hulls, payload suites, and actuator layouts with minimal code changes while remaining affordable enough for broader research use (Zhou et al., 29 Sep 2025).