🏬 Autonomous Mobile Robot Hospital Medication Delivery

Fleet Management — Assigning the Right Robot to the Right Delivery, in Real Time

Autonomous mobile robot (AMR) medication delivery begins in software, not hardware: a fleet management layer that treats every robot as a schedulable resource. When pharmacy releases a locked tote, the dispatch algorithm must weigh battery reserve, current task queue, unit priority, and physical proximity before committing a robot to the job — the same class of problem as ride-hailing dispatch, applied inside a building with elevators instead of streets.

• >140: US hospitals w/ AMR fleets (Aethon TUG deployments, 2024)
• 20–40: Deliveries per robot/day (typical 300+ bed hospital)
• <2 sec: Dispatch decision latency (fleet server task assignment)
• >97%: Fleet uptime target (SLA for clinical-critical routes)

Fleet management architecture and task-assignment algorithms

A hospital AMR deployment is coordinated by a central fleet management server — Aethon's TUG Central Server, Diligent Robotics' Moxi Fleet Manager, or Swisslog's ITS relay for automated material transport — running independently of any single robot's onboard controller:

Task ingestion: • Pharmacy dispensing system (or nursing unit via wall-mounted request panel) submits a delivery request: origin (pharmacy dock), destination (nursing unit bay), priority tier (STAT / routine / scheduled restock), payload type (locked drawer required for controlled substances vs. open tote for supplies) • Requests enter a priority queue; STAT medication requests (time-critical antibiotics, code-cart replenishment) preempt routine restock jobs

Robot assignment algorithm: • Candidate robots filtered by: battery state-of-charge (>25% reserve required to accept new multi-floor job), current task status (idle or nearing task completion), payload compatibility (locked-drawer-equipped units only for controlled substances) • Assignment cost function approximates: (estimated time-to-pickup) + (estimated delivery time) + (priority weighting), minimized across the idle/soon-idle candidate pool • Nearest-idle-robot heuristic augmented with a look-ahead: a robot 30 seconds from finishing its current job but much closer to pickup may beat a robot that is idle but far away

Network and communication layer: • Hospital Wi-Fi: dedicated VLAN segregated from clinical EHR traffic for security isolation, WPA2-Enterprise or WPA3-Enterprise authentication • Task push: MQTT or proprietary REST API from fleet server to robot onboard controller; robot acknowledges task acceptance and begins path planning • Continuous telemetry: battery %, location, task status streamed back to fleet server at 1–2Hz for dashboard visibility and re-routing decisions

Fleet sizing economics: • Typical mid-size hospital (300–500 beds): 3–8 robot fleet handles routine medication delivery, linen, and lab specimen transport combined • Each robot: capital cost $35,000–$100,000 depending on payload capacity and security features (locked-drawer models command premium) • ROI case built primarily on reduced nurse-runner time reallocated to direct patient care, not headcount reduction

SLAM Mapping — How a Hospital Robot Knows Exactly Where It Is

Before a robot can navigate a single corridor, it must solve simultaneous localization and mapping (SLAM): building a map of the environment while simultaneously tracking its own position within that map. Hospital deployments typically use a pre-built static map refined during a commissioning walk, then rely on real-time LiDAR scan-matching for millimeter-to-centimeter localization accuracy during live operation.

• 25–30m: LiDAR range (typical) (2D safety-rated scanner, SICK/Hokuyo)
• ±3–5cm: Localization accuracy (AMCL particle filter, steady state)
• 2–4 hrs: Map commissioning time (per floor, initial walk-through)
• Quarterly: Remap frequency (or after major renovation)

SLAM pipeline: mapping, localization, and landmark anchoring

Hospital AMR localization follows a two-phase approach distinct from fully online SLAM used in unmapped environments:

Phase 1 — Map building (commissioning): • A technician drives or walks the robot through every corridor, elevator lobby, and delivery bay on each floor during initial setup • 2D LiDAR (SICK S300, Hokuyo UST-10LX, or safety-rated equivalents required for people-sharing corridors — ISO 3691-4 mobile-robot safety standard) sweeps the environment at 270°–360° field of view • Graph-based SLAM (e.g., Cartographer, GMapping) fuses LiDAR scans with wheel odometry to build a 2D occupancy grid map: each cell marked free, occupied, or unknown • Resulting map resolution: typically 5cm/pixel grid; stored per-floor as the reference map for live operation

Phase 2 — Live localization (operation): • Adaptive Monte Carlo Localization (AMCL): particle filter maintains thousands of pose hypotheses, each weighted by how well a live LiDAR scan matches the stored map at that hypothesized pose • Steady-state localization accuracy: ±3–5cm position, ±1–2° heading under normal corridor conditions • Confidence/covariance metric exposed to the navigation stack — if particle spread grows (map mismatch, kidnapped-robot scenario from being manually relocated), robot drops to a conservative low-speed "relocalization" behavior

