Posted by @Achllle:
Repost from the old org
I’m wondering why the RMF fleet adapters are so tightly integrated with RMF core as opposed to communicating with it through ROS2 messages. It seems like because of the direct import (either python or c++), the adapters are required to live on the same compute device as RMF core. Is that statement correct?
If this is the case, all fleet adapters would be living on the same machine and if for some reason that machine goes down, fleets are unable to communicate with each other directly.
Chosen answer
Answer chosen by @Achllle at 2021-03-12T16:40:48Z.
Answered by @mxgrey:
I’m wondering why the RMF fleet adapters are so tightly integrated with RMF core as opposed to communicating with it through ROS2 messages.
The concept of an “RMF Core” is not well defined, so it tends to mean different things to different people. All of RMF is modular and node-based, designed to be distributed over multiple process or across a network. In our out-of-the-box implementation, each fleet adapter talks with each other and with the traffic scheduling system using ROS2 messages, so it can (and often will) be deployed across multiple machines on a network.
I wonder if you might be confused by the fact that the recommended Fleet Adapter API is a C++ API (with the option of Python bindings for those that prefer Python). The C++/Python API is designed to achieve several design goals:
- Narrow, explicit APIs that are tailored to specific use cases
- Long-term stability in the APIs and ABIs that users interface with, even as new features are added or implementations are improved
- Minimal requirements for users to understand ROS2 and reactive programming
The C++/Python API covers up all the details of using ROS2 and dealing with the traffic scheduling and negotiation system. It’s entirely possible for users to interact directly with the ROS2 traffic protocol messages, but it’s not recommended as that protocol is still in the process of being improved, and it is currently very difficult to maintain API/ABI stability for ROS2 messages if any changes are needed.
the adapters are required to live on the same compute device as RMF core. Is that statement correct?
As mentioned above, this is not the case, and in fact we have often run different fleet adapters on separate computers when performing demos and test cases in the past.
If this is the case, all fleet adapters would be living on the same machine and if for some reason that machine goes down, fleets are unable to communicate with each other directly.
The fleet adapters do not currently have a robust fail-over mechanism. Specifically if a fleet adapter needs to be restarted then when it starts back up, it will have lost track of all the tasks the its robots were assigned and performing. We’re currently working on adding a robust fail-over mechanism to the fleet adapters, but I can’t offer a specific timeline for that yet.
Posted by @mxgrey:
I’m wondering why the RMF fleet adapters are so tightly integrated with RMF core as opposed to communicating with it through ROS2 messages.
The concept of an “RMF Core” is not well defined, so it tends to mean different things to different people. All of RMF is modular and node-based, designed to be distributed over multiple process or across a network. In our out-of-the-box implementation, each fleet adapter talks with each other and with the traffic scheduling system using ROS2 messages, so it can (and often will) be deployed across multiple machines on a network.
I wonder if you might be confused by the fact that the recommended Fleet Adapter API is a C++ API (with the option of Python bindings for those that prefer Python). The C++/Python API is designed to achieve several design goals:
- Narrow, explicit APIs that are tailored to specific use cases
- Long-term stability in the APIs and ABIs that users interface with, even as new features are added or implementations are improved
- Minimal requirements for users to understand ROS2 and reactive programming
The C++/Python API covers up all the details of using ROS2 and dealing with the traffic scheduling and negotiation system. It’s entirely possible for users to interact directly with the ROS2 traffic protocol messages, but it’s not recommended as that protocol is still in the process of being improved, and it is currently very difficult to maintain API/ABI stability for ROS2 messages if any changes are needed.
the adapters are required to live on the same compute device as RMF core. Is that statement correct?
As mentioned above, this is not the case, and in fact we have often run different fleet adapters on separate computers when performing demos and test cases in the past.
If this is the case, all fleet adapters would be living on the same machine and if for some reason that machine goes down, fleets are unable to communicate with each other directly.
The fleet adapters do not currently have a robust fail-over mechanism. Specifically if a fleet adapter needs to be restarted then when it starts back up, it will have lost track of all the tasks the its robots were assigned and performing. We’re currently working on adding a robust fail-over mechanism to the fleet adapters, but I can’t offer a specific timeline for that yet.
This is the chosen answer.
Posted by @Achllle:
Thanks a lot for your answer, that helps clarify things up.
In the case that the adapters run on separate computers, if it’s not recommended to use the underlying ROS2 interface, are there ROS2 nodes connecting the C++ API to the fleet adapter or how is that interface achieved? Any pointers to where I could find this interface? (tried looking around myself but there’s a lot of changes going on 
)
Posted by @mxgrey:
Sorry for the delayed response, I just realized I forgot to follow up on this.
are there ROS2 nodes connecting the C++ API to the fleet adapte
Yes, the C++ API manages a ROS2 node, and even provides users with access to the rclcpp API of the node as you can see here.
The rmf_fleet_adapter::agv::Adapter class that’s linked above is the entry point for the current fleet adapter API, specifically Adapter::init_and_make or Adapter::make.
Adapter::add_fleet will help you create a “Full Control” fleet adapter, which assumes that your robots can be commanded to travel to arbitrary (x, y, yaw) coordinates.Adapter::add_traffic_light will help you create a “Traffic Light” fleet adapter, which assumes that your robot can tell us what path it is going to travel and accept pause/resume commands from us.