# libsurvive: open source 6DoF tracking for Lighthouse and Vive hardware

> libsurvive is a C library and tool set that provides 6DoF pose for SteamVR 1.0 and 2.0 generation Lighthouse hardware on any device, including trackers and controllers, without running the headset itself. It fits developers building open VR stacks; it does not fit people who want a polished turnkey runtime.

**collabora/libsurvive** — Open Source Lighthouse Tracking System

- Repository: https://github.com/collabora/libsurvive
- Stars: 949 · Forks: 195
- Language: C
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/collabora-libsurvive

## libsurvive takes on tracking only, and leaves the headset to someone else

libsurvive is a set of tools and libraries that enable 6DoF tracking on Lighthouse and Vive based systems, and the scope is stated plainly in the project's own description: it is completely open source and can run on any device. It covers both SteamVR 1.0 and SteamVR 2.0 generation of devices, and the claim is that it should support any tracked object commercially available.

The boundary matters more than the feature list. The project says the focus is on tracking, and that it does not independently run the HMD. That is a deliberate architectural decision rather than a missing feature, and it means libsurvive slots underneath a display stack instead of replacing one. If your goal is to boot a headset, this is the wrong layer, and the documentation points you at monado as an open source stack that does that job.

The audience is therefore narrow and technical: people writing VR applications, tools or research rigs on top of Valve's lighthouse hardware who need pose data and want it to come from code they can read and modify. Language bindings exist for Python and C#, and the repository ships example applications including api_example.c, simple_pose_test.c, survive-solver.c and survive-buttons.c, which is the shape of a library that expects to be embedded rather than clicked through.

## Calibration is a first-run step that rewrites config.json under XDG_CONFIG_HOME

The most important mechanical detail in the project is how calibration is established and stored. Calibration is the process that works out where the lighthouses sit in relation to the tracked objects. On the first run it can take up to ten seconds to communicate with the base stations and determine their arrangement.

After that first run, calibration keeps integrating object data as long as objects are momentarily stationary, which is why you may see lighthouses appear to shift slightly while the solver gets a good lock. Later runs shift much less. The result is written to config.json inside XDG_CONFIG_HOME/libsurvive. Delete that file and the next run recalibrates from scratch, though the documentation notes it is faster to pass the --force-calibrate flag instead.

There is a wrinkle worth knowing about if you work with recorded data. Some drivers change the name of this file, and recordings use a different event file name instead, so a pipeline that reads config.json from disk will not see the same thing a live run produces. The config file is also a plain file you can copy between machines, which is useful when you want the same physical base station layout recognised on a second host without waiting through calibration again.

## On Debian the build is a clone, udev rules, a dependency line and make

The documented Debian path is short enough to read in one sitting. You clone the repository, copy the udev rules so devices are usable without root, install the build dependencies, and compile.

```bash
git clone https://github.com/cntools/libsurvive.git
cd libsurvive
sudo cp ./useful_files/81-vive.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules && udevadm trigger
sudo apt update && sudo apt install build-essential zlib1g-dev libx11-dev libusb-1.0-0-dev freeglut3-dev liblapacke-dev libopenblas-dev libatlas-base-dev cmake
make
```

The rules file is the piece people skip. Without it the devices are not accessible to an unprivileged user, and the copy step is followed by a reload and trigger so the change takes effect without a reboot. On Windows no equivalent step is needed.

The Makefile is a thin wrapper around CMake, creating a bin directory and configuring a RelWithDebInfo build.

```make
build:
	mkdir -p bin
	cd bin && cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo .. && cmake --build .  -j 4
```

Once it builds, the first real use is a single binary.

```bash
./bin/survive-cli
```

Plug in a headset, tracker or controller, run that, and it should calibrate and display your setup. Before you do, close SteamVR. The documentation is blunt about the consequence of leaving it running: libsurvive will either cause SteamVR to lose connection to the device or will compete with it for bandwidth.

## Visualisation runs through websocketd and a local HTML page

Seeing what the tracker is doing is a separate step from running it, and the mechanism is a websocket bridge rather than a built-in 3D viewer. For visualisation you can download a binary of websocketd, or enable the experimental apt source and install it with sudo apt install websocketd. With that in place, the documented command starts the bridge and opens the bundled tool.

```bash
./bin/survive-websocketd & xdg-open ./tools/viz/index.html
```

The index.html file lives in the tools directory of the repository, so the visualiser ships with the source tree rather than being a separate application. The websocketd approach is worth understanding, because it explains the shape of the whole tooling set: libsurvive publishes tracking data over a websocket, and anything that can talk to a websocket can consume the poses.

Windows follows the same idea with a PowerShell wrapper. The build output directory, ./build-win/Release if you used the script, contains a survive-websocketd.ps1 that can be run as a PowerShell file, and websocketd should behave the same way as long as it is somewhere on the system path.

For the simplest start on Windows, the documentation suggests the release binaries instead of a source build. If you have cmake on your path you can run the make.ps1 script by right clicking it and selecting Run with PowerShell, and a more manual route opens CMakeLists in something like CMake GUI and uses a Visual Studio generator, which also exposes the build options. That build pulls its development dependencies from NuGet.

## The project rates itself as working but not yet measured

The status section is unusually candid for a project of this kind, and it is the best source of expectations you can get. The tracking and device enumeration work fairly well at this point, but the documentation says there is not an extremely large testing base and that the tools are not as polished as the comparable ones bundled in SteamVR. Work is ongoing to quantify how accurate the tracking is and to improve the user experience.

