How it works

How LidarFlow turns a rosbag into a georeferenced map

The flow is straightforward: upload the recording, pick your sensors, reconstruct in 3D from LiDAR or a single camera, georeference the output when GNSS exists, and review the artifacts — all in one browser workflow.

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

Upload the recording

Start with a `.mcap` or ROS1 `.bag`. The uploader shows transfer progress first, then a short server-side prepare step while LidarFlow scans the recording's topics and sensors.

02

Pick your sensors

LidarFlow detects what's in the bag — LiDAR, GNSS, IMU, `/tf_static`, and any cameras with their intrinsics — and you choose what to reconstruct from: LiDAR, a single camera, or both.

03

Reconstruct in 3D

The LiDAR path runs GLIM SLAM; the camera path runs monocular metric depth to lift a single video stream into a metric point cloud. Either way the browser shows queue and worker health instead of leaving you to guess.

04

Georeference and review

When GNSS is present, FlexCloud aligns the result to real-world coordinates. You get an in-browser preview and downloadable PCD/LAS/PLY 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.

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