How it works

How LidarFlow turns a rosbag into a georeferenced map

The product flow is straightforward: upload the recording, validate the topics, run LiDAR SLAM, georeference the output when GNSS exists, and review the artifacts in one browser workflow.

Upload .mcap or ROS1 .bagValidate LiDAR, GNSS, IMU, and TFRun GLIM + FlexCloud

Upload the recording

Start with `.mcap` or ROS1 `.bag`. The browser uploader shows transfer progress first, then a server finalization phase while the recording is prepared.

Validate the topics

LidarFlow checks that LiDAR exists, warns when GNSS is missing, analyzes IMU units, and inspects `/tf_static` before you spend time on a run.

Run SLAM

The mapping path uses GLIM underneath. The browser UI surfaces queue state and processing health instead of leaving you to guess what the worker is doing.

Georeference and review

When GNSS is available, FlexCloud aligns the SLAM output to geographic coordinates and the browser surfaces a preview plus downloadable artifacts.

Step-by-step walkthrough

What the browser workflow looks like

LidarFlow upload screen showing rosbag and MCAP drag and drop upload with transfer progress — **Upload progress** The upload flow is staged. You see acknowledged browser transfer first and finalization second.

LidarFlow topic validation showing /velodyne_points and /fix detected in a rosbag — **Topic validation** Topic suggestions surface before the run starts, including LiDAR, GNSS, IMU, and TF hints.

GLIM LiDAR SLAM run in progress in the LidarFlow browser dashboard — **Run status** Runs expose queue and worker health so stalls are visible instead of silent.

Georeferenced point cloud preview from a rosbag in LidarFlow — **Output preview** Successful jobs expose preview and download surfaces for mapped and georeferenced artifacts.

Under the hood

GLIM for SLAM, FlexCloud for georeferencing

Engineers want to know what stack is running underneath the UI, and they should. LidarFlow makes that explicit instead of hiding it behind vague platform language.

GLIM FlexCloud

Why not local-only?

Why not just run `bag_to_pcd` locally?

Because exporting timestamped point clouds is not the same job as building a mapped output. Local tools are still useful when you only need raw frames, but they stop short of a reproducible, browser-reviewable map.

ros2 run pcl_ros bag_to_pcd --ros-args \
  -p bag_path:=rosbag2_2025_01_01/ \
  -p topic_name:=/pointcloud \
  -p output_directory:=pcds

That upstream utility exports PCD frames for one topic. It does not validate your TF tree, run LiDAR SLAM, or georeference the result.

FAQ

Common workflow questions

Does LidarFlow replace bag_to_pcd?

Not exactly. `bag_to_pcd` exports frame-by-frame point clouds. LidarFlow is for the next job: turning the recording into one mapped output you can review and download.

Where do GLIM and FlexCloud fit?

GLIM drives the LiDAR SLAM step. FlexCloud handles the GNSS-backed georeferencing step after the SLAM map exists.

What happens if the recording has no GNSS?

The upload can still move forward as long as it has LiDAR. You still get a SLAM map; the only thing you lose is the georeferenced alignment.

Next step

See the conversion guides or request access to the beta

Rosbag to PCD Request beta access