Software overview

This section is the core of the site. It maps the open-source software that ROS developers use on marine vehicles, says which projects are maintained, and records the conventions and pitfalls that differ from land robotics.

109Projects tracked

76Support ROS 2

24Simulators

79Active in last 12 months

Find what you need

• Package catalog

  Search and filter every tracked project in one view.

• Autonomy frameworks

  Full stacks such as Blue, Project11, MVP, Orca, and SMaRC 2, plus non-ROS suites (MOOS-IvP, DUNE).

• Simulation

  Gazebo, Stonefish, Unreal, Unity, and Isaac Sim based simulators, with a selection guide.

• Drivers and interfaces

  ROS 2 driver status by sensor vendor, and the marine_msgs message set.

• Frames and conventions

  REP 103 and REP 105 on a vessel, ENU and NED, heading, depth, and time.

• Control and allocation

  Thrust allocation, station keeping, path following, and known issues.

• Localization and navigation

  DVL and INS dead reckoning, acoustic fixes, GNSS, and EKF tuning.

• Perception and mapping

  Sonar and camera processing, underwater SLAM, and bathymetry.

• Communication

  Acoustic modems, satellite, and middleware for slow or intermittent links.

• Tools and workflows

  Logging, visualization, geodesy, CI, and containers.

• Integration examples

  Reference architectures, EKF configurations, and launch patterns.

• Quick reference

  One-page cheat sheet for experienced developers.

The reference software stack

Most ROS 2 marine vehicles use the same layers. The package names are common choices, not requirements.

flowchart TB
  subgraph topside["Topside / shore"]
    OPS["Operator UI<br/>QGroundControl · CAMP · RViz · Lichtblick"]
  end
  subgraph vehicle["Vehicle computer (ROS 2)"]
    direction TB
    MISSION["Mission and behaviors<br/>mvp_mission · Nav2 BT · MOOS-IvP helm"]
    GUID["Guidance<br/>LOS path following · waypoint control"]
    CTRL["Control<br/>auv_controllers · ros2_control"]
    ALLOC["Thrust allocation<br/>thruster_manager · mvp_control"]
    EST["State estimation<br/>robot_localization · fuse"]
    DRV["Drivers<br/>DVL · INS · depth · GNSS · sonar · camera"]
    LOG["Logging<br/>rosbag2 (MCAP)"]
  end
  AP["Autopilot (optional)<br/>ArduSub · ArduPilot Rover · PX4"]
  HW["Thrusters · servos · ESCs"]

  OPS <-- "RF / tether / acoustic" --> MISSION
  MISSION --> GUID --> CTRL --> ALLOC
  DRV --> EST --> GUID
  EST --> CTRL
  ALLOC --> HW
  ALLOC -. "or via MAVLink" .-> AP --> HW
  DRV --> LOG

Two integration styles are common:

ROS 2 does the controlAn autopilot does the control

ROS 2 nodes compute control and thrust allocation and send commands straight to the ESCs or motor controllers, often through ros2_control. This gives full control over the algorithms. Blue with auv_controllers and MVP work this way.

An autopilot (ArduSub, ArduPilot Rover, or PX4) runs the low-level control and the failsafes. ROS 2 sends setpoints through mavros or the autopilot's DDS interface. This is the quick way to automate a BlueROV2 or a BlueBoat. Orca4 and Orca5 work this way.

How maritime software differs from land robotics

Topic	On land	At sea	Where to read more
Position	GNSS, lidar, or wheel odometry are available	No GNSS underwater. Dead reckoning from DVL and INS drifts; acoustic fixes are slow and noisy	Localization
Frames	ENU world, FLU body (REP 103)	Vendors and textbooks use NED and FRD; depth is positive down	Conventions
Communication	Wi-Fi or LTE at Mb/s	Acoustic links carry tens of bit/s to tens of kbit/s, with seconds of latency	Communication
Actuation	Wheels with direct kinematics	Over-actuated thruster sets, saturation, dead zones, and currents	Control
Perception	Cameras and lidar	Turbidity limits cameras; sonar is the main long-range sensor	Perception
Testing	Test on the bench or in the lab	Pool, lake, and sea time is expensive, so most testing happens in simulation	Simulation

Maintenance at a glance

Activity labels come from repository commit history and refresh every week. Treat them as a starting point, not a quality rating: read the issues, CI status, and release notes before you depend on a package.

Active commit within 12 months Low activity within 3 years Dormant older Archived read-only