Posted by @cwrx777:
Hi,
As it can be seen in the pic, there is an obstacle in the AMR’s path. Is it the limitation of RMF that it is not able to replan the route via another path after a certain timeout?
Edited by @cwrx777 at 2022-07-01T09:50:01Z
Chosen answer
Answer chosen by @cwrx777 at 2022-07-08T03:44:44Z.
Answered by @mxgrey:
The ability to navigate around an unknown obstacle using on board sensors is the responsibility of the AMR’s navigation stack, not a responsibility of RMF. RMF can only assist with obstacles whose predicted trajectories are reported to the traffic schedule. That’s why RMF can help robots to avoid traffic conflicts with “smart trolleys” (trolley beds that have localization devices on them) but would not be able to help with a random box.
The simulated robots in rmf_demos are intentionally very simple “slot car” robots that naively follow whatever path they’re given with no navigation stack. That decision was made because simulating an entire navigation stack is very computationally expensive, so multi-robot simulations would start to choke with only 2-3 robots if every robot simulated its own full navigation stack.
An enhanced use of RMF would be to use smart cameras to identify obstacles in a facility and then report those obstacles to the traffic schedule so that robots can avoid conflicts with them. Setting up such a system is ultimately the responsibility of a system integrator.
Posted by @mxgrey:
The ability to navigate around an unknown obstacle using on board sensors is the responsibility of the AMR’s navigation stack, not a responsibility of RMF. RMF can only assist with obstacles whose predicted trajectories are reported to the traffic schedule. That’s why RMF can help robots to avoid traffic conflicts with “smart trolleys” (trolley beds that have localization devices on them) but would not be able to help with a random box.
The simulated robots in rmf_demos are intentionally very simple “slot car” robots that naively follow whatever path they’re given with no navigation stack. That decision was made because simulating an entire navigation stack is very computationally expensive, so multi-robot simulations would start to choke with only 2-3 robots if every robot simulated its own full navigation stack.
An enhanced use of RMF would be to use smart cameras to identify obstacles in a facility and then report those obstacles to the traffic schedule so that robots can avoid conflicts with them. Setting up such a system is ultimately the responsibility of a system integrator.
This is the chosen answer.
Posted by @Yadunund:
We recently open-sourced a set of ROS 2 nodes that can detect the presence of certain obstacles and relay this information to Open-RMF.
See here for a demo where a LIDAR sensor is used to detect an obstacle similar to the one in the original post.
A lane_blocker node receives obstacle detection results and can decide whether to close a lane or impose speed limits for the same. This node is available in this branch
