Posted by @txlei:
Thank you for providing this new feature. I have just tested it out using the older office map. Works as intended but like to ask the following:
- there’s a caveat that the feature is only relevant for legacy fleet adapter (aka the full_control adapter). Can I clarify if it meant that fleets using full control implementation via the
rmf_fleet_adapterC++ API, this feature cannot be used? - Specifically, the lane closure closes the lane segment excluding its start and end waypoints. Is this explicit in the code implementation of this feature?
- Would there be any planning challenge if lane is closed when there are existing robot tasks (i.e. robot replanning) versus lane closure before any submission of robot tasks (i.e. first-time path planning ard closed lane). I have tested that both scenarios works fine but just like to ask if there are anything to take note.
- Currently is there any API to get a list of fleet_name for fleets “enrolled”?
Chosen answer
Answer chosen by @Yadunund at 2021-04-01T02:58:14Z.
Answered by @mxgrey:
there’s a caveat that the feature is only relevant for legacy fleet adapter (aka the full_control adapter)
That caveat only applies to the rmf_fleet_msgs::LaneRequest message API.
Can I clarify if it meant that fleets using full control implementation via the rmf_fleet_adapter C++ API, this feature cannot be used?
There is still a lane closure feature for the rmf_fleet_adapter C++ API for everyone who is developing a fleet adapter off of that, but you need to use these functions, and you should also remember to check whether the lane closure is relevant to any of your robots and trigger the RobotUpdateHandle::interrupted function on any that need to be rerouted. If your robot is in the middle of the lane that needs to be closed, then before triggering interrupted, you should also use one of these update_position calls to make sure the planner will reroute it the way you want.
I think the way all of this is implemented in the legacy fleet adapter [1] [2] is pretty reasonable, so you could use that as a reference point for how to make the lane closing work for your own custom fleet adapter.
Specifically, the lane closure closes the lane segment excluding its start and end waypoints. Is this explicit in the code implementation of this feature?
Right, closing a lane just means the planner will not attempt to use that lane to move the robot from the lane’s start waypoint to its end waypoint. If you want to close off a specific waypoint entirely, then closing every lane that leads to that waypoint would have the desired effect.
Would there be any planning challenge if lane is closed when there are existing robot tasks (i.e. robot replanning) versus lane closure before any submission of robot tasks (i.e. first-time path planning ard closed lane).
The only difference is that in the replanning case, the robot will take longer to finish its task than it originally predicted. If the lane closure happens before a task is submitted, then the fleet manager will know to account for the lane closure when estimating the task completion time.
Currently is there any API to get a list of
fleet_namefor fleets “enrolled”?
This is sort of an initial rough draft of the feature, so we haven’t firmed up what the “Standard Practices” should be regarding lane closure. I kind of expect different vendors or system integrators will have their own preferences about how lane closures should be handled. But if you want to work off of the ROS2 approach that we’re using for the legacy fleet adapter, you could infer which fleets will probably support the rmf_fleet_msgs::msg::LaneRequest API based on which ones are publishing rmf_fleet_msgs::msg::ClosedLanes messages to the "closed_lanes" topic. The ClosedLanes message contains the fleet name of each publisher, so if you gather up all the fleet names publishing to that topic, then there’s your list.