Landmark anchoring for drift correction: • Pure odometry drifts over distance (wheel slip, uneven flooring, elevator entry ramps) — SLAM corrects this by re-anchoring against fixed landmarks • Doorframes, wall corners, and distinctive corridor geometry serve as natural landmarks in LiDAR scan-matching • Supplemental fixed infrastructure: some deployments add passive RFID floor tags or QR fiducials at elevator lobbies and high-traffic junctions for high-confidence re-anchoring points, particularly where corridor geometry is repetitive (long parallel patient-room hallways with few distinguishing features)

Map maintenance: • Hospitals are dynamic environments: construction, furniture relocation, temporary equipment storage in corridors • Quarterly remap cycles (or triggered after known renovation) keep the static reference map current • Between remaps, the local costmap layer (Stage 3) handles transient obstacles the static map does not know about

Navigating Live Corridors — Global Planning Meets Real-Time Obstacle Avoidance

A hospital corridor is never empty: nurses, visitors, wheelchairs, IV poles, housekeeping carts, and other robots share the same 8-to-10-foot-wide space the robot must traverse. The navigation stack splits the problem into a global planner that finds an efficient route across the static map, and a local planner that continuously deforms that route in real time to flow around whatever is actually in front of the robot right now.

• 10 Hz: Local planning rate (costmap update + replan cycle)
• 0.9–1.3 m/s: Max corridor speed (reduced near people/junctions)
• 87°×58°: Depth camera FOV (Intel RealSense D435-class)
• <0.3m: Emergency stop distance (safety-rated LiDAR field)

Global vs. local planning and the obstacle-avoidance control loop

Global planner (A* / D* Lite / Dijkstra over the static occupancy grid): • Computes the shortest collision-free path across the full known map — pharmacy dock to nursing unit bay — ignoring dynamic obstacles not present in the static map • Re-invoked only when the robot deviates significantly from the planned route or when a persistent blockage (e.g., a corridor closed for cleaning) is manually flagged • Output: a sequence of waypoints spanning the route, including designated elevator staging points

Local planner (Dynamic Window Approach / Timed Elastic Band): • Operates on a rolling local costmap (typically a 4m×4m window centered on the robot) rebuilt at 10Hz from live LiDAR + depth-camera returns • Depth camera (Intel RealSense D435-class, 87°×58° FOV) adds obstacle detection below and above the 2D LiDAR plane — critical for catching low obstacles like IV pole wheels or a dropped object, and overhanging obstacles like a gurney IV pole • DWA evaluates a set of candidate velocity commands (linear + angular) each control cycle, scoring each for: obstacle clearance, progress toward the next waypoint, and trajectory smoothness — selecting the best-scoring command • Result: the robot appears to "flow" around a person walking toward it rather than stopping and waiting, unless the corridor is too narrow to pass safely

Speed modulation by context: • Open corridor, no obstacles: cruise speed 1.0–1.3 m/s • Person detected within 2m: speed reduced to <0.5 m/s • Elevator lobbies, blind corners, nurse station junctions: speed capped at 0.3–0.5 m/s regardless of detected obstacles (geofenced slow zones defined at map-commissioning time) • Safety-rated LiDAR maintains a protective field: any object within ~0.3m triggers immediate stop, independent of the planning stack — a hardware/firmware-level safety layer per ISO 3691-4 and ANSI/RIA R15.08 mobile robot safety standards

Multi-robot coordination: • Fleet server broadcasts each active robot's planned path segment to avoid two robots converging on the same narrow corridor or elevator simultaneously • Right-of-way rules: typically the robot further along its route, or the one carrying higher-priority (STAT) payload, receives priority; the yielding robot pulls into a designated waiting alcove

Crossing Floors — The Hardest Integration Problem in Hospital Robotics

Elevator integration is consistently cited by robotics vendors as the single most building-specific, hardest-to-standardize part of a multi-floor AMR deployment. Every building's elevator controller, door-timing behavior, and life-safety override logic differs — and the robot must interface with decades-old elevator control hardware never designed with robots in mind.

• 3 common: Integration methods (IO relay, BACnet/IP, dedicated API)
• 45–90 sec: Typical wait-to-board (peak-traffic elevator lobbies)
• Hard priority: Fire-service override (robot yields unconditionally)
• Growing trend: Dedicated robot elevator (new-build hospital design)

Elevator control integration methods and floor-transit protocol

Three integration approaches dominate current deployments, in ascending order of reliability and cost:

1. IO relay interface (legacy elevator retrofit): • A relay board wired directly into the elevator controller's existing car-call and floor-select circuitry, mimicking a person pressing buttons • Robot sends a digital signal to "call elevator to floor X," relay board triggers the physical button-press circuit • Cheapest, most compatible with old elevator systems, but offers no rich status feedback (robot cannot always confirm door state or car position with certainty) — increases reliance on onboard sensing (LiDAR door-gap detection) for safe boarding

