When we started designing Closer in late 2024, the question we kept returning to was not "how do we make a safe robot" but something more specific: what does safety mean when the robot and a person are occupying the same aisle right now, without a physical barrier between them?
The cage answers that question through separation. We chose to answer it differently, and the three principles that follow shaped every hardware and software decision we made in the first year of building.
Principle 1: Predictability before capability
People who work around machines need to predict what those machines will do next. This sounds obvious until you realize it has a counterintuitive implication: adding capability can reduce effective safety if the capability introduces unpredictable behavior.
We made a deliberate decision to cap Closer's operational speed at 1.0 m/s in shared-space operating mode, even though the drive system can sustain faster speeds. The reasoning was a simple calculation: the average walking pace of a picking worker in a warehouse aisle is around 1.2 to 1.4 m/s. At 1.0 m/s, the robot never overtakes a pedestrian from behind at a speed differential that creates a surprise encounter.
We also constrained our deceleration curve to be gradual rather than abrupt. A sudden stop from speed can be its own hazard: a worker following close behind may trip, goods on a cart may shift, a nearby picker could be startled. The transition from operating speed to a full proximity stop in our current implementation takes 280 to 320ms from trigger to zero velocity, depending on floor conditions. That is slow enough to feel smooth, but fast enough to prevent contact with a detected object in our deference zone geometry.
During early test sessions at a small logistics staging facility in Fukuoka Prefecture, operators commented without prompting that they could read where the robot was going two or three steps ahead. That legibility of motion was more important to worker acceptance than any single safety feature we had built. We were not expecting that feedback. It confirmed that predictability was not a constraint on capability but the primary design goal in its own right.
Principle 2: Deference before avoidance
There is a meaningful distinction between a robot that avoids an obstacle and a robot that defers to a person. Obstacle avoidance is a navigation problem: detect the blockage, compute a path around it, continue the mission. Deference is a different contract: recognize that a human's movement has priority, stop, and wait for them to complete it.
Our motion planning layer treats proximity to a detected person as a deference event, not primarily a navigation problem. When a person enters the deference zone (below 700mm clearance from any point on the robot chassis), the robot comes to a full stop and waits until the person has moved past or the clearance has reopened, rather than attempting to route around them.
We chose the 700mm threshold by working through the geometry of what a person reaching for a shelf at shoulder height actually occupies in an aisle. A person with arms extended to reach a high shelf typically extends their elbow approximately 400mm from the plane of their body. At 700mm chassis clearance, the remaining gap between the robot and that extended elbow is around 300mm. That is not comfortable for most people. Below 700mm, deference without exception is the right call.
ISO 3691-4 establishes requirements around detection zones and protective stop functions for automated industrial vehicles. Our zone geometry and stopping behavior were designed with those requirements as the reference. We are not saying avoidance is wrong for all robot applications. Avoidance solves a different problem than deference does, and for a robot operating in close human proximity, the social contract of deference changes how workers relate to the machine over days and weeks of operation in ways that pure avoidance does not.
Principle 3: Fail toward the stop
Hardware degrades. Software has edge cases. Sensors have limits. Every system deployed in a real environment will encounter conditions outside its design envelope eventually. The question is not whether failures will happen but what state the robot enters when they do.
We decided early in development that any sensing layer failure should default the robot to a full stop and maintenance mode, rather than continuing operation with the remaining healthy sensors. A depth camera fault does not trigger "fall back to ultrasonic-only proximity operation." It triggers a stop, a logged fault code, and an alert to the fleet dashboard.
This was a real tradeoff. A conservative failure policy produces worse uptime metrics because the robot stops more often for maintenance events. In our pilot data, approximately 14% of stop events are maintenance-mode triggers rather than proximity responses. That number is visible to operators, and it required explanation early on. But the alternative -- a robot that continues operating with degraded sensing and does not surface the fault to anyone -- is an indefensible design for a robot working arm-distance from people who have no way to know that a sensor has failed.
We log every stop event with the full sensor state, motion state, and proximity data at the time of the stop. Operators see those logs in the fleet dashboard and can review them. That transparency reinforced the conservative failure policy: once operators understood they could see exactly what triggered every stop, the frequency of maintenance stops became informative rather than a black mark on uptime figures.
What proximity-first demanded from the hardware
These three principles are not just policy statements. They produced concrete hardware decisions.
The three-layer sensing architecture exists because no single sensor type handles the full range of proximity events in a mixed-traffic aisle. Ultrasonics cover the 360-degree proximity ring well but are blind to low-profile obstacles below the transducer mounting height. The depth camera provides precise geometry in the forward zone but has minimum-range limits that create a sensing shadow close to the chassis. Floor-contact force sensing at the wheel assemblies catches what both miss: objects in the sub-200mm height range that the robot's wheels will contact first.
The motion planning layer was built from the start to treat sensing inputs as primary constraints rather than inputs that mission efficiency can override. This is a software architecture choice that runs against the grain of mobile robot systems optimized for maximum task throughput. A throughput-first design often treats proximity events as delays to route around. Our system treats them as the authoritative input that defines what the robot can do next.
Where this approach has limits
Multi-person close-proximity scenarios remain an active area of work. One person standing in a narrow aisle while the robot waits is a well-defined case. Three people moving at different speeds in the same aisle, two of them outside the sensor field and one in the deference zone, is more complex. Our current sensing and deference logic handles it, but the edge cases in group motion scenarios are not fully characterized yet.
We are also not claiming that proximity-first design is appropriate for every mobile robot application. High-payload industrial robots operating at high speed, autonomous forklifts at forklift operating speeds, robots in areas with no human co-occupation -- these have different safety profiles and physical separation may be appropriate for them. Proximity-aware design is suited for low-to-medium speed service robots that need to share mixed-traffic space with people who are not standing still and not expecting the robot to stop for them.
What keeps pointing us back to these three principles is a consistent signal from the pilots: workers who stopped noticing the robot and went back to their normal working pace within the first three days are the goal. Predictability, deference, and conservative failure are the levers that get there.
