MBZIRC Maritime Simulator

• MBZIRC Maritime Simulator is a ROS2-based open-source platform that models realistic maritime environments for autonomous surface vessels and UAVs.
• It incorporates hydrodynamic, hydrostatic, and environmental disturbance models (waves, currents, wind) to evaluate closed-loop perception and control systems.
• The simulator supports heterogeneous operations including dockside manipulation, reinforcement learning, and integrated mission planning with LLM and VLM frameworks.

Searching arXiv for papers on the MBZIRC Maritime Simulator and related maritime robotics uses. The MBZIRC Maritime Simulator is an open-source maritime robotics simulation environment used to model intervention and inspection tasks involving autonomous surface vessels and aerial robots in port-like settings. In the literature considered here, it is described as a realistic, ROS2-based platform implemented in C++ and Python, associated with the Mohamed Bin Zayed International Robotics Competition and built on the Gazebo simulation stack, with capabilities that include hydrodynamic and hydrostatic behaviors for surface vessels, environmental disturbances such as waves, currents, and wind forces, and sufficient UAV fidelity for aerial inspection and landing on a stationary deck (Nader et al., 2024, Din et al., 19 Jan 2026). Its reported uses span dockside object manipulation under wave disturbances and heterogeneous UAV–USV port inspection with LLM-driven planning and VLM-based semantic perception.

1. Provenance, scope, and positioning

The simulator is referenced in one study as the “MBZIRC Maritime Grand Challenge Simulator” developed by Open Robotics, with a cited repository at https://github.com/osrf/mbzirc?tab=readme-ov-file (Nader et al., 2024). In another study, it is described more generally as the “MBZIRC Maritime Simulator,” an open-source, ROS2-based platform implemented in C++ and Python and originally developed for MBZIRC (Din et al., 19 Jan 2026). The specific MBZIRC edition is not explicitly specified in the latter work.

Its scope, as represented in these sources, is to emulate maritime scenarios relevant to intervention tasks in and around ports and mariculture sites, including operations near docks and in realistic port infrastructure (Nader et al., 2024, Din et al., 19 Jan 2026). The simulator is positioned as a testbed for autonomous surface vessel behaviors, dockside manipulation, aerial inspection, and coordinated UAV–USV operations. This suggests that the simulator’s main research role is not merely visualization, but closed-loop evaluation of robot perception, control, and mission execution in disturbance-rich maritime environments.

The 2024 object-manipulation study characterizes the simulator as a realistic maritime environment used for testing a trained deep reinforcement learning policy under sea-wave disturbances (Nader et al., 2024). The 2026 port-inspection study uses it as the core testbed for a broader autonomy stack comprising symbolic mission planning, dependency-graph execution, navigation, semantic inspection, and coordinated recovery behaviors such as UAV landing on a USV deck (Din et al., 19 Jan 2026).

2. Simulation stack and environmental fidelity

The simulator is associated with the Ignition Gazebo/Gazebo Sim stack through citations to “ignition gazebo” and gazebosim.org, implying support for physics, 3D rendering, sensor simulation, and plugin-based extensibility (Nader et al., 2024). The 2026 study mentions Gazebo explicitly, but does not specify whether the exact version is Gazebo Classic or Ignition (Din et al., 19 Jan 2026). Across the two papers, the common picture is that MBZIRC maritime scenarios are constructed on Open Robotics tooling and integrated with ROS2 middleware.

Baseline environmental fidelity, as explicitly described in the 2026 study, includes modeling hydrodynamic and hydrostatic behaviors for surface vessels together with environmental disturbances such as waves, currents, and wind forces (Din et al., 19 Jan 2026). UAV flight is modeled with sufficient fidelity for aerial inspection and landing on a stationary deck (Din et al., 19 Jan 2026). The 2024 study further states that the simulator allows the simulation of different wave conditions according to the World Meteorological Organization sea state code (Nader et al., 2024).

The 2024 study ties wave condition configuration to “About WMO Code Table 3700,” indicating that sea conditions are parameterized by sea state levels (Nader et al., 2024). At the same time, that study does not provide significant wave height values, peak periods, wave spectra, or sea-surface-elevation equations, and therefore the exact wave model and parameterization cannot be reconstructed from the paper alone (Nader et al., 2024). Similarly, the 2026 study reports waves, currents, and wind, but does not provide quantitative weather ranges or sea-state codes for its inspection scenarios (Din et al., 19 Jan 2026).

