GEODE

GEODE (https://github.com/PengYu-Team/GEODE_dataset): a heterogeneous-LiDAR dataset built specifically around DEGENERATE geometry – flat surfaces, stairwells, metro tunnels (shield and tunneling), off-road, inland waterways, urban tunnels and bridges.

Three acquisition devices, and which one a bag came from decides its topics:

alpha   Velodyne VLP-16 (spinning)      /velodyne_points     PointCloud2
beta    Ouster OS1-64 (spinning)        /ouster/points       PointCloud2
gamma   Livox AVIA (non-repetitive)     /livox/lidar         CustomMsg

Topic names here were read out of the bags themselves, not from upstream’s cali/*.yaml. Those config files cannot be trusted for this: all three name the same “/os1_cloud_node1/points” and “/imu/imu”, all three declare VERT_RES 16 (beta is a 64-beam Ouster), and image_topic is also “/imu/imu”. They are visibly copy-pasted, and not one of those three lidar topics is what the bags actually contain – beta’s is “/ouster/points”.

The external IMU is on /imu/data at ~100 Hz on all three rigs. The beta and gamma rigs also record their lidar’s built-in IMU (/ouster/imu, /livox/imu); neither is used by default, matching botanicgarden.sh.

Sequence naming: most sequences carry the device as a filename suffix (Offroad1_beta, Tunneling_tunnel2_alpha, …). The single-device scenarios do not, so they are listed explicitly below – bridge* and Urban_Tunnel* are alpha rigs, flat_surfaces_* is a gamma rig. Both were confirmed by reading the bags. GEODE_DEVICE overrides the detection.

KNOWN, as of 2026-08-23: with the stock lidar3d-default pipeline this profile gets 1.4% drift through a metro tunnel (Tunneling_tunnel2_alpha) and 4.6% on the flat-surfaces AVIA sequences, but it DIVERGES on bridge01 – the estimate travels 41% of the 3.97 km reference path and drifts 552 m vertically. Wrong topics, a flipped IMU, missing per-point timestamps, IMU deskewing and a rotating lever arm have all been ruled out by experiment, so this looks like pipeline tuning rather than a mistake in the description below. Upstream’s own usage notes say to “adapt your SLAM algorithm using the provided dataset parameters”.

GROUND TRUTH, which is where this dataset will bite you: several scenarios were recorded with all three devices bolted to one rack and a SINGLE ground truth device, and which device the reference is expressed in changes per scenario. GNSS/INS scenarios (off-road, inland waterways) are in the BETA frame; the Leica-prism metro tunnels are in the ALPHA frame. So the device that needs no correction differs by scenario, and the rest need a half-metre body offset that no global trajectory alignment can absorb. That correction belongs to whoever scores the run, not to this profile – see upstream’s README, “Localization Evaluation”.

Running it

Online replay with the 3D GUI:

mola-lo-gui-geode /path/to/<sequence>.bag [additional flags]

Offline batch run, writing a trajectory file:

mola-lo-cli-geode /path/to/<sequence>.bag [additional flags]

What this profile sets, and why

These are defaults, not overrides: exporting any of these variables before running the wrapper takes precedence.

`MOLA_LIDAR_TOPIC`

Default: /velodyne_points

`LIDAR_POSE_X`

Default: 0.09610

`LIDAR_POSE_Y`

Default: -0.13380

`LIDAR_POSE_Z`

Default: 0.30320

`LIDAR_POSE_YAW`

Default: -0.2865

`LIDAR_POSE_PITCH`

Default: 0.8767

`LIDAR_POSE_ROLL`

Default: -0.1261

`MOLA_LIDAR_TOPIC`

Default: /ouster/points

`LIDAR_POSE_X`

Default: -0.02717

`LIDAR_POSE_Y`

Default: -0.03487

`LIDAR_POSE_Z`

Default: 0.06264

`LIDAR_POSE_YAW`

Default: -2.9771

`LIDAR_POSE_PITCH`

Default: -0.2861

`LIDAR_POSE_ROLL`

Default: -0.7826

`MOLA_LIDAR_TOPIC`

Default: /livox/lidar

`LIDAR_POSE_X`

Default: 0.04926

`LIDAR_POSE_Y`

Default: -0.01250

`LIDAR_POSE_Z`

Default: 0.02695

`LIDAR_POSE_YAW`

Default: -1.5768

`LIDAR_POSE_PITCH`

Default: 0.1000

`LIDAR_POSE_ROLL`

Default: -1.4587

`MOLA_MIN_NEARBY_POSES_OCCUPIED`

Default: 2

Non-repetitive scan pattern: accumulate more than one scan per location before moving on, so the local map and the simplemap are dense enough to register against. Same treatment as the Livox arm of botanicgarden.sh.

`MOLA_SIMPLEMAP_MIN_NEARBY_POSES`

Default: 2

Non-repetitive scan pattern: accumulate more than one scan per location before moving on, so the local map and the simplemap are dense enough to register against. Same treatment as the Livox arm of botanicgarden.sh.