FAST-LIO pcap record/replay + Virtual Livox

[jeff-hykin]

Adds virtual mid360 pcap record/replay to FAST-LIO; rips out the in-process pcap reader and the output-cloud downsampling/denoising.

Usage / Testing

Pcap to DB (also generates .rrd)

# gen <pcap>.db from the pcap (a <db>.rrd quick-look is written next to it)
python -m dimos.hardware.sensors.lidar.fastlio2.tools.pcap_to_db \
    --db output_mem2.db \
    --config overrides.yaml \
    --pcap mid360_shake_stairs/mid360_shake_stairs.pcap

Record a Mid-360 pcap

# Allow using tcpdump without sudo (only need to do once)
sudo setcap cap_net_raw,cap_net_admin=eip "$(which tcpdump)"
# set this (env var or python module config)
export DIMOS_PCAP_IFACE=enp2s0

from dimos.core.coordination.blueprints import autoconnect
from dimos.core.coordination.module_coordinator import ModuleCoordinator
from dimos.hardware.sensors.lidar.livox.pcap_recorder import LivoxPcapRecorder

record = autoconnect(
    LivoxPcapRecorder.blueprint(
        pcap_path="recordings/run1.pcap",
        # lidar_ip="192.168.1.107",
        # record_pcap_iface="enp2s0",
    ),
)
ModuleCoordinator.build(record).loop()

Replay a pcap to a module

from dimos.core.coordination.blueprints import autoconnect
from dimos.core.coordination.module_coordinator import ModuleCoordinator
from dimos.hardware.sensors.lidar.livox.virtual_mid360.module import VirtualMid360
from dimos.hardware.sensors.lidar.fastlio2.module import FastLio2
from dimos.visualization.vis_module import vis_module

replay = autoconnect(
    VirtualMid360.blueprint(
        pcap="recordings/run1.pcap",
        # lidar_ip="192.168.1.155",
    ),
    FastLio2.blueprint(),
    vis_module("rerun"),
).global_config(n_workers=3)
ModuleCoordinator.build(replay).loop()

[greptile-apps]

Greptile Summary

This PR adds pcap record/replay support to FAST-LIO2 (and harmonises the parallel PointLIO path), introducing a VirtualMid360 → FastLio2 → FastLio2Recorder pipeline that converts a Mid-360 pcap into a memory2 SQLite db plus a Rerun .rrd quick-look. It simultaneously strips out the in-process YAML config, world-frame cloud transform, voxel map, and cloud_filter/voxel_map.hpp headers from both the C++ binary and the Python module, replacing them with plain CLI-arg tuning.

• New FastLio2Recorder + pcap_to_db tool: wires VirtualMid360 (pcap replay over the Livox wire protocol) to an unmodified FastLio2 instance, polls the SQLite db until the lidar stream stagnates, then writes an aggregated world-frame .rrd.
• C++ refactor (main.cpp): YAML config path removed; all FAST-LIO tuning now comes from CLI args parsed directly into FastLioParams; SDK uninit is correctly ordered before clearing globals; the main loop is factored into run_main_iter; clouds are now published in the sensor frame (not world frame).
• PointLIO parity: the same YAML→CLI migration, sensor_frame_id, child_frame_id fix, TF-broadcast callback, and pcap_to_db script are applied symmetrically to the PointLIO module and recorder.

Confidence Score: 5/5

Safe to merge — the changes are well-scoped and the removed C++ infrastructure (world-frame cloud transform, voxel map, YAML config) is cleanly replaced by CLI-arg tuning with correct defaults.

The C++ refactor correctly re-orders SDK uninit before nulling globals (preventing a late-callback race), the new FastLio2Recorder mirrors the established PointlioRecorder pattern, and the pcap-to-db tool has a layered drain-detection strategy. The only finding is a minor timestamp-fallback inconsistency between FastLio2 and PointLio's TF callbacks that has no practical impact at runtime.

dimos/hardware/sensors/lidar/fastlio2/module.py (minor ts-fallback inconsistency with the PointLio counterpart)

Important Files Changed

