rslidar_sdk turns RoboSense sensors into ROS point cloud topics

A thin ROS layer over a standalone driver

rslidar_sdk is the Software Development Kit of the RoboSense Lidar based on Ubuntu, and it contains three things. The lidar driver core rs_driver, the ROS support, and the ROS2 support. The split matters because the documentation tells you which piece to use for which job. To get point cloud through ROS or ROS2, use this SDK. To integrate the lidar driver into your own projects, use rs_driver instead. That distinction is the whole architecture in one sentence, and it has a practical consequence: a team with a non-ROS stack, or with an existing custom node, does not need the ROS layer and can take the driver alone. The repository layout reflects it, with src/ for the sources, node/ for the ROS node, launch/ for the launch files, config/ for the parameters, rviz/ for visualisation setups, and doc/ for the documentation directory that the quick start guides link into.

Nineteen sensors and two point types

The supported hardware list is long and specific, which is a good sign for a vendor SDK. It covers RS-LiDAR-16 and RS-LiDAR-32, RS-Bpearl, RS-Helios and RS-Helios-16P, the RS-Ruby family in 128, 80 and 48 variants, the RS-Ruby-Plus in the same three sizes, the RS-LiDAR-M1, M2 and M3, RS-LiDAR-E1, RS-LiDAR-MX, RS-LiDAR-AIRY, RS-LiDAR-AIRYLITE-ETH, RS-LiDAR-EMX and RS-LiDAR-FAIRY. Only two point types are supported. XYZI carries x, y, z and intensity, and XYZIRT adds ring and timestamp. The distinction is not cosmetic. The ring number is what lets a consumer reconstruct the scan order and do per-ring processing, and the timestamp is what lets a consumer fuse the LiDAR with a camera or a radar, so choosing the simpler type when your pipeline needs the richer one produces a point cloud you cannot use, and choosing the richer one when you do not need it costs bandwidth. A separate quick start document covers changing the point type, and the parameters reference explains the option.

Getting the source, and the submodule that trips people up

The SDK is downloaded with Git, and the README warns that because it contains the submodule rs_driver you should also use git submodule to download it properly:

git clone https://github.com/RoboSense-LiDAR/rslidar_sdk.git
cd rslidar_sdk
git submodule init
git submodule update

There is a second route, and it is the one the documentation steers you toward if you are not using Git. The releases page hosts the built archive, and the instruction is to download the rslidar_sdk.tar.gz archive instead of the source code, because the source code zip file does not contain the submodule rs_driver and so it has to be downloaded manually. That warning is repeated in a second sentence and it is worth taking seriously, because a checkout without the driver submodule fails at build time in a way that looks like a broken toolchain rather than a missing directory. The repository has a .gitmodules file at the root, so the submodule is a tracked dependency rather than something you fetch by hand.

Dependencies, and why ROS and ROS2 cannot share a machine

The dependency list is split by ROS generation, and the ROS 1 side covers Ubuntu 16.04 with ROS Kinetic desktop, Ubuntu 18.04 with ROS Melodic desktop and Ubuntu 20.04 with ROS Noetic desktop. The ROS2 side covers Ubuntu 18.04 with ROS2 Eloquent desktop, Ubuntu 20.04 with ROS2 Galactic desktop and Ubuntu 22.04 with ROS2 Humble desktop, and Ubuntu 16.04 is explicitly listed as not supported for ROS2. Two essential libraries sit outside the ROS stack. Yaml, version v0.5.2 or newer, installed with libyaml-cpp-dev, and libpcap, version v1.7.4 or newer, installed with libpcap-dev, which is what lets the SDK replay a captured packet file. The strong instruction is not to install ROS and ROS2 on the same computer, to avoid possible conflict and having to manually install some libraries such as Yaml. There is also a recommendation to install ros-distro-desktop-full rather than assembling libraries piecemeal, on the grounds that it avoids version conflicts, and the note that this step can be skipped if that desktop package is already present.

Building and running under both build systems

The compile and run procedure is the same shape in both worlds, with a different build tool and a different launch file. For ROS 1 with catkin, you create a workspace folder and a src folder inside it, put the rslidar_sdk project into src, then from the root of the workspace run:

catkin_make
source devel/setup.bash
roslaunch rslidar_sdk start.launch

For ROS 2 with colcon, the workspace layout is the same, but you also need the separate packet definition project rslidar_msg from the RoboSense repository placed in the same src folder, and then:

colcon build
source install/setup.bash
ros2 launch rslidar_sdk start.py

Both instructions note that if you are using zsh you replace the source command with the zsh variant. And the ROS 2 launch file is not the same everywhere. The documentation explains that another version of start.py may be used since it is different on different versions of ROS2, and gives the example that elequent_start.py is used instead for ROS2 Eloquent. A single roslaunch command copied from a blog post for the wrong ROS2 distro is a common way to lose an afternoon.

Parameters, quick start paths and the advanced topics

Behaviour is changed through parameters, and the README links two documents for them, an introduction to parameters and an introduction to hidden parameters. The second one is the interesting link, because the name suggests the settings that exist for compatibility or for specific sensors rather than for general use. The quick start section lists three guides, connecting to an online LiDAR and sending point cloud through ROS, decoding a PCAP file and sending point cloud through ROS, and changing the point type. The advanced topics section adds online LiDAR topics, PCAP file topics, coordinate transformation, recording a rosbag and replaying it, and a solution for ROS2 Humble frame rate reduction. That last entry is a tell. Frame rate reduction on Humble is a known class of problem with high bandwidth sensors in ROS2, and the fact that the vendor documents a fix for it tells you the SDK runs into the transport limits of the middleware on that particular distribution, which is a thing to read before you commit to the platform.

Editorial conclusion

Adopt rslidar_sdk when you run RoboSense LiDAR hardware and want point clouds on a ROS or ROS2 topic without writing a driver, and when your machine can be dedicated to one ROS generation. Do not adopt it if you need ROS2 on Ubuntu 16.04, which the documentation lists as not supported, or if you need a support layer that is independent of ROS, in which case the driver core is the piece to take. Verify first that your sensor model appears in the supported list, that the point type you need, XYZI or XYZIRT, matches your downstream consumers, and that you have the release archive rather than the source zip, since the source download omits the driver submodule.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. RoboSense-LiDAR/rslidar_sdk on GitHub