Elevator integration middleware
The last disconnected system in your building
LiftLink lets robots call the elevator, align with the door, and ride in and out — across any elevator brand and any robot platform.
The part every robot vendor keeps rebuilding
OEM elevator APIs stop at the door
Elevator APIs call the car and open the door. Alignment, whether to push in, what to do when you miss it, and re-localizing on a new floor are all left for each robot vendor to solve.
Every vendor rebuilds the same thing
Without a shared middle layer, building owners who want several robot brands sharing the same elevators have no common way to manage it.
Hard to rehearse before go-live
The elevator is often the one system in a building that's still disconnected. Faults, crowding, and floor changes are hard to stage on site — they usually show up for the first time after launch.
How a robot rides the elevator on its own
From calling the car to walking out on the right floor — the full sequence has been verified across floors in simulation.
-
1
Align before calling
The robot moves to a fixed position in the elevator lobby before it requests a car, so it isn't scrambling to line up once the doors open.
-
2
Hold the door, check clear
Once the doors open, the robot holds them and confirms nobody is rushing in or out before it decides to proceed.
-
3
Enter on the door centerline
The robot drives straight in along the centerline of the door to avoid clipping the frame or threshold.
-
4
Select the floor automatically
Once inside, the robot presses the destination floor itself — no human needed.
-
5
Swap the map, then back out
On arrival, the robot switches to that floor's map first, then reverses out of the car, so it localizes to the floor it arrived at, not the one it left.
-
6
Reroute on a fault
If the assigned car is out of service, the robot automatically calls another car in the same bank, with no human intervention.
-
7
Re-call if it misses the ride
If it doesn't make the car, it doesn't wait in place — it immediately requests another one.
What you get
Robot-side ride SDK (ROS 2)
Calling, alignment, entry/exit, and fault rerouting packaged as a ROS 2 module that plugs into your existing navigation stack.
Elevator OEM API adapters
Adapters for elevator OEM APIs such as Otis and KONE, so you don't rewrite integration for every elevator brand.
Interface designed toward SS 713
Our interface is designed with Singapore's SS 713:2025 robot-elevator interface standard as the target; a full item-by-item gap check against the standard is still in progress (see Status below).
Simulation validation before go-live
Before touching a real site, the ride sequence runs through our simulation environment — calling, alignment, and fault rerouting included.
Site pack configuration
Elevators, floors, and skills live in site-pack data rather than code, so a new building is a configuration change, not a rewrite.
Who this is for
Robot manufacturers
Every vendor ends up rebuilding the same alignment, fault-rerouting, and re-localization logic from scratch.
Integrate the ROS 2 SDK once instead of re-solving it for every building and every elevator brand.
Building owners & hospital facilities teams
No common layer to manage multiple robot brands sharing the same elevators.
Subscribe per elevator or per building, not per robot — new robots join without renegotiating.
Elevator maintenance contractors
OEM APIs only call the car and open the door, with no ready-made module to resell as a value-added service.
Bundle elevator-robot integration into existing maintenance contracts as new recurring revenue.
We're not an OEM and we're not a hardware gateway
OEMs manage their own elevators. Robot vendors each rebuild their own integration. We're the layer in between.
Software-only, not a hardware gateway
Aethon proved a neutral integration layer has buyers — 1,000+ elevators by their own account — but it ships as a hardware gateway with proprietary certification. We're software-only, built to drop into a robot's existing navigation stack.
OEMs only manage their own elevators
Otis and KONE's service-robot elevator interfaces stop at calling the car and opening the door. The alignment, entry/exit, and fault handling on the robot side is exactly the gap we fill.
Strongest where it matters: ride reliability
We're not rebuilding elevator control — we're hardening the robot-side maneuvers: centerline entry, map-swap-then-reverse exit, and fault detection with rerouting, already validated across floors in simulation.
Site packs, not hardcoded logic
Elevator and floor definitions live in configuration data, not in code, so new sites are a config change, not a rewrite.
Pricing
Here's how the pricing is structured — actual quotes depend on site scale and scope.
Robot OEM license
Annual license per robot
- Robot-side ride SDK (ROS 2)
- Elevator OEM API adapters
- Pre-deployment simulation validation
Quoted per site and fleet size
Building subscription
Per elevator or per building, not per robot
- Shared elevator access for multiple robot brands
- New robots join without renegotiating
- Site pack setup and upkeep
Modeled on OEM elevator subscription pricing; quoted per site
Deployment project
First-site assessment and on-site validation
- Elevator interface site survey
- Real-world positioning calibration
- Fire-safety & liability scoping session
Quoted per site
Current status & validation roadmap
Verified
- Full ride sequence (align before calling, hold the door, centerline entry, select floor, map-swap exit, fault reroute, re-call) verified across floors in simulation
- Elevator integration logic shares the same decision layer and site-pack architecture that passes 435 automated tests, with 4 site packs built so far
In progress
- Roughly 20 cm of in-car positioning drift on real hardware; not yet validated or calibrated on a real elevator
- Cross-checking our interface item by item against the full text of Singapore's SS 713:2025 standard
Next
- Run one elevator end-to-end at a real site with a local maintenance contractor or partner building
- Scope fire-safety and liability responsibility with building stakeholders
- Check whether Taiwan has an equivalent local standard to SS 713
Frequently asked questions
Do we need to modify the elevator itself?
No elevator hardware changes are required. Our module runs on the robot side and calls the elevator OEM's existing control API (e.g. Otis, KONE) for functions like calling the car and opening doors, provided the building's elevator exposes one — whether it does gets confirmed during the pre-deployment site assessment.
What about older elevators with no exposed API?
We don't have a fixed answer yet for elevators with no exposed interface at all — this gets confirmed during the pre-deployment site assessment.
How do fire-safety and liability responsibilities get split?
This is on our roadmap to resolve and isn't answered yet — we work it out with the building owner and maintenance contractor during deployment planning.
How do you handle real-world positioning drift?
We know real hardware drifts roughly 20 cm inside the car, and we have not yet validated or calibrated this on a real elevator. It is the first item in any pre-deployment validation. See Status above for where that stands.
Can it support multiple robot brands at once?
Yes — that's the core problem we solve. OEM elevator APIs only call the car and open the door; our middle layer lets different robot brands share the same ride sequence, which is also why the building subscription isn't priced per robot.
How long does a building deployment take?
We haven't yet run a full deployment at a real site end-to-end, so we can't give a fixed timeline until we scope the first site together.
Book a 30-min walkthrough
Whether you're a robot manufacturer, a building owner, or an elevator maintenance contractor, tell us about your site and we'll set up 30 minutes to walk through how this fits.