Cross-floor dispatch is where RCS projects go to die. A fleet that runs beautifully on a single floor starts missing elevators, timing out, and deadlocking tasks the moment you add a second level. The vehicles are rarely the problem — AMRs cannot climb stairs, so they depend on elevators, and an elevator is a shared resource for the entire building. Your RCS controls the robots. It does not control the elevator's temperament.
Take one elevator ride apart
One cross-floor move is really five phases: call, wait, enter, ride, exit. Each phase can jam. The elevator never answered the call because the protocols never matched. The car arrived but the doors never opened because a status signal dropped. The robot entered but the doors would not close because of an obstruction. It rode up fine, then could not exit because its localization drifted.
The key insight: a robot must never guess elevator state. The elevator controller is the single source of truth, and the RCS must drive everything off the controller's state machine — car position, door status, load weight, travel direction. All four signals, no exceptions. Estimating any one of them, or assuming it from a timeout, is planting a mine.
The industry already has frameworks for this handshake, so do not reinvent the protocol layer from scratch. In the ROS2 ecosystem, RMF (the Robot Middleware Framework) defines a complete set of lift-integration messages — the fleet manager and the lift controller negotiate through standardized state handshakes, and the robot just executes. Singapore's IMDA technical guidelines for AMRs in commercial buildings likewise write the robot-lift-door data exchange into the spec. On the equipment side, Germany's Lödige Industries sells a lift automation module that lets AGVs and AMRs talk directly to freight lifts like the Olympus and Sherpa lines, with published figures up to the 20-metric-ton class. Check what your lift vendor and middleware already support before building anything custom.
Who gets to call the elevator
The first fork in the road: who issues the call? Two architectures exist.
Vehicle-to-lift direct connection: the robot arrives at the landing and calls the elevator itself. Simple — and only suitable for a one- or two-robot demo. Scale up and N robots call simultaneously, the elevator gets yanked in every direction, everyone fights for the car, and nobody moves.
RCS-centralized calling: every cross-floor request funnels into the RCS first, which issues a single stream of commands to the elevator and then dispatches each robot — which car, which floor. This is the right answer for real fleets, but it means the RCS must own the queueing. Three queueing rules I insist on:
Ride-share by direction. Batch robots heading the same way into one car. The cost of one elevator round trip is fixed; every extra robot in the car is pure gain.
Priority with anti-starvation. Urgent cross-floor orders may jump the queue, but cap the wait — an ordinary task waits at most N rounds, then gets forced through. Do not let low-priority tasks wait at the landing until the end of time.
Timeout eviction. If one robot hogs a car past its time budget — say the entry maneuver has not completed after several minutes — the RCS kicks it out of the current car assignment and re-queues it. The elevator is a scarce resource; no robot gets to squat in it.
My call: scheduling authority for cross-floor moves must sit with the RCS. Vehicles keep only status reporting — I arrived, I entered, I exited. Split the responsibilities, or you will never untangle a failure.
When the elevator goes down, the system must not
Elevators are machines; they break. More often they half-break: one door faults, one floor's buttons die, the car e-stops occasionally. Write the downgrade plan in three tiers, in advance.
Tier one, single-car failure: the RCS automatically reassigns tasks to the working cars, queueing unchanged. This demands at least two robot-usable elevators on site — one elevator plus cross-floor business equals a single point of failure. Flag it at project kickoff.
Tier two, all elevators down: suspend every cross-floor task, switch the RCS to single-floor mode, and keep same-floor work running; move cross-floor goods by manual transfer (forklift or hand cart via the freight route or stairwell). The system slows down but never stops.
Tier three, communication loss: if the RCS stops hearing the lift controller's heartbeat, every vehicle holds at its designated waiting point. No blind entries into the car. This is a safety red line — you never know whether the car is actually behind those doors.
Name the trade-off honestly: a downgrade plan trades efficiency for safety. Write it into the SLA and align with the customer in advance on what you guarantee when the elevators are fully down. The worst outcome is never discussing it, then blaming each other when it happens.
Pricing cross-floor tasks fairly
A cross-floor task is inherently more expensive than a same-floor one: it consumes one elevator round trip plus waiting time on both ends. Three rules for setting priority:
Weight by order urgency. Outbound tasks racing a carrier cutoff get their cross-floor weight bumped.
Cost the elevator trip. Convert one elevator round trip into task cost, and let the RCS prefer full cars and minimize empty runs when scheduling.
Separate the weight pool. Do not rank cross-floor tasks in the same priority pool as ordinary tasks — give them their own weighting tier, or the flood of same-floor work will bury them.
In one sentence: the elevator is the building's most expensive shared resource, and the entire scheduling strategy comes down to fewer empty trips and no robot left idling.
Pitfalls worth pinning to the wall: never let robots call the elevator themselves in a multi-robot fleet — that is where chaos starts. Verify the load: vehicle plus cargo must stay under the elevator's rated capacity, not by a kilogram over — a safety item, not an efficiency item. Wire up the fire alarm interlock: when the alarm trips, elevators go out of service, and the RCS must get the signal and freeze all cross-floor tasks immediately. Do the protocol integration first, then talk fleet size — a connected controller and a smooth state machine before adding vehicles. Get the order backwards and every added robot is another landmine. And if you can swing it, one robot-dedicated elevator is the simplest life; at minimum, secure dispatch authority during peak hours.
