Posted by @cwrx777:
Hi,
is there any hook or message informing the fleet adapter that the robot has reached the destination floor so that we can call the robot API to change the map?
Chosen answer
Answer chosen by @Yadunund at 2022-08-15T06:15:16Z.
Answered by @mxgrey:
The waypoints argument that will be given to the follow_new_path function of your RobotCommandHandle contains a list of rmf_traffic::agv::Plan::Waypoint objects that have a graph_index function.
When that graph_index is non-null you can pass it to Graph::get_waypoint and then call Graph::Waypoint::get_map_name to check what the current map is for that waypoint. If you see the map name change, then you should tell your robot to switch its map.
We don’t provide an out-of-the-box hook for this because map switching logic is likely to vary too much between robots and deployments. For example, in a certain deployment you might need the robot to decompose a very large floor into multiple maps internally, but inside the RMF traffic system those multiple maps would all be part of one single map. In that case you’d need a dictionary of nav graph index → robot's internal map name.
Posted by @mxgrey:
The waypoints argument that will be given to the follow_new_path function of your RobotCommandHandle contains a list of rmf_traffic::agv::Plan::Waypoint objects that have a graph_index function.
When that graph_index is non-null you can pass it to Graph::get_waypoint and then call Graph::Waypoint::get_map_name to check what the current map is for that waypoint. If you see the map name change, then you should tell your robot to switch its map.
We don’t provide an out-of-the-box hook for this because map switching logic is likely to vary too much between robots and deployments. For example, in a certain deployment you might need the robot to decompose a very large floor into multiple maps internally, but inside the RMF traffic system those multiple maps would all be part of one single map. In that case you’d need a dictionary of nav graph index → robot's internal map name.
This is the chosen answer.
Posted by @Yadunund:
The approach highlighted by @mxgrey is definitely the most robust considering all the possible scenarios.
One other approach could be to add a dock property to the first waypoint outside of a lift. Then your dock() callback implementation could check whether the previous waypoint was inside a lift and if so, trigger the robot specific functions to switch map + re-localise.
Posted by @mxgrey:
This would also be an interesting approach for map switches within large floors.
For RMF2.0 we could consider allowing system integrators to put custom triggers into the navigation graph, and they could make a trigger for changing the robot’s internal map.