The Best LiDAR for Robotics:
A Complete Buyer’s Guide
LiDAR for Robotics
A robot is only as capable as what it can perceive. Whether it’s an AMR navigating a warehouse aisle, an outdoor inspection robot crossing uneven ground, or an autonomous delivery vehicle merging with pedestrian traffic, the sensor choice behind that robot determines what it can safely do.
With the wrong sensor stack, navigation approaches accumulate drift over time and struggle in textureless or repetitive environments, a blank warehouse wall, a featureless corridor, a field of identical shelving. Object detection gets harder with poor lighting, reflections, occlusion, and glare.
This guide covers considerations when choosing LiDAR for a robotics project: what to look for, how LiDAR fits alongside cameras and other sensors in a robot’s perception stack, how it feeds SLAM and ROS, and which of Digiflec’s sensors suit which use case, with a straight comparison table at the end.
What to look for in a robotics LiDAR
Various key specifications should be used to determine whether a sensor is right for your robot, and they trade off against each other:
Field of view. A robot that needs to see everything around it, most indoor AMRs and AGVs, wants close to 360° horizontal coverage. A robot only watching one direction (a forward-facing inspection arm, a side-mounted collision sensor) can use a narrower, more directional sensor and spend the saved cost/weight elsewhere.
Range and resolution. Range needs to match your robot’s speed, stopping distance and area of interest, not just be “as long as possible”, a slow indoor AMR doesn’t need automotive-grade 200m range, but an outdoor robot moving at speed does. Resolution (points per second, angular resolution, beam/channel count) determines how small an obstacle the sensor can actually distinguish from the background, which matters more than raw range for cluttered environments.
2D vs 3D. A 2D LiDAR gives you a single-plane “something is there” read, cheaper, and enough for simple environment with less variables such as disconnected people/machines, overhangs or drop-offs. A 3D LiDAR builds a full point cloud of shape, size, and depth, which is what most modern AMRs, outdoor robots, and anything navigating a cluttered or multi-level space actually need.
Weight and power budget. This is the constraint that’s easy to ignore until it isn’t. A sensor drawing 30W and weighing a kilogram is a non-issue on a large AGV chassis and a dealbreaker on a small drone or lightweight mobile robot. Always check weight and power draw against your platform’s actual budget before comparing range/beam count specs.
Accuracy vs precision. These get used interchangeably in marketing copy, but they’re different specs, and the difference matters a lot for anything doing fine manipulation or measurement, like a cobot arm or a warehouse dimensioning system.
Data rate and processing budget. A higher-resolution sensor doesn’t just cost more to buy, it costs more to process. A dense 3D LiDAR pushing several million points per second generates a genuinely large data stream, and every one of those points has to be filtered, registered, and reasoned about within your robot’s control loop deadline. An example being a common 16-channel LiDAR produces roughly 426KB point clouds at 10Hz, scale that up to a 128-channel sensor doing 5.2 million points/second and the volume of data your onboard compute has to process every cycle grows enormously. If your compute platform can’t keep up, the practical failure mode isn’t “the sensor is bad”, it’s added latency between something entering the robot’s path and the robot actually reacting to it, which is a genuinely dangerous place for a safety-relevant navigation stack to be underspecified.
Data rate and processing budget
This is one of the most common ways a robotics project gets into trouble after the sensor’s already been chosen: the point cloud looks great on paper, but the robot’s onboard data transfer and compute can’t process it fast enough to act on it in real time.
Why more points cost more than they seem to. Every additional point in a scan has to be filtered, registered against previous scans, and clustered into “obstacle” or “not obstacle” before the navigation stack can act on it. That processing has to happen inside your control loop’s time budget, typically well under 100ms for a robot moving at any meaningful speed. A sensor that outpaces the compute available to process it doesn’t fail cleanly; it quietly adds latency between an obstacle appearing and the robot reacting to it.
How engineers actually deal with this, in practice:
- Voxel grid downsampling, the most common fix. The point cloud is divided into a 3D grid of small cubes (“voxels”), and every point inside a voxel is collapsed to a single representative point. This is fast, well-supported (it’s built into standard libraries like PCL and used inside ROS/Nav2’s own costmap generation), and the accuracy cost is manageable if the voxel size is chosen correctly.
- Ground plane removal, on an indoor or outdoor mobile robot, a large fraction of every scan is just the floor. Stripping out ground-plane points before clustering removes a big chunk of the data volume for free, since the floor is never the obstacle you’re trying to detect.
- Region-of-interest (ROI) / passthrough filtering, discarding points outside the space that’s actually relevant to navigation (behind the robot, above its height, beyond the distance it could possibly need to react within) before the expensive clustering step runs.
- Matching the sensor to the compute budget, not the other way round, this is the decision that should happen before purchase, not after. Simpler, lower-channel 2D LiDAR remains genuinely popular on cost- and compute-constrained robots specifically because it’s dramatically cheaper to process on modest onboard hardware than a dense 3D point cloud or a camera-based SLAM pipeline, not because it’s a worse sensor in the abstract, but because it’s a better match for what the robot can actually process in real time.
- Sensor setting, many sensors allow for laser channels to be switched on/off, azimuth adjustment which can reduce data generation for areas of no interest.
- Hardware acceleration, where the application genuinely needs the extra density (an outdoor robot at speed, a sensor doing double duty for scanning as well as navigation), the answer is often to size the onboard compute, an edge AI board with a GPU/vision-accelerator, not a bare microcontroller, to match the sensor, rather than under-processing a sensor that’s actually right for the job.
The honest pros and cons of downsampling / choosing a lower resolution:
In favour: lower latency between sensing and reacting, a smaller and cheaper compute platform, longer battery life on a mobile platform, and a generally simpler integration, all genuinely valuable on a small or cost-constrained robot.
Against: downsample too aggressively and you can lose exactly the small or thin obstacles you needed to detect, a voxel size larger than the smallest object you can’t afford to miss will erase it from the data before your navigation stack ever sees it. It’s the wrong place to cut corners on a safety-relevant obstacle-detection path, and it’s a poor fit for the scanning/inspection use case below, where the whole point is capturing fine detail rather than clearing a path.
The practical rule of thumb: set your voxel size (or accept a lower-resolution sensor) based on the smallest object you genuinely cannot afford to miss, not on whatever your compute platform happens to handle comfortably. If those two numbers don’t line up, the fix is more compute or a different sensor, not a downsampling setting that quietly makes the problem disappear from your test results without making it disappear from the real world.
Accuracy vs precision: not the same spec, and it matters more than it sounds
Most buyers read a single number off a spec sheet, usually labelled “accuracy”, and assume it tells them everything about how trustworthy the sensor’s measurements are. It doesn’t. Accuracy and precision are two different properties, and a sensor can be strong on one and weak on the other.
Accuracy is how close a measurement is to the true value. Precision is how repeatable the measurement is, how tightly clustered repeated readings are, regardless of whether that cluster sits on the true value or off to one side of it. A sensor can be precise but inaccurate, returning the same wrong distance every time with very little scatter, or accurate but imprecise, averaging out to the right distance over many readings while any single reading is noisy. For most robotics applications, ordinary navigation and obstacle avoidance, a bit of noise or a small systematic offset rarely matters. For a small number of applications, it’s the entire ballgame.
Why this matters for cobots. Collaborative robots working alongside people typically rely on speed and separation monitoring under ISO/TS 15066, where the robot’s safe operating speed and the minimum distance it must keep from a person are calculated directly from a formula that includes the sensor’s own position measurement uncertainty. A sensor with a systematic bias (poor accuracy) or high shot-to-shot noise (poor precision) forces a larger calculated keep-out distance to stay safe, which shrinks the robot’s usable workspace and can make an otherwise capable cobot cell impractically conservative. Both accuracy and precision reduce that required safety margin; neither alone is enough.
Why this matters for warehouse dimensioning robots. Real stock is rarely a set of neat, uniform boxes. Pallets get built with overhang, shrink-wrap bulges unevenly, cartons get stacked slightly off-square, and racking ends up holding a genuinely variable mix of load shapes and sizes. Measuring that variability accurately and consistently is what makes three things possible: working out how much space a given pallet or load actually occupies, spotting the genuinely free space around and above it, and deciding what can be slotted into that space next.
Accuracy and precision both matter here, but for different reasons. Accuracy is what stops the system from being systematically wrong about a load’s true volume, a sensor with a consistent bias will over- or under-estimate every irregular pallet in the same direction, which either wastes racking capacity (marking usable space as occupied) or causes new stock to be slotted somewhere it doesn’t actually fit. Precision is what makes the measurement trustworthy scan to scan: a noisy reading can make the same static load look like it’s changed shape between scans, which is exactly the kind of inconsistency that undermines a bin-packing or slotting algorithm trying to maximise storage density across a whole warehouse.
The same measurement problem scales up to loading trucks, trailers, shipping containers, and aircraft holds: knowing the real, remaining volumetric capacity of a partially loaded space, around irregular pallets and boxes rather than assuming a neat rectangular gap, is what lets a loader or dispatcher fit more cargo in before it departs, rather than leaving usable space unused because nobody could measure it with confidence.
Get the accuracy and precision to that level, and the same point cloud starts to earn its keep a second way: spotting physical damage. A dent, crushed corner, or bulged panel on a box or pallet load is really just a small deviation from the surface you’d expect a healthy box to have, detected by comparing the scanned surface against a reference or expected shape. The catch is that this only works if the deviation you’re trying to catch is bigger than the sensor’s own noise floor. A shallow dent that’s smaller than the sensor’s precision simply disappears into the noise, indistinguishable from normal measurement scatter, while a sensor with a systematic bias across its field of view can do worse than miss damage, it can warp the expected reference surface enough to flag healthy boxes as damaged or wave through ones that genuinely aren’t. A LiDAR sensor that’s already accurate and precise enough to trust for volumetric and slotting decisions is, in practice, also precise enough to catch the damage a noisier sensor or camera would simply miss.
The practical takeaway: for ordinary navigation and obstacle avoidance, don’t over-index on a single decimal place. For a cobot workspace or a volumetric logistics application, ask for accuracy and precision as separate, tested figures, not one blended marketing number, since it’s genuinely both that determine whether a slotting or load-planning decision built on the measurement can actually be trusted.
SLAM and ROS: how LiDAR feeds the software stack
LiDAR doesn’t do anything on its own, it feeds a software stack that turns point-cloud data into robot behaviour. Two things to know:
SLAM (Simultaneous Localisation and Mapping) builds a map of the environment and works out the robot’s position within it, at the same time, using the sensor’s point-cloud stream. This is the layer that fails first when a sensor is under-specified for the environment, sparse point clouds or narrow fields of view make it easy for SLAM to lose track in featureless or repetitive spaces.
ROS / ROS2, and specifically the Nav2 navigation stack in ROS2, is the near-universal middleware most robotics projects build on. Nav2 handles global path planning (the overall route to a goal), local planning (real-time obstacle avoidance and smooth motion control), and localisation, using cost maps built from your sensor data. A LiDAR with a Linux/ROS driver and a clean, dense point cloud makes integration straightforward; a sensor without one adds real integration time to your project.
Where LiDAR fits alongside stereo cameras and other sensors
A large share of robots on the market today get their depth perception primarily from a stereo camera, not a LiDAR, so it’s worth exploring the pro’s and cons versus 3D LiDAR.
How stereo depth actually works. A stereo camera uses two lenses at a fixed, calibrated distance apart (the baseline) and computes depth by matching the same point between the left and right images and measuring its disparity, the same principle as human binocular vision. Some stereo cameras are passive (relying purely on ambient light and scene texture to find matching points), and others are active, projecting an infrared dot pattern onto the scene to create artificial texture for the matching algorithm to lock onto, which is what most stereo cameras marketed for robotics actually do indoors.
Where stereo cameras genuinely win. They’re cheaper than most 3D LiDAR, produce a dense, per-pixel depth map at the same resolution as the image itself, and hand you registered RGB and depth from a single sensor, meaning classification and geometry come from the same device rather than needing to be fused from two. That combination is a large part of why stereo cameras are so common on manipulation arms, pick-and-place robots, and cost-sensitive mobile platforms, where LiDAR’s range and mechanical robustness aren’t the priority.
Where the real pitfalls are, and they’re genuine ones. Depth accuracy degrades with distance, and not gently, error grows roughly with the square of range, so a stereo camera’s usable accuracy at 6m can be the same as its accuracy at 3m on a wider-baseline model, and considerably worse than that on a compact, narrow-baseline unit. As a concrete real-world example, a longer-baseline stereo camera can have roughly double the depth accuracy of a shorter-baseline model at the same distance, which in practice means the compact, cheap unit that fits neatly on a small robot is also the one with the weakest long-range depth. Passive stereo also fails on textureless or repetitive surfaces (blank walls, glass, uniform flooring) because there’s nothing for the matching algorithm to lock onto, active IR-assisted stereo fixes this indoors, but that same IR pattern gets washed out by ambient sunlight once light levels get high enough, so a stereo camera that works reliably indoors can lose depth accuracy outdoors in direct sun, the opposite failure mode to what most engineers expect. On top of that, stereo depth is computed live from image matching, which adds its own compute cost on top of whatever else is running on the robot (see the data rate section above), and the two lenses need to stay precisely calibrated relative to each other, so vibration, mechanical shock, or thermal expansion over the robot’s lifetime can silently degrade depth accuracy until the camera is recalibrated.
Where LiDAR still has the edge. Depth accuracy that doesn’t degrade sharply with range or lighting, resilience to both very low light and direct sun without needing an active pattern that can be washed out, and no dependency on scene texture to produce a valid reading.
The practical takeaway: stereo cameras are a genuinely strong, common, and often correct choice, particularly indoors, at close-to-mid range, on cost-sensitive platforms, and anywhere a robot benefits from RGB and depth being aligned from one sensor. LiDAR earns its higher cost specifically where range, lighting extremes, or texture-independent geometric accuracy actually matter to the task, which is exactly why many production robots run both rather than choosing one over the other.
A concrete example of “run both”: RoboSense AC2. Rather than fusing a separate LiDAR and camera at the software level, AC2 is a single hardware unit combining a solid-state dToF LiDAR, stereo RGB cameras, and an IMU, with sensor synchronisation accuracy under 1ms. It’s designed specifically to answer the pitfalls above: it holds ±5mm precision across its full 0.05-8m range rather than degrading with distance the way pure stereo does, and it’s rated for 100 klux of ambient light resistance, meaning it’s built to keep working across bright sunlight, low light, and alternating conditions rather than losing accuracy the way an IR-pattern-based active stereo camera can outdoors. At 102×32×45mm with a 65mm human-eye-like stereo baseline, it’s built for exactly the tight spaces this trade-off usually gets forced on, humanoid robot heads, robot dog heads, and robotic arm end-effectors, warehouse AGVs, and home robots.
Safety certification: what robots working around people actually need
Most LiDAR spec sheets mention “eye-safe” and stop there, a laser Class 1 rating under IEC 60825-1, which just means the laser itself won’t damage human eyes. That’s a baseline every sensor in this guide meets. It is not the same thing as functional safety certification, which is what actually matters if your robot shares floor space with people and needs to prove, to a risk assessor, an insurer, or a regulator, that it will safely stop or slow down when a person enters its path.
Functional safety certification for this kind of application is governed by a specific set of standards: IEC 61496 (safety of electro-sensitive protective equipment, with “Type 3” covering complex opto-electronic sensors like scanning LiDAR), IEC 61508 (functional safety of electrical/programmable systems, rated in Safety Integrity Levels, SIL), and ISO 13849 (safety-related parts of machine control systems, rated by Category and Performance Level, PL). These are the certifications a machinery risk assessment or CE/UKCA compliance file actually asks for, and most commercial LiDAR, including the general-purpose sensors recommended above, simply aren’t certified to them.
RoboSense Safety Airy is. It’s a purpose-built safety-rated scanning sensor, certified to Type 3 (IEC 61496), SIL 2 (IEC 61508), and Category 2 / PL d (ISO 13849), with a PFHd of 8.0×10⁻⁸ and a 20-year mission time. In practical terms: a 275°×90° field of view, up to 60m max detection range (30m at 10% reflectivity), a 0.1m blind zone, configurable protective (6.9m) and warning (10m) zones, up to 64 zone sets and 64 monitoring cases, dual OSSD safety outputs, and IP65, all in a sub-650g, sub-100mm housing drawing under 15W.
This is a genuinely different sensor for a genuinely different job. The sensors in the comparison table above are for general perception and navigation; Safety Airy is for the specific, certifiable safety-stop function itself, the part of the system a regulator or insurer will actually ask you to demonstrate. Any warehouse robot, AGV, or AMR operating in shared space with people should be treating this as a distinct line item in the sensor stack, not an assumption covered by the main navigation LiDAR.
Important scope limit: Safety Airy’s Category 2 / PL d certification currently covers indoor use only.
What most robots use today for this, and why 3D changes what’s detectable
The sensors doing this job on most AGVs and AMRs right now are 2D safety laser scanners from Hokuyo and SICK, the two names buyers researching this topic will already have come across. Hokuyo’s UAM-05LP series and SICK’s microScan3 are both certified to the same standards referenced above (Type 3 under IEC 61496, SIL 2 under IEC 61508, Category 3 / PL d under ISO 13849), and both work the same way: a single scanning plane, typically 270-275°, at a fixed mounting height, with a configurable protective field (SICK’s microScan3 covers a 4m protective field and 40m warning field; Hokuyo’s UAM-05LP covers a 5m protective zone and 20m warning zone).
The limitation is built into how a 2D scanner works: it only detects what crosses its one scan plane. Anything above or below that fixed height, a raised forklift tine, an overhanging pallet load, can fall outside what the sensor is physically able to see, unless a second or third scanner is added at a different height to cover it.
RoboSense Safety Airy is a genuine 3D scanning LiDAR built to the same certification standards, with a 90° vertical field of view rather than a single fixed plane. That means it can assess risk at any height within its field simultaneously, including exactly the cases a single-plane 2D scanner can miss, like the position of a forklift’s tines or an elevated load, not just what’s at ankle or waist height. It’s one of very few sensors on the market bringing genuine 3D detection to this certification tier, rather than the single- or stacked-plane approach most safety scanners still use today.
LiDAR in Robotics Use cases
AMRs (Autonomous Mobile Robots). Indoor, dynamic environments shared with people and other equipment, the priority is wide field of view, dense point clouds for reliable dynamic-obstacle detection, and a weight/power budget that fits a compact chassis. A lightweight solid-state sensor with full 360° coverage is usually the right starting point.
AGVs (Automated Guided Vehicles). Often more structured and predictable routes than AMRs, but still need reliable obstacle detection for safety compliance, particularly around shared floor space with people. Mid-range 360° coverage with strong angular resolution for small/static obstacle detection is the priority here.
Warehouse robots. A specific case of the above with two added wrinkles: aisles are often narrow with high racking (so vertical field of view matters more than usual), and the robot may also need to scan racking or inventory as a secondary task, not just navigate, a genuinely different job from pure obstacle avoidance, closer to dimensioning and inspection than to path planning. Where that secondary task is parcel or pallet dimensioning for billing or freight classification, accuracy against a calibrated reference matters more than any other spec on this list, see the accuracy vs precision section above.
Cobots (collaborative robots). Working in shared space with people at close range puts sensor accuracy and precision directly into the safety calculation itself, not just obstacle avoidance generally. See the accuracy vs precision section above for why this shrinks or inflates the robot’s usable workspace.
Outdoor robots. Uneven ground, variable lighting, and weather all raise the bar. Longer range for higher operating speeds, a wavelength and design proven in rain/fog/direct sunlight, and a wide operating temperature range all matter more outdoors than indoors.
Humanoid and quadruped (legged) robots. A newer, fast-moving category with its own constraints: sensors typically need to fit into a head, face, or limb-mounted footprint, so size and weight matter as much as they do on a drone, while still needing enough precision and FOV for fine manipulation and stable footing on uneven ground. This is a category several LiDAR and fused-sensor vendors are now designing specifically for, rather than adapting an automotive or industrial sensor after the fact.
Robotic lawn mowers and other consumer outdoor robots. Similar constraints to outdoor robots generally, but with tighter cost targets and a need to reliably tell grass, kerbs, and small obstacles apart at close range, rather than needing long automotive-style detection distances.
Recommended LiDAR sensors for Robotics
- RoboSense Airy, under 240g, under 8W with full 360°×90° coverage and ±1cm accuracy. The natural starting point for AMRs and smaller mobile robots where weight and power are tightly constrained.
- RoboSense Fairy, trades some points-per-second for 150m range and 0.5cm precision in a still-light (<350g) package. Useful where you need more range than the Airy offers without moving to a heavier sensor.
- RoboSense E1R/D, a fully solid-state, automotive-grade sensor (120°×90° FOV, 75m max range, up to 50G vibration resistance, -40°C to +85°C, IP67/IP6K9K) built to survive harsher conditions than a typical indoor AMR sensor sees. The natural choice where a robot needs Airy-class solid-state reliability but in a tougher outdoor or industrial environment.
- RoboSense E2, An ultra-wide 180°×135° FOV, up to 1.5M points/second (dual return), 1cm (1σ) precision, 35m range at 10% reflectivity, ≤5W power, and 50G vibration resistance across -40°C to +85°C. Roughly 60% smaller and 40% lighter than RoboSense’s previous-generation robotics LiDAR in the same class. Ideal for humanoid robots, quadruped robots, drones, and robotic lawn mowers, where fine manipulation and a tight physical footprint both matter.
- Seyond Robin-W, a directional, wide-FOV (120°×70°) sensor built for side-view/blind-spot detection with no gap in coverage, in a compact, low-power (9W, 750g) footprint. Good fit where a robot needs strong lateral awareness rather than full 360° coverage.
- Seyond Hummingbird D1-R, a very compact (220g, 6W), ultra-wide 140°×100° FOV sensor with a blind zone under 10cm and an IMU built in as standard. Purpose-optimised for robotics, and small enough to mount on a robot arm or a tight corner where a larger sensor won’t physically fit.
- Seyond HM1X (Merlin), smaller again: a 20mm×50mm×26mm, 40g, sub-1W sensor built for close-range proximity sensing (0.1-10m) rather than area navigation. Suited to jobs where high accuracy and precision are required, also when the larger sensors above are too big, a robot arm’s end effector, a legged robot’s limbs, forklift attachment/tine-tip proximity, or handheld scanning aids.
- Ouster OS0, ultra-wide 90° vertical field of view specifically built with robotics and warehouses in mind, with genuinely strong dark-object and dust/fog performance, a direct answer to the low-light and obscurant conditions that trip up narrower-FOV sensors.
- Ouster OS1, Ouster’s longer-range, higher-resolution option (200m max, 128 channels, 5.2M points/second) for robots operating over larger areas or at higher speed than a typical warehouse AMR.
- Ouster OSDome, a 180° hemisphere field of view built for indoor 3D mapping, crowd analytics, and material handling, a strong fit where a robot (or fixed installation) needs to see up as much as out, such as tight indoor spaces with overhead obstacles.
LiDAR Comparison Table
| Sensor | FOV (H×V) | Max range | Points/sec | Weight | Power | Best for | Price range |
| RoboSense Airy | 360°×90° | 60m (30m @10% reflectivity) | 1.72M | <240g | <8W | Lightweight AMRs, drones | <$1,000 |
| RoboSense Fairy | 360°×32° | 150m (80m @10%) | ~690,000 | <350g | <10W | Mid/long-range mobile robots, handheld mapping | <$1,500 |
| RoboSense E1R | 120°×90° | 75m (30m @10%) | 260,000 (520,000 dual-return) | 330g | <10W | Industrial robots needing automotive-grade durability | <$1,000 |
| RoboSense E2 | 180°×135° | 35m @10% | 1.5M (dual-return) | n/a (~40% lighter than prior gen) | <5W | Humanoid/quadruped robots, drones, lawn mowers, fine manipulation | <$1,000 |
| Seyond Robin-W | 120°×70° | 150m (70m @10%) | up to 1.77M | 750g | <9W | Side-view/blind-spot detection, compact robots | <$5,000 |
| Seyond Hummingbird D1-R | 140°×100° | 50m (30m @10%) | 490,000 | 220g | 6W | Compact robots, robot arms, tight-space blind-spot elimination | <$1,500 |
| Seyond HM1X (Merlin) | 60°×45° | 10m | n/a (30 lines, up to 60 FPS) | 40g | 0.8W | Robot arm end effectors, legged robots, volumetrics | <$1,000 |
| Ouster OS0 SR | 360°×90° | 50m (20m @10%) | 5.2M | 500g | 14W | Warehouses, close-range robotics, dark/dusty environments | <$6,000 |
| Ouster OS1 SR | 360°×45° | 100m (45m @10%) | 5.2M | 500g | 14W | Longer-range or higher-speed robots | <$6,000 |
| Ouster OSDome | 360°×180° | 45m (20m @10%) | 5.2M | 500g | 14W | Indoor mapping, AMRs | <$6,000 |
Fused perception sensor (LiDAR + stereo + IMU in one unit)
| Sensor | Fusion | FOV | Range | Precision | Ambient light rating | Dimensions |
| RoboSense AC2 | dToF LiDAR + stereo RGB + IMU, hardware-synced <1ms | 120°×90° | 0.05-8m | ±5mm (full range) | 100 klux | 102×32×45mm |
This isn’t a direct alternative to the sensors in the main table above, it’s a different category: a single unit built for fine manipulation and pose/motion capture at close range (humanoid and quadruped heads, robot arm end-effectors), rather than area navigation. Worth considering specifically where a robot needs stable depth and RGB together in a very tight physical footprint, and where lighting can’t be controlled.
Safety-rated sensors: 2D scanners vs 3D
| Sensor | Detection | FOV | Max range | Safety certification | Weight | Power |
| Hokuyo UAM-05LP | 2D, single plane | 270° | 20m warning / 5m protective | Type 3 (IEC 61496), SIL 2 (IEC 61508), Category 3 / PL d (ISO 13849) | 500g | n/a |
| SICK microScan3 | 2D, single plane | 275° | 40m warning / 4m protective | Type 3 (IEC 61496), SIL 2 (IEC 61508), PL d (ISO 13849) | n/a | 7.2W |
| RoboSense Safety Airy | 3D, full point cloud | 275°×90° | 60m (30m @10%) | Type 3 (IEC 61496), SIL 2 (IEC 61508), Category 2 / PL d (ISO 13849) | <650g | <15W |
LiDAR for Robotics FAQ
What's the difference between 2D and 3D LiDAR for robotics?
2D LiDAR scans a single plane and tells you something is present at a given distance and angle, enough for simple, flat-floor navigation. 3D LiDAR captures a full point cloud of the environment’s shape and depth, which is what most modern robots need to navigate cluttered, multi-level, or dynamic spaces safely.
Do I need LiDAR if my robot already has a stereo camera?
Not always, plenty of indoor, cost-sensitive, and manipulation-focused robots run on stereo depth alone, and it’s a genuinely common, valid choice. The case for adding LiDAR is strongest where range matters (stereo accuracy drops sharply the further out you measure), where lighting is inconsistent or extreme (very low light, direct sun washing out an active IR pattern), or where the environment is textureless (passive stereo needs visual detail to compute depth at all). In safety-relevant applications specifically, LiDAR’s more consistent geometric accuracy across those conditions is usually worth having, even alongside an existing camera.
Which LiDAR works best with ROS2 and Nav2?
Any sensor with a maintained Linux/ROS driver and a clean, sufficiently dense point cloud will integrate cleanly with Nav2’s cost-map and planning layers. Check driver support and point density before range specs alone, a longer-range sensor with poor driver support will cost you more integration time than a shorter-range one that’s well supported.
What's the right LiDAR for a small warehouse AMR on a tight budget?
Start with a lightweight, full-360° solid-state sensor like the RoboSense Airy, it covers the core AMR requirement (dynamic obstacle detection in a shared indoor space) without the weight, power draw, or cost of a longer-range automotive-grade sensor you don’t need indoors.
Is a higher-resolution LiDAR always better?
Not once you account for what it costs to process. A denser point cloud takes more onboard compute to filter and act on in real time, and if your platform can’t keep up, the result is added latency between an obstacle appearing and the robot reacting, not a cleaner failure, a slower and less safe one. Match resolution to what your compute budget can actually process at your control loop’s rate, not to the longest spec sheet.
What's the downside of downsampling a LiDAR point cloud?
Downsampling (typically voxel grid filtering) is the standard way to make a dense point cloud cheaper to process, and it’s usually the right call for navigation and obstacle avoidance. The risk is setting the voxel size larger than the smallest object you can’t afford to miss, at that point the obstacle is filtered out of the data before your navigation stack ever sees it. It’s not a good fit for use cases needing fine detail, like the scanning/inspection case below.
How accurate is stereo camera depth compared to LiDAR?
It depends heavily on range. Stereo depth error grows roughly with the square of distance, so a stereo camera that’s accurate at close range can become considerably less reliable further out, and the effect is worse on compact, narrow-baseline cameras than on wider-baseline ones. LiDAR’s accuracy holds up far more consistently across its rated range, which is the main reason longer-range or safety-relevant applications tend to prefer it over stereo alone.
Does lighting affect stereo camera depth sensing?
Yes, in two different ways depending on the camera type. Passive stereo cameras (no projected pattern) need enough ambient light and scene texture to match points between the two lenses, so they struggle in low light and on blank or repetitive surfaces. Active stereo cameras add an infrared pattern to solve the texture problem indoors, but that same pattern gets washed out by strong ambient sunlight outdoors, which can mean a camera that performs well indoors loses depth accuracy in direct sun, the opposite of what most people assume about “better lighting.”
What's the difference between accuracy and precision in a LiDAR spec sheet?
Accuracy is how close a measurement is to the true value. Precision is how repeatable it is, how tightly clustered repeated readings are, whether or not that cluster is centred on the truth. A sensor can be precise but consistently wrong, or accurate on average but noisy shot to shot. Most spec sheets only publish one blended number; a few, like Seyond’s HM1X, list both separately.
Do cobots and dimensioning robots need better accuracy than a typical AMR?
Yes, and for different reasons. A cobot’s safe operating distance from people is calculated directly from the sensor’s measurement uncertainty under ISO/TS 15066, so poor accuracy or precision forces a larger, more conservative keep-out zone. A warehouse dimensioning system used for carrier billing or freight classification is doing legal-for-trade measurement, typically held to around ±5mm and requiring calibration against a known reference, which is specifically an accuracy requirement rather than a precision one.
What sensor should a humanoid or quadruped robot use?
These platforms have a specific constraint most other robots don’t: the sensor has to physically fit into a head, face, or limb, so size and weight matter as much as range. RoboSense’s E2 (180°×135° FOV, 1cm precision, roughly 60% smaller and 40% lighter than the previous generation) and AC2 (a fused LiDAR/stereo/IMU unit built for exactly this footprint) are both purpose-designed for this category rather than adapted from automotive or industrial sensors.
Does my robot's LiDAR need safety certification?
If it operates in space shared with people, “eye-safe” (laser Class 1) alone isn’t enough to satisfy a machinery risk assessment, that just means the laser won’t damage eyes. What a risk assessor or insurer actually asks for is functional safety certification: Type 3 under IEC 61496, a SIL rating under IEC 61508, and a Category/Performance Level rating under ISO 13849. Very few commercial LiDAR sensors carry these; RoboSense’s Safety Airy is a purpose-built exception, though its current certification covers indoor use only, so it isn’t a drop-in answer for an outdoor safety-stop requirement.
What's the difference between Hokuyo/SICK safety scanners and a 3D safety LiDAR like Safety Airy?
Hokuyo and SICK’s safety laser scanners (e.g. the UAM-05LP and microScan3) are the sensors most AGVs and AMRs use today for a certified safety-stop function, and they’re certified to the same standards as Safety Airy. The difference is what they physically detect: they scan a single fixed plane, so anything above or below that height, a raised forklift tine, an overhanging load, can fall outside what the sensor sees. Safety Airy scans a full 3D volume (90° vertical FOV), so it can assess risk at any height within its field at once, not just one plane.
Have a robotics project in mind?
Contact Digiflec’s team to talk through which sensor fits your platform, budget, and environment.
