search

osrf / rmf_core

Provides the centralized functions of RMF: scheduling, etc.
Apache License 2.0
102 stars 41 forks source link

obstacle re-routing #314

Closed imdalaf closed 3 years ago

imdalaf commented 3 years ago

We are implementing a project which requires the robot to perform obstacle avoidance. In the scenario that when the Fleet manager (FM) sends a job to RMF indicating start location at level 1 of the building and the destination location at level 2 of the building.

In the event that when the robot encounters an obstacle blocking the lane, we are thinking of using the robot ROS1 navigation route planning capability to plan for a new route to move around the obstacle to the next waypoint even if it is doing a big detour by taking other routes. Then upon reaching the next waypoint, it continues traveling according to what has been planned for it by the RMF.

Because the detour route is not registered by RMF, so it will be less optimal for the robot to robot conflict prevention and resolution function in RMF. So we will like to check if there is a way for our system to replace the current robot navigation task with our own path planned. So that this new route will be registered and monitored by RMF.

Alternatively, can we pause the current navigation task and insert a new navigation task with the detour route. This will register the new route to RMF and upon reaching the new route to the next waypoint after the obstacle, it then resumes the execution of the original navigation.

fyi, the fleet adapter we are implementing is the full control level.

mxgrey commented 3 years ago

I think it'll be much better overall to propagate the blockage information upstream to the full control fleet adapter to allow the fleet adapter to figure out a rerouting. This will be especially important if a robot is completely blocked off from its goal, because then the fleet adapter will need to report that its task has become impossible.

The ability to close certain lanes of the navigation graph in real-time is a valuable feature, so I've opened a feature request for it on the rmf_ros2 repo in the new open-rmf organization. I'll make a point of completing this feature by the end of this week, or sooner if possible.

In the meantime, on your end I would recommend developing a ROS2 node that can identify when a lane on the robot's navigation graph is impassable. With the new feature that I'll develop, when you've identified impassable lanes, you'll be able to issue a message to the fleet adapter to close those lanes off and replan.

Let me know if that solution sounds acceptable.

imdalaf commented 3 years ago

Great, definitely sounds good to me. Thanks.

The only concern that i have is that we are using a specific branch that implements the experimental watchdog function. This new feature that will be implemented, will it comes with the experimental watchdog function as well?

mxgrey commented 3 years ago

The experimental watchdog feature is merged into the main branch, so no worries there. The only catch with using the watchdog feature off the main branch is that at some not-yet-determined point in the future we will get rid of it to replace it with a stable API to accomplish the same requirement in a way that is at least as good as the watchdog approach. But we won't remove the experimental feature until the stable version is available.

mxgrey commented 3 years ago

The lane closing feature is now available, as of this PR: https://github.com/open-rmf/rmf_ros2/pull/15

Note that this feature is being added to the restructured RMF repos that are in the new open-rmf organization, so you'll need to set up a new workspace following the instructions listed here.

I'll close this issue. If you have any further questions/concerns about this feature, I recommend opening a discussion here.