Does Ouster SLAM consume LEGACY PCAP IMU before OSF writing?

Software
, ,
1

We are processing vehicle-mounted Ouster OS1-64 U02 data using Ouster SDK and ouster-cli.

Capture details:

  • Firmware: v2.5.3
  • IMU profile: LEGACY
  • LiDAR mode: 1024x20
  • Current voxel test: 1.4 m
  • Environment: open rural road, sparse field, powerlines, limited trees
  • Motion event: braking, reversing, and turning around

The original PCAP contains continuous LiDAR and IMU packets. We found no packet loss, timestamp gaps, duplicate frames, invalid timestamps, or nonfinite IMU samples. Our external BestNav trajectory is also continuous and time-aligned.

During normal driving, SLAM is coherent. During braking followed by a reverse-direction turn, forward translation collapses and the map becomes compressed or folded.

The raw LEGACY IMU packets remain present in the PCAP, but the generated OSF does not expose synchronized IMU fields. The CLI reports that synchronized IMU is unavailable and appears to fall back to constant velocity.

Our Phase 0.131_1 path opens the PCAP, writes a source OSF, and then passes that OSF to the SLAM pose-building path. We need to determine whether the IMU is being used internally before the OSF is written, or whether it is completely unavailable to the pose estimator.

Questions:

  1. Can the Ouster SDK or mapping::SlamEngine consume LEGACY IMU packets internally from the original PCAP when those samples are not exposed as synchronized IMU fields in the generated OSF?
  2. If legacy IMU is consumed internally, what exact API, field, stream, or runtime log proves that accelerometer and gyro samples were used for deskew or scan-matching prediction?
  3. If legacy IMU is not consumed, is there an official method to preserve or convert those packets into synchronized OSF IMU data that ouster-cli slam --deskew-method imu_deskew can consume?
  4. Can sparse actual RANGE support cause ICP to accept a false low-forward-motion solution even when LiDAR packets, timestamps, and columns remain valid? Does Ouster provide a supported method to reject ICP and skip map updates when actual RANGE geometry is insufficient?
  5. Can external time-aligned velocity or acceleration be supplied before ICP as a motion prior while preserving Ouster rotation, and what exact Ouster-supported workflow is recommended for braking and sharp turns in sparse outdoor scenes?
  6. Our OS1-64 U02 uses FW 2.5.3 with the LEGACY IMU profile. Would upgrading to a newer hardware revision, such as V7 or V8, provide FW 3.2+, ACCEL32_GYRO32_NMEA, and synchronized IMU support for imu_deskew? Is this limitation hardware-dependent, firmware-dependent, or both?

We are trying to determine whether the IMU is already participating in the Phase 0.131_1 pose path but is not being preserved in the OSF, or whether the pose estimator is operating without IMU entirely. We also need to know whether the supported solution is available through the CLI/SDK or requires a custom native SLAM modification.

2

The SDK builtin SLAM solution doesn’t process the LEGACY IMU data. It will fallback to the velocity based deskewing method (which wouldn’t work great if you have sudden movements or breaks).

Answers to the questions:

  1. The current SLAMEngine implementation doesn’t consume or process the LEGACY IMU, you will need a different implementation that does this and perform interpolation for it, which although can work but wouldn’t match the same performance and accuracy when you have the SYNCRHONIZED IMU enabled.
  2. It isn’t consumed
  3. there isn’t a method to do the conversion
  4. The current implementation does reject the frames that is missing large portion of the frame (more than 50% packets missing) but it doesn’t look at the frame contents. More robust ways to reject frames is in developement.
  5. The API currently doesn’t yet expose that but we should
  6. Yes, the Synchronized IMU feature requires a REV7 hardware+ and a FW 3.2+, the mapping quality will be a lot better especially if your platform anticipate sudden moves or fast rotations.

Hope this helps!