LidarFlow is not locked to specific hardware. If your driver publishes sensor_msgs/PointCloud2, the recording can be reconstructed. Some sensors additionally have presets we have tested on real data.
A .bag or .mcap recording containing a LiDAR topic of type sensor_msgs/PointCloud2, or the ROS1 Livox CustomMsg type. IMU and GNSS topics are optional and detected automatically when present.
It means the defaults for that sensor were chosen against real recordings from it, taking its scan pattern, point density and noise behaviour into account, rather than being inherited from a generic configuration. It does not mean other sensors are unsupported, and it is not a promise that every recording from a supported sensor reconstructs perfectly. Recording quality, motion and environment still dominate the result.
The ouster-ros driver publishes sensor_msgs/PointCloud2 on a points topic, with intensity, reflectivity, ambient and ring fields available. Uniform vertical spacing and dense returns make these recordings straightforward to reconstruct. Recording the IMU topic from the sensor is worth doing: it improves motion handling and costs almost nothing in bag size.
Livox sensors use a non-repetitive scan pattern rather than fixed rings, so per-frame coverage looks sparse while coverage builds up over time. The ROS driver can publish either PointCloud2 or the Livox CustomMsg type; both are accepted, with CustomMsg supported for ROS1 recordings. Longer captures of the same area help more here than they do with a spinning sensor.
The velodyne_pointcloud driver emits PointCloud2 with intensity and ring fields. The main thing worth checking before uploading is that you recorded the converted point cloud topic rather than only the raw velodyne_packets stream, since packets alone are not a point cloud yet.
Hesai, RoboSense, Unitree's built-in units, research rigs, and anything else with a ROS driver land in the generic path. The validator reads the actual field layout in your messages, so an unusual channel set is handled on its own terms. What we will not do is publish a compatibility badge for hardware we have not run, so treat the generic path as "expected to work, tell us if it does not" rather than as a guarantee.
If the driver publishes sensor_msgs/PointCloud2, the recording can be processed regardless of brand. Livox recordings using the ROS1 CustomMsg type are also accepted. Ouster, Livox and common Velodyne sensors additionally have field-tested presets.
Any name. The validator inspects message types rather than matching topic strings, so a non-standard topic name is fine as long as the message type is right.
Yes, for Ouster, Livox and common Velodyne sensors. A preset is a set of defaults chosen for that sensor's scan pattern and noise behaviour, not a separate code path.
It will still run on generic defaults, and results are usually good. We will not claim a guarantee for hardware we have not put through a real recording. Send us the run if something looks off and we will look at it.