Posted by @DDDWY:
“I have a scenario and would like to ask how to implement dynamic loading of map information. For instance, if I add new points and lanes, and modify the automatically generated 0.yaml file using my own code, how can I update the map in RMF without restarting? In a production environment, I consider adjusting the map as a crucial early deployment task. Having to frequently recompile and restart is inconvenient.”
“If I deploy using Kubernetes, is it feasible to simply restart the Deployment after compiling the latest 0.yaml?”
“If you could reply to me, I would greatly appreciate it.”
Edited by @DDDWY at 2024-07-09T14:01:06Z
Chosen answer
Answer chosen by @DDDWY at 2024-07-11T10:18:44Z.
Answered by @mxgrey:
The exact thing you’re asking for is not supported in the current generation of Open-RMF, although we’ll be able to support it in the next generation.
We do support a feature that might be sufficient, depending on your use case. If you can anticipate the map changes that you are going to need, then you can use the lane closing and opening features to modify which lanes the robots can use.
One of the reasons we don’t support arbitrary map changes during runtime is it’s very difficult to have sensible recovery behavior if the new map is completely different from the old map. We try to make sure that any stable API feature that we support has as few edge cases as possible. If you need an arbitrary map changing feature urgently, you can fork rmf_ros2 and add an API to modify the planner field of the FleetUpdateHandle, which is simply a shared_ptr<shared_ptr<Planner>>. It wouldn’t be hard to do, but I wouldn’t feel comfortable supporting it as part of the official API until we have the next generation planning capabilities available.
Posted by @mxgrey:
The exact thing you’re asking for is not supported in the current generation of Open-RMF, although we’ll be able to support it in the next generation.
We do support a feature that might be sufficient, depending on your use case. If you can anticipate the map changes that you are going to need, then you can use the lane closing and opening features to modify which lanes the robots can use.
One of the reasons we don’t support arbitrary map changes during runtime is it’s very difficult to have sensible recovery behavior if the new map is completely different from the old map. We try to make sure that any stable API feature that we support has as few edge cases as possible. If you need an arbitrary map changing feature urgently, you can fork rmf_ros2 and add an API to modify the planner field of the FleetUpdateHandle, which is simply a shared_ptr<shared_ptr<Planner>>. It wouldn’t be hard to do, but I wouldn’t feel comfortable supporting it as part of the official API until we have the next generation planning capabilities available.
This is the chosen answer.
Posted by @DDDWY:
Thank you very much for your response. I will try the suggested solution and share my results if it works well.
I also want to know about the progress of the next generation of RMF. When will it be released?
Posted by @mxgrey:
We’re much too far out to commit to a release date for the next generation. We’re still working on some foundational tools that will allow us to have a service-oriented architecture with good support for parallel async execution, as well as more sophisticated and robust multi-agent motion planning
My aim is to have those foundational tools finished and begin prototyping the next generation fleet adapters in November of this year.
Posted by @DDDWY:
Our company is currently implementing RMF, and we are looking forward to your new version in November. Thank you.