A delivery robot’s elevator connection has to coordinate a building service, not just recognize an open doorway. PUDU’s current FlashBot Max page presents cloud and hardware elevator-control options. Its earlier cooperation with Otis gives a more specific example of what a cloud or local API connection can coordinate: elevator dispatch at the group or bank level.
These sources describe different products and dates. The current FlashBot Max product page was checked on October 17, 2026. The PUDU–Otis cooperation announcement is dated September 22, 2023 and discusses FlashBot. The explanation below compares the integration arrangements described in those documents; no elevator or robot was operated for this article.
Cloud control connects the robot to an elevator service
The current product page lists cloud elevator control and identifies KONE and OTIS as supported examples, describing this route as requiring no elevator modification. Read that as the manufacturer’s description of its cloud option. The elevator supplier and the building’s available integration service still determine the specific connection used at a site.
The Otis announcement describes tests in Japan with Nippon Otis. It explains that the elevator protocol needed adjustments for different elevators and environments. This is useful detail behind the cloud label: a robot and an elevator service need to interpret the same requests in the context of the installed system.
Otis’s Integrated Dispatch API is described there as supporting a cloud or local connection and coordinating multiple elevators and different robots at group or bank level. That is broader than making one robot press one button. In a bank of elevators, dispatch is concerned with which car handles the request and how that request joins other traffic.
A local API connection and PUDU’s hardware option are different descriptions
PUDU separately advertises its own hardware elevator-control option on the FlashBot Max page. The Otis announcement’s local API connection describes where a software connection is made. Those are not interchangeable names for one implementation.
| Description in the source | What the source establishes | What to identify for a particular building |
|---|---|---|
| FlashBot Max cloud elevator control | A cloud option with named elevator-company examples and a no-modification claim | The installed elevator system and available supplier integration |
| FlashBot Max hardware elevator control | A PUDU-developed hardware option | The proposed hardware and its interface to that installation |
| Otis Integrated Dispatch API, cloud or local | A connection that can coordinate elevator groups and multiple robots | The actual API service, connection location and configured elevator bank |
The source descriptions do not provide enough installation detail to specify a retrofit kit for an arbitrary lift. A meaningful supplier proposal names the connection, the elevator bank and the party configuring each end. That turns “works with elevators” into an identifiable integration scope.
Separate the robot’s destination from the elevator’s dispatch job
Consider a hypothetical hotel delivery from a lobby to an upper-floor guest area. The robot’s task has an origin, a destination and a parcel compartment. The elevator system has to serve a request within the building’s lift traffic. These are linked jobs with different responsibilities.
The distinction explains why building integration belongs alongside mobile navigation. An AMR selection discussion can establish how a robot travels through corridors and responds to obstacles. An elevator interface establishes how that route crosses floors. Neither the width of a corridor nor the robot’s obstacle avoidance identifies which elevator-control connection is installed.
Delivery access remains a separate part of the handoff
The FlashBot Max page also describes IoT-linked calls and access through turnstiles, as well as compartment access by methods including password, phone and NFC. These are additional interfaces around the delivery. Elevator dispatch gets the robot between floors; compartment access determines how the recipient interacts with the carried item.
For a building demonstration, trace one actual proposed delivery across those interfaces: the selected corridor, the specific elevator bank, the destination access point and the recipient’s collection method. The result is a concrete workflow whose components can be assigned to the robot supplier, elevator provider and building operator, instead of a single cloud-integration label covering several different jobs.