A recurrent limitation across both sources is incomplete disclosure of low-level simulator configuration. Specific plugins, fidelity settings, noise models, hydrodynamic couplings, and version tags are not reported in the provided text (Nader et al., 2024, Din et al., 19 Jan 2026). A plausible implication is that reproducible use of the simulator depends substantially on external repository documentation rather than on paper text alone.

3. Robot platforms, sensing, and control abstractions

The simulator supports both a USV and a multirotor UAV in the 2026 inspection framework (Din et al., 19 Jan 2026). Typical USV sensing includes a camera, IMU, and a 270-degree LiDAR used for obstacle detection, localization, SLAM, and occupancy grid mapping, whereas the UAV uses a high-resolution RGB camera and IMU and relies on simulated pose data (Din et al., 19 Jan 2026). Thermal cameras and LiDAR on the UAV are not mentioned, and position estimation for the UAV is derived from the simulator rather than an external autopilot (Din et al., 19 Jan 2026).

ROS2 is the primary middleware stack, paired with Nav2 for USV navigation (Din et al., 19 Jan 2026). SITL/autopilot integrations such as PX4 or ArduPilot are not reported; instead, control is implemented via custom PID-based controllers (Din et al., 19 Jan 2026). The 2024 study also cites ROS 2, suggesting simulator integration through ROS2 messaging, sensors, and control, although it does not describe topics, services, or APIs used for interaction (Nader et al., 2024).

The USV model used in the 2026 study is a high-level differential-drive-style kinematic abstraction with PID control for trajectory tracking, and it neglects sway and heave for planning (Din et al., 19 Jan 2026). The state and dynamics are reported as

$$x_s = [x_s, y_s, \psi_s, v_s]^T,\qquad u_s = [a_s, r_s]^T,$$

with

$$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$

Global path planning uses A* over the occupancy grid, and local tracking uses PID on linear and angular velocity (Din et al., 19 Jan 2026). The USV provides differential thrust actuation and station-keeping to serve as a mobile base for UAV operations and landing (Din et al., 19 Jan 2026).

The UAV is modeled as a point mass in planning, with inner-loop attitude control abstracted away (Din et al., 19 Jan 2026). The reported state and control are

$$x_a = [x_a, y_a, z_a, \psi_a]^T,\qquad p_a = [x_a, y_a, z_a]^T,\qquad u_a = [u_{a,x}, u_{a,y}, u_{a,z}]^T,$$

with

$$\ddot{\mathbf{p}}_a = \mathbf{u}_a,\qquad \mathbf{u}_a \in \mathbb{R}^3,$$

or componentwise,

$$\ddot{x}_a = u_{a,x},\qquad \ddot{y}_a = u_{a,y},\qquad \ddot{z}_a = u_{a,z}.$$

Yaw is controlled by a separate yaw-rate loop, and the control architecture uses cascaded PID with inner-loop attitude and outer-loop position control (Din et al., 19 Jan 2026). Landing assumes that the USV is stationary at a known deck pose when the UAV initiates a fixed descent trajectory (Din et al., 19 Jan 2026).

These abstractions matter because they define the scope of fidelity actually exercised by the reported autonomy results. The 2026 paper explicitly notes that more realistic six-DOF vessel dynamics, deck motion, wave coupling, and gust models would strengthen robustness (Din et al., 19 Jan 2026).

4. Use in dockside manipulation and reinforcement learning

In the 2024 study, the simulator is used in a workflow for maritime object manipulation from a dock in the presence of disturbances caused by sea waves (Nader et al., 2024). The proposed learning algorithm is Soft Actor-Critic, described as employing an actor-critic framework in which the actors learn a policy that minimizes an objective function while the critic evaluates the learned policy and provides feedback to guide the actor-learning process (Nader et al., 2024).

Training is reported to have been performed in the PyBullet dynamic simulator, while testing was conducted in the MBZIRC maritime simulator (Nader et al., 2024). The same paper states that the simulator allows different wave conditions according to the WMO sea state code and reports that the trained agent achieved an 80 percent success rate when applied in the simulation environment in the presence of waves characterized by sea state 2 (Nader et al., 2024).

For completeness, the paper reproduces the standard SAC objective equations from the cited work:

$$J_\pi = E_{s\sim D, a\sim \pi}[ \alpha \cdot \log \pi(a|s) - Q(s,a) ],$$

$$J_Q = E_{(s,a,s')\sim D}[ 0.5 \cdot ( Q(s,a) - ( r + \gamma \cdot V(s') ) )^2 ],$$

