ERDI LASER
Menu
ProductsAll products1.54 µm · Microchip DPSS laser sources1535 nm · Eye-safe rangefinder modules905 nm · DToF sensors and rangefinders1064 nm · Ranging and designation systemsSmart opticsProduct catalogs1.54 µm Laser Sources · PDF1535 nm Rangefinders · PDF905 nm DToF Sensors · PDF1064 nm Laser Systems · PDFSolutionsTechnical knowledgeProduct videosFAQsAbout ERDIInstall App
Cart
TECHNICAL KNOWLEDGE

How to Run a ToF Sensor Acceptance Test for Warehouse Automation

Validate warehouse time-of-flight sensors for pallet detection or AMR docking. Check distance error, missed readings, latency, and recovery.

ERDI EngineeringTechnical article

A time-of-flight (ToF) distance sensor is ready for a warehouse installation when the controller can make the intended decision across the actual operating conditions. For a conveyor, that decision might be whether a carton has reached a reference point. For an autonomous mobile robot (AMR), it might be whether a docking face is in position. Measure distance error, missed readings, false detections, end-to-end response time, and recovery separately. Run the tests with the sensor installed behind its production window and connected to the production controller.

This guide covers process sensing such as pallet presence, carton position, and docking confirmation. Have the responsible safety engineer verify personnel protection and protective stops separately for the applicable installation. ISO 3691-4 describes safety requirements and verification for driverless industrial trucks and their systems, including AMRs within its scope. ISO 3691-4:2023

1. Define the controller decision and its acceptance limits

Choose one decision per test plan. For example, a pallet-presence sensor reports whether a pallet has reached the transfer point. A docking sensor reports whether the surface is within the allowed position window. State which physical surface the reading should represent. With a stretch-wrapped load, the reference could be the outer wrap or the carton behind it. That choice changes what counts as a correct reading.

Use the equipment's requirements to set the near and far distances, the acceptable position error, the maximum response delay, the longest allowed gap in usable data, and the acceptable rates for misses and false detections. Define what the controller should do when a reading is invalid, missing, or older than its allowed age. For variable-rate devices, define when a new reading is expected in each operating mode. Agree on the number of runs and the pass rules before collecting data.

Keep update rate and response time separate. A sensor may produce readings at regular intervals while its internal filtering, interface, host software, and controller logic add delay before the application sees a usable result. Review the distinction between measuring frequency and host data delivery in the ERDI guide to high-rate ranging.

2. Build a fixture that reproduces the installed geometry

Mount the sensor at the production height and angle, with the intended bracket, optical window, enclosure, and cable. Record the model, serial number, firmware, measurement mode, controller version, and configuration. Mark the sensor's distance reference plane using the applicable mechanical drawing. Measure reference positions from the same plane to the specified target surface. Use a reference instrument or fixture with documented uncertainty relative to the acceptance limit, and record how you align it. A consistent reference lets you distinguish the sensor's bias from variation introduced by the test setup. NIST guidance on measurement process characterization

Start with a fixed target at the center of the intended detection region. Then add the background and fixtures found at the site. Include the nearest rack upright, conveyor frame, floor, or opposite wall that could fall inside the field of view. If the surface can enter at an angle or partly fill the field of view, reproduce that geometry. Run one diagnostic baseline without the cover window if the supplier allows it. Keep the production-window configuration in every acceptance run. A cover window can reflect light back into the receiver and distort readings, so a clean bench result can change after assembly. STMicroelectronics cover window application note

3. Test the combinations that change the decision

Start with the normal setup. Test one variable at a time to locate the cause of any failures. Then combine the conditions that can occur together on the floor, such as a dark carton at the far limit beside a reflective rack on a sunlit dock. Pick real samples from receiving or operations, including worn pallets, wrapped loads, and empty carriers where relevant. Record the target material, finish, angle, and lighting for each case. If a supplier characterizes performance with calibrated reflectance targets or a specific light measurement method, keep those reference conditions distinct from the site observations. STMicroelectronics ToF datasheet, ranging performance test conditions

Test caseWhat to varyWhat to record
Fixed targetsNear limit, decision boundary, nominal point, and far limitReference distance, signed error, absolute error, and usable reading rate
Target and backgroundDark and light cartons, worn wood, wrap, labels, empty scene, and nearby rack surfacesMisses, false detections, and readings from the wrong surface
Lighting and installationOrdinary warehouse lighting, bright dock light, normal window contamination, and adjacent sensors runningReading status, error, and gaps in usable data for each condition
Moving loads and dockingIntended travel speeds, approach angles, and partial targets entering or leaving viewTime from physical event to controller decision, missed transitions, and repeated transitions
Startup and recoveryCold start, controller restart, and a controlled communications interruptionTime to first usable reading, stale-data handling, and recovery behavior

Run moving-load and communications-interruption trials in a controlled test area. Use independent instrumentation or a known fixture event for the reference transition. A controller log can show when it accepted a reading, but you still need a common timebase or measured clock alignment to determine when the physical event occurred.

4. Keep readings, gaps, and decisions in the same record

Log the case ID, time, reference distance or trigger, reported range, device status, and final controller decision. Capture frame sequence numbers or trigger identifiers when available. Keep invalid, missing, and stale events in the test record. A distance-error average computed from valid readings can look good even when the system repeatedly loses sight of a target.

  • Distance error uses the reported range minus the reference distance for each matched reading. Summarize signed error to see systematic offset, and absolute error to compare with a position tolerance. Include the worst observed error and the run conditions. If you report a percentile, include the sample count.
  • Missed detection rate is the share of defined target-present trials where the controller did not report the target within the allowed time. False detection rate is the share of target-absent trials where it reported one. Use the same trial definition throughout the report.
  • Response time starts at the reference event and ends when the controller accepts the decision. Report the slowest observed response and any timeouts. A timeout remains a separate outcome even if you also report latency statistics for successful trials.
  • Continuity and recovery track the longest gap in fresh, usable readings, plus the time from restoring the link to the first usable reading. Verify that a last-known distance expires according to the agreed controller behavior.

Inspect each required test case against its own limit. Keep results near the limit for engineering review if reference uncertainty prevents a clear pass or fail under the agreed decision rule. Save raw logs, settings, and fixture photos alongside the pass record so a technician can repeat the same run after replacing a sensor or changing firmware.

5. Repeat the most sensitive cases on site

Run the full matrix during factory acceptance or commissioning in the integration lab. At the warehouse, repeat the cases most sensitive to the actual location, such as dock lighting, rack geometry, vibration, target presentation, and adjacent equipment. After an optical window, bracket, filtering mode, or firmware change, rerun the affected cases before releasing the configuration for production. For a fleet rollout, decide which quick check every unit will receive and which full trials will be repeated on representative units. Keep those rules with the change record.

What to send with an integration inquiry

Share the required distance window, target materials and dimensions, worst approach angle, operating speed, expected lighting, window construction, available power and interface, and the longest acceptable gap in usable data. Include a drawing of the mounting position and a sample of the acceptance matrix if you have one. Those details let an engineering team review the application against the controlled documentation for the proposed model.

Browse the ERDI 905 nm sensor and rangefinder directory for model documentation, or send the requirements to ERDI for engineering review.

APPLY THE KNOWLEDGE

Need help matching a module to your system?

Discuss your technical requirements