Short answer: ultrasonic tops out around 7 m and is genuinely the wrong tool past that altitude; a single-point 905 nm laser rangefinder — whether it’s badged “LiDAR” or “laser rangefinder” — is the right choice any time you need altitude hold or terrain following beyond a few metres, and the only real decision left is which laser module: a compact, natively-supported unit good to 100–180 m, or a longer-range module good to 1,000–3,000+ m at a lower update rate.
“LiDAR” and “laser rangefinder” are mostly the same sensor here
Worth clearing up before comparing anything: the single-point sensors sold as drone “LiDAR” — LightWare’s SF-series, Benewake’s TF-series — are direct or pulsed time-of-flight laser modules, exactly the same underlying technology as an ERDILRF 905 nm laser rangefinder module. Neither one is a scanning, point-cloud-generating LiDAR in the surveying sense; both fire a pulse down one axis and time the echo. “LiDAR” in this market segment is largely a marketing label for a single-point ToF rangefinder, not a different sensing principle. What actually differs between products in this category is range, update rate, native flight-stack support, weight and price — the four things this article compares.
Ultrasonic: cheap, and genuinely short-range
ArduPilot’s own documentation for the MaxBotix I2C sonar rangefinder describes it as “inexpensive, short range (up to 7 m) rangefinder primarily designed for” altitude sensing (fetched 2026-09-04) — and notes that the narrow-beam EZ4 variant is recommended specifically for better noise resistance, while the wide-beam EZ0 trades that off for higher sensitivity. That’s a direct acknowledgment from the flight-stack documentation itself that acoustic ranging is a beam-width and noise-resistance compromise even within its short working distance.
Ultrasonic’s honest role in a modern stack is the last few metres of a landing flare, or ground-effect altitude hold on a small multirotor that never leaves single-digit-metre altitude. Past 7 m, per ArduPilot’s own guidance, you’re outside the sensor’s design envelope, not just pushing its accuracy.
Compact single-point laser modules: 100–180 m, native flight-stack support
This is the tier occupied by LightWare’s SF20/C and Benewake’s TF03. LightWare’s SF20/C is specified for 0.2–100 m (70% reflectivity target), an update rate of 48 to 5,000 readings per second, 905 nm wavelength, 7.5 g weight, and integrates natively with PX4 and ArduPilot without a protocol bridge — at $319 USD per unit (LightWare’s own product page, fetched 2026-09-04). Benewake’s TF03 covers 0.1–180 m, up to roughly 7 kHz frame rate, IP67-rated, with 100 kLux ambient-light immunity for reliable outdoor daylight operation (Benewake’s own product page, fetched 2026-09-04).
The appeal of this tier is plug-and-play: both are on ArduPilot’s built-in supported-rangefinder list, so they need no companion-computer bridge or scripting to get a working RNGFND1_TYPE. The trade-off is range — once your altitude-hold or terrain-following requirement exceeds 100–180 m, you’re outside what this class of sensor is built for, reflectivity assumptions notwithstanding.
When a longer-range 905 nm module is the better fit
ERDILRF’s LR-series and LRF3000A1 sit in a different range class than the compact native-integration modules above. LR1000E2 covers 4–1,000 m, LR2000E2 covers 4–2,000 m, and LRF3000A1 is rated for 1 m up to at least 3,000 m against the reflectivity and visibility conditions ERDILRF’s manual specifies (source: LR1000E2.md, LR2000E2.md, LRF3000A1.md — the exact reflectivity/visibility assumption behind the 3,000 m figure isn’t broken out in our published spec table; contact us if you need that condition confirmed for a specific altitude budget).
The trade-off runs the other way from the compact tier: measurement frequency is 1–10 Hz adaptive rather than kHz-class, and none of these protocols are on ArduPilot’s native list, so integration goes through the MAVLink-bridge or Lua-scripting path described in our Pixhawk/ArduPilot connection guide. That’s the right trade to make when the mission genuinely needs look-ahead range a 100–180 m sensor can’t give — high-altitude terrain following on a fixed-wing platform, or a survey aircraft that needs ground distance well before descent begins — and a 2–10 Hz update is fast enough for the vehicle’s closing speed.
Decision table
| Sensor class | Typical range | Update rate | Native ArduPilot/PX4 support | Best fit |
|---|---|---|---|---|
| Ultrasonic (e.g. MaxBotix I2C) | Up to ~7 m | Sensor-dependent, low-latency | Yes (MaxbotixI2C type) | Landing flare, ground-effect hold on small multirotors |
| Compact 905 nm laser (LightWare SF20/C) | 0.2–100 m | 48–5,000 readings/s | Yes, native | General altitude hold, obstacle sensing, no bridge needed |
| Compact 905 nm laser (Benewake TF03) | 0.1–180 m | Up to ~7 kHz | Yes, native | Higher-altitude hold, IP67 outdoor use, bright-daylight reliability |
| ERDILRF LR2000E2 | 4–2,000 m | 2–10 Hz adaptive | Via MAVLink bridge or Lua script | Fixed-wing terrain following, higher-altitude AGL beyond compact-sensor range |
| ERDILRF LRF3000A1 | 1–3,000+ m | 1–10 Hz adaptive | Via MAVLink bridge or Lua script | Long-range terrain following, survey and mapping platforms |
Sources: ArduPilot MaxBotix I2C page and full parameter list (fetched 2026-09-04); LightWare SF20/C product page (fetched 2026-09-04); Benewake TF03 product page (fetched 2026-09-04); LR1000E2.md, LR2000E2.md, LRF3000A1.md.
Frequently Asked Questions
What’s the real difference between “LiDAR” and a “laser rangefinder” for drone altitude sensing?
For the single-point sensors used in altitude hold and terrain following, there usually isn’t one — both are pulsed or direct time-of-flight laser modules measuring distance along one axis. “LiDAR” in this context is a market label, not a different sensing principle. A true scanning/point-cloud LiDAR is a different, heavier and more expensive category rarely used for simple altitude sensing.
What’s the maximum altitude an ultrasonic sensor can reliably measure?
ArduPilot’s own documentation describes the common MaxBotix I2C ultrasonic sonar as short-range, “up to 7 m” — that’s the flight stack’s own stated envelope for this sensor class, not a laser-specific limitation.
When should I choose a long-range ERDILRF module over a native-integration sensor like the SF20/C?
When your altitude-hold or terrain-following requirement exceeds roughly 100–180 m, which is outside the range class of compact natively-supported modules. The trade-off is a lower update rate (2–10 Hz adaptive versus kHz-class) and an integration path that goes through a MAVLink bridge or a Lua scripting driver rather than a built-in ArduPilot rangefinder type.
Does update rate or range matter more for altitude hold?
It depends on closing speed. A fast multirotor holding altitude close to the ground benefits from a kHz-class update rate so the control loop reacts quickly to sudden ground changes. A slower, higher-altitude fixed-wing platform doing terrain following generally needs range more than update rate, since it’s sensing further ahead relative to its speed.
Can I combine ultrasonic and laser rangefinders on the same aircraft?
Yes — ArduPilot supports multiple simultaneous rangefinders (RNGFND1_*, RNGFND2_* and further instances), which is exactly how many builds handle this: an ultrasonic sensor for the final few metres of landing flare, and a laser module for altitude hold and terrain following at every other altitude.
Talk through your mission profile
Tell us your typical operating altitude, closing speed and whether you need native flight-stack support or can integrate through a bridge, and we’ll confirm the right ERDILRF model and current lead time in writing. For the integration path itself, see our Pixhawk/ArduPilot connection guide.