BTS Workshop: Adoption of Conventions in the Underwater ROS Community - A Summary

The 2nd of October we held a workshop inside Breaking The Surface conference on the Adoption of Conventions in the Underwater ROS Community. Almost thirty attendants from 16 different organizations participated in it. For all those who could not participate, but that are interested in the topics that were discussed, we present here a short summary of what we talked about.

The workshop had the following structure:

  • Introduction and participants presentation.
  • Survey: How do you use ROS underwater and what you miss from it?
  • Open discussion (using the survey results as a starting point).
  • Conclusions.

The discussion focused especially on the standardization of low-level messages that are specific to the marine environment, and also on the need for simulators and various tools.

  • Messages

    • Proposal to define new sensor messages for marine related sensors like: DVL, SVS, CTD, modem, USBL, sonars… Consider to put them inside sensor_msgs or in some underwater specific package (e.g. marine_sensor_msgs).
    • Proposal to define missing control messages like: Thrust, Waypoint, List of Waypoints, …
    • We also talked about other missing messages, that are not only marine related, like: landmark based maps, navigation, vehicle/mission status, etc.
  • Simulators:

    • uuv_simulator looks promising but no participant uses it in their daily routine. Problems defining dynamic parameters and issues between NED (i.e., North East Down standard underwater frame) and ENU (i.e., East North Up, standard Gazebo frame) were commented.
    • Problems to simulate perception sensors like sonars, acoustic communications, underwater images were also discussed.
    • There is no “generic” solution (i.e., stand alone package) to perform a dynamics simulation with or without Gazebo. Only UUV_Simulator plugin and several custom packages.
  • Tools:

    • Calibration tools (e.g., TFs, Magnetic Compass, DVL, Controllers …), are missing but will be easier once low level messages are standardized.
    • Lots of gateways requested: ROS-MOOS, ROS-DUNE, ROS-MATLAB…
    • Mission tools: There are no standard tools to define a mission.
    • RViz plugins for marine specific sensors like DVL, Side Scan, Imaging Sonars, … should be done.
  • Safety:

    • Solutions for checking node status
    • Create a list of typical safety errors related to the underwater vehicles to be checked (as a guideline).

We agreed to create a public repository where we can start defining the proposed messages. Once there is agreement on the messages we will decide whether to add them to any existing package (e.g., sensor_msgs, nav_msgs, …) or whether to create one or more new packages.

This same discussion repository can be used to create some safety guidelines: what a checklist should include, which dangerous situations can be detected automatically and how they can be handled…

This package has been created at: We encourage everybody to check it and add their comments, issues, pull requests, … We need as much feedback as possible to make it complete, generic and useful for the community.

Thank you!

1 Like

Great work! Are any of the participants planning to attend the upcoming ROS underwater workshop at Woods Hole? With a very similar agenda, I would hope that such efforts are coordinated.

Thank you!
I will attend the workshop at WHOI and try to present the results in one of the lightning talks.

Narcis, I know this is a little late, but after seeing the conventions discussion on GitHub, I wanted to comment/ask:

There are a lot of other conventions for other domains and specific implementations, but there aren’t a lot of definitive works on the overarching data model and specific conceptual data models that represent each ‘message’. See, e.g. [1], which is itself rather lacking in details.

The point is that by starting at the conceptual data model level, we could say “these are the details required to communicate concept X”, and then have something specific for ROS (or ROS2, if needed) that provides rules on how the conceptual data model is mapped into a specific message-specification format. The payoff is that you can change the way you map the CDM to the LDM, and be kind of ready for a whole new messaging system. You could even write adapters that convert from one to the other (LDM) realtime, auto-generating adapters between middlewares.

Should we (we == ROS/ROS maritime people) be thinking at this level? Or is there really not any interest from the academic/start-up side? From big corporate entities I think there is interest, especially when it comes to interoperable defense stuff.


[1] IEEE 1872-2015 Standard Ontologies for Robotics and Automation

Interesting reflection Thomas! To be honest, I get a little lost when I talk about ontologies and conceptual data models. I think it’s something we need to keep in mind. However, I think that for our community - which is quite small - it’s probably easier to start with something more specific and then try to generalize a conceptual data model to automatically expand and maintain the specific messages.