is the process slow or we have an issue with the code

[Ahmed-TAIBECHE]

I'm running LONER SLAM on the MCR dataset using the provided mcr.yaml configuration, and the process gets stuck at the LiDAR timestamp re-computation step. Here are the details:

Command Used:

python3 run_loner.py ../cfg/fusion_portable/mcr.yaml
Observed Output:

Computing world cube using supplied trajectory bounding box
Starting LONER SLAM
Warning: Re-computing the LiDAR timestamps. This should only be done on fusion portable.
Assuming LiDAR timestamps within a scan are local, and start at 0
0%| | 0/1000 [00:00<?, ?it/s]### The progress bar remains at 0% (0/1000) for over 8 hours.

Dataset Details:

ROS Bag:

Path: ~/data/fusion_portable/raw_data/20220219_MCR_normal_01.bag (uncompressed from .bag.7z)

Size: 23.8 GB

Duration: 100 seconds (1:40s)

Messages: ~300,676

rosbag info confirms that the bag is valid and dense.

I TRIED TO USE a subset of the data same problem persisted.

---

Configuration (mcr.yaml):
yaml
Copy
baseline: defaults.yaml
dataset: ~/data/fusion_portable/raw_data/20220219_MCR_normal_01.bag
dataset_family: fusion_portable
calibration: ~/data/fusion_portable/calibration/20220209_calib
groundtruth_traj: ~/data/fusion_portable/groundtruth/20220219_MCR_normal_01/ground_truth_traj.txt
experiment_name: mcr
changes:
system:
world_cube:
compute_from_groundtruth: False
trajectory_bounding_box:
x: [-5, 25]
y: [-15, 20]
z: [-10, 10]
mapper:
optimizer:
model_config:
data:
ray_range: &ray_range [1, 35]
model:
ray_range: *ray_range

meshing_bounding_box:
x: [-18,10]
y: [-20,20]
z: [-4,4]

lidar_vertical_fov: [-22.5, 22.5]
(Note: Calibration should have a subfolder structure where ~/data/fusion_portable/calibration/20220209_calib/calib/ouster00.yaml exists.)

System and Environment:

OS: Ubuntu 20.04 Docker container running via Docker Desktop with WSL2 on Windows.

GPU: NVIDIA GeForce RTX 3050 (nvidia-smi confirms GPU availability).

Resource Usage:

CPU usage is high (one process using 171% CPU, another near 100%), indicating active processing.

Memory usage appears within available limits.

Issue Summary:
Despite active CPU usage (indicating that computations are occurring), the progress bar remains at 0% for more than 8 hours. Given the high density of the dataset (~300,000 messages in 100 seconds), it seems the LiDAR timestamp re-computation is extremely CPU-bound and may not be optimized for such large, dense datasets.

Questions/Requests:

Is there a known performance bottleneck in the timestamp re-computation step for dense Fusion Portable datasets like MCR?

Is there an option or recommended workaround to bypass or optimize the timestamp recalculation if valid timestamps are available?

Are there any recommended configuration changes for handling such large rosbag files effectively?

Any help or guidance to resolve this issue would be greatly appreciated.

[sethgi]

Definitely doesn't seem right that it makes no progress. But, we also haven't tested on WSL.

I'll find some time later in the next couple days to re-run this on my and and see what's happening. We've had some minor issues in the past with data formats changing and affecting our code, so it's possible this is on our end.