A 32-floor office tower in Shenzhen runs a fleet of AOMAN DOUBLE delivery robots serving 14 tenant floors, and the building's elevator system is a 2009 Schindler installation with no API, no IoT gateway and a controller cabinet that the property manager has never opened. The fleet nevertheless completes 300+ deliveries a week across all 14 floors. The integration that makes it work cost less than the robots themselves, was installed in four days, and — the part most buyers never expect — required no modification to the elevator at all. The robots call the elevator the same way a person does, through an interface that turns the physical call button into a network command.
This is the reality of elevator integration in 2026: there is no single standard connector, but there is a proven pattern. The delivery robot selection guide touches on the cabin-width question; this guide covers the integration layer underneath — the part that determines whether your multi-floor deployment takes three days or three months.
Why the Elevator Is the Hard Part
A delivery robot's navigation stack — LiDAR, SLAM mapping, obstacle avoidance — is designed for a world the robot can perceive. Elevators are the exception: the robot cannot see which floor the cabin is on, cannot know which cabin will arrive, and cannot control the doors. Every elevator integration is therefore a communication problem: the robot must (a) request service, (b) know which cabin and which direction, (c) enter safely, (d) select the destination floor, and (e) get priority over human traffic during busy periods. The robot navigation and SLAM guide covers the perception side; this is the coordination side.
The failures cluster into five modes, all of which appear in the failure modes guide: the robot arrives and no cabin answers (call not registered), the cabin arrives but the robot cannot tell it apart from the lobby (no cabin-state signal), the doors close on the robot (door-timing mismatch), the robot selects a floor but the cabin has already been hijacked by human passengers (arbitration loss), and — the most common in older buildings — the elevator simply has no digital interface at all.
Integration Model 1: Elevator API / IoT Gateway (Newer Buildings)
Modern elevator systems from KONE, Otis, Schindler, Mitsubishi and thyssenkrupp ship with digital interfaces: KONE 24/7 Connected, Otis Compass, Schindler PORT and equivalents. These expose call and floor-selection commands over an API, which the robot fleet software calls through an IoT gateway on the building network. This is the cleanest model: the elevator system natively supports external calls, destination dispatch, and priority arbitration, and the robot integrates in days.
The practical constraints are access and cost. The building owner must authorize the integration, the elevator vendor may require a service agreement for API access, and the API license can add $1,000–5,000 per year depending on the vendor and building contract. Multi-tenant buildings also raise the access-control question: the robot's destination floor permission must match the tenant's access card zone, which is where the smart office building deployment guide connects to the access-control system.
Integration Model 2: BMS Integration (Mixed-Age Buildings)
Most commercial buildings built before 2015 have a Building Management System (BMS) that supervises the elevators even when the elevators have no public API. The BMS exposes a supervisory interface — often BACnet or Modbus — through which a gateway can issue elevator calls and read cabin state. This model trades elegance for universality: integration is done once at the BMS level, and the fleet software talks to the BMS rather than to each elevator vendor.
This is the model that handles the Shenzhen tower's 2009 Schindler installation. The gateway connects to the BMS's elevator supervision port, the robot's call is injected as a supervisory command, and cabin position/floor state is read back to the fleet manager. The property manager's expectation — "you'll need to modify the elevator" — is wrong in almost every case: supervisory interfaces are designed for exactly this kind of external coordination. The integration cost typically lands between $3,000 and $8,000 including gateway hardware and engineering, versus the $18,000–40,000 range for a full controller retrofit on a classic elevator.
Integration Model 3: Relay Retrofit (Legacy Elevators)
When a building has neither API nor a usable BMS interface — small hotels, older residential towers, some hospitals — the fallback is a relay-based retrofit: a small controller wired in parallel with the hall call buttons and car call buttons, which the robot triggers over Wi-Fi. This is the most invasive model and the least common in production fleets, but it is the difference between automating a 1990s building and skipping it.
The engineering discipline that applies here is the same one the hospital delivery robot guide documents for clinical environments: the retrofit must fail safe. If the gateway loses power or the robot fails to communicate, the elevator must behave exactly as it did before — human passengers press buttons, nothing is blocked, no phantom calls accumulate. Fireman's service and fire alarm modes must bypass the integration entirely, which is why the safety compliance framework in the standards guide treats elevator integration as a safety-relevant subsystem rather than a convenience feature.
The Standards Landscape: VDA 5050 and Beyond
Two standards anchor the elevator conversation. VDA 5050, originally the interoperability standard for AGV fleets in European warehousing, is being extended to service robots — the hotels and resorts guide notes that a single fleet manager coordinating robots from multiple manufacturers on the same property map and elevator arbitration protocol is the direction the industry is moving. EN 81 (and its regional equivalents) governs the elevator hardware itself, which is why integration is always supervisory: the elevator's safety functions are closed systems by regulation, and no robot integration is permitted to touch them.
For buyers, the practical takeaway is that "VDA 5050 compliant" on a robot spec sheet describes the communication layer, not the elevator interface — the elevator side is a separate integration contract with the building and, where applicable, the elevator vendor. The fleet management guide covers the multi-robot side of this: when two robots and a cleaning robot all want the same cabin at 09:15, the arbitration logic decides, and it needs the same cabin-state data the integration provides.
The 420 mm Advantage: Why Cabin Geometry Decides
Elevator integration is pointless if the robot cannot fit the cabin. The AOMAN DOUBLE is 420 mm wide, which means it enters and exits elevators without turning — a specification that matters far more than most buyers realize, because the average commercial elevator cabin is 1.5–2.0 m deep and a robot that must reverse out of the cabin needs roughly 1.2 m of clearance inside, plus door dwell time. A robot that drives straight through the cabin turns the elevator into a corridor: enter, stop at the far wall, doors close, doors open on the destination floor, drive straight out. The difference in cycle time per delivery is 15–30 seconds, and across 300 weekly deliveries in the Shenzhen tower, that is the difference between one robot and two.
The selection guide's cabin-width section covers the specification side; the site-survey side is below, because geometry that works on paper fails in real buildings when the threshold gap exceeds the robot's ground clearance or the door sensors trigger on the robot's silhouette.
The Site-Survey Checklist: Three Days vs Three Months
The deployments that take three months fail the same five checks that the three-day deployments pass:
- Cabin and door geometry — measure door clear width (minimum 800 mm for a 420 mm robot with margin), cabin depth, and threshold gaps. Verify the robot can enter without turning and that door sensors do not false-trigger on the robot's body.
- Call interface availability — identify which integration model applies: elevator API, BMS supervision, or relay retrofit. This single decision drives 80% of the timeline.
- Access-control mapping — confirm the robot's floor permissions match destination floors, and that the access-control system recognizes the robot as a credentialed device rather than an intruder.
- Arbitration and priority rules — define peak-hour behavior: does the robot yield to human traffic during 08:30–09:30, and does the cabin-state feed let the fleet manager re-dispatch when a call is lost?
- Failure-mode walkthrough — test the elevator with the gateway offline, with the robot's network dead, and during fire alarm drill. The elevator must behave exactly as before integration.
The pilot program guide is the right vehicle for the checklist: a two-week pilot on two floors, with the site survey done in week zero, resolves every integration risk before the fleet purchase. The multi-site deployment guide then covers how the same integration package rolls out across a portfolio of buildings — because the second building always integrates faster than the first, and the survey checklist is the reason why.
The elevator is the last physical frontier of autonomous delivery, and it is no longer the blocker. With a supervisory integration on a 2009 controller, a 420 mm robot that drives straight through the cabin, and a survey checklist that catches geometry before contract signing, a 14-floor building runs a delivery fleet in under a week. The buildings that deploy multi-floor robots in 2026 are not the ones with the newest elevators — they are the ones that treated the elevator as an integration project instead of an obstacle.