2. BACnet/IP building-automation integration: • Modern elevator controllers (Otis Compass, KONE Polaris, Schindler PORT) expose building-automation-protocol endpoints • Robot fleet server communicates via BACnet/IP or a vendor REST API: request car, receive real-time car position/door-state feedback, confirm exclusive-use mode if supported • Some elevator vendors offer a formal "robot mode" — the car is taken out of normal passenger queue rotation for the robot's transit, then returned to service

3. Dedicated elevator interface hardware (Aethon TUG elevator board, Cyberdyne, Peerless-AV robot-elevator bridge): • Purpose-built controller board bridges the robot fleet protocol to the elevator OEM's control system, certified per elevator vendor for supported models • Provides the most reliable two-way handshake: robot requests car, receives confirmed arrival + door-open signal, boards, requests floor, receives confirmed floor-arrival + door-open before disembarking

Boarding protocol (regardless of integration method): • Robot navigates to a designated staging point in the elevator lobby, oriented to face the doors • On car-arrival + door-open signal, robot uses LiDAR to confirm the doorway is clear of people/obstacles before entering (never assumes the confirmed signal alone is sufficient — an occupied car requires the robot to wait) • Inside the car, robot holds a fixed position clear of the door-close sensor beam • On arrival at destination floor (confirmed via car-position feedback or a simple floor-count timer as fallback), robot exits only after independently confirming doors are fully open via LiDAR

Safety and priority overrides: • Fire-service recall mode: robot has zero override capability and must yield the car unconditionally — building fire-alarm systems and elevator fire-service operation always take absolute priority • A parallel best practice in new-build hospital design (seen in several 2022–2024 replacement hospital projects) is a dedicated service elevator reserved partially or fully for robot/logistics traffic, eliminating passenger-conflict entirely during peak hours

The Locked Drawer — Security, Authentication, and Closing the Delivery Loop

Delivering the medication tote to the right physical location means nothing without a secured, auditable handoff to an authorized recipient. The locked drawer and its authentication workflow is what distinguishes clinical-grade medication delivery robots (Aethon TUG with secure module, Diligent Moxi) from generic warehouse AMRs — controlled substances and patient-specific medications demand the same custody rigor as a human courier.

• Electromechanical: Drawer lock type (solenoid + position sensor)
• Badge RFID / PIN: Authentication method (staff-specific, not shared code)
• ~30–45 min: Nurse-runner time saved (per shift, per unit (published studies))
• Comparable or faster: Delivery time vs. runner (off-peak; runner faster peak-traffic)

Secure handoff protocol and comparative delivery-time performance

Arrival and staff notification: • Robot parks at a designated bay marker at the nursing station or medication room • Notification fan-out: audible chime at the robot, push notification to the unit's nursing dashboard/tablet app, and optionally a page to the specific nurse assigned to that delivery • Robot waits with a configurable timeout (typically 10–15 minutes) before escalating to a supervisor alert if unclaimed — relevant for controlled-substance totes that cannot simply be left unattended

Authentication and drawer release: • Staff member authenticates at the robot's onboard touchscreen or an integrated badge reader: RFID badge tap (same badge used for EHR/Pyxis/Omnicell login) or a personal PIN • System checks that the authenticating user matches the assigned recipient (specific nurse, or any authorized staff on that unit, depending on medication class and hospital policy) • On successful match, the electromechanical drawer lock (solenoid-actuated, with a position sensor confirming physical lock/unlock state — not just command-sent) releases; drawer position sensor also detects and logs when the drawer is physically opened and re-closed

Chain-of-custody audit record: • Each handoff logs: timestamp, authenticated user ID, drawer unlock event, drawer-open event, drawer-close event, and robot task-completion confirmation sent back to the fleet server and pharmacy system • For controlled substances, this record supplements (not replaces) the pharmacy's DEA-required perpetual inventory reconciliation — the robot provides transit custody evidence, the automated dispensing cabinet (Pyxis, Omnicell) at the point of use provides final withdrawal accountability • Failed/unclaimed deliveries auto-return to pharmacy after timeout, with the full unopened-drawer status logged

Comparative performance data (published hospital case studies, 2021–2024): • Nurse-runner baseline: a dedicated staff member walking medication totes floor-to-floor, typically 8–15 minutes per round-trip delivery depending on floor count and distance • AMR delivery: comparable or faster during off-peak hours (no waiting on a person to be available); can be slower during peak elevator-traffic periods where a human can take stairs or push through a crowd more nimbly than a robot yielding right-of-way • Net reported benefit is less about raw per-delivery speed and more about reallocating 30–45 minutes per shift of nurse-runner time back to direct patient care — the actual driver of most hospital ROI calculations for AMR programs

Diligent Robotics' Moxi robot, deployed across multiple US health systems since 2022, is designed specifically around the "invisible work" reallocation thesis: rather than replacing nurse-runners outright, it targets the estimated 30% of nursing time spent on non-patient-facing logistics tasks (fetching supplies, delivering lab specimens, medication totes), aiming to return that time to direct bedside care rather than headcount reduction.