mola_input_ouster

Provides a MOLA RawDataSourceBase module for Ouster LiDAR sensors using the native Ouster C++ SDK, without requiring any ROS middleware.

This module can operate in three modes:

• Live sensor: Connects to an Ouster sensor on the network.
• PCAP replay: Replays a recorded .pcap capture file.
• OSF replay: Replays an Ouster .osf recording (sensor metadata is embedded in the file — no separate JSON required).

It produces mrpt::obs::CObservationPointCloud and mrpt::obs::CObservationIMU observations for downstream consumption by mola::LidarOdometry, state estimators, or any other mola::RawDataConsumer.

Distro	Build dev	Release
ROS 2 Humble (u22.04)
ROS 2 Jazzy (u24.04)
ROS 2 Kilted (u24.04)
ROS 2 Lyrical (u26.04)
ROS 2 Rolling (u26.04)

Usage: OSF replay (just view, no SLAM)

OUSTER_OSF=/path/to/recording.osf \
mola-cli  $(mola-dir mola_input_ouster)/mola-cli-launchs/osf_ouster_just_view.yaml

Build dependencies

• mola_kernel
• mola_yaml
• mrpt (mrpt-obs, mrpt-maps)
• Ouster SDK (ouster_client, ouster_pcap, ouster_osf) — bundled as a git submodule (see below)

Ouster SDK: bundled submodule vs. system installation

The Ouster SDK is included as a git submodule under ouster-sdk/, so the package is self-contained and requires no separate SDK installation.

Clone with submodules:

git clone --recurse-submodules https://github.com/MOLAorg/mola_input_ouster.git

Or, if you already cloned without --recurse-submodules:

git submodule update --init --recursive

If a system-wide (or user-installed) Ouster SDK is already present on your machine, CMake will prefer it automatically. To force the bundled copy regardless, pass -DUSE_BUNDLED_OUSTER_SDK=ON to CMake.

Usage: Sensor check (just view, no SLAM)

Quickly verify connectivity and inspect the raw point clouds without running any odometry:

OUSTER_HOSTNAME=os-122xxxxxxxxx.local \
mola-cli  $(mola-dir mola_input_ouster)/mola-cli-launchs/live_ouster_just_view.yaml

Same for a recorded PCAP file:

OUSTER_PCAP=/path/to/capture.pcap \
OUSTER_META=/path/to/metadata.json \
mola-cli  $(mola-dir mola_input_ouster)/mola-cli-launchs/pcap_ouster_just_view.yaml

Usage: Live LiDAR odometry

OUSTER_HOSTNAME=os-122xxxxxxxxx.local \
mola-cli  $(mola-dir mola_input_ouster)/mola-cli-launchs/lidar_odometry_ouster_live.yaml

Or using the convenience script:

mola-lo-gui-ouster-live os-122xxxxxxxxx.local

For LiDAR-Inertial Odometry (LIO) with IMU deskewing:

```bash MOLA_DESKEW_METHOD=MotionCompensationMethod::IMU
mola-lo-gui-ouster-live os-122xxxxxxxxx.local

File truncated at 100 lines see the full file

Changelog for package mola_input_ouster

0.2.0 (2026-10-01)

• ci: make scripts/release.py identical across repos by auto-discovering packages

• fix .gitignore: anchor build-* to directories only

• ci: add clang-format and colcon build workflows

• Merge pull request #3 from MOLAorg/feat/dataset-ui Add playback UI (pause, speed, seek) for PCAP and OSF replay

• Replay: bound the scans published per call, re-anchor after max speed

  - Publish at most 5 due scans per spinOnce() and drop the remaining lag. Otherwise, when decoding is slower than the requested speed, each call has more scans due than the last, and pause/seek stop responding.

  - Reset the replay time when playing as fast as possible, so switching back to a positive speed does not stall until the wall clock catches up.

• Add playback UI (pause, speed, seek) for PCAP and OSF replay Implement mola::Dataset_UI, enabled only when replaying a file (via datasetUI_enabled(), when available in mola_kernel), so the MOLA GUI shows the usual dataset playback panel. There is none in live mode.

  - Replay no longer sleeps inside spinOnce(): the replay time advances with the wall clock times the playback speed, and each scan is published once its time comes. Pause and speed changes take effect immediately.

  - OSF: scan count and duration come from the stream stats, and seeking uses the per-message index (or even spacing, if the file has none).

  - PCAP: read with PcapReader. A background thread indexes the file so the replay can seek, and the panel shows up once that finishes.

  • New start_paused parameter (MOLA_DATASET_START_PAUSED in the launch files).

  - Fix: allocate the LidarScan from the sensor info, so it has the right number of columns per packet. Profiles not using the default one made ScanBatcher throw on the first packet.

• ci: add GitHub release workflow on version tags Adds scripts/release.py (version-consistency check + changelog-based release notes) and .github/workflows/github-release.yml, which creates a GitHub Release whenever a M.m.P tag is pushed. Mirrors the pipeline already used in nanoflann_vendor.

• Merge pull request #2 from MOLAorg/perf/osf-rev8 Fix LiDAR sensorPose, speed up scan conversion, add scan decimation

• Docs: LiDAR sensorPose is the mounting pose; fix transform direction in log

• Fix LiDAR sensorPose, speed up scan conversion, add scan decimation

  - Fix: point clouds had lidar_to_sensor_transform applied twice. The SDK's XYZ LUT already maps ranges into os_sensor, and sensorPose composed the same transform (typically a 180 deg yaw) again, so the cloud was rotated with respect to the IMU frame. sensorPose is now the mounting pose alone. On a sideways-mounted sensor with the IMU gravity prior on, a 62 s run drifted 9 m with the old pose vs 0.1 m with the fix.

  - scanToObservation() resolved channel fields by name for every pixel. It now resolves them once per scan, sizes the cloud once and fills its buffers through raw pointers: 124 -> 28 ms per 4096x256 scan, producing identical point data.

  - New decimate_columns / decimate_rows parameters (OUSTER_DECIMATE_COLUMNS / OUSTER_DECIMATE_ROWS in the launch files) keep every N-th column / row, for high-resolution sensors whose full scans are more than LiDAR odometry needs.

  - OSF replay: skip IMU samples whose slot was never filled (zero timestamp), as happens in a partial first scan.

• Merge pull request #1 from MOLAorg/feat/mrpt3 Port to MRPT 3.x

• Merge remote-tracking branch 'origin/develop' into feat/mrpt3

• build: fall back to bundled Ouster SDK when a system OusterSDK export is incomplete Another package in the workspace can export a CMake package also named OusterSDK; if that export is missing its generated Targets.cmake file, find_package() aborted the whole configure instead of just reporting not-found. Check for that file

File truncated at 100 lines see the full file