Cleaning, service & hospitality robots

Labour shortages and rising wage costs make repetitive indoor tasks in hotels, restaurants, hospitals, airports and shops hard to staff. Autonomous cleaning machines, serving/delivery robots and care-support carriers use onboard SLAM, obstacle detection and fleet software to do these tasks around people. Typical benefit: staff are freed from routine floor care and fetch-and-carry for guest- and patient-facing work, with documented cleaning proof.

Problem & value

• Today: floor scrubbing, vacuuming, plate/tray running and in-building delivery are manual, often at night or in peak hours, with high turnover and uneven quality.
• AI value: robots map a site once, plan coverage paths, avoid people and obstacles in real time and report what was cleaned or delivered. Vendors such as Brain Corp, Avidbots and Pudu publish customer case studies on hours of labour shifted; figures are vendor-reported and vary strongly by site, so pilot with your own baseline [1][2].
• Reality check: most commercial value today is in repetitive, structured tasks (scrubbing large floors, point-to-point delivery). Open-ended tasks such as clearing tables or making beds are still research or early pilots (see ROBO-004).

Variants

• Autonomous floor cleaning (scrubbers, sweepers, vacuums) for retail, airports, warehouses, offices.
• Hospitality: serving and runner robots in restaurants, room-delivery robots in hotels (elevator integration), reception/guide robots.
• Hospital logistics: delivery of linen, meals and lab samples; disinfection robots.
• Care & social assistive robots in nursing and elderly care: fetch-and-carry, night-round and telepresence robots are service robots in a care setting. Same navigation stack, plus stricter hygiene, privacy and, where a robot has a medical purpose, MDR considerations. Embodied conversation robots are covered in CONV-016, fall monitoring in HLTH-015.
• Private use: robot vacuums and mops (consumer; see ROBO-012 for smart-home context).

How it works

1. site mapping (SLAM, zones, no-go areas, elevator/door links)
2. task scheduling (cleaning plan, delivery request from app/POS/PMS)
3. localisation + path / coverage planning
4. perception (LiDAR + depth + camera: people, obstacles, cliffs, glass, spills)
5. local safe motion control (speed limits, stop/slow near people)
6. fleet management cloud (monitoring, reports, OTA updates)
7. human-in-the-loop: staff loads/empties, resolves stuck robots, reviews reports

• Perception: small CNN/transformer detectors on an embedded SoC classify people, doors, pets, wet floor; learned semantic maps label rooms and objects. Safety-rated stopping (bumpers, safety LiDAR) stays deterministic and is not delegated to a learned model.
• Planning: classical SLAM and coverage planning plus learned components; multi-robot fleets use task allocation (optimisation) and elevator/door orchestration over open interfaces (e.g. VDA 5050 or vendor APIs, MassRobotics/ROS 2 based tooling).
• Language layer: emerging voice/LLM front ends let staff command robots in natural language or let guide robots answer guests; keep it separate from motion safety.

Data preparation

This use case needs little classic data. What matters are site maps (floor plans, no-go zones, lift and door positions), cleaning schedules and task lists, and for integrations the room, order or ticket data from PMS, POS or CMMS. These often live in facility drawings, Excel schedules or paper checklists. Typical gaps are outdated floor plans, undocumented routes, inconsistent room numbers and unclear rules for where robots may drive and film.

Preparation steps: digitise floor plans and routes, fix room and location IDs (PREP-010), replace paper cleaning checklists with digital capture (PREP-008), export PMS or CMMS data via APIs (PREP-005) and define rules for camera data, including blurring or deleting footage (PREP-022, PREP-024). Most vendors map the building themselves in a day or two. Data preparation is a small share of the effort, typically below 15 percent; the main work is organisation and change.

Implementation paths

Which path for whom

• SMB (hotels, restaurants, shops, care homes): Path A, because robots-as-a-service with support and CE marking are mature; the only integrations are lifts, doors and maybe the POS.
• Enterprise (hotel chains, retail and facility-service groups): Path B, because many sites need fleet data, tickets and room or task systems (PMS, POS, CMMS) connected via vendor APIs.
• Public (hospitals, municipal buildings): Path A, because CE-marked, supported products fit procurement rules; check camera data handling and EU service partners.

Path A — Buy (recommended for SMBs)

• Cleaning: Brain Corp (BrainOS, fitted to scrubbers from several OEMs), Avidbots, Gausium (Gaussian Robotics), Nilfisk and Tennant autonomy offerings, Kärcher (DE) and Diversey autonomous machines; Tennant, Nilfisk (DK), Kärcher (DE) are EU-based or EU-present.
• Hospitality/service: Pudu Robotics, Bear Robotics (Servi), Keenon, Richtech; hotel delivery from Savioke/Relay Robotics; many are non-EU, so check EU support and data flows.
• Hospital/care logistics: Aethon (TUG), Swisslog Healthcare (CH/DE), Diligent Robotics (Moxi, US, pilots).
• Models: robots-as-a-service (RaaS) lease including support is common; choose A for almost every SMB. Verify CE marking, EU service partner, camera/data handling and elevator integration.

Path B — Build on cloud APIs

Rarely the core. Use cloud for fleet analytics, ticket integration (PMS/POS/CMMS), and optional VLM/LLM services (guest Q&A, anomaly photos) with EU-region endpoints. Integrate vendor fleet APIs via n8n or custom services (ROBO-002 pattern).

Path C — Self-host (open source)

• Stack: ROS 2 with Nav2 (navigation), SLAM Toolbox or RTAB-Map, Open-RMF (multi-vendor fleet, lift and door interoperability), micro-ROS for controllers [3][4].
• Perception: YOLO-class or RT-DETR detectors, Depth Anything-type depth models; NVIDIA Isaac ROS or similar on Jetson Orin (HW1).
• Effort: needs robotics engineers and a certified hardware base; sensible for OEMs, integrators and research, not for end-user SMBs.

