To ROS2 or not to ROS2, that’s not the Vista question

How to effectively create and use a messaging mechanism for connected primary functions software subsystems?

Wageningen, April 27, 2020

Author: Manfred van der Voort

Version: CONCEPT

Introduction

At the start of project Vista, the starting point was used to apply and utilize ROS or ROS2 at the core of the software. Taking advantage of this would include making good use of ROS(2) functions that show great similarity to what is being developed in Vista. This includes support for stereovision camera, Lidar sensors, trajectory planning, etc.

As the project continues and the insights and possibilities of the various primary functions are shifted somewhat, the question arises whether the application of ROS(2) is still so evident from the projects perspective. The most immediate reason for this is the fact that, according to current insights, a “2D Pose Estimation” based RTLS is being developed, without the use of stereovision camera and Lidar sensors. And with that, the possible ROS(2) application becomes more of a question. In other words, what will possibly still be used from ROS(2)?

This question eventually leads to the more underlying question: are we going to use DDS / FastRTPSFOOTNOTE: Footnote (as part of ROS2) for our joint messaging facility or something else? And, for that something else, ZeroMQ is now being assumedFOOTNOTE: Footnote.

And with this fact we arrive at the statement: “To ROS2 or not to ROS2, that’s NOT the Vista question”. The rest of this advisory document looks at the pros and cons of FastRTPS vs ZeroMQ for Vista as we know it today.

Primary functions overview for VISTA

Below is the current overview of which is already known that it must be adjusted somewhat, with the known primary and supporting functions.

RequirementsFOOTNOTE: Footnote

Although the process step in the functional architecture progress still has to be taken to determine communication patterns, message types and naming, a global picture has already emerged. This is outlined below as a indicative framework of assumed requirements so far:

• low latency necessary
• multimedia data for (protocol) signaling and actual data transfer between the different subsystems
• bidirectional traffic necessary
• video streams provided for DC view -> HMI and in due course optionally DC view -> Yard Management applications
• video streams appear unidirectional so far
• video stream may sometimes seem to become multicast (so 1 -> many)
• Pub / Sub mechanism is now most suitable for HMI devices
• Pub / Sub can be possibly being used for OpenCV if you want to do a kind of stitching between the dock row cameras, or publishing truck movement near real time

If we taking all this into account, these global requirements are still relatively limited, with low latency in particular becoming a crucial one.

Topology variants

Choosing a middleware solution for messaging queing (MQ) always results in the fundamental choice between a Broker based MQ solution or a Non Broker based MQ solution. The former also called hub-and-spoke topology and the latter messaging bus topology.

With the possible choice of ZeroMQ, we opt for a brokerless approach with advantages and disadvantages.

Big advantage of this topology: in principle simple, highest possible performance due to lack of central store and forward and no additional software middleware components are required.

Disadvantage of it: does not scale favorably with increasing nodes, no common place for possible semantic conversion of messages and no decoupling of peers, so that information (IP addresses, port numbers) are usually recorded in the nodes themselves which is from a change management point of view not ideal during run time.

Selection criteria

In the table below, I’ve collected the most obvious selection criteria both from a technical point of view and project management view.

Criterion	FastRTPS	ZeroMQcurve
Learning curve   (large, medium, low )	medium	low
Language bindings   (low, reasonable, large)	low for plain vanilla and to make it reasonable for FastRTPS only, ROS2/DDS must be used as well!	large
Fit for purpose general   (small, reasonable, large)	large, but only with the additional development and run time load of ROS2 included!	large
Simplicity of use   (small, reasonable, large)	reasonable if FastRTPS only, small if ROS2 is also includedFOOTNOTE: Footnote	large
Security   (small, reasonable, large)	large and integrally	reasonable, but only with an optional add-on which doesn’t offer all language bindings
Suitable for data messaging, signaling   (raw) video (large, medium, low)	large	large
Availability of knowledge in project   (low, reasonable, large)	low	reasonable
Availability of public knowledge for application   (low, reasonable, large)	low	largeFOOTNOTE: Footnote

Advice

Overlooking this collected insights for both different options to effectively create and use a messaging mechanism for connected primary functions software subsystems,I recommend the following:

1. Only fully deploy ROS2 / DDS / FastRTPS when there is sufficient knowledge available for the project and there is a greater advantage for Vista in the long term in a HAN context and (further?) expected project delay is allowed.
2. If these conditions cannot be met, give up now because ROS2 as a condition for DDS / FastRTPS produces unwanted load on further development and even more importantly, system integration
3. Switch to this deployment of ZeroMQ and invest directly in practical knowledge within the project for the most common features to be used, particularly for video streaming
4. Consider an equivalent Application Gateway function (ZeroMQ <-> HTTPS/WebSockets) for the WP4 / HMI domain comparable with the existing ROS2 / Web Topic Translator
5. With this functionality, specific functions such as push messages and streaming HTTP (S) can be offered without WP4 having to invest in ZeroMQ and keep maximum freedom of choice or the HMI / Truck device solution
6. Should it be important to support ROS2/DDS/FastRTPS based integrations now or later, use Tier4 to create an external ROS2/DDS/FastRTPS interface (external with respect to RTLS, Path control and HMI). Then the Vista core is primarily ZeroMQ based and optimized for that, while the non core interface can offer both through a solo Tier4 implementation.