Design & Selection · Module 02

Sensor selection criteria: reading a datasheet

A datasheet describes the sensor in its best light. This guide lists what to look for, and what to ask when a number is missing.

Intermediate
Module 02: Sensor Selection, Trade-offs & Integration
Written for ROS 2 Jazzy where ROS 2 is used
Sources checked 2026-11-05

Assumptions: General guidance. No manufacturer figure is quoted: product specifications must be taken from the datasheet of the exact model.

1. Engineering problem

Two sensors with similar headline numbers can behave very differently in your robot. The headline range is measured on a convenient target; the quoted accuracy may be at a single distance; the rate may be at a lower resolution. Choosing well means reading the datasheet for the conditions you will run in, and finding what it leaves out.

2. When is this needed?

Before buying any sensor.
When a sensor in the field does not match its datasheet.
When comparing vendors.

3. Selection and design decisions

Sixteen selection criteria
Criterion	What it is	What to check
Measurement range	Maximum (and minimum) distance or value measured	Stated at what target reflectivity, light level or condition? Minimum range matters as much as maximum.
Field of view	Angular coverage, horizontal and vertical	Blind zones near the sensor and where the robot body blocks the view.
Accuracy	How close the measurement is to the true value (systematic error)	Over which range, and at what confidence (1σ? maximum?)
Precision	How repeatable measurements of the same thing are (random error, noise)	Often listed as noise, repeatability or standard deviation.
Resolution	Smallest change the output can represent	Fine resolution does not imply accuracy.
Update rate	Measurements per second	At which resolution or mode? Some sensors lower the rate at full resolution.
Point rate	Points per second for a LiDAR or depth sensor	Per return mode; how many points land on a small target at range.
Latency	Time from the physical event to the data being available to your software	Rarely stated; usually must be measured end to end.
Noise	Random variation of the output	Noise density, bandwidth and units (an IMU’s noise density is not its noise in your bandwidth).
Environmental robustness	Behaviour in sun, rain, dust, temperature, vibration	Ingress rating is not performance in rain; look for test conditions.
Power consumption	Average and peak power	Start-up peak, and whether heaters or motors add to it.
Compute requirements	CPU, GPU, memory and bandwidth to use the data	Mostly your own algorithms; measure on your platform.
Interface support	Electrical interface and protocol	Driver availability for your OS and ROS 2 distribution.
Calibration complexity	What must be calibrated and how often	Factory calibration vs per-unit; does it drift?
Reliability	Lifetime, failure rate, ingress and shock	Ask for MTBF basis and test conditions; mechanical parts wear.
Cost	Purchase plus integration plus support	Include cables, mounts, calibration targets and drivers.

Datasheet versus real-world performance

Conditions: specifications are typically stated for favourable conditions (a bright, matte, perpendicular target, room temperature, no vibration).
Statistics: “typical” is not “guaranteed”. Prefer minimum or maximum limits, and ask what confidence level an accuracy figure has.
Mode: range, rate and accuracy often trade against each other; use the figures for the mode you will run.
System effects: mounting, cabling, time synchronisation and calibration add error the datasheet cannot include.
Missing numbers: latency, timestamp accuracy and long-term drift are often missing; plan to measure them.

4. Advantages and disadvantages

Higher resolution or range usually costs rate, power and compute.
More accurate sensors cost more and are often more sensitive to calibration.
A rugged, sealed unit costs weight and money but saves field failures.

5. Requirements and constraints

The condition you must survive sets the shortlist, not the headline figure.
Interfaces and drivers must match your computer and ROS 2 distribution.
Budget includes integration and validation effort.

6. Architecture

requirement (numbers) ─▶ shortlist (type) ─▶ datasheet at YOUR conditions ─▶ buy one ─▶ test against the requirement ─▶ standardise

7. Implementation

Write each requirement with its operating conditions (for example “detect a dark, 10 % reflective object at 20 m in rain”).
For each shortlisted model, find the datasheet value that corresponds to that condition; if none exists, mark it “to measure”.
Make a table of requirement, datasheet value, margin and source page.
Order one unit and run the validation procedure from the sensor family guide; record measured versus datasheet.
Decide, and keep the table with the design record.

8. Real examples

A LiDAR with a long headline range: the range was stated for a highly reflective target; for a dark object the usable range is much shorter. Ask for the range at the reflectivity of your target.
An IMU with excellent bias stability: the figure is at constant temperature; your robot’s warm-up changes the bias. Check the temperature behaviour.
A camera with a high frame rate: available only at a reduced resolution that is useless for your task.

9. Failure scenarios

Comparing headline numbers stated under different conditions.
Ignoring minimum range and blind zones.
Assuming latency is small and constant.
Treating “typical” values as guarantees.

10. Troubleshooting

Reproduce the datasheet’s own test condition and measure; if you match it, the sensor is fine and your conditions differ.
Change one condition at a time (target, distance, light, temperature) until performance matches the operating case.
Update the requirement table with what you measured.

11. Validation

Every requirement has a datasheet value at the right condition or a measured value.
Margin between requirement and measured performance is stated.
Latency and time-stamp accuracy have been measured on the integrated system.

12. Engineering checklist

Operating conditions written for every requirement
Datasheet figures matched to those conditions
Minimum range, blind zones and field of view checked
Typical vs guaranteed values distinguished
Latency and timestamp accuracy measured
Interface, power and driver verified
Calibration procedure and drift understood
Table of requirement versus evidence saved

13. Further references

Manufacturer datasheets for the exact model (not fetched here). The interactive Sensor Selection Calculator lists, per sensor type, the datasheet specifications to verify.

Related on FixTheRobot

Complementary Strengths and Weaknesses of Cameras and LiDAR Perception · Lesson