[Bug]: A single client freezes and does not update its position anymore

[Odin-byte]

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

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

OS and version

Ubuntu 22.04

Open-RMF installation type

Source build

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

2.3.0

ROS distribution

Humble

ROS installation type

Docker

Other ROS installation methods

No response

Package or library, if applicable

Free Fleet ROS1 Client

Description of the bug

I have a docker based emulation of 3 robots running, which all run a free fleet ros1 client.
The only change made to this client is that the docking server is no longer of type Trigger, but a custom SetString Client which controls the docking process based on a given docking station name.

In addition to this I added new atomic states to keep track if the robot is currently docked to any station. If that is the case and the robot receives a movement cmd, it triggers the undocking process before following the given path.

Every time I start my emulation all robots start docking to their chargers. During this process there are no positional updates, as the docking service is blocking to ensure that the docking has finished, before the task feedback is send to RMF.

Robot 2 and 3 are still functional after the docking finished, updating their positions and being able to start moving when receiving a task. Robot 1 does not update its position after docking and when starting a task it does start to move, but does not update its position and starts to replan based on its old position.

I have a feeling this is happening because of my blocking service call, which takes 10 seconds depending on the station. Is there any way to fix this or deal with docking processes blocking this long?

If you have any follow up questions, please do not hesitate to ask.

Steps to reproduce the bug

1. Launch 3 robots each with its own Free Fleet ROS1 Client running
2. Wait for them to dock as the fleet adapters finishing task is charging
3. The robots do not update their positions while docking (this is expected due to the blocking nature of the service client)
4. Robots 2 and 3 finish docking and update their positions
5. Robot 1 does not update its position and still shows up in the pre docking position
6. Send a task to all robots

Expected behavior

All Robots start an undocking process, not updating their positions. After that they start following the given path.

Actual behavior

Robot 2 and 3 do as expected. Robot 1 does not update its position, but instead keeps re planning based on its old position, because of the missing positional updates.

Additional information or screenshots

I did make some changes to the path handling and docking service as stated above.