mxgrey
commented
3 years ago What you've described is actually the expected behavior for this scenario, although I understand that it's not desirable for your use case.
To elaborate on that, there is an implicit assumption in the current design of the full control fleet adapter that when a robot goes idle, it no longer needs to participate in traffic negotiation. The idea is that a robot should only be allowed to go idle when it is in a designated location that will not conflict with the traffic of other robots. However, the fleet adapter does not currently enforce that assumption because the question of how to enforce it in a generalized way is tricky, and this particular concern hasn't been a top priority yet, because we currently just rely on the system integrators to command their robots to only go idle in reasonable places.
We do have several ideas for how to solve this, which we are actively working on:
- Before a robot goes idle, the full control fleet adapter should automatically command it to go park in designated parking spot, to keep it out of the way of other robots.
- If a robot does need to wait at a waypoint that puts it in conflict with other traffic, that waiting should be handled as an explicit
ActiveWaitingtask instead of leaving the robot completely idle. TheActiveWaitingtask would be responsible for keeping the robot on the desired waypoint as much as possible while still having the robot move over to allow other robots to pass.
These features are not available yet, but they are under active development. I don't have a timeline for either of them currently, but I would expect to see them within the next few months.
Hi, would like to explain a test scenario where a robot remain in conflicted state indefinitely.
The rmf_demo office world is modified to have an additional waypoint "block" in the middle of the lane. It also include 2 fleets with one robot each. The purpose was to test the response of the current traffic management system when an idle robot (tinyRobot1) at the
blockwaypoint, is in the way of another robot (mobot1). mobot1 has a loop request betweenstation_1andcubicle_1.My predicament was that tinyRobot1 would still participate in negotiation, although its idle/ has no other tasks, and move to another waypoint eg.
tinyRobot1_charger, out of the way of mobot1’s path and continue staying idle. Alternatively, even if tinyRobot1 does not want to negotiate, mobot1 could reroute. Instead of turning left, it would turn right and go the longer way tostation_1and thencubicle_1.However, none of the two possible solution was found by the traffic system. In the log below, it seemed that there were no active negotiation from the
rmf_traffic_scheduleas well. Though mobot is aware there was an "interruption" and tried to replan, the green path from the visualizer says otherwise. Does mobot knows that there is a possible "conflict"? Could you explain about the behavior exhibited here?