---
title: MBZIRC Maritime Simulator
url: https://www.emergentmind.com/topics/mbzirc-maritime-simulator
type: topic
---

# MBZIRC Maritime Simulator

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 [2406.03223], [2601.13096]. 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` [2406.03223]. 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 [2601.13096]. 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 [2406.03223], [2601.13096]. 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 [2406.03223]. 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 [2601.13096].

## 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 [2406.03223]. The 2026 study mentions Gazebo explicitly, but does not specify whether the exact version is Gazebo Classic or Ignition [2601.13096]. 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 [2601.13096]. UAV flight is modeled with sufficient fidelity for aerial inspection and landing on a stationary deck [2601.13096]. The 2024 study further states that the simulator allows the simulation of different wave conditions according to the World Meteorological Organization sea state code [2406.03223].

The 2024 study ties wave condition configuration to “About WMO Code Table 3700,” indicating that sea conditions are parameterized by sea state levels [2406.03223]. 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 [2406.03223]. Similarly, the 2026 study reports waves, currents, and wind, but does not provide quantitative weather ranges or sea-state codes for its inspection scenarios [2601.13096].

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 [2406.03223], [2601.13096]. 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 [2601.13096]. 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 [2601.13096]. 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 [2601.13096].

ROS2 is the primary middleware stack, paired with Nav2 for USV navigation [2601.13096]. SITL/autopilot integrations such as PX4 or ArduPilot are not reported; instead, control is implemented via custom PID-based controllers [2601.13096]. 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 [2406.03223].

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 [2601.13096]. 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 [2601.13096]. The USV provides differential thrust actuation and station-keeping to serve as a mobile base for UAV operations and landing [2601.13096].

The UAV is modeled as a point mass in planning, with inner-loop attitude control abstracted away [2601.13096]. 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 [2601.13096]. Landing assumes that the USV is stationary at a known deck pose when the UAV initiates a fixed descent trajectory [2601.13096].

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 [2601.13096].

## 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 [2406.03223]. 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 [2406.03223].

Training is reported to have been performed in the PyBullet dynamic simulator, while testing was conducted in the MBZIRC maritime simulator [2406.03223]. 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 [2406.03223].

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 [2406.03223]. 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 [2406.03223].

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 [2601.13096]. 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 [2601.13096]. Buoys, signage, pipelines, and compliance markers are not specifically listed [2601.13096].

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 [2601.13096]. 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 [2601.13096].

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 [2601.13096]. Mission formulation is given as the tuple
$$
\langle M, P_{env}, K, A \rangle,
$$
where $M$ is the natural-language mission description, $P_{env}$ the environment state, $K$ the operational knowledge, and $A$ the action space [2601.13096]. The LLM mapping is formalized as
$$
\mathcal{L}: \mathcal{M} \times \mathcal{P}_{env} \times \mathcal{K} \mapsto \pi.
$$

Each action is represented as
$$
\tau_i = \{a_i(\mathcal{R}, \{\theta_i\}, \{\sigma_i\}), p_i\},
$$
where $a_i \in A$, $\theta_i$ encodes geometric and temporal parameters, $\sigma_i$ carries sensor configurations and inspection queries, and $p_i$ are preconditions [2601.13096]. The system builds a directed acyclic graph whose nodes are the actions $\tau_i$ and whose edges encode precedence constraints and inter-robot spatial dependencies [2601.13096]. Execution uses topological sorting, actions become ready when their preconditions are in `completed_steps`, and parallel execution is permitted if spatial conflicts are absent [2601.13096]. The paper illustrates a recovery chain:
`FlyTo(UAV, HoverPointAboveUSV) → LandOnUSV(UAV, USVDeck) → GoHome(USV, PortDock)` [2601.13096].

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

Semantic inspection is formalized as
$$
\mathcal{V}: \mathbf{I} \times \mathcal{M}_{inspect} \mapsto \mathcal{R}_{inspection},
$$
where image data and a mission-specific prompt are mapped to a structured, human-readable inspection report [2601.13096]. The VLM pipeline supports open-vocabulary detection and compliance checks related to cranes, workers, vehicles, sailboats, and vessels within port zones [2601.13096]. LiDAR is used for SLAM and navigation rather than for the VLM pipeline [2601.13096].

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 [2601.13096]. 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 [2601.13096]. The same paper states that Qwen2-VL and Moondream2 show stronger semantic reasoning, with Moondream2 offering the best speed–accuracy balance [2601.13096].

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 [2601.13096]. 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 [2601.13096].

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 [2406.03223]. 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 [2601.13096].

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` [2406.03223], [2601.13096]. The 2026 paper further states that full data for benchmarks will be made public upon acceptance [2601.13096]. Nevertheless, simulator asset packs, ROS2 launch configurations, topic schemas, and licensing terms are not specified in the paper text [2601.13096].

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 [2601.13096]. 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 [2601.13096].

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 [2406.03223], [2601.13096].

Source: https://www.emergentmind.com/topics/mbzirc-maritime-simulator