Path D — Custom training

Only for OEMs: fine-tune detectors on site-specific classes (spills, chairs, wheelchairs, glass doors), or train learned navigation policies in simulation (ROBO-010). Needs thousands of annotated frames from the target environments; privacy filtering of recorded video is mandatory.

State of the art (2026)

• Commercial autonomy for floor cleaning and serving is mature; the competition is on price, battery/uptime, elevator interoperability and fleet analytics.
• Interoperability is improving (Open-RMF, VDA 5050 extensions), but multi-vendor fleets in one building still need integration work.
• Foundation-model features (language commands, open-vocabulary detection, VLM scene understanding) are arriving in guide and care robots, with manipulation (clearing tables, opening doors) still limited [ROBO-004].
• Failure modes: glass and mirrors, dark or reflective floors, crowds, children and wheelchair users, changed layouts, Wi-Fi/elevator outages, getting stuck. Social acceptance and staff workflow often decide success more than algorithms.

Shared resources & combinations

• Same navigation, fleet and elevator stack as ROBO-002 (AMRs) and ROBO-020 (sidewalk delivery).
• Safety perception patterns from ROBO-016; humanoid/VLA successors in ROBO-004.
• Conversation front ends: CONV-012 (hospitality concierge), CONV-016 (companion robots).
• Care setting: HLTH-015 (fall detection), ROBO-018 (exoskeletons for care work).

Effort, cost & KPIs

• Path A: days to weeks for mapping and rollout; cost drivers are lease/purchase, service contract, consumables and staff training.
• Path C/D: 6-18 months of robotics engineering; only for product builders.
• KPIs: area cleaned per shift, autonomy rate (interventions per 100 h), uptime, delivery success rate and time, guest/staff satisfaction, incidents and near-misses, cost per cleaned m2.

People & change

Management decides on budget and responsibility. The department lead (housekeeping, facility, nursing or service lead) is the process owner and defines routes, times and no-go zones. End users (cleaners, waiters, nurses) must be involved before the purchase, because the robot changes their daily work. IT handles Wi-Fi, lifts and integrations; the DPO checks the cameras; suppliers cover service and updates.

Works council: yes in practice. Robots with cameras, sensors and logs in workplaces are suited to monitor staff behaviour or performance, so §87(1) no. 6 BetrVG co-determination applies, and §90(1) no. 3 requires timely information about AI-planned work processes. Conclude a works agreement on camera use, data deletion and no performance evaluation of individuals (GUIDE-004). Public bodies involve the Personalrat.

Data protection: guests, patients and staff may be filmed; consult the DPO early, check the legal basis, deletion periods and the AVV with the vendor; a DPIA is likely in care and hospital settings (GUIDE-005). AI literacy: support staff with a short introduction (GUIDE-006). Start with one floor or area as a pilot, name robot champions and communicate that robots take over heavy, repetitive tasks so staff gain time for guests and care (GUIDE-008). Staff can pause or stop the robot at any time.

Risks, regulation & compliance

• Product safety: robots are machinery. The Machinery Directive 2006/42/EC applies until the Machinery Regulation (EU) 2023/1230 applies from 20 January 2027, which adds requirements for machinery with self-evolving behaviour and cybersecurity [5]. Cleaning machines fall under EN 60335-2-xx / industrial cleaner standards; mobile robots under ISO 3691-4 and ISO 13482 (personal care robots).
• EU AI Act: the robot is usually a product whose safety component may be AI-driven; under Art. 6(1) high-risk status (obligations for Annex I products from 2 Aug 2028 per the Digital Omnibus, Reg. (EU) 2026/1744) requires Annex I legislation with third-party conformity assessment, and the Machinery Regulation is listed there for safety components. Most cleaning/serving robots with conventional safety functions are therefore minimal risk in practice, but classification depends on design; check with the manufacturer [6]. Care robots with a medical purpose fall under the MDR and are typically high-risk. Art. 5: do not use cameras on service robots for emotion recognition of staff, or for biometric categorisation; emotion inference on employees is prohibited, and real-time remote biometric identification in public spaces is restricted. Transparency (Art. 50) applies to guest-facing chatbot/voice features.
• GDPR: onboard cameras and microphones capture guests, patients and employees. Do a DPIA for care and hospital settings, minimise recording (on-device processing, blurring, no audio storage by default), post visible notices, and agree a works-council arrangement for staff (Germany: BetrVG co-determination) [7].
• Other: liability and insurance, hygiene rules in hospitals, accessibility (blocked escape routes), cybersecurity of fleet clouds (Cyber Resilience Act for products with digital elements, phased from 2026-2027).
• Mitigations: safety-rated sensors, speed limits near people, staff training, incident log, EU data residency, tested emergency stop.

Getting started

1. Pick one structured task (e.g. nightly hall scrubbing or restaurant tray running) and baseline its labour hours.
2. Walk the site with 2-3 vendors, testing elevators, glass, carpets and peak-hour crowds.
3. Check CE declaration, EU service partner, data flows and camera settings; do the DPIA.
4. Involve staff and works council early; define who handles stuck robots.
5. Run a 4-8 week pilot with KPIs, then scale.

Sources

1. Brain Corp — autonomous cleaning robots — https://www.braincorp.com
2. Pudu Robotics — service robots — https://www.pudurobotics.com
3. Nav2 — ROS 2 navigation stack — https://docs.nav2.org
4. Open-RMF — robotics middleware framework — https://www.open-rmf.org
5. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
8. ISO 13482:2014 Personal care robots safety — https://www.iso.org/standard/53820.html