Filename	Overview
dimos/hardware/sensors/lidar/fastlio2/tools/pcap_to_db.py	New script that wires VirtualMid360 + FastLio2 + FastLio2Recorder to convert pcap files to SQLite db + rerun .rrd. Well-structured with a pcap-span parser, poll-until-drained loop, and non-fatal .rrd generation. Stagnation-timer initialisation issue was flagged in a previous thread.
dimos/hardware/sensors/lidar/fastlio2/module.py	Major refactor: drops YAML config and mount/map-freq/cloud-filter fields, gains sensor_frame_id + TF-broadcasting _on_odom_for_tf. Minor ts-fallback inconsistency with PointLio counterpart.
dimos/hardware/sensors/lidar/fastlio2/recorder.py	New FastLio2Recorder that appends odometry and lidar into a memory2 SQLite db with pose stamping via @pose_setter_for. Clean and consistent with PointlioRecorder.
dimos/hardware/sensors/lidar/fastlio2/cpp/main.cpp	Large refactor: drops YAML config, world-frame cloud transform, voxel map, and init-pose offset; gains plain-CLI tuning args, run_main_iter factoring, and correct SDK uninit ordering (LivoxLidarSdkUninit before null-ing globals). Sensor-frame cloud path is clean.
dimos/hardware/sensors/lidar/pointlio/scripts/pcap_to_db.py	New pcap-to-db script mirroring the fastlio2 version for PointLio. Carries the same last_lidar_max = 0.0 stagnation-timer initialisation issue as the fastlio2 counterpart (flagged separately).
dimos/hardware/sensors/lidar/pointlio/module.py	Parallel refactor to FastLio2: drops YAML, gains CLI-driven PointLioParams, sensor_frame_id, and child_frame_id fix (was body_frame_id). TF-broadcast _on_odom_for_tf correctly uses msg.ts directly.
dimos/hardware/drive_trains/flowbase/config.py	New file holding FLOWBASE_MID360_MOUNT pose constant. Currently unused — flagged in a previous thread.
dimos/memory2/module.py	Adds Recorder infrastructure: pose_setter_for decorator, _prepare_streams for APPEND mode, _resolve_pose/ts, and TF recording. Substantial new capability but well-structured.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant pcap_to_db as pcap_to_db script
    participant Coord as ModuleCoordinator
    participant VM360 as VirtualMid360
    participant FL2 as FastLio2 (C++ binary)
    participant Rec as FastLio2Recorder
    participant DB as SQLite DB

    pcap_to_db->>Coord: build(blueprint)
    Coord->>VM360: start()
    Coord->>FL2: start() [waits warmup_sec]
    Coord->>Rec: start()

    VM360-->>FL2: Livox wire protocol (UDP) host_ip/lidar_ip alias
    FL2-->>Rec: odometry (LCM → Out port)
    FL2-->>Rec: lidar pointcloud (LCM → Out port)
    Rec-->>DB: append fastlio_odometry / fastlio_lidar

    loop every _POLL_SEC
        pcap_to_db->>DB: _odom_stats(odom_stream) + _odom_stats(lidar_stream)
        DB-->>pcap_to_db: (count, min_ts, max_ts)
        alt lidar_max stagnant for _STAGNANT_SEC OR sensor span reached
            pcap_to_db->>Coord: stop()
        end
    end

    pcap_to_db->>DB: _write_rrd (aggregate world cloud + path)
    DB-->>pcap_to_db: .rrd file

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant pcap_to_db as pcap_to_db script
    participant Coord as ModuleCoordinator
    participant VM360 as VirtualMid360
    participant FL2 as FastLio2 (C++ binary)
    participant Rec as FastLio2Recorder
    participant DB as SQLite DB

    pcap_to_db->>Coord: build(blueprint)
    Coord->>VM360: start()
    Coord->>FL2: start() [waits warmup_sec]
    Coord->>Rec: start()

    VM360-->>FL2: Livox wire protocol (UDP) host_ip/lidar_ip alias
    FL2-->>Rec: odometry (LCM → Out port)
    FL2-->>Rec: lidar pointcloud (LCM → Out port)
    Rec-->>DB: append fastlio_odometry / fastlio_lidar

    loop every _POLL_SEC
        pcap_to_db->>DB: _odom_stats(odom_stream) + _odom_stats(lidar_stream)
        DB-->>pcap_to_db: (count, min_ts, max_ts)
        alt lidar_max stagnant for _STAGNANT_SEC OR sensor span reached
            pcap_to_db->>Coord: stop()
        end
    end

    pcap_to_db->>DB: _write_rrd (aggregate world cloud + path)
    DB-->>pcap_to_db: .rrd file

Loading

_{Reviews (2): Last reviewed commit: "fastlio main.cpp: match pointlio formatt..." | Re-trigger Greptile}

[greptile-apps]

Stagnation timer arms prematurely on first poll

last_lidar_max is initialised to 0.0, and _odom_stats returns 0.0 for MAX(ts) when the table is empty (via row[2] or 0.0). The very first poll iteration after odometry appears will therefore evaluate lidar_max == last_lidar_max as True, immediately arming stagnant_since. If the recorder's lidar table hasn't been written yet at that moment — which can happen because FAST-LIO rate-limits lidar publishes to pointcloud_freq (default 100 ms) — the 5-second stagnation clock is already running. In the worst case this causes an early exit before a single lidar frame is recorded.

The same pattern exists in dimos/hardware/sensors/lidar/pointlio/scripts/pcap_to_db.py (line 263). Initialising last_lidar_max = None and skipping the stagnation check until at least one non-zero lidar frame has been observed would avoid the false positive.

[greptile-apps]

FLOWBASE_MID360_MOUNT is defined but never imported or used

This file was introduced in this PR to hold the FlowBase mount pose, but a search of the entire codebase shows no import site for FLOWBASE_MID360_MOUNT. The counterpart _flowbase_mid360_mount was removed from mobile.py along with the mount= parameter (which was also removed from FastLio2Config). As written, this constant is dead code — the mount pose is not compensated anywhere for the FlowBase. Either wire it into a downstream TF publisher / extrinsic field, or remove the file until it is needed.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!