Nominal speed, payload, sensors and autonomy are only the beginning of a mobile robotics evaluation. The more difficult questions emerge when the robot becomes part of a live operation: who requests missions, who handles alarms, where the robot charges and what happens when a path is blocked?
A platform can have LiDAR, cameras, GNSS, 5G and sophisticated compute and still deliver little value if its mission logic and operational ownership are unclear. The real engineering object is the complete system, not the vehicle in isolation.
01 / Treat interfaces as design objects
Draw a system boundary that includes people, robots, fleet management, WMS/MES/ERP, doors, chargers, stations, IT/OT networks and service functions. For every interface, specify inputs, outputs, timing, failure handling, diagnostics and accountable parties.
An API document may describe endpoints. It does not automatically describe what must happen when a transfer is interrupted or when two systems disagree about mission status.
02 / Model the operating envelope
Payload capacity depends on mass distribution, handling height, stability, floor quality, grades, acceleration and the equipment configuration. Nominal endurance depends on the actual sensors, duty cycle, payload, temperature and charging opportunities.
Record verified limits and explicit assumptions. Avoid designing around the maximum advertised value without reserve or test evidence.
03 / Make failure and recovery first-class requirements
For a blocked route, lost localization, low battery, failed charging, interrupted WMS message or inaccessible station, define the safe behavior, alarm destination, recovery authority and return-to-service steps.
A robot that stops safely is a good starting point. An operation also needs to know how the interrupted process is recovered without duplicate deliveries or missing material.
04 / Engineer autonomy around charging and maintenance
Charging stations occupy space, use electrical infrastructure and consume fleet time. Define when robots leave production, how queues are avoided and what happens if a dock is occupied or unavailable.
Maintenance access, spare parts, diagnostics and operator procedures affect the system’s practical availability just as much as the vehicle’s component quality.
05 / Prove the operation, not the feature list
Create acceptance criteria around completed work, recovery, interfaces and support. Include representative shifts, changes of personnel, abnormal conditions and clear ownership after handover.
The best solution is not necessarily the machine with the most futuristic appearance. It is the system that repeatedly completes the task without adding unmanageable complexity.
The robot is one component; the product delivered to the customer is a dependable operational system.