Service Robot Elevator Integration Across Floors
Why Floors, Not Square Metres, Decide the Fleet
A single-floor building is a coverage problem: measure the area, divide by work rate, add margin. A multi-floor building is a logistics problem, and the arithmetic that works on one floor gives the wrong answer on five. The constraint stops being how fast a robot cleans and becomes how long it waits for a lift, how long a person takes to cross the building to rescue it, and how much of a shift is lost to vertical travel.
The numbers are not marginal. A 30,000 square metre building over six floors presents the same cleaning area as a 30,000 square metre single-storey warehouse, but the fleet that serves it may need twice the units, or a smaller fleet with a floor-dedicated strategy. A robot that spends nine minutes per trip waiting for and riding a lift, and makes eight trips a day, loses 72 minutes of an eight-hour shift to vertical transport, about 15 percent of its capacity, before any cleaning happens.
That is why lift integration is not an IT feature on a comparison sheet. It is the difference between a fleet that covers a building and one that covers the ground floor beautifully and the rest of the building occasionally.
The Integration Stack, Layer by Layer
Getting a robot through a lift requires four layers to work, and vendors habitually quote only the top one.
| Layer | What it does | Who owns it | Typical failure |
|---|---|---|---|
| Robot-side navigation | Holds a map spanning all floors, plans a route to the lift lobby, docks into the car | Robot vendor | Map fragments per floor; robot will not plan across the boundary |
| Communication path | Carries the call and destination request from robot to lift controller | Integrator or vendor gateway | Wi-Fi dead zone in the lift shaft; request never arrives |
| Lift controller interface | Accepts an external call, assigns a car, opens doors on arrival | Lift manufacturer, or a third-party module | Controller is a closed proprietary system with no external interface |
| Building policy | Decides whether robots may share passenger cars, and at what hours | Building owner and facilities team | Policy written after installation, contradicting the technical design |
The bottom two layers decide whether a project succeeds, and neither belongs to the robot vendor. A building with lifts from a manufacturer that offers no external interface needs a hardware module wired to the controller, which is a lift-specialist job with its own cost and its own certification implications. Buyers who approve a robot purchase before confirming the lift interface discover this at commissioning, when the fleet is already on site.
The practical check is a single question asked of the lift maintenance contractor before signing anything: can this controller accept an external call request, and through what interface, documented in writing? A verbal yes from a sales engineer is not an answer.
Three Approaches and What Each Really Costs
There are three ways a fleet crosses floors, and they differ by an order of magnitude in cost and by a lot in reliability.
| Approach | How it works | Capital cost signal | Best fit |
|---|---|---|---|
| Dedicated service lift | One lift reserved for robots and goods, robot calls it directly with no passenger logic | Highest, but often already exists in back-of-house | Hospitals, hotels, large mixed-use buildings with a goods lift |
| Interface to an existing passenger lift | Robot gateway calls the lift, rides with or without passengers | Moderate: gateway, controller module, commissioning | Office buildings, retail, with a cooperative lift contractor |
| Floor-dedicated fleet | Robots never leave their floor; one unit per floor or per floor pair | Lowest integration cost, highest unit count | Buildings with closed lifts, heritage plant, or a hostile landlord |
The third option is dismissed too quickly. A 4-unit floor-dedicated fleet on a six-floor building costs more in hardware than a 3-unit integrated fleet, but it removes an entire integration project, removes the lift as a single point of failure, and avoids the staffing question of who rescues a robot stuck in a car. On buildings with fewer than about 4,000 square metres per floor, floor-dedicated is often the cheaper answer over five years once integration risk is priced honestly.
Interaction Latency and Round-Trip Arithmetic
Integration quality shows up as latency, and latency is measurable before purchase. Ask for the timings, not the feature list.
| Step | Good | Acceptable | Failing |
|---|---|---|---|
| Call request to car assignment | Under 2 seconds | 2 to 5 seconds | Over 10 seconds, or retry loop |
| Door open to robot fully inside | Under 25 seconds | 25 to 45 seconds | Over 60 seconds, or requires a person |
| Total trip time, adjacent floors | Under 60 seconds | 60 to 120 seconds | Over 3 minutes |
| Retry success after a missed call | First retry works | Second retry works | Requires manual intervention |
Multiply the trip time by trips per day to get the capacity the fleet loses. A delivery robot in a hotel making 40 trips a day at 90 seconds of lift overhead loses an hour, which on an eight-hour shift is one robot in eight. That number belongs in the fleet sizing calculation, not in a footnote, and it should be measured during the pilot rather than taken from a datasheet.
Peak-Hour Policy: Robots and People in the Same Lift
The technical integration usually works. The operational model is what breaks, because a robot sharing a lift with passengers during a morning peak is a complaint generator regardless of how well the software behaves.
- Time-window the fleet. Restrict lift-based robot travel to off-peak windows, typically before 07:00, between 10:00 and 11:30, and after 19:00. This is the single most effective policy, and it costs nothing but a schedule.
- Reserve a floor range. Let the robot use the lift only for its assigned floors, so a passenger never finds their car diverted to a basement plant room.
- Define the yield rule. If a passenger enters, does the robot exit, continue, or hold position? Holding position at the back of the car with a clear announcement is usually best; exiting mid-ride strands it between floors.
- Post the policy where people see it. A small sign explaining that the cleaning robot uses the service lift between certain hours removes most objections before they form.
- Escalate, don't improvise. A robot blocking a lift door is a safety issue with a defined response, and the response belongs in the building's emergency procedure alongside the fire plan.
For fleets where a robot shares corridors and lifts with staff, the human-robot interaction side of the same problem, including induction and signage, is covered in human-robot collaboration and change management.
Wi-Fi, Dead Zones and the Shaft Problem
Lift shafts are radio-opaque metal boxes, and a fleet that depends on continuous connectivity will lose contact inside them for the duration of every ride. Two designs survive this: local autonomy, where the robot completes the ride on its own logic and reconnects at the destination landing, or shaft-side coverage, where an access point or a leaky-feeder antenna serves the car itself.
Local autonomy is cheaper and is what most sites should require. The specification item is explicit: the robot must complete a queued lift journey without network connectivity for at least three minutes, and report the completed journey on reconnection. Where the building genuinely needs live monitoring inside the car, shaft coverage is a small civil works project, and it should be quoted before the fleet is ordered rather than discovered during commissioning.
Dead zones also appear where they are least expected: basement plant rooms, stair cores, and thick-walled service corridors. A walk test with a laptop on the actual robot channel, on every floor the fleet will serve, is a two-hour exercise that prevents a month of intermittent faults. The wider site-readiness picture is set out in site survey and readiness assessment.
The Pre-Purchase Checklist
Six confirmations, in order, before a multi-floor fleet is ordered.
- Lift interface confirmed in writing by the lift maintenance contractor, naming the interface and any controller module required.
- Integration cost quoted separately from the robots, including the module, cabling, commissioning and any lift certification impact.
- Trip latency measured on a pilot unit in the actual building, not on a reference site in another country.
- Fallback defined for each lift, whether a manual mode, a goods lift, or a floor-dedicated unit.
- Policy written covering time windows, passenger sharing and the yield rule, agreed with the building operator.
- Docking space verified at every landing: the robot needs a marked position clear of the door swing, about 1.5 by 1.5 metres for a compact unit and more for a large-format scrubber.
For buildings where the lift question cannot be solved, the alternative is a fleet that never needs one. The compact AOMAN C2 Pro is specified for narrow aisles and per-floor deployment, and the AOMAN D1 supports elevator and gate integration for delivery work across floors. Send us the lift details and floor plan and we will return a trip-time estimate against your operating window before you commit to a fleet size.
Mapping a Building That Has Floors
Multi-floor mapping is its own discipline. The fleet needs one logical map per floor plus a linking route at each lift landing, and the landing coordinates must be identical whichever floor the robot arrives from, or the robot will re-localise on every trip and lose minutes each time. Ask the vendor during the pilot to demonstrate a route that starts on floor two, crosses to floor five, and returns, without a manual correction. That single demonstration exposes most mapping failures.
Who Rescues a Stranded Robot
A robot stopped on a landing at 23:00 with doors closing behind it is an operational event, and it needs an owner. The cheapest arrangement is a named technician on the building's existing night shift with a documented recovery procedure and a key to the service lift. The expensive arrangement is a vendor call-out with a four-hour response that arrives after the shift has already been lost. Recovery time is part of the availability figure the fleet is bought against, and it belongs in the uptime SLA and contract rather than in a support brochure.
What Changes in the Contract
Three clauses are specific to multi-floor deployments. First, an integration acceptance test at the building, defined by trip time and retry behaviour, not by a feature demonstration. Second, an availability figure measured per floor rather than per building, because a fleet that reaches five of six floors on time is not meeting the requirement. Third, a stated position on lift interface support: if the lift controller is upgraded or replaced during the contract term, who pays to re-establish integration? That question is asked rarely, and it is the one that turns a working deployment into a stalled one two years later.
