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

The τ-∆t Problem #2

Open
raja-s opened this issue Nov 18, 2017 · 0 comments
Open

The τ-∆t Problem #2

raja-s opened this issue Nov 18, 2017 · 0 comments

Comments

@raja-s
Copy link
Owner

raja-s commented Nov 18, 2017

I refer to this as the “τ-∆t problem” because it all revolves around the choice of the values of τ and ∆t (which correspond to ORCA::tau_ and ORCA::deltaT_ in the implementation). Here's an explanation of these two values based on the paper:

  • τ represents the amount of time for which we want to “plan ahead”. More formally, it is the minimum amount of time in the future during which we want to guarantee that no collisions will occur between agents. So the greater the value of τ, the earlier agents will become aware of the presence of other agents moving closer to them.

  • ∆t represents the amount of time during which we want to move our agents with their new velocities obtained by planning ahead for τ time.

This means that the following constraint must hold: 0 < ∆t <= τ, otherwise collision-free navigation is not guaranteed.
To me, it makes sense to have ∆t significantly smaller than τ. If instead we set ∆t = τ, then when agents compute collision-free velocities, they will go all the way until they are literally stuck to one another at which point they recompute new velocities. That is because the ORCA algorithm is optimal by construction, in the sense that agents will deviate as little as possible to avoid collision.
Here's a screenshot of the demo running with this configuration:

demo-agents-stuck-resized

If we do set ∆t to be smaller than τ, agents will start slowing down smoothly as expected and deviate from their current trajectories when crowds start forming. The problem is that with this configuration, for some reason agents suddenly start penetrating one another and moving around while they're overlapping.
Here are two screenshots of the demo showing this effect:

demo-agents-overlap-1-resized
demo-agents-overlap-2-resized

Note that in a real-world application with physical robots for example, agents would obviously bump into one another instead, and the behavior from that point on would probably be undefined.

What confuses me even more is the fact that the formulation of the algorithm only mentions ∆t once, in the equation for updating positions at every iteration, and it doesn't say anything about the relationship between τ and ∆t.

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

No branches or pull requests

1 participant