fix(rosbag): widen Reader.messages start by 1ns to dodge rosbags MCAP chunk-filter off-by-one

[hakuturu583]

Summary

Defensive workaround for an off-by-one bug in rosbags' MCAP backend that causes Rosbag2Reader.get_pointcloud (introduced in #277) to drop messages sitting at chunk boundaries. Observed loss is data-dependent but can exceed 50% for high-rate topics such as LiDAR packets.

Root cause (in rosbags upstream)

rosbags/rosbag2/storage_mcap.py:591:

if (start is None or start < x.message_end_time):

message_end_time is the inclusive timestamp of the chunk's last message, so the comparison should be <=. When the message we want is the last message of its chunk, the chunk is excluded from the search and the query returns empty.

Fix

Widen start by 1ns in Rosbag2Reader.get_pointcloud. The interval [target_ns - 1, target_ns + 1) still uniquely identifies the target packet (timestamps within the same topic are not packed at 1ns spacing).

Impact

On one production T4 dataset (50 frames, 6 LiDAR channels), 334 of 571 hesai_front_left packets (~58%) were previously unretrievable; all packets resolve after this fix.

Follow-up

A separate issue will be filed against rosbags upstream to fix the comparison at the true root cause. Once that lands and we bump our pinned rosbags, this widening remains correct and can stay as-is.

Test plan

• New regression test in tests/rosbag/test_reader.py exercises a packet at a chunk boundary
• pytest tests/rosbag/ -v passes
• ruff check clean

🤖 Generated with Claude Code

[github-actions]

☂️ Python Coverage

current status: ❌

Overall Coverage

Lines	Covered	Coverage	Threshold	Status
4588	3782	82%	50%	🟢

New Files

No new covered files...

Modified Files

File	Coverage	Status
t4_devkit/rosbag/reader.py	72%	🔴
TOTAL	72%	🔴

updated for commit: 20ea389 by action🐍