search

osrf / rmf_core

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

Introducing ResponsiveWait task phase #308

Closed mxgrey closed 3 years ago

mxgrey commented 3 years ago

This PR introduces the ResponsiveWait task phase. This task phase can be used any time a robot needs to wait somewhere that it might interfere with the traffic of other schedule participants.

While running the ResponsiveWait phase, a robot will try to sit on the designated waypoint, but will automatically move out of the way of other traffic and will participate in traffic negotiations.

In this PR, we also have any idle robots automatically engage in a ResponsiveWait phase, which will automatically be canceled when they are assigned a new task.

Note that this change means that if two robots are both idle on locations where they have overlap in their footprints/vicinities, then they will likely enter an endless cycle of negotiating with each other. That problem will be addressed when the parking spot reservation system is completed. In the meantime, users are advised to avoid situations where robots are idle on locations where they conflict with each other.

mxgrey commented 3 years ago

This PR is useful for testing these changes: https://github.com/osrf/rmf_demos/pull/213

mxgrey commented 3 years ago

In my testing I have a map with parallel lanes where a robot is parked on one of the lanes.

With the addition of this behavior, I think we'll need to reconsider some maps and how they're configured. I think there's a tendency to have needlessly large vicinities for robots, and that's something we should try to cut back on. Cutting down on the vicinity sizes should eliminate most of these idle robot interference issues.