ROS 2 driver checklist for LiDAR, depth cameras, gimbals and GNSS on a robot
Updated 2026-11-04 · YUANZHI ROBOTICS engineering team
Before you buy a sensor for a robot dog, UGV or drone, check five things about its ROS 2 driver: it is maintained for your ROS 2 distribution (Humble or Jazzy) and your CPU architecture, it publishes standard message types, it supports hardware time synchronization, it lets you set frame IDs and QoS, and its bandwidth and CPU load fit your onboard computer. Most integration delays come from one of these, not from the sensor itself.
1. Distribution, architecture and who maintains the driver
Most onboard computers on mobile robots are ARM64 (NVIDIA Jetson Orin) running Ubuntu 22.04 with ROS 2 Humble, or Ubuntu 24.04 with Jazzy. A driver that only ships x86 binaries, or a vendor SDK built only for Ubuntu 20.04, will cost you days. Check three things on the driver repository: the last commit date, whether the README names your distribution, and whether issues about ARM64 builds get answered. Prefer drivers maintained by the sensor vendor (for example livox_ros_driver2, ouster-ros, realsense-ros, zed-ros2-wrapper, and the Hesai and RoboSense ROS 2 SDKs) over unmaintained community forks.
2. Message types your stack actually consumes
SLAM, navigation and recording tools expect standard types: sensor_msgs/PointCloud2 for LiDAR, sensor_msgs/Image plus CameraInfo for cameras, sensor_msgs/Imu, and sensor_msgs/NavSatFix for GNSS. Watch for exceptions. The Livox driver can publish its own CustomMsg format (needed by some LiDAR-inertial odometry packages) or standard PointCloud2, selected by a launch parameter, and the two are not interchangeable. Point clouds should carry per-point time or ring fields if your deskewing algorithm needs them. Dual-antenna GNSS heading is usually not part of NavSatFix at all; receivers such as the Unicore UM982 report heading in their own log messages, so you need a driver or a small parser that turns it into an orientation your localization can use.
| Sensor type | Typical ROS 2 output | What to check |
|---|---|---|
| LiDAR (Livox Mid-360, Ouster OS1, Hesai XT32) | PointCloud2, often an Imu topic too | Per-point timestamps, PTP support, custom vs standard message, Ethernet IP setup |
| Depth camera (RealSense D435i, Orbbec Gemini 335, ZED X) | Image, depth Image, CameraInfo, optional PointCloud2 and Imu | USB or GMSL link, whether depth runs on the camera or the host GPU, resolution and FPS profiles |
| Gimbal / PTZ camera | Often no ROS driver; RTSP video plus ONVIF or a vendor protocol for control | Who writes the bridge node, video latency, whether pan/tilt angles can be read back |
| GNSS receiver (UM980, UM982, ZED-F9P) | NMEA or vendor binary over serial, mapped to NavSatFix | RTK correction input (NTRIP), heading output, PPS for time |
| IMU (Xsens MTi-630, Epson G366) | Imu | Rate, covariance fields filled in, frame convention |
3. Time synchronization
LiDAR-inertial odometry and camera-LiDAR fusion fail quietly when timestamps disagree by tens of milliseconds. Ask whether the sensor supports IEEE 1588 PTP over Ethernet (many current LiDARs do), a PPS input from a GNSS receiver, or only host-receive time. Then check the driver: some drivers stamp messages with the time the host received them, which hides network jitter. Choose one time source for the whole robot, usually PTP from the onboard computer or a GNSS-disciplined clock, and verify it by comparing message stamps from two sensors while the robot turns in place.
4. Frames, TF and QoS
Every driver should let you set the frame_id; fixed names baked into the code cause collisions when you mount two of the same camera. Publish the static transforms from your mechanical design (base_link to each sensor) from one place, following REP 103 axis conventions. Camera drivers publish optical frames with a different axis order, a common source of rotated point clouds. For QoS, high-rate sensor topics are usually published best-effort, and a subscriber set to reliable may receive nothing at all. Check this first when ros2 topic echo works but your node gets no data.
5. Bandwidth and compute on the robot
A Livox Mid-360 produces about 200,000 points per second and draws about 6.5 W; an Ouster OS1 draws about 20 W and, depending on its mode, much more data. Uncompressed depth and color streams can saturate a USB bus shared with other devices. On a Jetson Orin NX, measure CPU and memory with every driver running at its final settings before adding SLAM and perception, and use composable nodes or shared-memory transport for large topics where the driver supports it. Record with rosbag2 (MCAP storage is a good default) and confirm the disk keeps up with all topics at once.
6. Network and power details that block the first boot
- Ethernet LiDARs ship with fixed default IP addresses; plan the payload subnet so they do not clash with the robot's own internal network.
- USB cameras need a cable and port that survive vibration; a loose connector looks exactly like a driver crash.
- GNSS receivers need the right serial baud rate and output logs configured once and saved in the receiver.
- Each sensor's startup current must fit the payload power design; see our guide on powering robot payloads.
Acceptance test before the sensor goes on the robot
On the bench, run all drivers together for at least an hour with recording on, then check: every topic at its expected rate (ros2 topic hz), no growing latency, a correct TF tree (ros2 run tf2_tools view_frames), stamps from all sensors on the same clock, and a clean restart after a power cycle. Only then mount the sensors and tune SLAM; our mapping payload guide covers that next step.
YUANZHI ROBOTICS integrates these sensors with ROS 2 drivers, time sync and TF set up for the target robot, and writes bridge nodes for gimbals and GNSS heading where no driver exists. Pick sensors in the payload configurator, look at platforms such as the Unitree Go2 EDU or Clearpath Husky A200, or see our robot autonomy and robot payload services.
FAQ
Does the Livox Mid-360 have a ROS 2 driver?
Yes. Livox maintains livox_ros_driver2, which supports ROS 2 and can publish either standard sensor_msgs/PointCloud2 or the Livox CustomMsg format that some LiDAR-inertial odometry packages expect. You choose the format with a launch parameter and set the sensor and host IP addresses in a JSON config file.
Which depth cameras work best with ROS 2 on a Jetson?
Intel RealSense (realsense-ros), Orbbec Gemini (OrbbecSDK_ROS2) and Stereolabs ZED (zed-ros2-wrapper) all have vendor-maintained ROS 2 drivers. RealSense and Orbbec compute depth on the camera; ZED computes depth on the host GPU, so it uses more of the Jetson.
How do I control a PTZ or thermal gimbal from ROS 2?
Most security PTZ and thermal gimbals have no official ROS 2 driver. The usual approach is to bring the RTSP video stream into ROS 2 Image messages and write a small node that sends pan, tilt and zoom commands over ONVIF or the vendor's protocol, reading back the current angles if the camera supports it.
How do I get dual-antenna GNSS heading into ROS 2?
Receivers such as the Unicore UM982 output heading in their own log messages, not in NavSatFix. You need a driver or parser node that reads those logs over serial and publishes the heading as an orientation, plus an NTRIP client to feed RTK corrections.
Why does my ROS 2 node receive no sensor data even though ros2 topic echo works?
The most common cause is a QoS mismatch: sensor drivers usually publish best-effort, and a subscriber set to reliable will not connect. Use the sensor data QoS profile in your subscriber and check again.