Native ROS 2

Compatible with: picoScan100, picoScan120, picoScan150

Native ROS 2 publishes scan data directly from the LiDAR firmware through DDS. The host therefore needs only a ROS 2/DDS subscriber; no SICK driver is required.

Quick start

1. Verify the device and ROS 2 prerequisites below.
2. Enable Native ROS 2 (DDS) in the device web interface.
3. Configure Cyclone DDS with the IP address of the host interface connected to the sensor.
4. Start rviz2 and add one of the published topics.

Prerequisites

Device

The picoScan150 requires firmware V2.2.1 or later and an activated native ROS 2 license (PICOSCAN RosConnect). picoScan150 PRO versions (part numbers 1134610 and 1142273) are delivered with this license pre-installed. If the license is missing, contact SICK. See How to activate LiDAR licenses?.

The picoScan120 requires firmware V2.2.1 or later. The latest firmware and update instructions for both devices are available from the SICK firmware download.

ROS 2 environment

Install a ROS 2 distribution. The examples below use ROS 2 Humble; Jazzy and Kilted are also supported.

Install the Eclipse Cyclone DDS middleware using the Cyclone DDS installation instructions.

Windows network profile

DDS discovery requires the sensor network interface to allow local network traffic. In PowerShell, inspect the interface and set it to Private if necessary. Replace 5 with the interface index connected to the sensor:

Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 5 -NetworkCategory Private

Enable native ROS 2

In the device web interface, open Application → Data output and set Measurement data output format to Native ROS 2 (DDS).

The ROS 2 domain ID on the host must match the device, and DDS/RTPS discovery must be able to reach the sensor interface. Native ROS 2 publishes data only; configure the sensor through the REST API, CoLa, or the web interface.

Published topics

The native publisher exposes these topics simultaneously. All messages carry the hardware PTP timestamp in header.stamp.

Topic	Message type	Content
/scan/all_points_echo0	sensor_msgs/LaserScan	First echo per beam; compact payload.
/scan/all_points	sensor_msgs/MultiEchoLaserScan	All echoes per beam, up to three.
/cloud/all_points	sensor_msgs/PointCloud2	Full 2D point cloud; compatible with PCL and standard visualization tools.

Visualize the point cloud

Create a Cyclone DDS configuration file and set NetworkInterfaceAddress to the IP address of the host interface connected to the sensor. This example uses 192.168.0.100. See the Cyclone DDS configuration reference for additional options.

<?xml version="1.0" encoding="utf-8"?>
<CycloneDDS
  xmlns="https://cdds.io/config"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">
  <Domain>
    <General>
      <NetworkInterfaceAddress>192.168.0.100</NetworkInterfaceAddress>
    </General>
  </Domain>
</CycloneDDS>

Linux

Source ROS 2, select Cyclone DDS, set the configuration file, and start rviz2:

. ~/ros2_humble/install/local_setup.bash
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
export CYCLONEDDS_URI="file://$HOME/CycloneDDS/my-config.xml"
rviz2

In rviz2, add /cloud/all_points or a scan topic. Set Fixed Frame to world, or to the frame configured on the device.

Windows

In a Windows command prompt, source ROS 2, select Cyclone DDS, set the configuration file, and start rviz2:

call C:\dev\ros2_humble\local_setup.bat
set RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
set CYCLONEDDS_URI=file://%USERPROFILE%/cyclonedds.xml
rviz2

In rviz2, add /cloud/all_points or a scan topic. Set Fixed Frame to world, or to the frame configured on the device.

Native ROS 2 or host-side driver?

Both approaches produce standard ROS 2 messages. The difference is where UDP segment assembly and DDS publishing run.

With native ROS 2, the device assembles scan segments and publishes DDS data:

picoScan firmware
  ├─ scan execution
  ├─ segment assembly on-device
  ├─ PTP timestamp
  └─ DDS publish over Ethernet

host
  └─ DDS subscriber

With sick_scan_xd, the host receives and decodes Compact UDP data, assembles complete scans, and publishes them through DDS:

picoScan firmware
  └─ UDP Compact scan data

host driver process
  ├─ UDP receive and decode
  ├─ segment assembly
  └─ DDS publish

Native ROS 2 leaves more host CPU available for navigation, SLAM, or other sensors. Use the host-side driver when you need host-side decoding control, IMU topics, or support for a device without a native publisher.

DDS capabilities

Because the device runs a DDS participant in its firmware, it joins the ROS 2 network as a first-class peer:

• Interoperability: ROS 2 nodes, MathWorks ROS Toolbox, OpenDDS-based systems, and custom DDS clients can subscribe directly.
• Multiple subscribers: The sensor publishes once per scan; adding subscribers does not add another device-side publishing step.
• Per-subscriber QoS: Subscribers can negotiate policies independently, such as BEST_EFFORT for control and RELIABLE for recording.
• Automatic discovery: RTPS discovery finds subscribers without a broker or static IP table.
• Hardware timestamps: header.stamp is set at the hardware scan trigger. With PTP synchronization, it aligns with other sensors.

CPU benchmark

Measurements across 11 picoScan150 profiles used 15-50 Hz scan rates, 0.05-1.0° angular resolutions, 100 scans per method, and IEEE 1588 PTP synchronization. Single-echo sensor_msgs/LaserScan data was used for a direct comparison.

Parameter	Value
Host	Raspberry Pi 4, ARM Cortex-A72, 4 cores, Ubuntu 22.04
RMW	Fast DDS (rmw_fastrtps_cpp)
Network	Direct Gigabit Ethernet
Latency definition	Δt = treceive_on_host − header.stamp

Average system CPU load was 8.5% for native ROS 2 and 21.5% for sick_scan_xd, expressed as the percentage of one Raspberry Pi 4 CPU core.

DDS video tutorials

• How to use native ROS 2 (DDS) on Linux
• How to use native ROS 2 (DDS) on Windows