Ouster SDK: C++ and Python libraries for Ouster LiDAR sensors

The vendor toolkit for Ouster hardware

The Ouster SDK is a cross-platform C++ and Python Ouster sensor development toolkit, and the repository contains the source code for connecting to and configuring Ouster sensors and for reading and visualizing data.

The scope is deliberately narrow. These are the libraries and tools for Ouster's own LiDAR sensors, not a generic point cloud stack. That matters for evaluation, because the packet format, the sensor configuration protocol and the beam layout are all specific to the hardware. If you run mixed fleets, the Ouster part of your stack and the rest of it will not share a data model.

The release history shows the project reaching a stable line. The listed releases are OusterSDK Release 1.0.1 on 2026-08-13, OusterSDK Release 1.0.0 on 2026-07-17, and OusterSDK Release 0.16.2 on 2026-05-05. Moving from 0.16 to 1.0 in a single quarter is a semantic version reset, which usually means the API was allowed to change shape and that earlier 0.x code needs review before it compiles against 1.0.

The audience is a robotics or perception engineer who has Ouster sensors and needs to configure them, pull point clouds, record data and look at it. The documentation is split in two, with SDK documentation at docs.ouster.com/sdk-docs and separate public sensor documentation at docs.ouster.com/sensor-docs, and the README points at both.

The project is BSD 3-Clause licensed with a COPYRIGHT file and a LICENSE, and the last push was on 2026-10-17.

Six C++ components and a Python package

The repository layout is the architecture, and it splits into named components.

ouster_core contains the Ouster SDK core C++ library, which is where the client and the sensor interaction live. ouster_algorithm contains shared perception and mapping algorithms. ouster_pcap contains C++ pcap functions for Ouster sensors, which is the packet capture and replay path. ouster_osf contains the C++ OSF library for storing Ouster sensor data. ouster_viz contains a customizable point cloud visualizer. The python directory holds the code for the Ouster sensor Python SDK, distributed as the ouster-sdk package.

There are also directories that the README's component list does not mention, and they are worth noticing because they tell you the SDK has grown beyond the original six. There is ouster_library, ouster_mapping, ouster_perception and ouster_sensor as top-level directories, alongside a thirdparty/ directory and a vcpkg.json, which is how the C++ dependencies are declared for the vcpkg package manager.

The build system is CMake, with a top-level CMakeLists.txt, a cmake/ directory of modules, CMakeSettings.json for Visual Studio users, a Jenkinsfile for continuous integration, and a .clang-format plus .clang-tidy for formatting and linting the C++. There is a .clangd file for the clangd language server. A Dockerfile and .dockerignore sit at the root, and a VERSION file records the version.

The split between OSF and pcap is the one that will affect your workflow most, so it is worth saying plainly: pcap is the familiar packet capture format, and OSF is the Ouster format for storing sensor data, with its own C++ library here. If you need to replay a recording into a pipeline later, the choice of format is a decision you make at capture time, not afterwards.

The examples directory is the usage documentation

The examples/ directory is the most useful thing in the repository for learning the API, and its file names read like a table of contents of what the SDK can do.

There is a client_example.cpp and a client_packet_example.cpp for talking to a sensor, a cluster_example.cpp for multi-sensor setups, and a config_example.cpp for sensor configuration. There is a lidar_frame_example.cpp, a frame_set_source_example.cpp and a representations_example.cpp for working with the different ways the SDK hands you data.

The OSF pair, osf_reader_example.cpp and osf_writer_example.cpp, shows the read and write sides of the Ouster format, and a slam_example.cpp indicates that a mapping workload is a supported scenario. The visualizer examples are the densest group: viz_example.cpp, viz_events_example.cpp, viz_mesh_example.cpp, viz_notifications_example.cpp, viz_screenshot_example.cpp, and two zone_monitor files for zone set and zone states.

The linking examples are the ones to look at if you are integrating the C++ library. There is a static_linking_example, a shared_linking_example and a compiled_in_linking_example, which between them cover the three ways a consumer normally pulls the SDK into a build, and they exist because getting linkage right against a native C++ library with a visualization layer is a real task rather than a formality. A helpers.cpp and helpers.h sit alongside them, and cxxopts.hpp is vendored in for command line parsing.

There is also an examples/hil/ directory, for hardware in the loop. Its presence says the SDK is expected to be exercised against real hardware in CI, not only against recorded data.

Installing the Python package and the split with ROS

The Python package is published on PyPI as ouster-sdk, and the README gives both an upgrade and a fresh install command.

For an upgrade:

python3 -m pip install --upgrade ouster-sdk

For a fresh install:

python3 -m pip install ouster-sdk

The C++ side is not installed the same way. The README does not give a build or install command for the C++ libraries, so a C++ consumer follows the SDK documentation rather than a command in the readme, and the vcpkg.json plus the CMake modules in the cmake/ directory are the visible machinery for that path.

The other thing to know before you start is where the ROS driver went. The README carries a note that Ouster ROS driver code has been moved out to a separate GitHub repository, with a pointer to github.com/ouster-lidar/ouster-ros and the instruction to follow the instructions on that repository's main page. If your plan involved a ROS integration, you are planning against two repositories, and the versioning between them is not something the SDK repository manages.

Support is split three ways, which is a sensible division for a vendor. SDK support goes through GitHub Issues in this repository. Community discussion goes to the Ouster Community Forum at community.ouster.com. Support for Ouster products outside the SDK goes to Ouster Customer Support. And for suspected security problems there is a dedicated address, [email protected], rather than the public issue tracker.

Where the SDK stops and the sensor documentation starts

There are three boundaries worth naming before you commit, and they are all visible in the repository rather than hidden.

The first is the split between the SDK and the sensor itself. The README points to two separate documentation sets, one for the SDK and one for the public sensor documentation, and the repository is described as the code for connecting to and configuring sensors. Configuration semantics, the meaning of the returned metadata and the behaviour of a particular firmware release live in the sensor documentation, not here. A change in sensor firmware can change what your code sees without a change in the SDK.

The second is that this is Ouster hardware only. The parsing, the beam layout, the metadata model and the configuration protocol are all specific to these sensors, and there is no abstraction layer here that would let you point the same code at a different vendor's LiDAR.

The third is the 1.0 boundary. A code base written against 0.16 is not a 1.0 code base, and the SDK's own changelog in CHANGELOG.rst is where you would find out what changed. There is no compatibility promise stated in the readme for the 0.x to 1.0 transition, so treat the changelog as the authority rather than assuming the semver rules were followed in spirit.

The visualizer is worth calling out on its own because it is a distinct product surface. ouster_viz is described as a customizable point cloud visualizer, and the examples directory contains screenshots, events, mesh and notification examples alongside the basic one, which means the visualizer is a first-class deliverable with its own event and notification model, not a debugging aid.

None of this makes the SDK hard to adopt. It makes it a vendor tool with a vendor's boundaries, which is the right shape if your sensors are Ouster sensors.

Editorial conclusion

Adopt the Ouster SDK if you are building against Ouster LiDAR hardware in C++ or Python and want the vendor's client, configuration and data handling rather than writing packet parsing yourself. Do not adopt it for a different LiDAR vendor's hardware, since the parsing and configuration model is sensor specific, and do not expect the ROS integration to arrive with it, because that has moved to the separate ouster-ros repository. Verify first that the release you pick is on the 1.0 line rather than 0.16, that the sensor firmware and SDK versions you are pairing are supported together, and that you understand what the OSF format gives you over a plain pcap before you commit to it as your recording format.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. ouster-lidar/ouster-sdk on GitHub
3. Project website
4. README
5. Releases