-
Notifications
You must be signed in to change notification settings - Fork 41
full-control traffic participants negotiation not started #303
Comments
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:
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. |
I've added an issue to track the new feature: #304 |
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
block
waypoint, is in the way of another robot (mobot1). mobot1 has a loop request betweenstation_1
andcubicle_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_1
and 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_schedule
as 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?The text was updated successfully, but these errors were encountered: