Open Source RoboticsRobots, software & learning

YDLidar SDK

Software

YDLidar SDK implements sensor communication and scan APIs with C/C++ source and language bindings. [1] [2] [3] [4]

Installation & first result →Official websiteGetting started

For
Robotics developers selecting a concrete sensor, interface or simulation workflow [1] [2] [3] [4]
Source rights
Named licenses are documented by part. Review licenses
Unknowns
operating system, compute requirements not fully established. Review gaps

Source researched · Not tested by us
Sources checked · Research details

Licenses & related hardware

Requirements · Research details and dates

On this page

Overview

YDLidar SDK implements sensor communication and scan APIs with C/C++ source and language bindings. It supports serial/network-related routes described by the upstream protocol documentation. This profile concerns that interface implementation, not the manufacturing design or firmware of every YDLIDAR device. [1] [4]

Is this for you?

Known limitations
  • Historicalplatform/Python instructions do not establish a currenttestedbuild.
  • Defaultsensorparameters and MITidentifiedportions mustnotbe applied blindly to everydevice/file.

Editorial assessment of cited source; no runtime or hardware test.

[1] [2] [3] [4] · Editorial assessment

What you need

Dependencies
  • DocumentedCMake>=2.8.2 and C++build route; Pythonbindings additionally requireSWIG
  • Sensor-specific serial/network/adapter and model/baud configuration

[1] [2] [3] [4]

Installation & first result

Open the upstream getting-started guide [1] [2] [3] [4]

  • Select the named hardware/model and corresponding source configuration before installation.
  • Follow the cited starting route while keeping package, device and firmware versions matched; no operation reproduced here.

Editorial assessment of cited source; no runtime or hardware test.

[1] [2] [3] [4] · Editorial assessment

Installation

C++11 compiler and CMake >=2.8.2, build directory/cmake/make/install route; documented Ubuntu Python bindings additionally require Python and SWIG >=3.0.

Upstream documented requirement/configuration only, not independently tested installation or compatibility.

[1] [3]

Project notes

Distinguish the core build from the bindings

The build guide requires a C++11 compiler and CMake 2.8.2 or later and documents a build directory, cmake .., make and installation. Its Python route additionally requires Python and, for the documented Ubuntu route, SWIG 3.0 or later; the guide says an existing Python/SWIG setup can cause the main install to install bindings as well. Treat those as historical source instructions, not a tested modern Python toolchain or proof that a wheel contains every component. No core or binding was compiled here. [3]

The selected CYdLidar constructor supplies defaults such as /dev/ydlidar, 230400 baud, serial device type and a triangulation lidar type. Those are initial source values, not a universal configuration for all supported products. Match the actual model, transport and model-specific settings before receiving scans or changing motor behavior. The README's model/protocol documents are additional sources to inspect for that selected device. [1] [4]

A bounded next step is the corresponding source sample and configuration, followed by a device-specific build and communication test. No serial/network connection, scan data, automatic reconnection or range accuracy was tested in this review. [3] [4]

What we checked

Pinned documentation/selected source review only; no build, installation, live device/network, simulator, calibration or performance test.

Not yet established

  • Requirements: operating system, host computer
  • Version-specific hardware compatibility (ecosystem tags alone do not establish it)

Updates

Upstream last updated
Not established
Latest release
Not established
Profile updated
Nov 1, 2026
Sources last checked
Nov 1, 2026
Next review
Dec 1, 2026
Reviewed revision
e008f32

Source files and licenses

Distinct robot-facing source implementation/interface; no purchased hardware design or untested performance claim.

LayerAvailability / license
softwareavailable · MIT identified portions; third-party notices separate
Scoped source declaration; purchased hardware, firmware, binaries, assets and external dependencies require separate terms. [1] [2] [3] [4]
documentationavailable · MIT identified portions; third-party notices separate
Scoped source declaration; purchased hardware, firmware, binaries, assets and external dependencies require separate terms. [1] [2] [3] [4]

No separate physical design, pretrained distribution or dataset is selected as the released contribution in this scoped software review.

Read the license scope rather than only its filename

LICENSE.txt identifies portions of the SDK as MIT and includes additional third-party notices: the serial library has its own MIT notice, math/angles.h has a BSD notice retaining source/binary notices and prohibiting endorsement without permission, and the network library separately requires retained notices and restricts author/CarrierLabs endorsement. The sampled CYdLidar source has an MIT header; that is not a license audit of every transport dependency or device firmware. Keep those scopes separate before reusing code or distributing binaries. [2] [4]

References

Each source links to the exact revision we read. “Used for” shows where this page relies on it.

Correction guidance · Discussion is not enabled · Profile format 0.7.0-draft.5

Change history