PedVO explanation

[dkal3]

Hi!!! I hope that you are fine!!! I study PedVO algorithm. The source code and the dissertation. I have stuck at the chapter Turning. I have understood the philosophy but I try to understand how it has been implemented. I would be appreciate if you could help me to understand it.

562 float dx = det(prefDir, rx); 563 float dy = det(prefDir, ry); 564 _orcaLines[i]._direction.set(dx, dy); 565 _orcaLines[i]._point.set(p);

581 // rotate 582 float px = _orcaLines[i]._point prefDir; 583 float py = _orcaLines[i]._point n; 584 float dx = _orcaLines[i]._direction prefDir; 585 float dy = _orcaLines[i]._direction n; 586 // scale 587 py = turnInv; 588 dy = turnInv; 589 // set 590 _orcaLines[i]._point.set(px, py); 591 _orcaLines[i]._direction.set(norm(Vector2(dx, dy)));

These are the pieces of the code that seems difficult to understand. Where is the centripetal acceleration computed? Thank you in advance!!!

[curds01]

So, the key to this "turning" behavior is that it's not turning in the traditional sense. The basic ORCA-like optimization uses a simple Euclidian distance (in velocity space) for finding the "best" alternative to an otherwise infeasible preferred velocity.

Because it's Euclidian distance, that means a velocity that speeds up 0.1 m/s is equally good as one that maintains speed but turns (some small amount). The distances between the preferred velocity and those two options are the same.

What the turning code does is make the cost anisotropic. So, that turning that same amount is considered a better deviation than changing speed (or vice versa, depending on the penalty).

In practice, I didn't ever find that the turning in PedVO had significant behavioral impact. There would be subtle changes every now and then, but not as much as I'd hoped.

The feature that PedVO feature will truly benefit from (once I move the code over from my dead-end code) is planning with respect to way portals instead of way points. You can see the original paper here. It's the reason that preferred velocity is encoded the way it is in Menge. So, that the ecosystem is ready for me to change PedVO's optimization functions -- I just haven't done it in Menge yet. It's yet another mark of shame that I can't find the time to do it all.

So, moral of the story -- PedVO is in principle unique from ORCA in three ways: density sensitivity, turning bias, and way portals.

• density sensitivity is now equally available to all models by applying a velocity modifier.
• turning didn't have a significant impact.
• way portals is still waiting to be included in my Menge implementation.

Sorry 'bout that.

[dkal3]

Its all right!! Another question ! I would like to ask about Composite Agents. The idea of Composite Agents has been implemented to PedVO?

[curds01]

That question suggests you are the only person in the world to read my dissertation. Did you lose a bet? ;)

Nope. There are no composite agents in Menge. Sorry.

[dkal3]

Haha!! I am not a heroine!! So as not to bother you with questions all the time. I study the source code of PedVO algorithm and try to understand which parts of the dissertation have been implemented. -Priority - Right of way -Turning have been implemented. Am I right?

[curds01]

That is correct -- I'll push the way portals in and let you know when that happens.

I have CompositeAgents in some really antiquated code that isn't Menge-compatible, if you're interested. I'm torn about adding it to Menge. While it has value, it has limited value -- specific moments where it's really good, but, difficult to generalize. That's the joys of grad school -- you're rewarded for publishing papers more than you are for creating something of lasting value. :)

[dkal3]

OK, it does not matter. One last thing and we can close the issue. A limitation of PedVO is the optimization function. Could you give me an idea or refer me something to read to get some ideas of which alternative function can be used? Thank you very much!!!

[curds01]

Changing the optimization function is problematic. First I'd ask what you'd hope to achieve.

The basic ORCA model simply uses Euclidian distance in velocity space as the optimization function. That means it doesn't have any bias towards speeding up, slowing down, turning left, or turning right.

The "turning" behavior in PedVO attempts to give a slight bias beween speed changes and turning. The effect is small and it can't distinguish between speeding up and slowing down or turning left and turning right.

Way portals changes the optimization function by optimizing with respect to a space of velocities rather than a single velocity -- this generally helps the agents turn more while preserving speed.

The reformulation of the optimization function will affect what an agent does when the preferred velocity is not feasible. So, if you can articulate what you want the agent to do in that case and can find some mathematical basis for describing it, that's your optimization funciton.

For efficiency, you really want a convex optimization function. You're guaranteed, in some sense, a unique solution, one that can be easily defined by projecting the preferred velocity on the linear constraints. If the optimization isn't convex, you'll have to use a different optimization mechanism. For example, the original RVO had a highly non-convex optimization and used probabilistic sampling to find the best solution. It has some nice properties, but can be quite expensive.

So, do you have any more specific thoughts/questions about the optimization function?

[dkal3]

No, your answer is detailed!!! Thank you very much for your time!