[Interfaces] AUV Standard Interfaces

[natrad100]

Background

As ros2 auv developers, we need a standard set of interfaces for generic AUV operations so that it is easier to integrate and developer for multiple platforms.

[arjo129]

@lauralindzey has been working on the following: https://github.com/apl-ocean-engineering/hydrographic_msgs She had presented this at the first maritime meeting. I think the next checklist we need to come up with is what are missing and various tools to visuallize things with.

[lauralindzey]

It's not just me working on those!

Kris Krasnosky (@captkrasno), Roland Arsenault (@rolker) and Val Schmidt have been collaborating on defining a set of messages in that repo.

• Kris has a 2D visualizer for imaging sonar data: https://github.com/CaptKrasno/acoustic_msgs_tools
• Roland has developed a rviz plugin for imaging sonar data: https://github.com/rolker/rviz_sonar_image

Additionally, Project Dave's imaging sonar simulator uses that message format: https://github.com/Field-Robotics-Lab/nps_uw_multibeam_sonar

[natrad100]

So UMAA have done a pretty in-depth job in this for both AUV and USV's - https://www.auvsi.org/unmanned-maritime-autonomy-architecture

They have an IDL setup which is very verbose but is certainly design to be a one for all approach - https://www.auvsi.org/sites/default/files/UMAA-3.0.1-IDL-DistroA.zip

Can anyone check to see what the licensing implications will be if this is a path we would follow?

[ndahn]

Judging from the license found in the zip file deriving from UMAA should be fine:

2.1.1 Notwithstanding the requirements of 2.1, the GOVERNMENT recognizes that you retain ownership and copyright in DATA or SOFTWARE that you develop through derivation of software from the WEBSITE. You retain your right to use, modify, release and display such DATA or SOFTWARE for your own purposes.

[natrad100]

Has anyone had any success with building these IDL's? There are a few features not implemented in ROS (union types etc) that require handling?

[ndahn]

Is there a tutorial or some documentation on how to build IDLs for ROS? I might take a look into this if no one beats me to it.

[natrad100]

I've done some digging, there is no easy way to use the rosidl to generate the message interfaces. There is a PR open to provide enum support but hasn't been merged yet.

[natrad100]

@ndahn I've added you to the maritime_interfaces repository

[mikedef]

@ndahn Back in December I was attempting to pass strings from ROS2 to fastdds and I used this tool https://github.com/eProsima/Fast-DDS-Gen to build IDLs for ROS. So far it's the only way that I have found to do this. You had to do some manual editing of files though to get things to sync up properly in ROS. I followed the example from https://github.com/osrf/ros2_raw_dds_example.

[russkel]

There is also this https://github.com/oceansystemslab/auv_msgs/tree/ros2-master that I fixed up for ROS2.

[ndahn]

Thanks @natrad100!

Right now I feel that while having an idl2msg converter would be the high road, the much faster and less error prone way right now would be to just translate the UMAA definitions by hand. Not fun, but also not more than a few hours of work.

Anyone wants to give some input on that?

[russkel]

Please keep in mind the work in the rosidl packages, for example an IDL parser: https://github.com/ros2/rosidl/tree/rolling/rosidl_parser

As the format is already in IDL I am not sure if there's much to be gained from converting to msg?

[natrad100]

Thanks @natrad100!

Right now I feel that while having an idl2msg converter would be the high road, the much faster and less error prone way right now would be to just translate the UMAA definitions by hand. Not fun, but also not more than a few hours of work.

Anyone wants to give some input on that?

I guess the other issue with doing it by hand is that when the re-release new versions they'll need manual updating which is a little frustrating. Agree with @russkel re IDL, just need a way of handling the capability discrepancies in between ROS an fastDDS (enums, unions etc)

[arjo129]

Another option is that we could use a bridge for messages which require support for special interfaces. I suspect it will be hard to get all of the missing features in. We could for instance have ros2 compatible messages and then bridge them. As we add features to ros2 to support the missing features we could remove these features from the bridge. The problem with this is we will inherently lock ourselves into a specific DDS vendor for the bridge.

[russkel]

I can't help but think that creating a bridge and then having client libraries that deal with the bridged Msgs would be just as much work as just adding the support into rmw. At this stage supporting just the default DDS vendor probably makes sense.

[ndahn]

Thanks @natrad100! Right now I feel that while having an idl2msg converter would be the high road, the much faster and less error prone way right now would be to just translate the UMAA definitions by hand. Not fun, but also not more than a few hours of work. Anyone wants to give some input on that?

I guess the other issue with doing it by hand is that when the re-release new versions they'll need manual updating which is a little frustrating. Agree with @russkel re IDL, just need a way of handling the capability discrepancies in between ROS an fastDDS (enums, unions etc)

It's these discrepancies that I'm worried about. I agree that providing a usable parser would make things easier in the long run and help the community as a whole, but that will also require a few weeks if not months of work instead of a few days (assuming no one will work on this full time).

I don't quite get the purpose of the bridge?

[ndahn]

I could work on this one of these days. This won't stop an IDL parser from appearing, we'll have something useful at hand and they could serve as a reference. I think I could get some of that done this Friday!

[natrad100]

Just relaying some info from the element chat:

I'm not going to make it on tonight for the message discussion (12:30am in Darwin) - as an update, we have determined the best approach:

a) add union type and single file enum capability to rosidl generator

b) run parser over UMAA messages

We're looking for assistance in undertaking part a, with completion eta November meeting.

FastDDS currently supports union types, but is not supported in ROS. By adding this capability, we can successfully support the UMAA standard with rosidl modification.

If you're interested, please comment in the thread linked below. https://github.com/ros-maritime/issue_tracking/issues/17

If you have any additional questions on our approach, flick me a message in element.

[arjo129]

For reference @clalancette gave a related talk: https://vimeo.com/649649793/31032f6fba

[russkel]

After watching the roscon video it seems that plug and play compliance with UMAA isn't trivial at all due to ROS2 middleware layers missing a few features. In addition to that, the ROS2 DDS topic names are mangled and DDS types don't match with ROS2 types. Plug and play compatibility with a UMAA system is going to require bridging or quite a large number of ROS2 middleware changes. If we're less interested in compatibility and more with just having a standard message set that is mostly compliant at the field name level then the approach mentioned https://github.com/ros-maritime/issue_tracking/issues/17#issuecomment-1202546460 will work.

[arjo129]

@natrad100 has made significant progress on this front. See the messages here: https://github.com/Greenroom-Robotics/hydrographic_msgs and https://github.com/Greenroom-Robotics/maritime_interfaces