First, understand the building
Before a robot begins a routine service, the proposed operating area needs a survey. Corridors that look similar on a plan can behave very differently during the working day. One may fill with waiting patients; another may carry beds between theatres and recovery. Flooring, thresholds, ramps, turning space and wireless coverage all affect feasibility. The useful map therefore combines physical measurements with knowledge from porters, facilities teams and clinical staff.
Mapping methods vary. Some systems use laser scanners to recognise surrounding geometry, while others combine cameras, wheel measurements and inertial sensors. Simultaneous localisation and mapping, commonly called SLAM, is one approach to building or maintaining a map while estimating position. It is not a promise that the machine understands a hospital like a person does. Glass, reflective surfaces, altered layouts and moving crowds can complicate sensing.
Position is an estimate, not certainty
Localisation compares sensor observations with a representation of the environment. The robot must manage uncertainty rather than assume its position is exact. If confidence becomes inadequate, the safe response may be to stop and request assistance. A repeated problem at one junction can indicate changed surroundings, poor map features or an unsuitable operating condition. It should not be treated simply as a staff training issue.
Navigation software may distinguish between a wider route plan and local obstacle avoidance. The route plan identifies a permitted path to the destination; local behaviour responds to nearby people and objects. ROS 2 and the Nav2 project are useful educational references for these concepts, although not every commercial platform uses them. A software architecture diagram also says little about the safety assurance of a finished product.
Doors need an agreed conversation
A machine can recognise that a door is closed without having permission or the means to open it. Automated access may require a tested interface with the door controller and access-control system. The design should establish who authorises the request, how the door’s state is confirmed and what the robot does if the opening is obstructed. Fire doors and secure boundaries need particular care; convenience must not defeat their protective role.
Staff should never have to prop open a controlled door to keep a routine delivery running. That workaround can undermine security, ventilation or fire arrangements. Facilities and security teams should review access privileges, operating hours and the consequences of system failure. The robot should have only the access needed for its approved service, with changes managed as carefully as changes to a staff access profile.
A lift is a shared resource
Lift use introduces another sequence of decisions: call, wait, identify the correct car, enter, travel and leave. A busy passenger lift may not provide enough space for a loaded robot and its required clearances. Rules need to cover people already inside, priority movements, door timing and communication failures. Lift integration must be approved with the responsible building and lift specialists, not improvised through repeated physical button pressing.
The EN 81 series provides an important standards context for lift safety, while the Lifting Operations and Lifting Equipment Regulations 1998, known as LOLER, are relevant to lifting equipment duties in Great Britain. Their precise application is for competent specialists to determine. An interface that successfully calls a lift in a demonstration is not evidence that the complete arrangement is acceptable for daily hospital use.
Design the interruption before launch
Routes change when construction starts, equipment is parked or an emergency movement takes priority. A fleet manager may offer an alternative route, but it must remain within approved boundaries. Staff need a clear way to report a blocked passage without becoming robot operators themselves. Temporary restrictions should have an owner and an expiry or review process, otherwise yesterday’s workaround can quietly become today’s unexplained behaviour.
Agree where a robot may wait, how long it may remain there and who receives a fault notification. Recovery instructions should distinguish a routine pause from a condition requiring isolation or technical assistance. Network connectivity requirements also need careful definition: some machines navigate locally during a connection loss, while other functions may become unavailable. Test the actual product and configuration rather than assuming that all autonomy depends on continuous remote control.
Finally, walk the route with people who use it at different times. Accessibility reviews should consider wheelchair users, assistance dogs, people with sight loss and anyone who needs extra time at a doorway. The Centre for Accessible Environments and the British Standards Institution offer relevant built-environment resources. The goal is not merely successful robot passage; it is a route that remains understandable and usable for everyone.