Elevator integration for service robots in BC — who does what

A delivery or cleaning robot that cannot ride the elevator is a one-floor robot. In practice, the elevator is where more deployments stall than anywhere else — not because the technology is hard, but because the ownership is unclear.

Three paths, in order of preference

1. The elevator maker's API. KONE, Otis, Schindler and TK Elevator all offer cloud or gateway interfaces for robot dispatch. This is the cleanest path: the robot calls the car through a documented interface, gets status back, and nothing in the elevator controller is modified. It requires a service agreement with the elevator company and, usually, a reasonably modern controller.

2. The robot vendor's IoT module. Most Chinese service-robot makers ship a module that sits alongside the controller and drives the call buttons through relays. It works on older equipment where no API exists. The critical detail: the module's connection to the controller is elevator work. It is not robot work.

3. A dry-contact interface. The lowest common denominator — relays wired to call buttons and floor indicators. Reliable and cheap, but the most invasive, and the one that most obviously requires a licensed elevator mechanic.

Where the line sits

This is the part we put in writing on every project, because ambiguity here is how people get hurt and how projects get red-tagged:

• Anything inside or connected to the elevator controller is elevator work. It is performed by the building's licensed elevator contractor, under permit and inspection where the authority having jurisdiction requires it. In British Columbia that authority is Technical Safety BC.
• Everything on the robot side is ours. The robot's network, the gateway, the credentials, the call logic, the behaviour when a car is full or out of service, and the floor-by-floor testing.
• The building owns the decision. The elevator contract, the modernisation state of the equipment and the maintenance agreement all belong to the owner, and they determine which of the three paths is even available.

If a vendor tells you their technician can "just wire it in" over a weekend, that is the moment to slow down.

What we test before calling it done

A robot that can call an elevator in a demo is not a robot that can use an elevator in a building. Our floor-by-floor test covers:

1. 1. Call from every floor, in both directions
2. 2. Boarding with the door held, including a door-obstruction recovery
3. 3. Exit at the correct floor, with a deliberate wrong-floor recovery test
4. 4. Behaviour when the car arrives already full of people
5. 5. Behaviour when the car is switched to independent service or taken out of service mid-trip
6. 6. Fire alarm recall — the robot must clear the car and not re-call it

That last one is not optional. A robot parked in a recalled elevator during an alarm is a life-safety problem, and it is the first thing a serious building engineer will ask you about.

Plan the timeline, not just the integration

The technical work is usually a day or two. Getting the elevator contractor scheduled, the permit handled if one is needed, and after-hours access arranged is what actually sets the date. We start those conversations at the site survey, before anyone signs a purchase order — because a robot that arrives before its elevator path is agreed sits in a storeroom, and that is expensive in a way nobody budgeted for.