That statement sets the ceiling for any production claim. Pose data flows, devices enumerate, but the accuracy and precision figures do not exist yet in the project, and the roadmap lists hard numbers on accuracy and precision as an open item. The documentation even invites contributors who can test on a CNC machine to help measure this, which tells you the measurement problem is real and unsolved rather than a documentation oversight.

Two further roadmap items shape day to day use. Dynamic correction of calibration would detect and silently recalibrate lighthouses that might have moved, with the stated end goal of a system where the user is never aware of any calibration requirements. Until that lands, a base station that gets nudged invalidates the stored geometry, and you find out through drift rather than a message. An Android binary or port is also on the agenda, and a Windows improvement would use something like usbmon.

The failure mode that is easiest to hit is data starvation. If the USB or radio connection stutters for too long, the tracking will occasionally glitch out for a brief period, and better handling of that is listed as a known gap rather than a solved problem.

## How libsurvive differs from monado and from the SteamVR tools

The realistic comparison is not with other tracking libraries but with two alternatives that sit at different layers. The first is monado, which the project itself points to for the job libsurvive declines. Monado is an open source stack that runs the HMD; libsurvive concentrates on the tracking of lighthouse and Vive devices and does not independently run the HMD. If your requirement is a complete runtime for the headset, monado is the answer and libsurvive is a component. If your requirement is pose data inside an application you already control, libsurvive is the answer and monado is beside the point.

The second alternative is the tooling that ships with SteamVR. The documentation makes the trade-off itself, saying the tools are not as polished as the comparable ones bundled in SteamVR. That comparison covers the user experience, the maturity of the interface, and the size of the testing base. What you get instead is source you can read, modify and embed, with Python and C# bindings for scripting, plus a websocket data path that lets you build a visualiser or an automated test rig of your own.

The open question is not capability but measurement. Whether a given application can live with the residual error depends on numbers the project has not published yet, and it depends on the physical setup of your own base stations.

## MIT licensing, active commits, and tagged releases that stopped in 2022

The licence field on the repository says MIT, which is a short permissive licence with no obligations around linking or redistribution of modifications beyond keeping the copyright notice. It is worth reading the LICENSE file yourself for the exact text, and none of this is legal advice. For a C library that you may link into an application, MIT removes most of the friction that proprietary SDKs introduce.

The activity picture is mixed in a way that the commit date alone hides. The repository is not archived, and the last push was on 2026-10-19, so work is happening on the tree. The tagged releases tell a different story: v1.0 landed on 2022-02-06, v1.01 on 2022-02-14, and v0.4 on 2020-10-22. So there is a long gap between the newest tag and the current head of the branch.

That gap is a practical upgrade question. Anyone installing from a release binary or a distribution package is picking up code from early 2022, while anyone building from master gets everything committed since, including the calibration and accuracy work that the roadmap describes. The build system supports both paths, with a Makefile, CMakeLists.txt, a make.ps1 script for Windows, a Dockerfile.ros for ROS environments, and packaging metadata in pyproject.toml and setup.py for the Python bindings, where the version string is derived from git describe at build time. When you pick a source, pick it deliberately rather than by accident.

## Conclusion

Use libsurvive when you are writing an application that needs 6DoF poses from Lighthouse or Vive trackers and cannot accept a closed runtime, and when you are prepared to handle calibration, udev rules and a rough tooling surface yourself. Do not expect a drop-in replacement for the SteamVR tools, since the project itself says its tools are less polished and that the accuracy numbers are still being quantified. Before depending on it, check that your Lighthouse base stations and tracked devices are supported, confirm the poses your application needs against your own measurements, and plan for the fact that a stalled USB or radio link will still produce brief tracking glitches.

## FAQ

### How do I build libsurvive on Debian?

Clone the repository, copy the 81-vive.rules file to /etc/udev/rules.d/ and reload the rules, install the listed apt dependencies including cmake and the lapacke and openblas development packages, then run make. The build is a CMake project driven by a small Makefile wrapper.

### Does libsurvive replace SteamVR and run the headset?

No. The project states that the focus is on tracking and that it does not independently run the HMD. For an open source stack that does run the headset, the documentation points to monado.

### How is calibration stored and can I force it to rerun?

Calibration results are saved in config.json inside XDG_CONFIG_HOME/libsurvive, and the first run can take up to ten seconds to work out the lighthouse positions. Deleting the file forces a recalibration, but the documentation suggests the --force-calibrate flag as the faster path.

### Can I run libsurvive while SteamVR is running?

The documentation advises closing SteamVR for the best results, because depending on the system libsurvive will either cause SteamVR to lose connection to the device or will compete with it for bandwidth.

### Is there a way to see the tracking data visually?

Yes, through websocketd. Install websocketd, then run ./bin/survive-websocketd & xdg-open ./tools/viz/index.html to open the bundled visualiser page. On Windows the build folder contains a survive-websocketd.ps1 wrapper for the same job.

## Sources

- [collabora/libsurvive on GitHub](https://github.com/collabora/libsurvive)
- [Issues](https://github.com/collabora/libsurvive/issues)
- [License: MIT](https://github.com/collabora/libsurvive/blob/master/LICENSE)
- [README](https://github.com/collabora/libsurvive/blob/master/README.md)
- [Releases](https://github.com/collabora/libsurvive/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/collabora-libsurvive