Livox SDK2 gives C and C++ programs a point cloud stream from Livox lidars

The SDK is three pieces, and the protocol is public

Livox SDK2 is a software development kit designed for all Livox lidars such as the HAP and the Mid-360, developed in C and C++ following the Livox SDK2 communication protocol, and it provides easy to use C style APIs so that users can quickly connect to the lidars and receive point cloud data.

The repository splits into three parts, and the README names them. There is the Livox SDK2 core code under sdk_core, the Livox SDK2 APIs in the header file include/livox_lidar_api.h, and three samples under samples.

The fourth thing worth noticing is that the communication protocol itself opens to all users. It is the protocol between user programs and Livox products, and it consists of control commands and the data format. The README links the Mid-360(S) protocol documentation in both Chinese and English, and the HAP protocol documentation in both languages as well.

That is the significant strategic fact about this SDK. The wire format is documented, so a team that outgrows the SDK can implement the protocol directly, and a team that wants to check the SDK's behaviour can compare them. For hardware whose protocol is closed, neither of those is possible.

Building on Ubuntu, and where the files land

The prerequisites are modest. The supported operating systems are Ubuntu 18.04 or above and Windows 10 or 11, the compilers need to support C++11, and CMake 3.0 or newer is required. Architectures listed are x86 and ARM, which matters because a lidar is usually mounted on a robot rather than on a workstation.

On Ubuntu the steps are the standard CMake sequence, and the README writes them out:

$ sudo apt install cmake

and then the clone, configure, build and install:

$ git clone https://github.com/Livox-SDK/Livox-SDK2.git
$ cd ./Livox-SDK2/
$ mkdir build
$ cd build
$ cmake .. && make -j
$ sudo make install

The install location matters for anyone packaging this. The generated shared library and static library are installed to /usr/local/lib, and the header files to /usr/local/include. The README also documents how to remove it again, by deleting the liblivox_lidar_sdk_ files and the livox_lidar_ headers, which is the kind of uninstall note that matters when a robot image is built by a script.

The parallel make is worth noting for a build that runs in CI, and the whole sequence is quick enough to run on every image build.

Windows builds use Visual Studio generators

On Windows the dependencies are Visual Studio 2019 and CMake 3.0 or newer, and the flow is the Visual Studio one. You clone and create a build directory with the md command:

> git clone https://github.com/Livox-SDK/Livox-SDK2.git
> cd Livox-SDK2
> md build && cd build

Then the project is generated, and the generator flag is the decision that matters because it selects the architecture:

> cmake .. -G "Visual Studio 16 2019" -A x64

or, for a 32-bit project:

> cmake .. -G "Visual Studio 16 2019" -A Win32

After that you compile in Visual Studio 2019, as the README says.

The two-step Windows process is the slow path compared with the Linux one, and it is the path you follow if you are developing on a workstation and deploying to a robot. The samples are built as part of the Visual Studio solution, which is why the sample instructions later point at the executables in the build samples directories under Debug or Release.

The three samples, and what each one is for

The SDK includes three samples, and they are the fastest way to see the SDK work on real hardware. They are the quick start program, the logger, and the multi-lidars upgrade tool.

The quick start sample connects to the lidar and shows that data is arriving. On Ubuntu you run it from its directory with a config file argument:

$ cd samples/livox_lidar_quick_start && ./livox_lidar_quick_start ../../../samples/livox_lidar_quick_start/[config file]

and the expected output shows the data handle initialising and a detection channel being created:

> [info] Data Handle Init Succ.  [data_handler.cpp] [Init] [42]
> [info] Create detection channel detection socket:0  [device_manager.cpp] [CreateDetectionChannel] [232]

The logger sample records lidar data, and it takes its parameters from a JSON config file, either hap_config.json or mid360_config.json. The three documented parameters are lidar_log_enable, which is true by default, lidar_log_cache_size_MB, which is 500, and lidar_log_path, which is the current directory. It runs the same way, from its own directory with a config file argument.

The multi-lidars upgrade sample is the one with a consequence. It takes a config file and a firmware file path, and after it runs the lidar stops and the firmware upgrade starts, with the progress printed on the terminal and a success message when it finishes. That is a device management capability, not just a data path, and it is worth understanding that a firmware write is happening when you run it.

The config file describes your network

Every sample takes a config file, and the basic config sample lists the required fields. The structure is per model, with a section for the lidar family, and inside it the network information:

{
  "HAP": {
    "lidar_net_info" : {
      "cmd_data_port"  : 56000,
      "push_msg_port"  : 0,
      "point_data_port": 57000,
      "imu_data_port"  : 58000,
      "log_data_port"  : 59000
    },

The port names tell you what travels where. The command port is where commands go, the push message port is where the device pushes, the point data port is where the point cloud arrives, the IMU port is for inertial data, and the log port is for the device's own logging. The push message port defaults to zero in the sample, which suggests it is optional.

Below that sits the host network information, a list of entries with the lidar addresses, so one config file describes both sides of the conversation. That structure is why a multi-lidar setup needs a config file edited carefully rather than a set of command line flags.

The README notes that the config file name in the command represents the config file name, and that you can choose a different one depending on your needs, so the samples ship templates for both supported sensor families.

The samples directory holds more than the three programs

The README describes three samples, and the repository listing shows more directories under samples than that. There is a CMakeLists.txt for the samples, and then directories for debug_point_cloud, lidar_cmd_observer, livox_lidar_info_get, livox_lidar_ip_set, livox_lidar_quick_start, livox_lidar_rmc_time_sync, logger and multi_lidars_upgrade.

Those names describe the surface of the SDK quite precisely, and it is worth reading them as a feature list. There is a sample for debugging point cloud data, one for observing lidar commands, one for getting device information, one for setting the lidar IP address, one for time synchronisation, and the quick start for connecting.

The set tells you the SDK covers more than reception. You can configure the device on the network, you can inspect what it reports about itself, you can watch the command channel, and you can synchronise time with the device, which matters for any system that fuses lidar data with other sensors and needs the timestamps to line up.

The top-level entries support the same picture. There is an include directory holding the public API header, an sdk_core directory with the implementation, a 3rdparty directory for the bundled dependencies, a CMakeLists.txt, a CHANGELOG.md, a LICENSE.txt and the samples.

Where this SDK is the wrong choice

The first limit is the hardware scope. This is a SDK for Livox lidars, and both the API and the config file are shaped around those devices, with model sections for the HAP and the Mid-360. If your fleet includes sensors from another vendor, this SDK does not abstract that away, and you will end up with one integration path per vendor.

The second is the release rhythm. The recent tags are v1.3.1 from 2026-04-15, v1.2.5 from 2024-02-18 and v1.2.4 from 2023-11-20, so there is a gap of more than two years between 1.2.5 and 1.3.1. The last push was on 2026-09-21 and the repository is not archived, so work happens, but for a project embedded in a robot you should expect to vendor and maintain the SDK yourself rather than expect a release train.

The third is the platform story. Linux and Windows are the documented targets, and while ARM is listed as an architecture, the sample instructions are for x86 workstations, so an ARM robot build is on you.

The fourth is the API style. The SDK is deliberately C style, which is good for embedding in an existing C codebase and for a stable ABI, and it is less pleasant than a C++ wrapper if you prefer RAII and containers. The upside is that the C style API is easy to bind to other languages, which is often the reason to choose it.

And the fifth is the licence, which the repository records as a custom licence that GitHub cannot classify. The LICENSE.txt file in the repository is the document to read, and for a commercial robotics product that reading is not optional.

Licence, releases and where the project stands

The licence is recorded as a custom one that GitHub cannot classify, with the LICENSE.txt file at the root of the repository as the reference. For a vendor SDK that is not unusual, since commercial terms and research terms sometimes differ, but it does mean the file has to be read rather than assumed.

The release history is v1.3.1 from 2026-04-15, v1.2.5 from 2024-02-18 and v1.2.4 from 2023-11-20, and the last push to the repository was on 2026-09-21, with the repository not archived. The changelog is at the root as CHANGELOG.md.

The primary language of the repository is C++, which matches the description of the SDK as developed in C and C++ while exposing a C style API. The C style interface is the deliberate part of the design: it can be called from C, it is straightforward to wrap in another language, and it does not impose a C++ object model on the caller.

The two supported sensor families are the HAP and the Mid-360, and the documentation for both is maintained in Chinese and English, with the Mid-360 documentation living on the Livox wiki and the HAP documentation in the repository's own wiki. For a team outside the Chinese market, the English versions are the ones to work from, and they exist for both protocols and both models.

Editorial conclusion

Livox SDK2 fits a robotics or perception team that runs Livox hardware and needs point cloud data and device control from a C or C++ program without reimplementing the wire protocol. It is the wrong tool if you want a hardware-neutral lidar abstraction, since the config file and the API are shaped around Livox devices, and the wrong tool if you need a maintained release cadence, because the version history is irregular. Before you build on it, check three things: that your sensor is one of the supported models, the HAP or the Mid-360, that you can supply a config file with the correct ports and lidar addresses for your network, and that you read the licence file in the repository, since the licence is recorded as one that GitHub cannot classify. The current release is v1.3.1 from 2026-04-15, the last push was on 2026-09-21, and the source is C++ with a CMake build for Linux, Windows and ARM.

Frequently asked questions

Official sources

1. Issues
2. Livox-SDK/Livox-SDK2 on GitHub
3. README
4. Releases