When a FAST-LIO map looks clean while stationary but smears during turns, check the point-time contract before changing the LiDAR–IMU extrinsics. A field with the right name can still carry the wrong unit, origin, or meaning. Motion compensation needs the acquisition time of individual points; a cloud arriving regularly does not prove those times are interpreted correctly.
Start with the exact driver and estimator revisions, inspect the incoming timing field, and calculate the duration it represents. Then compare a stationary capture and a controlled moving capture using the same configuration. This procedure narrows a timing-scale problem without treating every distorted wall as a calibration failure.
The LiDAR and IMU recording guide explains how to preserve the necessary data. Here the decision is narrower: whether the installed consumer converts that preserved field correctly. Keep the original recording intact while testing interpretation changes on copies.
Identify the code path that actually consumes your cloud
The upstream FAST-LIO repository provides implementation-specific guidance about point timing and supported input paths. Its ROS 1 examples are not automatically the contract of a ROS 2 port. Record the repository, commit, launch configuration, LiDAR type selection, message type, and any conversion node between the driver and estimator.
Follow one message from publication to preprocessing. Confirm whether the consumer receives a custom sensor message or PointCloud2, and whether a converter renames fields, casts their types, subtracts a reference time, or changes units. Changing a parameter in an unused launch file has no diagnostic value. Save evidence of the effective runtime parameter and the input handler that uses it.
The upstream preprocessing header defines time-unit enum values SEC=0, MS=1, US=2, and NS=3. It also defines different point layouts, including a floating-point time and an integer t. These details are a source reference for that implementation, not a universal numbering scheme for every fork.
Write a field contract before selecting a unit
A useful contract records the field name, storage type, unit, reference origin, and range within a cloud. The ROS 2 PointField definition describes names, offsets, datatypes, and counts; it does not assign a universal meaning to a custom time field. Obtain that meaning from the driver documentation or source.
| Evidence | Question to answer | Failure it can reveal |
|---|---|---|
| Field name and datatype | Does the consumer read the field the driver emits? | Missing field or incompatible layout |
| Unit and conversion | Are values seconds, milliseconds, microseconds, or nanoseconds? | Timing scale differs by powers of ten |
| Origin | Is each value relative to scan start, another reference, or an absolute clock? | Correct unit with incorrect reference time |
| Coverage | What acquisition interval do the valid points span? | Zeros, resets, incomplete data, or unintended batching |
| IMU relationship | Do IMU samples cover the same interval in an aligned clock? | Insufficient coverage or inter-sensor offset |
Inspect several complete messages, not just the first point. Record minimum and maximum valid values and representative samples at different positions. Storage order may follow rings or packet assembly rather than acquisition order, so a decreasing value between neighboring array entries is not by itself proof of broken timing.
Calculate the implied scan duration
In the upstream PointCloud2 preprocessing implementation, the time-unit switch converts supported input values to an internal millisecond scale: seconds multiply by 1,000; milliseconds by 1; microseconds by 0.001; and nanoseconds by 0.000001. The custom-message overload follows a separate handler, so this switch is not a general fix for every input format.
For an illustrative calculation, suppose a driver explicitly documents relative microsecond offsets spanning 0 to 100,000. The represented interval is 0.1 seconds, or 100 milliseconds. Interpreting those same numbers as milliseconds produces 100 seconds. This example demonstrates unit conversion; it is not a claimed scan duration or performance measurement for any sensor.
Compare the converted interval with the documented acquisition window and actual batching mode. Do not require equality with the publication period: a message can combine packets, omit points, or represent a partial sweep. If these boundaries are unclear, the scan-batching diagnostic helps separate message grouping from acquisition timing.
Also inspect the message header. The PointCloud2 definition includes acquisition time and frame in its header, but your driver’s convention still determines how per-point offsets relate to that stamp. Correcting a unit does not resolve a start-versus-end reference mismatch or synchronize two independent clocks.
Compare static and moving runs with one variable changed
Select a scene containing rigid walls and edges at varied orientations. Secure the sensors and cables, retain the same filters and extrinsics, and capture a stationary baseline. Then use a controlled movement permitted by the platform’s test procedure. Keep people outside the operating area and avoid changing timing, calibration, and filtering together.
Inspect the same structures in both runs. A clean stationary cloud can coexist with incorrect point timing because the platform moves little during acquisition. Distortion that increases during rotation is a clue to investigate timing and compensation, but it can also arise from synchronization, IMU axes, or changing mounts. Preserve those alternatives in the test record.
Change the unit interpretation only when the field contract supports it. Repeat the same movement and retain the previous output for comparison. The motion-distortion and sampling guide gives broader application context; the present experiment should remain focused on a documented scale change.
Decide what the evidence permits you to change
A corrected conversion and improved repeated moving runs support retaining that conversion. They do not establish that the extrinsics are accurate or that the full navigation system is qualified. If the point interval is plausible but distortion persists, inspect clock alignment, IMU sample coverage, frame conventions, and mechanical rigidity before recalibrating.
The calibration workflow addresses those broader spatial and temporal relationships. Keep the timing-scale worksheet alongside the calibration output so a later software update does not silently invalidate the input contract. A changed driver revision deserves a fresh check even when its topic name is unchanged.
For commissioning, save a compact evidence package: device and firmware identities, driver and estimator commits, effective parameters, timing-field samples, converted interval, clock references, stationary and moving recordings, and a short before-and-after observation. Agree on application-specific geometric acceptance criteria before selecting the better-looking result. The robot pallet-handling test guide illustrates how integration evidence should connect to the task the robot must perform.
Questions engineers ask during timestamp diagnosis
Can a stable cloud publication rate rule out wrong time units?
No. Publication cadence describes messages leaving the driver. Per-point offsets describe acquisition within those messages. Both can look regular while the consumer applies an incorrect scale.
Should I try every timestamp-unit value and choose the best map?
Use the documented field contract first. Blind trials can hide a second error and create an unexplained configuration. Test only interpretations justified by the emitting and consuming code.
Does a unit correction replace LiDAR–IMU time synchronization?
No. Scale, reference origin, and inter-sensor clock alignment are separate checks. Confirm all three before treating motion compensation as reliable.
When should I recalibrate?
Recalibrate when timing interpretation and sensor alignment checks are supported by evidence, the mount is stable, and repeated validation still indicates a spatial transform problem. Keep the same test scene to make the next comparison meaningful.
