Cleaning robots, delivery bots and inspection drones are quietly becoming building occupants in their own right across Australian commercial precincts — with their own network requirements, their own charging infrastructure, and their own need to open doors and call lifts. Designers who treat this as a facilities-management procurement decision rather than an ELV design input are the ones whose buildings can't actually host the robot fleet arriving over the next lease cycle.
Wireless Coverage: Roaming Handoff Is the Real Spec, Not Signal Strength
Most autonomous mobile robots (AMRs) use SLAM (simultaneous localisation and mapping) for navigation, continuously comparing live lidar or camera data against a stored map to know their position. That process depends on an uninterrupted data link — if a robot loses WiFi mid-corridor while roaming between access points, its localisation can drift enough to trigger a safety stop. Standard enterprise WiFi, tuned for laptops and phones that tolerate a 200-400ms roaming gap, is often too slow for robot navigation, which typically needs handoff under 50ms. This requires deliberate controller-level tuning — aggressive roaming thresholds, 802.11r fast transition where supported — rather than assuming existing office WiFi will simply work for a robot fleet layered on afterward.
Lift Integration Is a Vendor-Specific Problem
Robots that need to travel between floors must call and ride lifts autonomously, and this integration is not standardised across the industry — Otis, KONE, Schindler and other OEMs each expose their own destination-dispatch API, and a robot fleet vendor's compatibility has to be confirmed against the specific lift OEM installed in a given Australian building, not assumed as a generic capability. This is worth resolving at design stage for any new precinct expecting robot traffic, since retrofitting lift-API integration after commissioning is materially more expensive than specifying it into the original lift package.
- Confirm lift OEM API compatibility with intended robot fleet vendors before lift package award, not after building handover.
- Reserve charging dock locations with dedicated power and, where the dock also serves as a WiFi anchor point, a wired network drop rather than relying on the dock's own wireless uplink.
- Coordinate door-hardware access credentials for robots through the same access-control head-end used for human staff, issued and revoked through the same governance process.
- Map robot travel paths against fire egress routes at design stage — a docked or slow-moving robot blocking a corridor during an evacuation is a life-safety issue, not just an operational inconvenience.
Design takeaway: A robot fleet is best treated as a new class of building occupant on the ELV design brief — with its own network, power, lift-access and door-hardware requirements — rather than a facilities-management purchase that's expected to bolt onto existing infrastructure without any coordination.
Safety Standards: ISO 3691-4 Is the Closest Fit, Not a Perfect One
ISO 3691-4 governs driverless industrial trucks and is the standard most Australian facilities managers currently reference for AMR safety in shared spaces — covering safety-rated obstacle detection, speed limiting near pedestrians, and emergency-stop behaviour. It was written primarily with industrial/warehouse environments in mind, so applying it to office-lobby or hospital-corridor robot deployments requires some judgement about which clauses genuinely transfer, and Australian facilities managers should expect to document this interpretation explicitly in the robot fleet's operating procedures rather than assume blanket compliance.
Frequently Asked Questions
Can a cleaning or delivery robot use a building's existing WiFi?
Only if roaming handoff between access points is fast enough. SLAM-based navigation robots need sub-50ms handoff to avoid losing localisation mid-corridor, which standard enterprise WiFi tuned for laptops and phones often doesn't deliver without specific roaming-aggressiveness configuration on the controller.
Do robots need their own lift access protocol?
Yes. Most robot fleets integrate with a lift's destination-dispatch system via a vendor-specific API (from Otis, KONE, Schindler or similar) rather than a universal open standard, which means lift-robot compatibility needs confirming per lift OEM at design stage, not assumed as a given.
What safety standard applies to autonomous mobile robots in Australian buildings?
ISO 3691-4 covers driverless industrial trucks and is the reference standard most Australian facilities managers apply to AMRs operating in shared pedestrian spaces, covering safety-rated obstacle detection and speed limiting, though it was written primarily for industrial rather than commercial-office environments.