Both architectures will clear a typical navigation spec. They fail differently, and the failure mode you get is a function of operating hours, mechanical environment, and ambient light — none of which appear on the datasheet.
Range, FOV, angular resolution, accuracy, update rate, IP rating. A rotating unit and a solid-state unit can match on every line and still diverge sharply in service, because the parameters that separate them are operational rather than optical.
What follows is the reasoning we use when the spec is already satisfied and the question becomes which architecture to put on the machine.
The architectural difference, and what follows from it
A rotating scanner sweeps one or more emitter/receiver pairs through 360° of azimuth on a motorized assembly. Elevation coverage comes from channel count — a 48-channel unit stacks 48 beams across a vertical fan, and each rotation samples the full azimuth at each of those elevations. The mechanism is what buys the 360°, and the mechanism is a bearing under continuous load.
A solid-state unit illuminates a fixed field with no macroscopic moving parts. Coverage is bounded by the optical design — typically a forward fan or cone. There is no bearing, and there is also no way to see behind the sensor.
Nearly every practical difference between the two derives from those two paragraphs.
| Property | Rotating | Solid-state |
|---|---|---|
| Wear mechanism | Bearing + optical assembly, load accumulates in revolutions | No rotating mass; wear dominated by emitter/driver aging |
| Coverage | 360° azimuth, elevation set by channel count | Fixed FOV — forward fan or cone |
| Shock/vibration | Rotating mass couples to chassis excitation | No resonant rotating assembly |
| Per-point dwell | Short — bounded by rotation rate | Longer integration possible on fixed field |
| Ambient (sun) rejection | Set by emitter wavelength; dwell is secondary | Set by emitter wavelength; longer integration is a secondary aid |
| Motion artifact | Rolling-shutter-like skew during motion | Whole-field capture, less skew |
| Typical failure | Bearing wear, gradual accuracy drift | Emitter degradation, thermal derating |
Duty cycle: converting MTBF into a calendar
MTBF is a rate expressed in hours, and it is routinely misread as a date. For a mechanism whose wear accumulates in revolutions, the useful conversion is:
At 20 Hz, the assembly turns 72,000 times per powered hour — 1.73 × 10⁶ per 24-hour day. A single-shift machine at 8 powered hours accumulates that same count in three calendar days. Same sensor, same MTBF figure, replacement intervals separated by a factor of three in wall-clock time.
This matters because the sensor accrues revolutions whenever it is powered, not whenever the robot is moving. An AMR idling at a charge station with the stack up is still turning the bearing. Utilization in the fleet-management sense and duty cycle in the sensor-wear sense are different numbers, and the gap between them is often large.
The question worth asking is not whether the MTBF figure is good. It is: given my scan rate and powered hours, what revolution count does the unit reach at my planned replacement window, and where does that sit against the published life?
Do that arithmetic before the fleet ships and the answer is a maintenance interval. Do it after and it is a field failure rate.
A note on failure distribution
Bearing wear is a wear-out mechanism, so failures cluster rather than distributing uniformly. A fleet commissioned in the same month tends to reach the wear-out region of the bathtub curve in the same quarter. Solid-state failure modes — emitter degradation, driver aging, thermal derating — are generally gradual and show up as measurable performance drift rather than a step change to zero. Which of those two profiles your service organization would rather absorb is a real question, and it is not always the one with the better mean.
Mechanical environment
A rotating assembly has a rotating mass with a resonant frequency. Chassis excitation couples into it. Repeated shock — a forklift crossing a dock plate, an AGV on broken asphalt, an AMR hitting the same expansion joint two hundred times a shift — is a periodic load applied at a rate set by the traffic pattern, not by anything the sensor controls.
Two things follow. First, a rated shock tolerance and a rated vibration tolerance are separate claims addressing separate mechanisms — a single high-g transient and a sustained sinusoidal or random input load the bearing differently, and a unit qualified against one is not thereby qualified against the other. Read both lines on the datasheet, and read them against your environment rather than against each other. Second, the relevant number is not peak shock magnitude but the count of shock events over the service interval. A single 5 g impact is unremarkable. Two hundred per shift, at a repeatable frequency, over three shifts, is a fatigue input — and fatigue is a function of cycle count, not peak amplitude.
Solid-state units have no rotating mass to excite. On sealed indoor concrete the distinction is close to academic. On a yard tractor or an outdoor AGV it is the dominant term.
Ambient light and operating wavelength
Sunlight is broadband noise across the near-infrared band, and rejecting it is fundamentally an SNR problem. The dominant lever here is not architecture — it is the emitter wavelength, and it applies equally to rotating and solid-state units.
The solar spectrum at ground level is not flat. It has deep absorption notches where atmospheric water vapor removes most of the incident IR — around 950 nm, 1150 nm, and across the 1300–1400 nm band. A LiDAR whose emitter sits in one of those notches operates against a much lower ambient floor than one at, say, 905 nm, where solar irradiance is strong. This is why 1550 nm and other long-wave designs tolerate direct sun that overwhelms a 905 nm unit. The mechanism is the wavelength, not whether the assembly spins.
Integration time is a secondary factor. A unit that can dwell longer on a given return — whether by architecture or by trading frame rate — improves SNR against a fixed ambient floor, and a fixed-field design has more freedom to make that trade than one whose per-point dwell is bounded by rotation rate. But this is a smaller effect than choosing an emitter band that the sun does not occupy, and it does not substitute for it.
The practical consequence for selection: if direct sun is in the operating envelope, the first question is the emitter wavelength, not the architecture. A rotating unit in a solar-blind band will outlast a solid-state unit at 905 nm in bright sun, and no amount of integration time closes that gap. Put direct sun in the test plan with a time-of-day axis regardless, because the interaction with your specific surfaces is hard to predict from the datasheet alone.
Motion artifacts
Less discussed and worth a line. A rotating unit samples azimuth sequentially, so a full revolution is not an instantaneous snapshot — it is a sweep taken over the rotation period, during which the platform has moved. At 20 Hz, a robot at 2 m/s translates 10 cm within one revolution. The resulting skew is systematic and correctable if you have accurate ego-motion and timestamp the points properly, but it is a real term in the error budget and it scales with platform speed.
Whole-field solid-state capture largely sidesteps this. If your platform is fast and your localization is tight, the arithmetic is worth doing.
Coverage: what the application actually requires
Full 360° azimuthal coverage is the right default for most mobile platforms. It is genuinely required whenever the robot localizes by scan-matching against a mapped environment and needs geometry in every direction to constrain the pose — in a repetitive aisle environment, azimuthal coverage is what makes the match well-conditioned — and it is what lets a single sensor cover approach directions the path planner does not fully control. Most AMR and AGV deployments need it, and specifying it is usually correct rather than reflexive.
The cases where a narrower field suffices are real but specific: a machine whose motion, obstacle set, and reverse handling are all tightly constrained — forward travel with a dedicated rear-facing sensor, for instance. Where those constraints genuinely hold, a fixed forward field removes a bearing; where they only mostly hold, the coverage gap is a liability. Treat the narrower field as the exception that has to be justified, not the default.
A common configuration takes both: a rotating unit for localization plus a solid-state unit for forward obstacle detection. That is not redundancy. The two are answering different questions — where am I, and what is about to be in the way — at different update rates and different confidence requirements. Their failure modes are also largely uncorrelated, which is the more interesting property.
Selection heuristics
Rotating
- Localization by scan-matching against a map; pose constraint requires azimuthal coverage.
- One or two shifts, indoors, sealed floor — revolution accumulation is slow relative to the replacement window.
- Mapping, survey, or digital-twin work, where full-scene 3D is the deliverable rather than an input.
- Range or elevation coverage is the binding constraint. For reference, the VF48-50 is 48 channels, 360° × 50°, 50 m, IP67; the LR-16F-100 extends to 100 m.
Solid-state
- Continuous or three-shift operation, where revolution count over the service interval is the dominant term.
- High shock-event count: outdoor surfaces, dock plates, expansion joints, yard duty.
- Direct sunlight inside the operating envelope rather than at its edge.
- Platform speed high enough that intra-revolution skew is a meaningful line in the error budget.
- Forward perception is the actual requirement. The LR-F240 covers a 10 cm – 12 m forward fan; the VSS-50 gives a wide 3D fan from 50 cm to 50 m.
Neither architecture is a safety function
Stated plainly because the comparison invites the error.
Both are perception sensors. Neither is certified to initiate a protective stop for a person. Functional safety is a separate layer with its own certification chain — Type 3, SIL2, PL d — evaluated against IEC 61496 for the sensing device and integrated into a safety function whose PL is assessed at the system level under ISO 13849. On our stack that layer is the GS1-5, a 270° scanner with a 5 m protective field, specified independently of whatever navigation architecture sits above it.
The rotating/solid-state decision is a reliability and coverage decision made on top of an established safety floor. A navigation sensor with excellent obstacle detection is still not a safety device, and a discussion that drifts toward "it will also handle personnel detection" has left the architecture question and entered the certification question, where the answer is determined by the certificate rather than by the point cloud.
Worked example
Two AMRs from the same OEM, same software stack, same line item in the requirements document: 360° obstacle detection to 25 m, ±3 cm.
Machine A. Single shift, mapped climate-controlled DC, sealed concrete, 1.5 m/s. Localizes continuously by scan-matching in a repetitive aisle environment. Revolution accumulation at 8 powered hours/day reaches the wear-out region well outside the planned refresh. No significant shock input, no direct sun, skew at 1.5 m/s is inside the error budget. Rotating is correct — the full 360° coverage is doing real work for localization, and nothing in the environment attacks the bearing.
Machine B. Continuous operation, transitions between an indoor pick face and an outdoor covered dock, crosses a dock plate roughly 200× per shift, 2.5 m/s. Same requirement line. Revolution count is 3× Machine A's per calendar month; shock events approach 6 × 10⁵ per year at a repeatable frequency; direct sun at the dock door in the afternoon; skew at 2.5 m/s is now material. All four terms point the same direction.
Identical spec line, opposite correct answer. The spec was never the discriminator.
Are you speccing LiDAR?
If you're speccing LiDAR for a mobile platform and want to pressure-test an architecture choice against your actual duty cycle, environment, and coverage requirements, we're happy to work through it with you. Bring the operating hours, the ride, the lighting, and what the robot actually needs to see — the same variables this article walks through — and our engineers will help you reason about the tradeoffs before you commit to a sensor.