# OrbbecSDK v1: the OpenNI-compatible branch for legacy Orbbec depth cameras > OrbbecSDK's main branch is the v1 line, a pre-compiled C SDK that still speaks the OpenNI protocol to older Astra and Gemini hardware. This review covers what it does, how a first build is wired up, and when you should be on v2 instead. **orbbec/OrbbecSDK** — Orbbec SDK v1&v2 Pre-Compiled Repo - Repository: https://github.com/orbbec/OrbbecSDK - Website: https://www.orbbec3d.com/ - Stars: 318 · Forks: 51 - Language: C - License: NOASSERTION - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/orbbec-orbbecsdk ## What OrbbecSDK v1 is for, and who should not use it OrbbecSDK is a camera SDK for Orbbec depth cameras, written primarily in C with C++ examples. The main branch is the v1 line, currently at version 1.10.37, and its distinguishing feature is protocol coverage: the README states that this branch is compatible with Orbbec's original OpenNI protocol devices through built-in code, so one codebase can drive both older and newer products. That sentence is the whole reason the v1 branch still exists after v2 shipped. The audience is narrower than the repository name suggests. This is for teams with an existing Orbbec camera in hand, usually one already deployed in a robot, kiosk, or scanning rig, who need a supported driver path. It is not a general-purpose 3D vision library. If you are choosing a camera for a new product, the support table is the first thing to read, because several current models are marked not supported on v1: Gemini 305, Gemini 305g, Gemini 345, Gemini 345Lg, Gemini 435Le, Gemini 335Le, Gemini 335Lg, Gemini 215, Gemini 210, and both Pulsar LiDAR models. For all of those, the table points to Orbbec SDK v2. The reverse case is the interesting one. Gemini 2 XL is marked recommended for new designs on v1 and not supported on v2. Astra+ and Astra Pro Plus are limited maintenance on v1 and not supported on v2. If you own one of those three, v1 is not a legacy fallback, it is the only supported branch. That asymmetry, not the version number, should drive the decision. ## Architecture: a CMake C library with pre-compiled binaries and C/C++ examples The repository layout is conventional for a C SDK distributed as binaries plus headers. The top level holds CMakeLists.txt, OrbbecSDKConfig.cmake, OrbbecSDK.pc.in, package.xml, and the include/, lib/, examples/, doc/, and misc/ directories. The include/ and lib/ split means you link against a pre-built library rather than compiling the driver from source, which is why the repository description calls itself a pre-compiled repo. The pkg-config template and the CMake config file are two supported ways for a downstream build to find the library. Examples are organized by language: examples/c/ and examples/cpp/, with their own CMakeLists.txt and separate README files for English and Chinese. That structure tells you the intended integration path is a CMake project that pulls in OrbbecSDK as a dependency and then calls the C API, with the C++ examples as the readable reference. The presence of package.xml is consistent with ROS-style packaging, though the README does not document a ROS 2 workflow on this branch. The device layer is where the two protocols meet. The README says OpenNI protocol support is built into this branch, while v2 targets UVC-standard USB products. That is a firmware-level distinction, not a wrapper: Astra Mini Pro and Astra Mini S Pro use different communication protocols in firmware v1.x.x and v2.x.x, and the README is explicit that v1 supports only v1.x.x firmware while v2 supports only v2.x.x. There is no runtime negotiation that papers over this. ## Wiring up a build and getting a first depth stream The README does not contain a step-by-step install guide. It points to a device support list and, for users in China, recommends the Gitee mirror instead of GitHub. The repository itself ships CMake config files and pre-compiled libraries, so the practical path is: obtain the package, place it somewhere your build can find it, and let CMake resolve it. The examples directory is the reference for what a working program looks like, and examples/README.md is the file to read first. A downstream CMake project locates the package through the config file the repository provides, OrbbecSDKConfig.cmake. The README does not publish the imported target name, so open that config file and read the target it defines before writing your link line. For non-CMake builds, OrbbecSDK.pc.in indicates a pkg-config file is generated, which means a Makefile can consume pkg-config flags instead. The repository does not show the contents of either file in the README, so there is no snippet to copy here; the file itself is the source. Once the package resolves, the C++ examples under examples/cpp/ are the fastest path to a first frame. The repository does not publish the API call sequence in the README, so treat the example sources as the specification: build one of them with the same CMake setup, run it with the camera connected over USB, and confirm that a depth stream starts. If no device is detected, the support table is the first thing to check, because a model marked not supported on v1 will not appear no matter how the build is configured. ## The firmware and model matrix is the real failure mode Most SDK integration problems are build problems. This one is a purchasing and firmware problem, and it fails in ways that look like software bugs. Three concrete traps stand out in the README. First, a device can be supported by both branches but require a different minimum firmware version in each. The README calls this out directly and tells you to consult the Supported Devices list for details. A camera that works on v1 today may need a firmware update before it works on v2, and that update may not be reversible in the field. Second, the Astra Mini Pro and Astra Mini S Pro case is a hard fork. Firmware v1.x.x speaks one protocol, v2.x.x speaks another, and each SDK supports exactly one. If you upgrade the firmware to move to v2, you cannot go back to v1 without downgrading firmware, and the README points to a separate migration document on the v2 repository rather than covering the downgrade path here. Third, the maintenance tiers are not equivalent. The README defines recommended for new designs as full support with new features, bug fixes, and performance optimization; full maintenance as bug fix support; and limited maintenance as critical bug fix support. Astra+ and Astra Pro Plus sit in limited maintenance on v1 and are not supported on v2, which means the only branch that runs them receives critical fixes only. That is a legitimate state for a deployed fleet and a poor state for a product you plan to ship for years. ## Orbbec SDK v2 is the alternative, and the difference is protocol, not features The obvious alternative is Orbbec SDK v2, maintained in a separate repository. The distinction is not a feature set or an API generation: v2 drops OpenNI protocol support and targets Orbbec USB products that follow the UVC standard. The README states that v2 no longer supports legacy OpenNI devices, which continue to receive bug fixes in the v1 branch. That single change explains the entire support table. Every model marked recommended for new designs on v2 is a UVC device. Every model that only v1 can drive is a legacy OpenNI device, or in the Gemini 2 XL case a device the table simply assigns to v1. So the choice is mechanical: identify your camera's protocol generation, and the SDK follows. If you have a mixed fleet, you are maintaining two integrations, because the README does not describe a single binary that handles both. There is a second practical difference. The README encourages checking whether your device is supported by v2 and using the new release if it is, which signals that v2 is where new work is expected. Staying on v1 for a UVC-capable camera means opting out of that direction, and the table's full maintenance tier for models like Gemini 335 and Femto Bolt is a bug-fix commitment, not a feature commitment. ## Licence, packaging, and what upgrading actually costs The repository's licence is reported as NOASSERTION, meaning the automated classifier could not map LICENSE.txt to a known identifier. LICENSE.txt exists at the top level, so the terms are stated, but you have to read the file itself before shipping anything. Nothing in the README summarizes redistribution or linking terms, and I would not treat a camera SDK's licence as interchangeable with a permissive open source licence without reading it. That is a factual gap, not legal advice. Upgrade cost has two components. The SDK side is small if you stay within a branch: releases are tagged, the current one is v1.10.37, and the previous two were v1.10.35 and v1.10.27, so the cadence is roughly a few releases a year. Linking against a tagged release and reading its release notes is a manageable process. The hardware side is where the cost sits. Moving from v1 to v2 for a model supported by both branches may require a firmware update, and for the Astra Mini Pro and Astra Mini S Pro it definitely does. Firmware updates on deployed robots or installed kiosks are field operations, not build steps. If your fleet is large, price that in before treating v2 as a simple dependency bump. Also note the README's recommendation that users in China pull from the Gitee mirror, which affects which artifact you pin in a build system that fetches dependencies automatically. ## Conclusion Adopt OrbbecSDK v1 only if your hardware is on the v1 support table and v2 lists it as not supported: the Astra+ and Astra Pro Plus (limited maintenance), or Gemini 2 XL (recommended for new designs on v1 only). If your camera is a Gemini 305, 345, 335Le, 435Le, or a Pulsar LiDAR, the v1 branch marks it not supported and v2 is the correct target. Before committing, verify three things: your exact model against the support table, the minimum firmware version for that model in the SDK you choose, and whether your toolchain matches the pre-compiled libraries under lib/. The Astra Mini Pro and Astra Mini S Pro are the sharpest edge case, because v1 supports only v1.x.x firmware and v2 supports only v2.x.x, so the SDK choice is effectively a firmware decision you cannot reverse casually. ## FAQ ### What is Orbbec SDK? It is a C/C++ SDK for Orbbec depth cameras, distributed as a pre-compiled library with headers, CMake config files, and C and C++ examples. The main branch is the v1 line, version 1.10.37, and it is compatible with Orbbec's original OpenNI protocol devices through built-in code. ### How to install Orbbec SDK? The README does not give a step-by-step install procedure. It ships pre-compiled libraries under lib/, a CMake package config (OrbbecSDKConfig.cmake), a pkg-config template (OrbbecSDK.pc.in), and examples/README.md as the starting point. Users in China are advised to use the Gitee mirror. ### how to install orbbec sdk There is no documented installer. Integration is done by pointing a CMake or pkg-config build at the shipped library and headers, then building one of the examples in examples/c/ or examples/cpp/ to confirm the camera is detected. ## Sources - [Issues](https://github.com/orbbec/OrbbecSDK/issues) - [orbbec/OrbbecSDK on GitHub](https://github.com/orbbec/OrbbecSDK) - [Project website](https://www.orbbec3d.com/) - [README](https://github.com/orbbec/OrbbecSDK/blob/main/README.md) - [Releases](https://github.com/orbbec/OrbbecSDK/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/orbbec-orbbecsdk