ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Common message structures for UUVs?


#1

Hi everyone,

following the discussion started by @narcispr in this proposal to include DVL messages to the sensor_msgs package (https://github.com/ros/common_msgs/issues/116), I would like to ask if there are other implementations of ROS message/service structures out there of typical sensors for maritime robotics.
At the beginning of the implementation of our simulation environment it was a little difficult finding a standard (or any standard) in that matter, and in the end we ended up setting our own, but that becomes an issue later on regarding compatibility and portability. It could also be the case that I was uninformed about something that already exists, but until now couldn’t find nothing really close to a common ground.
I think starting to converge to a structure that can be used by several projects, as @narcispr suggested , would help avoid every single new project setting up the messages and services all over again.


BTS 2018 workshop: adoption of conventions in the underwater ROS community
#2

Hi @musamarcusso, I think that most of the sensor related messages that the underwater community uses are covered by the sensor_msgs package except for very specific ones like the DVL, the Side Scan Sonar or the USBL.

I don’t know any other standard repository specific for underwater sensors, but I think that if we have to define only few new messages, we can add them directly in the sensor_msgs package.

For me, the most prioritary messages are the DVL and the Side Scan Sonar. For the Multibeam we can always use a LaserScan msg. Which messages you think we should start with?


#3

Hi @narcispr, both DVL and side scan sonar messages could be proposed to the common_msgs repository if we find some examples.
You mentioned for DVL these links below, but it would be good to know what is used to narrow down to one solution.


#4

The first example (UWSim) is a very specific DVL message for an RDI DVL while the second (uuv_simulator) for me is more generic. The only problem that I see with the second is that most of DVL sensors can provide measurements wrt. sea bottom or/and wrt. water. However, changing the velocity_covariance or publishing two topics (one for bottom and another for water measurements) will be enough.

We could start the discussion using the (uuv_simulator) as a base. For the Side Scan Sonar, and example can be found at SSS msg.


#5

I disagree that common messages have us well-covered. The UAV community is going through a broader discussion to drive towards a common ROS API. Perhaps something similar here is appropriate? Especially given the sudden spike in interest for maritime robotics. There are enough unique sensors for a UUV-specific sensors package.

The existing LaserScan message is a start, but it would help to have beam widths. Most multibeams offer both equiangular and equidistant spacing, and LaserScan (like most laser scanners) only supports equiangular spacing. Some larger multibeams also do real-time yaw compensation that results in non-coplanar beams. Sure, we could use a pointcloud, but most existing multibeam post-processing software assumes a constant number of beams with a quality indicator. Launch angles are helpful if you ever want to re-raytrace your data.
And that’s just for bathymetric multibeams. An R-Theta image would be really handy for imaging multibeams (BlueView P900, Kongsberg M3, etc).

The vehicle I am currently helping to transition to ROS will require messages for: DVL, depth, subbottom profiler, two different sidescans, multibeam imaging sonar, multibeam swath sonar, inertial navigation system, one- and two-way travel-time measurement, USBL fixes, CTD, sound velocity, and a generic scalar water-column measurement (ph, oxidation reduction potential, fluorescence, dissolved oxygen, optical backscatter, whatever the instrument guys down the hall gin up next month). Some of those can re-use existing messages, but there’s enough there to propose a UUV-specific sensors package. That’s just us. Other teams will need bathymetric side-scan, scanning imaging sonars, and tons more even before adding unique situations like in-situ mass spectrometry, custom sampling gear, etc that should be handled in their own packages.


#6

Hi @musamarcusso, regarding your question, there is already and ros package for underwater robotics: auv_msgs . If you think this maybe be helpful, we are happy to discuss ways to improve the current package to fit everyone’s needs.


#7

Hi @ivaughn. I agree that there are plenty of messages that can be defined for the underwater robotics community. However, defining messages is the tip of the iceberg! For instance, I agree that a better multibeam message could be defined, however, to see the multibeam data in reat time using a laserscan message is already done but if a new message is defined this functionality must be reimplemented. What I want to say is that maybe, and only maybe, a good solution can be to add the very basic messages in the sensor_msgs package as soos as possible, and have a deeper discussion about all the rest. We are also interested in most of the message that you propose. I put a list of them and our current implementacion FYI:

  • DVL (custom)
  • depth (sensor_msgs/FluidPressure)
  • Sidescan Sonar (custom)
  • Multibeam Sonar (sensor_msgs/laser scan)
  • inertial navigation system (sensor_msgs/IMU + nav_msgs/Odometry + …)
  • One- and two-way travel-time measurement (custom)
  • USBL fixes (geometry_msgs/PoseWithCovarianceStamped)
  • CTD (custom)
  • sound velocity (custom)
  • water-column measurement (custom)
  • Battery System (sensor_msgs/BatteryState)
  • Cameras (sensor_msgs/CameraInfo)
  • GPS (sensor_msgs/NavSatFix)
  • …

#8

Hi @Icarlucho, I had found the auv_msgs back then, but I understood that they were to be used on a higher level for the vehicles, not on the sensor level, or did I miss something there?


#9

Hi @ivaughn, do you know how the UAV community is planning to implement their solutions for a common ROS API? It wouldn’t be a bad idea to learn from them in that aspect.


#10

The discussion seems to be centered around a discussion thread: Proposed standard interface for aerial vehicles in ROS

Many common UAV messages are already available in the std_msgs package, so it looks like effort has focused on developing REPs (105, then 147) to codify best-practices.

This discussion is showing that ROS is less mature for underwater vehicles-- which makes sense, that thread is older than the marine robotics SIG! Presumably some combination of REPs and AUV-specific message standardization is required. Some code development for rviz plugins and/or common drivers would really help drive adoption.

I’m just concerned that if ROS adopts a few messages without broader community involvement we’ll continue a lot of very isolated development. We just wrote yet another RDI DVL parser because none of the existing messages-- including the one proposed-- meets our needs. We’re at least the second group well-suited to being long-term maintainers of such a package to do that in the last 18 months.

Maybe we should try to identify a venue for an underwater robotics ROS workshop? A lot of the new stakeholders are new to open-source software, not just ROS. Many of them don’t even comment on the mailing list.


#11

I think a workshop is a great idea. Like you said, if just a few people contribute their implementations the problem isn’t going to be solved. Maybe it would be possible to organize a workshop in some of the upcoming robotics conference/events?


#12

Hi, well the auv_msgs was indeed to be used on a higher level, but we can consider if it is possible to expand the functionality. I don’t know what other people think but it might be a good idea to have everything in one message package? or maybe not, but it might be worth discussing the possibility at least.
If you want we can open an Issue in the github page and take if from there.


#13

Some upcoming events that come to mind:

  • IROS 2018 - Madrid
  • ROSCon 2018 - Madrid (?) - I think it is not confirmed yet
  • Breaking the Surface - Biograd na Moru, Croatia
  • Maritime RobotX - Hawaii, US

I don’t know how it could work to organize something like a workshop alongside any of these events (I think in Breaking the Surface it can be still proposed to organize a workshop session), if there is an interest from more people an workshop, it could still be done. All these events will happen from October to December of 2018.


#14

Our team (Universitat de Girona) use to participate/collaborate in Breaking the Surface. I can ask for a workshop session there if you want.


#15

Sorry for the late reply. I think that would be a great idea. I don’t know anymore if I can attend, but would be worth trying to organize something.


#16

Today we have send a workshop proposal for the next Breaking The Surface workshop. The idea is to have a session there in which we can start discussing at least which messages should be included in a underwater or marine sensor_msgs like package. If possible we will create a first draft to be later discussed online.