The 80ms figure appears in our product documentation, and when operators see it they usually ask one of two questions: "What exactly are you measuring?" and "Is that fast enough?" Both questions deserve a real answer.
This post covers the methodology behind the number, the physics of what 80ms means at aisle operating speeds, and how it factors into mixed-traffic aisle planning. We are not claiming that 80ms is the correct threshold for every deployment. We are explaining where our measurement comes from and how operators should reason about it when planning mixed-traffic coverage.
What we are actually measuring
"Response time" for a proximity-triggered deceleration has to be defined precisely or it is meaningless. We measure from the first moment a human body enters the robot's protection zone at a specified approach speed, to the moment the robot's wheels begin measurable deceleration (wheel speed drops by more than 5% of nominal speed). We do not measure time to full stop: that is a different and longer figure that depends on mass, floor surface, and the deceleration profile configured in firmware.
The measurement uses a mechanical arm swinging a body-representative target into the detection zone from the robot's blind side. The test object is a 30cm cylinder, sized per ISO 3691-4 Annex B guidance for human-leg detection tests. We log timestamps at three points: first sensor detection, control loop motor command, and wheel encoder deceleration onset. Nothing is inferred from simulation.
Breaking down the latency chain
The 80ms breaks into three hardware-defined layers that stack sequentially.
Sensor polling interval is the largest single contributor. Our ultrasonic array runs at 50Hz, which gives a maximum polling gap of 20ms. The depth camera runs at 30fps, giving a maximum gap of 33ms. Sensor fusion logic takes whichever detection fires first. In practice, an object entering at 0.8 m/s (a typical human step approaching the robot) will be caught by ultrasonic within the first polling cycle, yielding an average detection latency around 10ms.
Processing and command latency covers the path from sensor interrupt to CAN bus motor command. Our real-time controller handles this in one 5ms control loop tick. In peak load conditions, with all three sensor layers active and a map update running simultaneously, we have measured up to 12ms on this step. The controller prioritizes protective-stop commands over map updates when both are pending.
Motor actuation delay is the time from command receipt to wheel encoder showing measurable deceleration. Brushless DC hub motors with direct drive show approximately 8 to 15ms of torque buildup before deceleration is observable on the encoder. Floor surface roughness and wheel contact patch add a few milliseconds of noise to this measurement.
The 80ms figure is the P90 value across 500 test runs on our standard 6m x 2m aisle test rig, with three different approach vectors. P50 is around 58ms. P99 is 107ms. We report P90 because it is the figure that matters for worst-case aisle planning, not because P50 sounds worse.
What 80ms means at aisle operating speed
At the robot's standard aisle operating speed of 1.2 m/s, 80ms represents approximately 96mm of travel distance during the latency window. The protection zone detection boundary is set at 600mm from the robot chassis edge in the direction of travel. This means when deceleration begins, the robot is still at least 500mm away from the point where the obstacle entered the zone, before braking distance is factored in.
Full stopping from 1.2 m/s at our default deceleration profile (0.8 m/s², set to avoid disrupting carried cargo) takes approximately 900ms and covers about 540mm of floor distance. Combining the 96mm latency travel with the 540mm braking distance gives a total stopping footprint of roughly 640mm from the detection boundary entry point.
This is why protection zone sizing matters as much as response time. A 200ms response time can still be safe at low speed with a large enough protection zone. A 50ms response time at 2.0 m/s with a small zone may not be. The response time number only tells you what you need when paired with operating speed and zone sizing for the specific facility.
Three test scenarios beyond the standard frontal approach
Lateral entry from a rack gap. A person steps out from between two shelving units at 90 degrees to the robot's travel direction. This is the scenario where depth cameras outperform ultrasonic: the object appears in frame suddenly rather than approaching gradually. In our tests, the depth camera provides first valid detection in lateral scenarios; ultrasonic confirms within 15ms after that. The combined response time for lateral entry averages 88ms at 1.2 m/s operating speed, about 10ms slower than frontal approach.
Low-height obstacles below camera field. A bag or box placed on the floor ahead of the robot. The floor-contact force layer handles this, but it is the slowest of the three sensing layers, with a response time measured at approximately 120ms from physical contact. This is a known gap in the above-floor proximity chain. Floor-contact sensing is a safety backstop for below-camera-height scenarios, not a primary detection mechanism. Operators should know this when evaluating deployment in facilities with floor-level clutter.
Human crouch in travel path. A worker bending to retrieve something from a floor-level shelf, reducing their visible height profile. The depth camera is tuned for minimum detection height at 40cm from floor level, which captures most crouch postures. We have observed detection gaps for very low crouch postures (under 35cm height) in high-ambient-light environments. This is a documented limitation under active hardware review.
What operators actually need to plan for
When an operations manager is evaluating whether to deploy in a mixed-traffic aisle, the 80ms figure alone is not what they should focus on. The questions that actually matter: What speed will the robot operate at in this specific aisle, given pick density and human traffic patterns? What is the realistic worst-case approach speed of a human worker? Is the aisle width sufficient for the robot's nominal path plus protection zone radius plus comfortable human clearance?
For most retail and mid-scale logistics aisles (2.4m to 3.0m wide), operating at 1.0 to 1.2 m/s with our current zone tuning, the response timing works without requiring exclusion zones. For narrow aisles (under 2.0m wide), we typically recommend reducing operating speed to 0.6 m/s, which proportionally increases the reaction distance available within the same 80ms latency window.
We are not saying 80ms is the only safe threshold or that faster is always better. We are saying this is what we measure, how we measure it, and how the number connects to facility planning decisions. A robot with 50ms response time operating at 1.8 m/s in a narrow aisle may present greater risk than our setup at 80ms and 1.0 m/s in a standard-width corridor.
Field variation is real and we track it
Benchmark numbers look clean in documentation but vary in the field. Floor surface matters: sealed concrete gives lower motor actuation variance than uncoated wood or textured epoxy. Ambient temperature affects ultrasonic propagation speed by roughly 0.17% per degree Celsius. At an unheated warehouse in January in Fukuoka (ambient around 8 to 10C), the sensor's effective range needs recalibration. We ship with a floor-surface calibration routine and a temperature compensation table in firmware, but both require the initial commissioning step to be completed correctly.
In practice, deployed units sit in a P90 range of 75ms to 115ms depending on floor type, temperature, and traffic density. We log response time in pilot fleet telemetry and flag any unit where P90 exceeds 120ms for a maintenance inspection. If a unit in a cold facility shows drift above 100ms P90 consistently, the first check is whether the temperature compensation table was calibrated for the actual ambient range in that building.
Operators planning a deployment should ask for telemetry from the most comparable pilot environment we have run, not just the spec sheet figure. The spec sheet number is reproducible on our test rig; the telemetry number is what their facility will actually see.
