Deployment preparation

AMR Site Survey Checklist Before a Robot Pilot

OpenDroids · October 4, 2026 · 4 min read

An autonomous mobile robot site survey should describe the environment the robot will actually work in. Start with a route and a task, then document the conditions that can change. A clean floor plan alone does not show queues, temporary obstacles, handoffs, or the recovery process when something goes wrong.

Use this checklist to prepare a supplier assessment. It does not certify that a location is safe or that a particular robot can operate there. The selected system's documented limits and a site-specific review determine what can proceed.

Map the task from start to finish

Mark the pickup point, delivery point, alternate destinations, charging area, and storage location. Describe how the load is placed, secured, transported, and removed. Identify who initiates the task and who confirms completion.

Record whether the robot must cross shared work areas, public areas, or restricted zones. Note any doors, elevators, ramps, or traffic controls involved. Ask the supplier which integrations are supported for the exact configuration; do not assume every autonomous platform can handle them.

Include the fallback workflow. If the robot is unavailable, who completes the task and how do they know it is still pending? A deployment without a fallback can turn a recoverable equipment issue into an operational backlog.

Observe routes under changing conditions

Walk the route at representative times rather than only before opening. Measure the constraints the supplier requests, and record moving furniture, queues, parked carts, floor transitions, thresholds, and areas where loads obscure visibility.

Photograph the environment only with permission and avoid including people or sensitive site details unnecessarily. Keep the survey in the site's controlled documentation rather than publishing operational layouts on a public page.

Document the difference between a permanent obstruction and a temporary one. A narrow fixed passage and a queue that forms unpredictably lead to different deployment questions. Include any requirement to keep paths accessible for people.

Capture floor and load conditions

Record the floor surfaces, slopes, transitions, moisture or debris conditions, and cleaning schedule relevant to the route. Get the supplier's operating limits in writing. A robot's apparent ability to cross a threshold in one demonstration does not establish a general approved use.

Describe the load's dimensions, weight range, center of mass, stability, and any special handling requirements. Include how staff will avoid incorrect loading. If the task includes fragile, hot, medical, or otherwise sensitive items, obtain the appropriate task-specific handling review.

Define an unacceptable handling event before testing. That may include a shifted load, missed handoff, or arrival at the wrong destination. A completion count should not classify these events as successful simply because the robot moved.

Check infrastructure and recovery

List required network coverage, power, charging access, and any integration endpoints. Ask what continues to work when connectivity is interrupted and what requires a remote service. Document who can see operational data and who can change the system's configuration.

Ask how operators stop, pause, recover, and restart the system using the manufacturer's supported process. Identify the escalation contact and the expected response for a blocked route or hardware fault. Do not improvise safety controls from a general guide.

Navigation software such as the open-source Nav2 project illustrates that navigation is a system of components and environment assumptions. Its existence does not establish that a particular commercial robot uses it, or that a site survey can be replaced by software alone.

Turn observations into a pilot brief

Summarize the task, route, load, infrastructure gaps, fallback process, and open supplier questions. Add a proposed test window and the measurements you will record: attempted cycles, completed cycles, interventions, and handling exceptions.

Use the robot pilot calculator to explore task-time assumptions, then replace them with measurements. Include the unresolved site work in the ownership-cost worksheet.

Share the brief with OpenDroids before selecting a deployment. A detailed route and acceptance plan gives a supplier something specific to confirm, revise, or decline, which is more useful than asking whether a robot works “in warehouses” or “in restaurants” in general.

Prepared with AI assistance using the current public product and linked references. Practical checklists and illustrative examples are original planning aids. They do not establish product guarantees or replace a situation-specific review.

Related guides