Add an idle robot conflict scenario

[mxgrey]

This adds a scenario to the office world which is useful for testing the changes in osrf/rmf_core#308

Use the $ ros2 launch demos office_idle_conflict.launch.xml to test out what happens when an idle robot is acting as an obstacle for a looping robot.

[Yadunund]

Tested and no issues. But since the migration of rmf_demos has completed, should we instead open this PR here?

[youliangtan]

Previously before the recent commit (osrf/rmf_core@283d91d), I am able to observe the idle robot making way for the other robot with an active task. However, this behaviour is not reproducible after the change.

To test it out:

ros2 launch demos office.launch.xml

# seperate terminal (request tinyRobot1 to loop between 2 charging points)
ros2 run rmf_demo_tasks dispatch_loop -s tinyRobot1_charger -f tinyRobot2_charger -n 3 --use_sim_time

Expected behaviour: tinyRobot2 gives way to tinyRobot1 at waypoint tinyRobot2_charger

[mxgrey]

@tanyouliang95 Traffic negotiations fundamentally cannot support cases where two robots want to end on the same goal. It was actually a bug that the use case you described was able to work before, and one purpose of the commit that you're pointing to was to fix that bug.

Think about it this way: The purpose of a traffic negotiation is to allow all robots to successfully reach their individual goals. If multiple robots have the goal of ending on the same waypoint to remain there for an indefinite period of time, then their goals are fundamentally incompatible. An incompatible goal set means that the negotiation should be considered impossible.

The upcoming reservation system should help prevent multiple robots from having the same goal at the same time. That should allow us to prevent this situation by using the reservation system to reassign the goal of the idle robot to wait somewhere else.

Have any other issues or confusing behaviors been encountered with the negotiation system updates?

[youliangtan]

@mxgrey Clear enough. Then this behaviour makes total sense. Other than that, no issue with this "ResponsiveWait" feature in rmf_core. 👍