[Other issue]: `task_id` in the `fleet_state` topic and `update_handle.current_task_id`

[cwrx777]

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

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

Description

This question concerns the behavior of task_id in the fleet_state topic and update_handle.current_task_id, specifically during emergency pullover scenarios and when the interrupted task is killed or canceled. There seems to be inconsistencies

ROS2: humble
OS: Ubuntu 22.04
rmf_ros2 commit hash: [f41fae50cab9c008853632f6f0a229b60c7c6994](https://github.com/open-rmf/rmf_ros2/commit/f41fae50cab9c008853632f6f0a229b60c7c6994)

Observations:

Scenario 1: Set Emergency signal when robot is idle ( finishing request: park)

Robot State	Event / Action	fleet_state.task_id	update_handle.current_task_id
Idle	Idle task set (e.g., ParkRobot)	(empty)	ParkRobotXXX
Idle	Set Emergency signal	(empty)	emergency_pullover-0
Performing emergency pullover	Clear Emergency signal	(empty)	emergency_pullover-0
Idle	Set Emergency signal	(empty)	emergency_pullover-1
Performing emergency pullover	Clear Emergency signal	(empty)	emergency_pullover-1

Scenario 2: Set Emergency signal when robot is idle (finishing request: nothing)

Robot State	Event / Action	fleet_state.task_id	update_handle.current_task_id
Idle	Idle task set to nothing	(empty)	(empty)
Idle	Set Emergency signal	(empty)	emergency_pullover-0
Performing emergency pullover	Clear Emergency signal	(empty)	emergency_pullover-0
Idle	Set Emergency signal	(empty)	emergency_pullover-1
Performing emergency pullover	Clear Emergency signal	(empty)	emergency_pullover-1

Scenario 3: Let robot finish task after emergency signal is cleared

Robot State	Event / Action	fleet_state.task_id	update_handle.current_task_id
Performing task (e.g., patrol)	Task in progress	patrol-0	patrol-0
Performing task	Set Emergency signal	patrol-0	emergency_pullover-0
Performing emergency pullover	Clear Emergency signal	patrol-0	emergency_pullover-0
Performing task	Task in progress	patrol-0	emergency_pullover-0
Performing task	Task completed	(empty)	(empty)

Note:

1. task patrol-0

   ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyRobot1 -p coe lounge supplies --use_sim_time
   

2. Set emergency signal while robot is moving to lounge.
3. Clear emergency signal while tinyRobot1 is moving to emergency pullover stop

Scenario 4: Cancel robot task during emergency pullover:

Robot State	Event / Action	fleet_state.task_id	update_handle.current_task_id
Performing task (e.g., patrol)	Task in progress	patrol-0	patrol-0
Performing task	Set Emergency signal	patrol-0	emergency_pullover-0
Performing emergency pullover	Cancel task (cancel_task_request) during emergency	patrol-0	emergency_pullover-1
Performing emergency pullover	Clear Emergency signal	patrol-0	emergency_pullover-1
Performing task	Task in progress	patrol-0	emergency_pullover-1
Performing task	Reached lounge	(empty)	(empty)

Note:

1. task patrol-0

   ros2 run rmf_demos_tasks dispatch_patrol -F tinyRobot -R tinyRobot1 -p coe lounge supplies --use_sim_time
   

2. Set emergency signal while robot is moving to lounge.
3. Cancel the task
4. Clear emergency signal while tinyRobot1 is moving to emergency pullover stop
5. After emergency signal is cleared, patrol-0 task still continue until the robot reached lounge and stop there (finishing_request = nothing)..

[cwrx777]

After reviewing the code, I found that the task_id published in the fleet_states topic, the booking.id in task_state_update, and the task_id in fleet_state_update JSON all originate from the TaskManager’s current_task_id(). I believe this is meant to reflect tasks submitted through task_api_requests.

Whereas update_handle.current_task_id() comes from the RobotContext and reflects what the robot is currently executing. This includes not only user-submitted tasks but also internally generated ones such as finishing_request, emergency pullover, or retreat-to-charger tasks.

However, there seems to be a potential bug: in some cases the RobotContext’s current_task_id may not be reset after these internal tasks complete, which could leave the robot reporting an outdated or incorrect task ID.

[mxgrey]

I think task management during emergency pullovers is definitely something we haven't exercised enough and would benefit from user feedback on.

During an emergency pullover, do you think it would be better for the reported task ID to be whatever non-emergency task is assigned to the robot, or should it be the ID of the emergency pullover task? From your issue ticket it sounds like the main concern is that the task ID isn't being reset to the active task after the emergency pullover is finished, but I wonder if we should prevent the emergency pullover from changing the task ID altogether?

[cwrx777]

During an emergency pullover, do you think it would be better for the reported task ID to be whatever non-emergency task is assigned to the robot, or should it be the ID of the emergency pullover task?

I see emergency pullover task as non-user tasks, like finishing request such as park robot, charge, and retreat to charger. And based on this existing behavior, there is no task_state_update for this. task state update is meant to update system integrator's application on the status of the task submitted by it and not for updating the application of the status of internal tasks. I hope the behavior is kept this way. Other than for tracking the task status, our application is using the task_state_update to determine if the fleet adapter is still alive (i.e not restarted) and so that if the application didn't receive the task state update after a period of time, it will resubmit the task.

From your issue ticket it sounds like the main concern is that the task ID isn't being reset to the active task after the emergency pullover is finished, but I wonder if we should prevent the emergency pullover from changing the task ID altogether?

Yes, my ticket indeed is about resetting the robot context task ID to the active task when the robot is no longer performing emergency pullover task (i.e emergency signal has been cleared).

My other question is what should the expected behavior be when the task manager received cancel_task_request or kill_task_request of the active user task during emergency pullover, and what is the expected behavior of the task after the emergency signal is cleared. An example is shown in the scenario 4.

My observation:

1. When the task manager received cancel_task_request or kill_task_request of the active user task during emergency pullover, TaskManager::_begin_pullover will get called again.

2. Should all task_api_requests on active task id be ignored during emergency?

3. if finishing_request is set to nothing and while the robot is moving to emergency pullover stop and emergency signal is cleared, the robot will continue to move.

I have opened PR #465 for review