[GSoC 2026 Project #7] Architectural query on IMU/LiDAR temporal alignment and queue blocking in Dora's event loop

[ydhc777]

Hello mentors (@ruping Cen) and the dora-rs community,
I have a specific architectural question regarding the Localization Operator when handling optional IMU inputs alongside LiDAR data.
Given dora-rs's asynchronous Event::Input stream mechanism, if the Localization Operator is occupied processing a heavy LiDAR scan (e.g., executing an NDT or AMCL update), the high-frequency IMU events might pile up in the operator's input queue. This queue blocking could lead to processing stale IMU data, severely impacting real-time pose estimation.

My questions regarding the expected design pattern for Project #7 are:

1.Internal vs. External Alignment: Is the Localization Operator expected to handle this asynchrony internally (e.g., implementing a dedicated Ring Buffer and timestamp interpolator to align the Arrow-backed IMU/LiDAR messages), or is the preferred DORA_NAV architecture to utilize a framework-level synchronization node upstream that ensures time-aligned "tick" events before piping data into the localization node?

2.Queue Management: Are there recommended dora.yaml configuration patterns (like specific drop strategies or queue size limits) we should adopt to mitigate this exact sensor fusion bottleneck in simulation and real-world datasets?

[KOKOSde]

For an MVP, keep the IMU and LiDAR alignment inside the Localization Operator with a bounded timestamped IMU ring buffer. Do not block waiting for perfect sync, just interpolate from the freshest IMU window around each LiDAR scan.