-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Other issue]: The robot does not move and generates a plan in a loop #373
Comments
I recently discovered that a race condition related to this block can lead to an arbitrarily repeating loop of replanning like the one you're describing. I have a branch where this has been fixed (along with a number of other new features and fixes), and I'll be opening a PR for it today or tomorrow at the latest. |
I think this other issue has the same root cause. |
Great, I'm looking forward to testing it. |
I carefully checked the code again and reproduced the scenario where the problem occurred. But I think, is it because the transportation plan is unreasonable that the two robots are very close face-to-face? Can this situation be avoided in an ideal environment? |
It seems very common for two robots to encounter each other face-to-face, causing them to indicate obstacles and then block each other.When I start three robots and continuously send tasks, this situation always occurs after a certain period of time.In this situation, the two robots will remain stationary until human intervention separates them. Is this a bug? May I ask for advice on how to prevent such a situation from occurring or how to resolve it ? |
The current state of the traffic negotiation system is not likely to find a solution when you have numerous robots moving left and right along a single bidirectional lane. This is called a "token swapping" problem and requires specialized solvers to be tractable for more than 2 agents. I'm working to incorporate token swapping techniques into the next generation of RMF traffic planning, but this type of scenario won't be feasible in the meantime. To make this scenario work, I recommend changing the single lane into two lanes that periodically connect, e.g.: This way robots can all go in either direction at the same time, e.g. robots going to the left will use the bottom lane while robots going to the right will use the top lane. The robots will generally prefer the lower lane if there are no conflicts, but will be able to use the upper lane to get around each other. |
This looks very useful, I will try it out. Thank you for your guidance! |
Before proceeding, is there an existing issue or discussion for this?
Description
I built a small map myself and placed 5 robots named TinyRobot 1, 2, 3, 4, and 5.
After randomly generating a series of tasks, the following situation arises. TinyRobots 1, 2, and 4 are stuck in the road and do not move, while they continuously generate plans in a loop. However, the destination of tinyRobot1 is on its left, and it is not blocked.
Moreover, according to the printed logs, only tinyRobot 2, 3, 4, and 5 participated in conflict negotiation (calculated from 0) and tinyRobot 1 did not trigger conflict negotiation.
May I ask what are the possible reasons for the plan being generated in a cycle but not being executed?
The text was updated successfully, but these errors were encountered: