Why does RMF mostly use two Topics when making a request to another ROS component instead of using services?

[Odin-byte]

On the first glance it seems much simpler to use a service to request something from another ROS node and receiving a response instead of sending out a request over one topic and checking another topic for an answer, like its done within the ingestor or dispenser adapters.

Why was this structure chosen and is there a reason not to refactor it to use services instead?

Greetings!

[mxgrey]

There are a few factors that came into play, but the single biggest factor is that the current architecture was implemented in the very early days of ROS 2 when services suffered a lot of reliability issues due to default DDS configurations which were highly in flux in those days.

There was a significant probability back then that service calls would fail due to configuration or network connectivity problems. The reliable thing to do was repeatedly blast requests and responses over topics until you could observe the effect that you wanted.

Another factor is that many operations that Open-RMF does would be better described as Actions rather than Services, but Actions weren't available at all in ROS 2 when we started this project, but you can approximate an action easily enough with two streaming topics.

I'm inclined to believe that these issues are largely resolved now within ROS 2, so I'm planning on making significantly more use of services and actions as we develop the next generation architecture for Open-RMF.