You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However the implementation does not currently replan the itinerary of a robot in the fleet that may be affected by a closure. Currently the fleet adapters have to implement logic to decide whether to replan. We can save a lot of repeated code in fleet adapter implementations if this logic was moved upstream.
@mxgrey do you see any issues with moving the replanning logic directly into theFleetUpdateHandle::close_lanes() implementation?
The text was updated successfully, but these errors were encountered:
I think it's a tricky situation because I don't think simply the fact that a lane is closing is enough information to tell us whether a robot which is moving down that lane should replan and potentially backtrack.
For example, if the lane is being closed because an obstacle has appeared in the middle of the lane, then a robot which is on that lane but past the obstacle should not replan.
For simplifying high-level decisions like this, I might suggest that we can put the replanning logic into the EasyFullControl with a lane-closing API that requires users to specify an obstacle location so that the EasyFullControl adapter knows how to make the right decision.
The FleetUpdateHandle::close_lanes() allows for lanes in the navigation graph of the fleet to be closed.
However the implementation does not currently replan the itinerary of a robot in the fleet that may be affected by a closure. Currently the fleet adapters have to implement logic to decide whether to replan. We can save a lot of repeated code in fleet adapter implementations if this logic was moved upstream.
@mxgrey do you see any issues with moving the replanning logic directly into the
FleetUpdateHandle::close_lanes()
implementation?The text was updated successfully, but these errors were encountered: