RVO2-CS: reciprocal collision avoidance for C# agents

Each agent takes half of the responsibility for a collision

The algorithm is the point, and the README explains it well enough to judge whether it fits. Multiple independent mobile robots or agents need to avoid collisions with each other without communication among agents while moving in a common workspace. The formulation, optimal reciprocal collision avoidance, gives sufficient conditions for collision free motion by letting each agent take half of the responsibility of avoiding pairwise collisions.

That halves it in a specific sense. For every agent pair, each side treats the other as if it will keep half of the effort to stay clear, and the library computes the velocity that satisfies that assumption. The result is that agents slow down, veer, or stop in ways that no central coordinator issued.

The README states that selecting the optimal action for each agent is reduced to solving a low dimensional linear program, and that the resulting motions are smooth. Smoothness matters more than it sounds. A crowd that snaps to new directions every frame looks broken, and an avoidance layer that produces jittery motion gets disabled by game designers.

The same passage claims the approach was tested on dense and complex simulation workspaces involving thousands of agents, computing collision free actions for all of them in only a few milliseconds. That is a figure from the original research write-up reproduced in the README, not a measurement you can confirm from the repository, and the milliseconds figure depends entirely on agent count and hardware.

The API is a set of obstacles, agents, preferred velocities and a step call

The README describes the shape of the library in a few sentences. It is an open source C# .NET 10 implementation of the algorithm in two dimensions with a simple API for third party applications. The user specifies static obstacles, agents, and the preferred velocities of the agents. The simulation is then performed step by step via a simple call to the library.

That is a small surface, and small is a feature here. The preferred velocity is the interesting parameter, because it separates what an agent wants to do from what it is allowed to do. Your steering code says where the agent is heading, the library computes what it can actually do while avoiding everyone else, and the two do not have to agree.

The last sentence of the description is the one game and robotics developers care about: the simulation is fully accessible and manipulable during runtime. Obstacles, agents and velocities can be added, removed or changed between steps, which is what makes the library usable in a live scene rather than a pre-baked path.

What the README does not provide is the class and method names. It describes the API rather than listing it, so you should expect to read the source under RVOCS/ to learn the exact type names before writing the first call.

Two dimensions only, and the README says so in one phrase

The scope limit is stated in the same sentence as the .NET version: it is an implementation of the algorithm in two dimensions. There is no mention of a three dimensional variant anywhere in the README, and the repository root contains no separate dimension or axis handling that suggests one is planned.

This is the first thing to check against your project, because it is the constraint most likely to end the evaluation. If your agents move in a building with floors, in a flight simulation, or in a volume where height matters, this library does not model that dimension. You would have to project to a plane, decide which plane, and accept that the avoidance reasoning is only valid in that slice.

The second limit is conceptual and comes from the algorithm itself. ORCA assumes agents are independent and do not communicate. That is its strength in a large crowd, and also its constraint. If your agents need to negotiate, form formations, yield to a traffic controller, or follow a shared plan, that logic has to live outside this library. The README describes no mechanism for passing intent between agents.

Where the code comes from and how the build is set up

There is no install command in the README and no package feed is named, so the honest description is that you obtain the source from the repository. The project homepage is listed at gamma.cs.unc.edu/RVO2/, which the README also links as the reference for the algorithm and its authors.

The repository root is more tooled than a typical research port. It contains a CMakeLists.txt with CMakePresets.json and CTestConfig.cmake for a CMake build, a BUILD.bazel with MODULE.bazel and .bazelversion for a Bazel build, and RVOCS.slnx for the .NET solution. There is a global.json, which pins the SDK the project expects, and the README describes the library as targeting .NET 10.

Alongside the library there are directories named Blocks, Circle and RVOCS, plus a doc directory and an examples area. The names Blocks and Circle suggest scenario or benchmark shapes rather than API modules, which fits the research origins of the project, though the README does not describe their contents.

Project hygiene is handled with tooling you can see in the root: a .pre-commit-config.yaml, a .yamllint.yaml, a renovate.json for dependency updates, and a CITATION.cff for citation metadata.

The dev container builds on ubuntu:26.04 and mounts the workspace

For contributors, the repository ships a container setup. The Dockerfile starts from a current Ubuntu base and carries labels that record the authorship, the licence and the upstream source, with the image version labelled as 2.1.0.

FROM ubuntu:26.04
ARG TARGETARCH
LABEL org.opencontainers.image.authors="Jur van den Berg, Stephen J. Guy, Jamie Snape, Ming C. Lin, Dinesh Manocha"
LABEL org.opencontainers.image.licenses="Apache-2.0"

A compose file defines a single dev service that builds from that Dockerfile and mounts the working directory into the container, so edits on the host are immediately visible inside.

services:
  dev:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/workspace:cached

The mount is what makes the container usable for development rather than just for producing an image. A .devcontainer directory is also present, which is the mechanism editors like Visual Studio Code use to open the same environment.

There is also a Brewfile for macOS dependency setup and a requirements.txt that pins cffconvert and reuse, the two Python tools used to validate the CITATION.cff file and the SPDX licensing metadata in comments and files.

Two licences in one repository, which needs reading before reuse

The repository is under Apache-2.0, and the LICENSE file, the REUSE metadata and the SPDX headers in the source files all say so. The Dockerfile repeats it as an image label.

The README complicates that picture. Its opening HTML comment carries a Creative Commons Attribution-ShareAlike 4.0 notice for the README content itself, while the REUSE-IgnoreStart and REUSE-IgnoreEnd markers further down carry the Apache-2.0 block for the library description. The original RVO2 work is credited to Jur van den Berg, Stephen J. Guy, Jamie Snape, Ming C. Lin and Dinesh Manocha at the University of North Carolina at Chapel Hill, with bug reports directed at [email protected].

Practical advice, without pretending to be legal advice: if you copy code from RVOCS/ into your own project, the Apache-2.0 terms on those files apply to what you take, and you should keep the copyright and licence headers intact and note your modifications. If you reuse the README prose itself, check which of the two notices governs the passage you are copying, because the file contains both. The LICENSES/ directory and the reuse tooling exist to keep that metadata machine checkable, which is a good sign that the ambiguity is being managed rather than ignored.

Old release tags, recent commits

Maintenance facts here need care, because the version numbers and the commit dates point in different directions.

The listed releases are v2.0.1 on 2016-05-11 and v2.0 on 2015-12-08. Those are old tags, and anyone looking for a package feed version will notice them. Meanwhile the last push to the repository was on 2026-10-14, only days before this writing, and the Dockerfile labels the image as version 2.1.0. The active work is in the repository rather than in published tags, which is common for a library whose consumers build it from source.

The project also carries a Zenodo DOI badge and a CITATION.cff file, which means it is intended to be cited as a research artefact. The upstream RVO2 page remains the canonical reference for the algorithm itself, and the README links to it from the top.

For anyone planning an adoption, the practical consequence is that you should pin to a specific commit rather than expect a tagged package to appear, and you should read the CHANGELOG or commit log yourself before assuming the C# port matches the behaviour described in the original research pages.

Editorial conclusion

RVO2-CS is the right pick when you have many agents that need to move through the same space without talking to each other, especially in a game engine or a robotics simulator where you already handle paths and want only the local avoidance layer. It is the wrong pick for a single robot that needs global route planning, for three dimensional motion, or for agents that must coordinate explicitly, since ORCA assumes agents act independently and each takes half the responsibility for a collision. Before you build against it, check the target framework in global.json against your own runtime, because the project describes itself as a .NET 10 implementation, and read the source under RVOCS/ to confirm the class names and the step call, since the README describes the API in prose rather than listing it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. snape/RVO2-CS on GitHub