Mutex group performance (#475)

Open-RMF Open-RMF General
1

Posted by @cwrx777:

The feedback from the ground is that with mutex group, the robot idling time (waiting for the next follow_new_path) is considerably slower and quite often receives replan to the same (current) waypoint.
I also notice the fleet adapter keep logging the following message:
Replanning for [%s] after locking mutexes %s because the external traffic has substantially changed.

Is there anything in the C++ code we can fine-tune to improve the mutex group performance?

2

Posted by @mxgrey:

I also notice the fleet adapter keep logging the following message:
Replanning for [%s] after locking mutexes %s because the external traffic has substantially changed.

This is an informational message and should not be interpreted as though an issue has happened. It just means that while the robot was waiting for the mutex, something about the traffic activity in the upcoming area has changed.

The feedback from the ground is that with mutex group, the robot idling time (waiting for the next follow_new_path) is considerably slower

I appreciate that you’re trying to provide feedback on the feature, but this is too vague for me to take any action on. I would need you to explain in concrete terms what sequence of events is happening and how it is different from what you would expect.

In general I don’t find it surprising that mutexes would add delays because that’s somewhat their purpose: to hold back a robot to mitigate the risk that it will interfere with another robot’s operation. I’ll need you to be as specific as possible about the circumstances (e.g. what is the layout of the nav graph, what+where are the mutex groups, where were the robots positioned, and what was taking longer than you expect) so I can understand the concern.

Is there anything in the C++ code we can fine-tune to improve the mutex group performance?

In principle you have every right to fork the code and make any changes you’d like to it, but I doubt it would yield any benefit proportional to the effort involved. Fine-tuning the algorithms is a next generation goal and isn’t feasible with the current codebase.

In our own deployments we’re able to get good traffic behavior by tuning the nav graph rather than the C++ code, so that’s where I would recommend focusing your efforts.