Sunday, March 21, 2010

Custom hRVO

I have tried to pick up my ever growing queue of interesting local avoidance / velocity planning methods. There are certain things I liked about my TOI-sampling scheme, but the results were not quite what I would like it to be.

One of the things that initially got me into creating the TOI-sampling scheme was an assumption that it is good idea to move at maximum velocity most of the time. In practice this seems to be a faulty assumption. It creates a rushing behavior, much a like a headless chicken running around. Especially in crowded situations.

So one thing I have have been pondering is that what might happen if I just removed that assumption and used huge amount of samples instead to test different speeds too. Much like what RVOlib does.

You can see the results in the above video. I think it is much improved now. I used the sample scoring scheme as my previous TOI sampling used. The good thing about it is that it handles all kinds of nasty things really well.

One problem that this custom hRVO suffers is aliasing. The H is in lower case as the method does not quite use the hybrid-RVO method, but does has similar side bias as HRVO does. As clearly visible from the take over situation with 4 agents, the agents favor to pass each other from right. This reduces velocity selection flickering a lot in head-to-head and overtaking situations.

Another trick I added was to favor velocities close to the current velocity. In my previous attempts this has always resulted the agents to favor the wrong solutions too much, resulting cases where the agents hug each other each other, skip towards the sundown and live happily ever after.

In this experiment I also used the pathfinder from the previous blog post to avoid static obstacles.

Anyways, I think this was a successful experiment, even if not completely practical because of the huge number of samples per agent. Inspired by the Geometric Methods of Multi-agent Collision Avoidance video, I think I'm going to try the ORCA method the next to see if I can get similar quality with cheaper calculations.


  1. Always interesting to read your blog :)

  2. I don't think you'll get the same quality using ORCA velocity obstacles, it seems it does 0 prediction. But for behavior LOD it seems great. Anyway I'm interested by your feeback !

  3. By prediction you mean to use multiple forward iterations when selecting the velocity?

    If so, the above implementation is not using it either. Usually you need a lot of precision to solve the example cases in the video, which means lots of samples to find the first good sample, which in turn means it is not very practical to do another iteration.

    It's kinda crappy that geometric methods are too exact, they tend to get into deadlocks really easily (see the 4 way case in that Geometric Methods of Multi-agent Collision Avoidance video), while ramdom sampling adds just enough noise there so that you get higher propability of gettings thigs resolved, and at the same it suffers from aliasing.

    If you have some experience on doing multiple forward iterations, I'd love to hear about it :)

  4. Correction: 4 way case = 5 agent case.

  5. I like your idea to sample movement possibilities based on different velocities a lot and am blown away by the results you show. I like this approach as it is very individual or entity based and because I assume that our brain is working (predicting) quite similar when we move.

    You say that the number of sampled needed per entity are too many - how many samples are we talking about?
    How many different velocities are you testing with (low-medium-high?)?
    Might it be possible to apply a metric to the "fitness" of a sample so you could first only run a few samples and if they don't fit the fitness metric more samples are run?


  6. For the sample locations, it uses 31x31 grid, where samples outside the circular area are thrown away. That is somewhere around 700 samples, which is a lot. But the resolution is not quite enough. I use jitter within single cell to improve the changes of getting better results. Works, but results are of course unpredictable.

    RVOlib uses 250 random samples. I tried that too, but the "head-to-head chicken in corridor" case cannot be solved with so few samples. Also some of the other tight locations become quite unpredictable with that little samples.

    The most costly part is the time-of-collision raycast, and I think it should be possible to just cast that into N directions and then deduce the slower/faster samples from that. I have try that later if this method proves to be good.

    Further, I think it should be possible to use some kind of focusing or edge aware adaption to further reduce the sample count. There is quite high temporal coherence there too.

  7. By 0 prediction I meant that ORCA (in the article examples) seems to avoid at the last possible moment resulting in lots of contacts between entities where RVO or HRVO tries to avoid collisions earlier (I'm not a good expert on those methods as I haven't implemented one yet).

    FYI the method I'm working on at Golaem involves a velocity space sampling method using only 200 samples and it works pretty well !

  8. I think the ORCA collision avoidance distance depends on how much the code is truncated. In case of ORCA, it is hard constrain, but with TOI sampling method, it is more softer constrain.

    Can you tell, how you distribute the samples?

    Can it handle similar cases like the 2 agents head-to-head in a corridor in above video?

  9. Awesome! Can't believe I just found your blog?!