Interoperability Interest Group May 2, 2024: Sneak Peek of Next Generation Open-RMF

Community Page

Meeting Link

Calendar Link

The current implementation of Open-RMF has proven to be a valuable proof of concept for enabling heterogeneous fleets of robots to operate in shared spaces and with shared infrastructure. Now with the benefit of lessons learned from numerous trial deployments, we are looking towards a reimplementation to increase the scope, scale, capabilities, reliability, and ease of use that Open-RMF provides to its users. The next session of the interoperability group will reveal the new software architecture that’s planned to tackle all these needs at the same time.

Beyond improving the design and implementation of Open-RMF, our architectural plans may be of interest to developers that need to deal with interoperability in general. We’ll be explaining how our choices will enable high performance, highly-concurrent (parallel/multithreaded), memory safe, bug-free code that can tie together disparate systems with a high degree of modularity.

The key themes will be to take advantage of a high performance Entity-Component-System framework (specifically Bevy) and a service-driven architecture to create an SDK that has a broad and flexible surface area, in stark contrast to the design choice of having a very narrow and rigid API take by the current Open-RMF. We’ll talk about the trade-offs of these choices and why we’ve decided to make such a sharp pivot.

2 Likes

Hello,
I am working on implementing Open RMF in a research lab. I was interested in this meeting, but I could not join.
I have a few questions about the meeting:

  1. Is the recording going to be available? I found the April’s one.
  2. Do the current adapters work on the new scheme?

The recording will be available eventually. It takes some time to make its way onto Vimeo.

The slides are available right away at this link.

Do the current adapters work on the new scheme?

I don’t think this is mentioned in the slides, but in the recording I mention that the rmf_fleet_adapter API which is currently the recommended way to develop a fleet adapter will continue to be supported in the new scheme, but its implementation will be fully gutted and replaced with the new architecture. The API will effectively be frozen, so it won’t benefit from new capabilities, but fleet integrations that worked previously will continue to work the same.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.