$$V(s) = E_{a\sim\pi}[ Q(s,a) - \alpha \cdot \log \pi(a|s) ].$$

However, the study does not map these equations to MBZIRC-specific rewards, action spaces, observation vectors, or simulator configurations (Nader et al., 2024). It also does not provide concrete dock geometry, object assets, manipulator model details, control frequency, simulation step size, time horizon, or termination conditions for the MBZIRC scenario (Nader et al., 2024).

This creates an asymmetry in the literature: the simulator is explicitly used as a realistic evaluation environment for RL-based manipulation, but the paper provides only high-level information about the scenario. A plausible implication is that MBZIRC serves in this context primarily as a disturbance-rich transfer environment rather than as a fully specified benchmark in the paper itself.

5. Extension to autonomous port inspection

The 2026 study substantially extends the simulator for autonomous maritime port inspection by a heterogeneous UAV–USV team (Din et al., 19 Jan 2026). New virtual port assets include a harbor basin, central docking stations, multiple small boats, cargo ships, ship-loading cranes, ground vehicles such as trucks and forklifts, and stacked shipping containers (Din et al., 19 Jan 2026). Buoys, signage, pipelines, and compliance markers are not specifically listed (Din et al., 19 Jan 2026).

At the planning level, the port is formalized as a bounded domain with static and dynamic obstacles:

$$P \subset \mathbb{R}^3,\qquad O_s = \{o^s_1,\ldots,o^s_n\},\qquad O_d = \{o^d_1(t),\ldots,o^d_m(t)\}.$$

The team produced SLAM maps from USV LiDAR occupancy grids and planned A* paths around docking areas, cranes, and container stacks (Din et al., 19 Jan 2026). The paper’s examples include central docking zone inspections by the UAV near home, crane work-zone inspections in which the USV transports the UAV and the UAV performs a 360-degree orbit, and container-stack inspections in which the USV deploys the UAV and the UAV flies a rectangular path (Din et al., 19 Jan 2026).

The simulator is therefore used not only as a vehicle dynamics environment but also as a mission-level testbed for mixed static-dynamic maritime infrastructure. This suggests an expanded role for MBZIRC as a systems-integration environment where navigation, deployment logistics, inspection geometry, and recovery sequencing can all be exercised in one world model.

6. Mission planning, semantic inspection, and execution middleware

The 2026 framework integrates an LLM-driven planner, a dependency-graph execution layer, and a VLM-based semantic inspector within the simulator (Din et al., 19 Jan 2026). Mission formulation is given as the tuple

$\langle M, P_{env}, K, A \rangle,$

where $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$0 is the natural-language mission description, $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$1 the environment state, $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$2 the operational knowledge, and $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$3 the action space (Din et al., 19 Jan 2026). The LLM mapping is formalized as

$$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$4

Each action is represented as

$$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$5

where $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$6, $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$7 encodes geometric and temporal parameters, $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$8 carries sensor configurations and inspection queries, and $$\dot{x}_s = v_s\cos\psi_s,\qquad \dot{y}_s = v_s\sin\psi_s,\qquad \dot{\psi}_s = r_s,\qquad \dot{v}_s = a_s.$$9 are preconditions (Din et al., 19 Jan 2026). The system builds a directed acyclic graph whose nodes are the actions $$x_a = [x_a, y_a, z_a, \psi_a]^T,\qquad p_a = [x_a, y_a, z_a]^T,\qquad u_a = [u_{a,x}, u_{a,y}, u_{a,z}]^T,$$0 and whose edges encode precedence constraints and inter-robot spatial dependencies (Din et al., 19 Jan 2026). Execution uses topological sorting, actions become ready when their preconditions are in completed_steps, and parallel execution is permitted if spatial conflicts are absent (Din et al., 19 Jan 2026). The paper illustrates a recovery chain: FlyTo(UAV, HoverPointAboveUSV) → LandOnUSV(UAV, USVDeck) → GoHome(USV, PortDock) (Din et al., 19 Jan 2026).

Safety is enforced through preconditions and conflict checks in the Communication Manager rather than through an explicit optimization with separation constraints or geofencing equations (Din et al., 19 Jan 2026). The framework supports re-planning when obstacles change or communications degrade, although latency, bandwidth, and packet-drop models are not reported (Din et al., 19 Jan 2026).

Semantic inspection is formalized as

