There is a growing need for mobile robots to be able to interact with general infrastructure such as automatic doors and elevators (referred to as “lifts” in some regions). For convenience we will lump these non-robot devices under the umbrella term of facility “infrastructure”. Typically system integrators will perform ad hoc integration with infrastructure devices, using various protocols, often based on OPC-UA and/or MQTT. This may require developing a custom ROS node to integrate the infrastructure into a ROS-based system.
We would like to see the development of a community standard message package for infrastructure interactions. The Open-RMF project has various message packages that it has been using to do infrastructure integration, but these message definitions were developed specifically for the use cases that we needed to deal with and never targeted for general consumption. Nevertheless, there are many lessons we learned while working with these message definitions, and we would like to leverage that experience towards general-purpose infrastructure messages for the community.
This session of the interest group is meant to facilitate an open discussion about this topic. We are specifically hoping for community input on the matter, especially from anyone who is aware of similar existing efforts in open infrastructure integration. Most likely we will have follow-up sessions in later months as we attempt to iterate towards a set of message definitions that can get compelling buy-in from the community. A desired final result of this effort would be an REP along with a release of one or more message packages related to infrastructure integration.
We will start the session with an overview of lessons learned from our efforts with Open-RMF, including some open questions that we would appreciate specific community feedback on. Some of those open questions include:
- What to use to uniquely identify different “participants” in a system? E.g. unique string (centrally controlled), unique integer (centrally controlled), UUID (distributed generation)?
- Representation of different modes of operation: standardized integer (like http error codes) or user-defined string?
- Device-specific message definitions or generic/abstract message definitions? E.g.
DoorStatevsDeviceState. - Release separate message packages for each type of device, or one unified
infrastructure_msgspackage?
After that we will open up for general discussion, with priority for anyone who knows of relevant existing standards/specifications/efforts that they would like to share.
