[Other issue]: Does Negotiation proposed itinerary only cover the current task?

[CarlyyyChen]

Before proceeding, is there an existing issue or discussion for this?

• [X] I have done a search for similar issues and discussions.

Description

Hi team, a quick question regarding the negotiation proposals made by the fleet adapter: Does it only include the timed-waypoints for the robot's current task, or does it take into account the remaining tasks in the queue as well?

For example, if a robot is running a delivery task, and have a parking task afterwards as a "finishing task", when proposing an itinerary for this robot, will the finishing waypoint for that itinerary be the dropoff waypoint (from the delivery task), or will it be the parking spot (from the parking task)?

I tried to look into Negotiate service implementation, and the respond(~) function in GoToPlace.cpp, but not able to figure this out. Many thanks in advance!

[mxgrey]

The horizon for any negotiation is only up to the destination of the current GoToPlace.

This is known to cause issues when multiple robots are trying to go to the same place at the same time. There are a few mechanisms to mitigate that problem including the followed_by field and mutex groups.

We have plans to fix this without needing workarounds using a reservation system, but that's still in experimental stages.

[CarlyyyChen]

Hi Grey, thanks so much for your prompt reply! Could you please elaborate more on how we can use the followed_by field to mitigate the problem? Currently this field is derived directly from the task (patrol, delivery, charge etc) assigned to the robot right?

Also there is no "mutex" option from the property drop down in my traffic editor. I am currently running simulation on humble. Does it mean that mutex property is not supported on humble yet?

Much thanks again!