$$x_a = [x_a, y_a, z_a, \psi_a]^T,\qquad p_a = [x_a, y_a, z_a]^T,\qquad u_a = [u_{a,x}, u_{a,y}, u_{a,z}]^T,$$1

where image data and a mission-specific prompt are mapped to a structured, human-readable inspection report (Din et al., 19 Jan 2026). The VLM pipeline supports open-vocabulary detection and compliance checks related to cranes, workers, vehicles, sailboats, and vessels within port zones (Din et al., 19 Jan 2026). LiDAR is used for SLAM and navigation rather than for the VLM pipeline (Din et al., 19 Jan 2026).

The study reports quantitative VLM evaluation on UAV and USV streams in simulation and real data. Qwen2-VL attains semantic correctness of approximately 83.3% on UAV-Sim and USV-Sim, 82.7% on UAV-Real, and 84.5% on USV-Real, with inference time of approximately 0.59–0.62 s (Din et al., 19 Jan 2026). Moondream2 attains approximately 82.5%, 81.7%, 80.4%, and 83.3% semantic correctness, with inference time of approximately 0.26–0.31 s and the fastest load time of about 3.6 s (Din et al., 19 Jan 2026). The same paper states that Qwen2-VL and Moondream2 show stronger semantic reasoning, with Moondream2 offering the best speed–accuracy balance (Din et al., 19 Jan 2026).

The LLM-planning component is also benchmarked. Reported average response times are approximately 8.44 s for GPT-4o, 8.74 s for GPT-3.5-Turbo, 14.46 s for GPT-4, 13.56 s for Gemini, and 10.7 s for LLaMA (Din et al., 19 Jan 2026). Reported average correctness values are 94.3, 93.2, 93.1, 84.7, and 42.7 respectively, while average execution success percentages are 86.0, 84.0, 81.0, 72.3, and 32.4 (Din et al., 19 Jan 2026).

These results locate the simulator within a contemporary autonomy pipeline that combines symbolic planning, classical navigation, and multimodal semantic reasoning. The simulator’s significance here lies in providing the environmental dynamics, robot embodiments, and middleware hooks needed to test those components in coordinated maritime scenarios rather than in isolation.

7. Reproducibility, limitations, and research significance

Both papers reveal a tension between broad simulator capability and limited paper-level reproducibility. The 2024 study does not provide scenario configuration files, meshes, dock geometry, object properties, action and observation spaces, sensor payload definitions, noise or latency models, hydrodynamic details, SAC hyperparameters, or MBZIRC-specific reward design (Nader et al., 2024). The 2026 study adds considerably more system detail, but still does not list ROS topics, services, actions, message schemas, launch files, plugin names, model file paths, hardware requirements, autopilot SITL integrations, exact Gazebo version, camera intrinsics or extrinsics, or detailed communication models (Din et al., 19 Jan 2026).

The public artifacts cited in the literature include the Open Robotics MBZIRC repository and a project repository for the LLM–VLM inspection framework, with code and videos at https://github.com/Muhayyuddin/LLM-vlm-fusion-port-inspection (Nader et al., 2024, Din et al., 19 Jan 2026). The 2026 paper further states that full data for benchmarks will be made public upon acceptance (Din et al., 19 Jan 2026). Nevertheless, simulator asset packs, ROS2 launch configurations, topic schemas, and licensing terms are not specified in the paper text (Din et al., 19 Jan 2026).

The limitations explicitly noted in the 2026 work are substantial: USV planning neglects sway and heave; UAV planning uses a point-mass acceleration model with assumed perfect inner-loop tracking; landing assumes a stationary USV deck; camera intrinsics, extrinsics, sensor noise models, and rendering details are not specified; communication realism is qualitative; and large terminals, heavy traffic, and complex compliance workflows are not explored (Din et al., 19 Jan 2026). The paper proposes future work on adaptive mission planning under dynamic environmental conditions, model compression for on-device inference, additional sensing modalities such as hyperspectral sensing, and long-term real sea trials (Din et al., 19 Jan 2026).

Taken together, the available literature portrays the MBZIRC Maritime Simulator as a maritime robotics environment whose practical value derives from three linked properties: disturbance-aware maritime world modeling, heterogeneous robot support, and ROS2-centered integration with higher-level autonomy software. At the same time, the papers show that many simulator details remain externalized to repositories or unstated, so careful interpretation is required when treating reported results as benchmark-comparable across studies (Nader et al., 2024, Din et al., 19 Jan 2026).