Skip to content
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

Handling Collisions with Limited 3x3 FOV #3

Open
Tviskaron opened this issue Sep 23, 2023 · 3 comments
Open

Handling Collisions with Limited 3x3 FOV #3

Tviskaron opened this issue Sep 23, 2023 · 3 comments

Comments

@Tviskaron
Copy link

Tviskaron commented Sep 23, 2023

Hello!

First off, thank you for your work on the SCRIMP paper. It presents an intriguing approach to the challenges problem.

One aspect I'm curious about is how SCRIMP handles potential collisions with a very restricted 3x3 FOV. To paint a picture, consider a scenario where two agents (agents A [moving right] and B [moving left]) are in a narrow corridor with just a single cell between them, such that they're outside each other's FOVs:

#####
.A.B.
#####

Given their limited visibility, how does the system ensure these agents avoid collisions in real-time? Does the global communication mechanism based on the modified transformer help in such close-quartered scenarios, or are there other components of the system that play a role in avoiding potential conflicts in such situations?

@wyt2019suzhou
Copy link
Collaborator

Hello!
I have not tried to visualize how the model works in such narrow corridor problem. But I think both the global communication and the tie-breaking strategy proposed in the paper can deal with this situation. In particular, before a collision occurs, the tie-breaking strategy will force only one agent to be allowed to perform its original action, while the other agent will perform a new valid action. In this example, if A and B will meet in the blank grid in the middle of the corridor, and assuming that B is always allowed to perform its original action (left), then the valid action for A will be left and stay. If A choose stay, then in the next step, the only valid action for A is left. Eventually, B will walk through the corridor, while A will continue to walk back until it is completely out of the corridor. But that's just a perfect assumption; in an actual task, B might not always be the favoured agent, and then A and B might be stuck in the corridor until the end of the episode. So, my future work will be on how to choose the right agent and allow agents to perform more than just one action when breaking the breaking.

@Tviskaron
Copy link
Author

Thank you for your detailed response. I am particularly intrigued by the specifics of the communication and tie-breaking mechanisms in SCRIMP, especially within a decentralized framework. Could you provide more details on the type of information exchanged between agents during these phases? Additionally, is the communication process based on multiple rounds, or does it utilize a global information channel?

On another note, I recommend exploring lookahead techniques like Monte Carlo Tree Search to further refine the tie-breaking strategy. Our recent paper https://arxiv.org/pdf/2312.15908.pdf delves into similar methodologies and might provide some valuable insights for your research.

@LiWang1580
Copy link

Hello author,when installing modules according to txt in readme, networkx2.8.8 is inconsistent with python3.7. How can I solve it? Thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants