Introduction
A key challenge in developing real world robotic systems is selecting a suitable middleware, such as ROS2 (probably the most widely used in general robotics, but not dominate in ocean robotics), MOOS-IvP (with the value of the IvP Behavior-based autonomy engine) or Goby3 (with a focus on nested communication and low-throughput comms links).
While it introduces complexity, sometimes it is helpful to run two middleware systems in parallel and pass data between them. You might want to do this, as I often do, if you wanted the pHelmIvP autonomy engine from MOOS-IvP and the nested communications architecture of Goby3. Or if you wanted the acoustic communications drivers of Goby3 with the wide array of existing ROS2 libraries. To do this, we need technical components in place to bridge both the transport and messaging of both systems. For my purposes I call these interoperability apps “gateways”.
In this post I want to highlight two existing gateways, both of which connect my middleware project Goby3 with one of two other popular open source middlewares: MOOS and ROS2.
Both bridges are built on the same general concept:
- an application that connects to the transport layers of both middlewares
- a loadable set of customizable plugin libraries (shared libraries) that define the specific message translations required for the current system. This allows complete flexibility in translating from MOOS strings to Goby Protobuf or JSON (typically) types to ROSMsg structs.
Goby / MOOS
The MOOS / Goby gateway (goby_moos_gateway) is in the main Goby3 source repository and can be installed with the libgoby3-moos-dev and goby3-moos Ubuntu packages.
It is showcased in my Goby3 course, and is launched in the AUV launch file using the environmental variable “GOBY_MOOS_GATEWAY_PLUGINS” to define the plugin libraries to use: goby3-course/launch/trail/auv.launch at master · GobySoft/goby3-course · GitHub
The source code for the plugin used here is goby3-course/src/lib/moos_gateway at master · GobySoft/goby3-course · GitHub . The key thing to note is that this small plugin library does the work of subscribing to the Goby3 message (Group: goby3_course::groups::usv_nav / Protobuf Type: goby3_course::dccl::NavigationReport) and publishing the quasi-standard MOOS-IvP “NODE_REPORT” string on the MOOS side.
A real world open source example is the JaiaBot system that runs on a mostly Goby3 middleware but uses the pHelmIvP from MOOS-IvP: JaiaBot: Architecture
Goby3 / ROS2
The ROS2 / Goby3 gateway application goby_ros_gateway has a similar design, with a lightweight application that loads shared library plugins to do the message translation work.
The gateway is in a ROS2 package (to avoid having a dependency on all of ROS in Goby3): GitHub - GobySoft/goby_ros_gateway: Gateway between Goby and ROS
There is another ROS2 package that provides a set of examples: GitHub - GobySoft/goby_ros_examples
In this case we use JSON (which Protobuf supports) as the messaging compatibility between the two systems.
Conclusion
While is can be more complicated to run these “binary star” systems, there are often real technical benefits to using two middlewares: you can the best of both systems and users familiar with one can add code to that side of the system without full understanding of the other, as long as the interfaces are well defined.
The Goby3 to MOOS and ROS2 gateway applications allow you to define simple and application specific message translation code (using shared library plugins) that are loaded and run by applications included in the project (goby_moos_gateway and goby_ros_gateway, respectively).
Please share any thoughts or questions you have on this approach or how it is used.