web
You’re offline. This is a read only version of the page.
close
Support Portal

Application /Product Knowledge

picoScan100: Native ROS 2 explained

Article No: KA-10645
Version: 1.2
Subject to change without notice
This article covers the architectural background, the concrete benefits of the DDS-native approach, and benchmark results across all 11 profiles.
Related Products
picoScan100

Table of Contents

The picoScan100 carries a fully integrated ROS 2 publisher inside its firmware. Scan data enters the ROS 2 graph directly from the sensor, without a host-side driver process. The advantage is CPU efficiency: the native publisher keeps the host nearly idle, while an external driver consumes a growing fraction of a CPU core that scales with scan rate and angular resolution.

Architecture

Two paths from LiDAR to ROS 2

Both integration methods produce standard ROS 2 messages with hardware-derived timestamps. The structural difference is where the DDS publish step runs, and therefore where the processing cost falls.

The picoScan100 transmits scan data as UDP datagrams. In the native path, segment assembly and DDS publishing happen on-device inside the firmware. With the external driver they happen on the host, which is why the driver carries a meaningful CPU cost regardless of how fast or capable the host is.

Native ROS 2 (built-in)
picoScan100 firmware
  ├─ scan execution
  ├─ segment assembly on-device
  ├─ PTP timestamp
  └─ DDS publish over Ethernet

host: DDS subscriber only
    e.g. /scan/all_points_echo0
sick_scan_xd driver
picoScan100 firmware
  └─ UDP compact scandata

host driver process
  ├─ UDP receive + decode
  ├─ segment assembly
  └─ DDS publish e.g. /scan_fullframe

Published message types

The native publisher exposes three topic types simultaneously. All carry the same hardware PTP timestamp in header.stamp. Benchmarks on this page used single-echo only (sensor_msgs/LaserScan) for a fair one-to-one comparison with sick_scan_xd, which also publishes single-echo full-frame scans.

Topic Message type Content
/scan/all_points_echo0 sensor_msgs/LaserScan First echo per beam. Compact, lowest per-message payload. Used in the benchmarks on this page.
/scan/all_points sensor_msgs/MultiEchoLaserScan All echoes per beam (up to three).
/cloud/all_points sensor_msgs/PointCloud2 Full 2D point cloud. Larger payload, compatible with PCL and standard visualization tools.
DDS as the foundation

What DDS brings to sensor integration

ROS 2 is built on DDS, the Data Distribution Service standard defined by the Object Management Group. Because the picoScan100 runs a complete DDS participant inside its firmware, it joins the ROS 2 network as a first-class peer rather than a device that needs an adapter layer.

🌐
Interoperability

Any DDS-compliant application receives the sensor data directly: ROS 2 nodes, MathWorks ROS Toolbox, OpenDDS-based systems, or custom DDS clients. No conversion layer or bridge process is required.

👥
Multiple subscribers at no sensor cost

The sensor publishes once per scan. Every subscriber on the network receives the same data simultaneously. Adding a visualization node, a logger, or a second algorithm puts no additional load on the device.

⚙
Per-subscriber QoS

DDS Quality of Service policies are negotiated independently per subscriber. A control loop can request BEST_EFFORT while a data recorder uses RELIABLE, both on the same topic at the same time.

🔌
Automatic discovery

No broker, no configuration file per node, no static IP table. New subscribers are found through RTPS participant discovery.

🔧
Middleware vendor neutrality

Fast-RTPS, CycloneDDS, and other OMG-compliant implementations all interoperate with the sensor out of the box.

🕐
Hardware timestamps in every message

header.stamp is set at the hardware scan trigger, before any network or OS latency accumulates. With PTP clock synchronisation on the host, those timestamps align directly with other sensors without software correction.

Host resource efficiency

CPU is where the difference is

Because the picoScan100 uses a segment-based UDP output format internally, the end-to-end latency for both integration methods is comparable: the same scan data travels the same network path. What differs significantly is the computational cost on the host.

With the native publisher, the host runs only a DDS subscriber. With sick_scan_xd, the host additionally receives and decodes compact UDP scan datagrams, assembles the segments into a full frame, and then publishes via DDS.

On an embedded host such as the Raspberry Pi 4, this difference matters in practice. A navigation stack, a SLAM algorithm, or a second sensor running alongside a driver-based integration competes directly for the same CPU budget. The native publisher leaves those resources untouched.

Measurements

Test setup and results

Measurements were collected across all 11 picoScan150 scan profiles, covering scan rates from 15 Hz to 50 Hz and angular resolutions from 0.05° to 1.0°. Each profile was measured with 100 scan samples per method, with the LiDAR clock synchronised to the host via IEEE 1588 PTP. Single-echo (sensor_msgs/LaserScan) data was used in both methods for a direct comparison.

Parameter Value
Host Raspberry Pi 4 (ARM Cortex-A72, 4 cores) · Ubuntu 22.04 · ROS 2 Humble
RMW Fast-RTPS (rmw_fastrtps_cpp)
Network Direct Gigabit Ethernet
Clock sync IEEE 1588 PTP · host as grandmaster (software timestamping), LiDAR as PTP client
Latency definition Δt = treceive_on_host − header.stamp (both UTC, PTP-aligned)
CPU measurement System CPU: total host load via top -b.
Sample size 100 scans per profile per method

System CPU by scan profile

Total host CPU load during measurement. Bars are scaled so 50 % CPU = full bar width.

Native ROS 2 (system CPU)
sick_scan_xd (system CPU)
P1  15 Hz  0.50°
6.2 %
13.6 %
P2  15 Hz  0.33°
6.9 %
15.6 %
P3  20 Hz  0.10°
7.6 %
20.2 %
P4  20 Hz  0.25°
8.2 %
18.6 %
P5  25 Hz  0.25°
11.3 %
18.8 %
P6  30 Hz  0.10°
9.9 %
26.6 %
P7  40 Hz  0.25°
10.0 %
25.2 %
P8  50 Hz  0.25°
9.8 %
31.1 %
P9  15 Hz  0.05°
7.0 %
25.8 %
P10 40 Hz 0.125°
11.0 %
26.8 %
P11 15 Hz 1.00°
6.0 %
13.8 %
Average
8.5 %
21.5 %

All figures are percentages of a single ARM Cortex-A72 core (Raspberry Pi 4).

Keywords:
picoScan, pico, picoScan100, picoScan120, picoScan150, ROS, native ROS 2, ROS, ROS 2, RosConnect, ROS2
Create request