RPM to Degrees per Second

Divide the sweep rate in degrees per second by a thousand. At 600 RPM that gives 3.6° per millisecond, so a single degree of azimuth takes about 278 microseconds. It matters because a point cloud is not a photograph: the packet header carries a time, but each column inside it was measured at a slightly different instant, and the azimuth field is the only way to recover which one. Software that stamps every point in a revolution with the same time is throwing away up to a full sweep duration of accuracy, which at highway speeds is metres of position error on the far side of the scan. Sensors that publish a per-column azimuth alongside a synchronised clock exist precisely so that a consumer can interpolate a pose for each column rather than for the frame.

Because the sensor origin moves while the beam sweeps. A revolution at 600 RPM takes 100 milliseconds, and a vehicle at 72 km/h travels two metres in that time, so points gathered at the end of the turn were measured from a viewpoint two metres further down the road than the points at the start. Assembling them into one cloud in sensor coordinates stretches walls, curves straight kerbs and smears anything the scan crosses obliquely. Rotation is worse than translation: a brisk yaw during a turn shears the whole sweep sideways. The fix is deskewing — interpolating the platform pose across the sweep from wheel odometry or an inertial unit and transforming each column into a common frame at the sweep's reference instant. Spinning faster reduces the error simply because there is less time for anything to move.

Directly and unforgivingly, because the firing electronics run at a fixed pace regardless of how fast the head turns. A sixteen-beam head producing 300 000 points per second emits about 18 750 columns per second. At 300 RPM that is 3 750 columns spread over a revolution, roughly 0.1° apart; at 600 RPM it becomes 1 875 columns and 0.19°; at 1 200 RPM only 938 columns and 0.38°. The consequence is a detection range limit that has nothing to do with laser power: a 0.4° step means beams are 70 centimetres apart at 100 metres, so a narrow object such as a post can slip between two columns entirely. Slower spinning buys back that detail at the cost of update rate, which is why a sensor watching for small obstacles at range and a sensor tracking fast traffic are usually configured differently.

Sixty divided by the revolutions per minute gives the seconds between consecutive looks at any fixed bearing: twelve seconds at 5 RPM, four at 15 RPM, two and a half at 24 RPM. That interval sets how far a target can move unobserved and therefore how large the association gate in a tracker must be, which is why long-revisit systems need better motion models to keep tracks joined up. Dwell time is the other half of the story: it is the beamwidth divided by the sweep rate, so a 1.4° beam at 90 °/s illuminates a target for about 15 milliseconds, and how many pulses fit into that window decides how much integration gain is available. Speeding the antenna up shortens both numbers together, improving reaction time while weakening detection on the faintest targets.

Take the once-per-revolution index pulse the head provides, work out the angle from that index to the bearing you want, and divide by the sweep rate to get the delay. At 3.6° per millisecond, a camera looking 90° off the index needs a 25 millisecond delay after each pulse. Two practical cautions apply. Exposure has width: a 10 millisecond exposure spans 36° of sweep at that rate, so the beam and the shutter only overlap over part of the frame and a shorter exposure tightens the alignment considerably. And any fixed latency in the trigger path — opto-isolator, shutter lag, rolling readout — shifts the azimuth the camera actually catches, so the delay is normally calibrated against a target rather than trusted from the arithmetic alone.