A depth camera helps an autonomous mobile robot (AMR) locate objects above the floor and measure the geometry around it. When choosing a camera, start with what the robot needs to see, what its chassis or payload may hide, and how soon the navigation system needs the data.
DOMI offers compact ToF arrays, USB RGB-D cameras and embedded ToF modules. Use the robot’s target list, mounting position and host requirements to shortlist a format, then evaluate it on the robot along the intended route.
Define the AMR perception tasks and target set
Record the width, height and material of the smallest obstacle the robot needs to detect. Mark where each target must become visible, including turns and station approaches. A forward-facing depth camera measures returns from visible surfaces within its field of view. A planar scanner measures along its scan plane. Plot the sensor positions and check which targets the chassis or load may hide.
| AMR task | Targets to define | What to check on the robot |
|---|---|---|
| Forward obstacle detection | Low objects, narrow legs, angled panels, overhanging loads and crossing objects | Coverage across the travel corridor and during turns, including the minimum target at the required distance |
| Floor changes and edges | Ramps, transitions, thresholds and drop-offs on the intended route | The expected floor region, the change in measured floor geometry and the response when floor data is missing |
| Docking and alignment | Pallet openings, station edges or other pose references | Whether the feature stays in view from approach through final alignment. Pallet detection and docking |
| Navigation and localization | Stable structures and changing objects along the route | Which depth observations the navigation stack uses for local obstacle updates or pose estimation |
What a depth camera contributes to navigation
The camera measures depth in its own coordinate frame. Perception software can turn valid measurements into obstacle observations for a local map. A localization or simultaneous localization and mapping (SLAM) system may also use depth if its inputs and processing support it. Localization estimates where the robot is, planning selects a path, and control executes motion. Decide which software stage consumes the depth data, which coordinate frame it expects and how old an observation can be when that stage uses it.
Separate obstacle detection from safety-rated protection
Depth-camera data used for navigation and obstacle avoidance is separate from any safety-rated protective function. Any protective function must be designed and validated at the machine or system level using the appropriate safety architecture and applicable safety requirements.
Set range, field of view and target-sampling requirements
Draw the required detection zone in plan and side views. Mark the nearest and farthest required observation points, the edges of the travel corridor, the camera position and tilt, and any part of the bumper, chassis or load that blocks the view. Use the depth field of view (FOV) when estimating distance coverage. RGB and depth may cover different angles.
For a plane perpendicular to the optical axis, use the axial distance to estimate horizontal coverage.
coverage width = 2 × axial distance × tan(horizontal depth FOV / 2)Near the image center, multiply the active depth image width in samples by the ratio of target width to coverage width to estimate the samples across a front-facing target. Then count valid samples with the target at the center and edges of the required zone. Target angle, distortion and filtering affect how many of those samples the software can use. ToF camera selection guide
Near-field floor and low-obstacle coverage
Check the floor intersection of the vertical depth FOV using the proposed mount height and tilt. Mark the nearest usable depth boundary and any floor region hidden by the robot or its load. Place low test objects near the boundary and at the sides of the travel corridor. A downward-looking channel can give a separate view of the floor. Keep missing depth distinct from a measured change in floor geometry and define how the navigation software handles each case.
Build the motion and latency budget
Measure two intervals on the moving robot. Frame age runs from capture to controller use. Obstacle response time runs from the moment the obstacle enters the required zone to the moment the controller uses an observation of it. The second interval includes the wait for a usable capture. Exposure, capture cadence and filtering can affect which frame first yields a usable observation.
| Timing checkpoint | What to record | Timestamp |
|---|---|---|
| Target enters the zone | Independently recorded entry time for the test target | _____ |
| Acquisition | Capture time for the frame that supplied the observation. Record the exposure reference used for the timestamp and the frame interval. | _____ |
| Host receipt | Arrival time for that frame | _____ |
| Perception output | When the observation becomes available after depth processing and filtering | _____ |
| Navigation update | When the obstacle observation is applied to the local map or planning input | _____ |
| Controller use | When the controller consumes a decision based on the observation | _____ |
Use a common clock or align the timestamps across devices. Trace the observation through perception, the navigation update and controller use. Calculate each interval from its own start and end timestamps. Use successive checkpoints to locate delays in transfer, queueing, processing or the control cycle. Record trials with no usable observation as misses. Compare typical and high-percentile times under normal and peak host load, and relate the response to travel and turning speeds.
Transform depth into robot coordinates
Use the camera’s intrinsics and documented depth convention to convert valid image samples to spatial points. Apply the measured rotation and translation from the installed camera frame to the robot frame. Filter known chassis or payload geometry and select the height and distance region relevant to the task.
With the robot stationary, place a reference target at known positions in front of it and to either side. Compare those positions with the transformed observations and check that the height filter retains low obstacles. Record the mount and transform together. Repeat the same check after representative travel over the intended surfaces and after service to see whether vibration or a mount change shifted the observed positions. If the navigation stack marks and clears obstacles from depth observations, test how it handles unknown space when a frame is missing or the view is blocked.
Evaluate light, materials and missing depth
Test the target set under the lighting changes the robot will see. Include a mixed scene with a low-return target beside a brighter surface. Fit the final optical window and record its condition for each run, including any dust or marks. Repeat a representative run after cleaning to compare the results. Where other active sensors share the route, repeat a matched run with the other units on and off while holding the target, mount and lighting steady.
Record gaps in the depth image separately from missed detections and false obstacle reports. Those records help the team decide whether to investigate the optical scene, perception settings or navigation logic. Depth measurement test guide
Choose the sensing and integration route
For a compact depth array, check how many valid samples the smallest target returns at the required distance and at the edges of the mounted view. Evaluate RGB-D when the host needs both appearance and depth. Consider embedded ToF when the camera must fit into a custom chassis and the host has a matching camera pipeline. A single-point channel can complement area sensing when a local floor or clearance check needs one distance.
List the data the host needs, its supported interface and stream modes, and where depth conversion, filtering and frame transforms will run. For a ROS-based stack, check the required driver, message type, frame IDs and timestamp behavior against the chosen hardware and software versions. If the design needs multiple streams or cameras, define how you will measure timing alignment and how the host handles missing frames.
Plan pilot and production validation
Run the same target set in a controlled setup and on the installed robot. Set the distance, speed and pass criterion before each run. For missing depth, specify the target image region, the number of frames and the fraction of samples that must be valid. For detection, record the number of misses across trials with a known target and the number of false obstacle reports across trials with a clear path.
| Target or event | Distance and speed | Light and route segment | Record | Pass criterion |
|---|---|---|---|---|
| Narrow pallet leg or low object | _____ | Warehouse aisle center and edge. Record light at the target. | Valid samples and detections in target trials, false obstacles in clear-path trials | _____ |
| Low-return target beside a reflective surface | _____ | Warehouse loading transition. Record the light on both sides. | Missing depth in the target region and effect on obstacle observations | _____ |
| Floor transition or drop-off | _____ | Downward view along the intended route | Expected floor geometry, invalid data and navigation response | _____ |
| Docking reference with the intended load | _____ | Approach, turn and final alignment | Feature visibility and pose observations through the approach | _____ |
| Stale or interrupted stream | _____ | Representative route under peak host load | Age at controller use and recovery behavior | _____ |
Record the camera build, firmware, stream settings, host load, mount transform, optical window condition and robot load with each run. Before production, repeat the critical cases with the intended hardware and software. Set a service interval or inspection trigger for the mount, window and calibration. 3D obstacle-avoidance solution
Relevant DOMI depth-sensing options
| Sensing route | DOMI model and documented configuration | What to evaluate on the AMR |
|---|---|---|
| Compact area depth | DMAS2M001 SPAD dToF array with a 940 nm VCSEL and 40 × 30 depth at 10 fps. <br> Stated ranging is 0.2–8 m at 30 klux for targets with 10–90% reflectivity. | Check target sampling and timing on the mounted robot. Compare the stated ranging conditions with the route. |
| Host-based RGB-D | DM-RGBD5002A with VGA ToF depth up to 640 × 480, RGB up to 1280 × 960 and USB 2.0. | Evaluate the depth and RGB stream configuration needed by the host, including processing and timing under load. |
| Embedded ToF | DMOM2808D with 320 × 240 depth, 850 nm illumination and two-lane MIPI CSI-2. | Evaluate the host capture path, mechanical fit, optical window and calibration workflow for the installed module. |
For a wider shortlist, compare the available ToF camera modules and RGB-D cameras.
Share the smallest target, working distances, travel speeds and mounting sketch with DOMI. Include your host platform and required data output or interface. We can help you narrow the sensing options and plan which conditions to test first. Contact the DOMI engineering team
FAQs
How does a depth camera support AMR navigation?
It supplies distance measurements that perception software can turn into local obstacle observations. A navigation stack can also use depth for mapping or localization when its software accepts those inputs.
How do I choose a depth camera for AMR obstacle detection?
Map the travel corridor through turns and identify the smallest target the camera needs to see. Check where the depth view meets the floor, where the payload blocks it and how early an observation reaches the controller. Use those requirements to compare a compact array, RGB-D or an embedded module on the mounted robot.
What latency should I measure on a moving AMR?
Measure frame age from capture to controller use. Measure obstacle response from target entry to controller use to include the wait for a usable frame.
How should I test dark and reflective targets?
Test the same target at the required distances and angles, first by itself and then beside a surface with a different reflectivity. Compare valid depth and detection results for the two scenes.
Can navigation depth data qualify an AMR’s protective function?
No. Navigation depth data can support obstacle detection and route planning, but it does not by itself qualify the AMR’s protective function. Qualification depends on the complete machine-level safety design, implementation, and validation.
Can one depth camera support travel and docking?
Evaluate both views on the mounted robot. During travel, the camera needs to cover the obstacle corridor. During docking, it needs to retain the alignment feature through the approach. Test both with the intended load in place.
When should I evaluate RGB-D, embedded ToF or a compact depth array?
Start with the data the navigation system needs. Evaluate RGB-D for appearance plus geometry, embedded ToF for a custom host camera pipeline, and a compact array when its sampling can resolve the targets in the required zone.
