Feature and limitation of traffic-light adapter

Open-RMF Open-RMF General
1

Hi,

What is the feature and limitation of traffic-light adapter support in the latest/main branch?

is there any fleet adapter example (python is preferred) I can refer to?

How is the integration to lift and door done? switch map?

2

The traffic-light adapter was implemented quite a while ago for “Demo Platform 2” of the RMF project. The goal was very narrow: Support traffic management for robots that are already integrated with a facility’s systems and which can only accept pause and resume commands from Open-RMF.

is there any fleet adapter example (python is preferred) I can refer to?

I’m not aware of any open source examples of a traffic-light integration since all robot APIs that needed the traffic-light integration were proprietary. The python bindings do exist though.

How is the integration to lift and door done? switch map?

Facility integration like door and lift interaction was not done for this robot type, largely because it seemed infeasible for us to manage these interactions while not having much control over the robot. Therefore all of these other integrations are expected to be done by the robot vendor already.

I think in the next generation there will be opportunities to have more sophisticated traffic-light integrations. With the upcoming flexibility of workflow execution, it may be more feasible to mash together vendor-specific control with door and lift interactions.

3
  • In an environment with multiple AMR systems with varying degree of controls (e.g. full control, traffic light), am I correct to say that the door and lift integrations in open-rmf only supports full control AMR systems and each traffic-light AMR system must have direct control/integration to the door and lift, bypassing open-rmf?
  • If the traffic-light AMR systems allow certain degree of customizations, is it possible for the AMR systems to utilize open-rmf to control doors and lifts ?
4

They don’t necessarily have to bypass Open-RMF. Their integrations could still use the door and lift messages and thereby talk to door and lift adapters, but the use of those messages currently needs to be implemented by the system integrator.

The basic reason it’s like this is that the out-of-the-box door and lift integration for full control systems relies on the GoToPlace implementation, which can’t really be applied directly to a traffic-light integration. I’m open to ideas on how to generalize this for the next generation interfaces. The next stage of interface design will be “Execution Protocols”, so that will be a good opportunity to consider how to design door and lift integration to work more easily for traffic-light integrations.

If the traffic-light AMR systems allow certain degree of customizations, is it possible for the AMR systems to utilize open-rmf to control doors and lifts ?

Yes, since the traffic light integration is done through a library, you can combine the usage of that library with your own calls to the door and lift messages. You could write a Python adapter that interacts with the EasyTrafficLight API while also using the ROS messages and topics to communicate with the doors and the lifts whenever the robot needs to pass through one of them.