Real sensor beam tables

Both captures below are the same scene, the same seed, the same thirty-two channels and the same vertical field from minus 25 to plus 15 degrees. The only difference is the table. On the left, the VLP-32C’s measured elevations; on the right, the even ladder every open-source simulator produces when you give it those two numbers.

Same channel count, same field, different sensor. A detector trained on the right cloud has learned a ring spacing no hardware produces, and finds out on the day it meets the real one.

The elevations come from the calibration files the vendors’ ROS drivers ship, in firing order rather than sorted, because firing order is what per-point timing depends on. Where a value is derived rather than published, the profile says so and the derivation is written into capture.json under lidar.beams.approximations. The HDL-64E is the clearest case: its two laser blocks have published endpoints but no published per-laser angles, so the record says the angles inside each block are spread evenly, rather than leaving a reader to assume a calibration file behind them. A dataset built on a derived table cannot be mistaken for one built on a measured one.

Choosing a sensor in the Studio hides the channel count and vertical field controls, because those two numbers are consequences of the table rather than settings. Rotation rate, points per turn, range and both noise figures stay editable, because they are configurable on the hardware too. A custom mode keeps the plain two-number field for a head that is not in the list.

A real head does not photograph a scene, it sweeps one. A revolution at 10 Hz takes a tenth of a second, and each laser fires at its own offset inside the firing cycle. Every point NameFrame writes carries that time: the column’s fraction of the revolution plus the laser’s own offset, in microseconds, as a time_us column in the PLY and as lidar.times.bin beside the KITTI file, whose four-float record has no room for it. Anything doing odometry or de-skewing needs those times, and a sweep that reports one timestamp for every point quietly tells it the vehicle never moved.

A vehicle carrying a spinning head does not wait for the revolution to finish, so the returns at the end of a sweep are taken from somewhere else than the returns at the start. That mismatch is what de-skewing exists to undo, and a simulator that samples the whole cloud from one pose quietly deletes it from the data.

With motion enabled, each ray leaves from where the sensor has reached by its own firing time, and the return is still written against the pose the frame publishes: exactly the skew a real cloud carries. The velocity comes from the previous frame at the declared frame rate, and lidar.json records it in the point convention, so a consumer can undo the skew with the numbers as written.

Measured against the matched still capture with the noise zeroed: rays fired in the first millisecond of the revolution moved 0.018 m where velocity times time predicts 0.017, growing to about three metres by the end of the turn. It is off unless asked for, it requires a video capture because that is what defines the interval a velocity is measured over, and where it cannot be measured, the first frame of a run, or a camera cut, the frame records the refusal and the reason instead of quietly writing an unskewed sweep.

The instance ids are the point. The boat that is instance 7 in the RGB mask is instance 7 in the point cloud, from the same frame, so image and cloud agree about which object is which without an annotation pass. An optional gate refuses a frame when an object visible in the image received no return at all, which is the failure that ruins a fusion dataset silently.