Chapter 7: AMRs and Service Robots — Leaders in Scaling

Overview

The question in this chapter is not “who has sent out the most robots?” It is: How does the capability of one mobile robot become a repeatable service operated by tens or hundreds of machines? Warehouse AMRs, factory-logistics vehicles, food-delivery robots, and floor cleaners differ in form and task. All must receive work, reserve routes and shared resources, charge, recover from faults, and return a trustworthy result to an existing business system.

The thesis is that scaling AMRs and service robots is an operations and recurring-economics problem, not a robot-count contest. Shipment is evidence of market entry, but it is not active fleet, task utilization, customer repurchase, software subscription, or maintenance revenue. A single robot's maximum speed does not guarantee system throughput in a congested aisle. Value moves toward fleet orchestration, WMS and MES integration, charging, maintenance, field service, and contract design.

SEER Robotics, Geek+, and Pudu Robotics are the three locked deep profiles for this chapter ^{[1] [6] [10]}. SEER represents a controller and integrator ecosystem. Geek+ represents warehouse fulfillment backed by exchange filings. Pudu spans delivery, cleaning, hospitality, and industrial transport. The selection is not an absolute ranking; it is a comparison of different scaling paths under one evidence discipline.

After reading this chapter... - You can distinguish production capacity, shipment, installation, active fleet, order, revenue, subscription, and utilization. - You can explain how a robot management system, warehouse execution system, WMS, MES, and ERP divide responsibility. - You can compare SEER, Geek+, and Pudu across the same product, technology, finance, traction, maturity, and developer fields. - You can model how charging, traffic, recovery, maintenance, and field service change throughput and recurring economics. - You can design a line-side logistics pilot with a task schema, unified log, KPIs, safety boundaries, and ownership.

7.1 The Unit of Scale Is a Completed Order

An AMR needs localization, mapping, route planning, obstacle detection, and drive control. A service robot adds interaction with people and building resources such as doors, elevators, rooms, and tables. Cleaning adds coverage and consumables; hospitals add chain of custody and privacy. The buyer nevertheless purchases neither SLAM nor “autonomy” in isolation. It purchases transport, picking, delivery, cleaning, or collection completed within a service window.

The denominator therefore needs to move from robot units to orders. One robot completing 100 missions per day does not imply that twenty robots complete 2,000. Intersections, charger queues, elevators, human handoffs, picking stations, and empty destinations are shared resources. Beyond some fleet size, another vehicle can reduce total throughput by adding congestion.

Utilization is not simply the percentage of time that power is on. Productive travel, load transfer, work waiting, traffic waiting, charging, fault, planned maintenance, and human intervention need separate states. High travel utilization can be wasteful if vehicles run empty. Lower utilization can be rational reserve capacity for peak orders. Utilization only has meaning next to service level and order completion.

The correct unit can vary by sector. Warehouse automation may use an accurate order line completed before cutoff. Factory logistics may use the correct lot delivered in production sequence. Cleaning may use a zone that passes inspection. Hospitality may use a secure handoff to the intended guest. A robot movement is an intermediate event, not the final unit of value.

7.2 Fleet Orchestration Is More Than Traffic Software

A robot management system (RMS) assigns missions, prevents route conflict, and observes battery and fault state. At scale it needs more than shortest paths. It decides which order is urgent, which vehicle has the correct top module, when a charger should remain available, and how elevators, doors, stations, and aisles are reserved.

Fleet value depends on charging, traffic, recovery, WMS and MES integration, utilization, and service operations ^{[3] [15] [16]}. AutoRT organized task proposal, safety filtering, low-level skills, and human supervision across many robots and months. BUMBLE combined a map, skill library, memory, and requests for human help in building-scale missions, yet its full-task success remained below one half. Neither paper proves commercial AMR performance. Both show why long missions depend on the product of skill reliabilities and the ability to recover operationally.

Fleet decisions occupy different time scales. Drive control runs in milliseconds, obstacle response in seconds, missions and charging over minutes, demand waves over hours or days, and maintenance and software release over weeks or months. Centralizing every instantaneous velocity creates network dependence. Letting each robot make every decision independently creates traffic and reservation conflict. Local safety and motion authority must be separated from central mission and shared-resource authority.

A good scheduler may intentionally choose a longer route to keep a critical intersection free. It may charge a vehicle earlier because the next job is heavy. It may preserve one vehicle as reserve rather than maximize instantaneous use. These decisions reveal why a fleet KPI cannot be reconstructed from a robot data sheet.

7.3 Deep Profile I — SEER Robotics

The Korean rendering is 시어 로보틱스, the English brand is SEER Robotics, and the Chinese brand is 仙工智能. The official legal name is 上海仙工智能科技股份有限公司. Official company material reports a 2020 foundation, a Shanghai headquarters, and several regional entities ^[17]. The complete role of every subsidiary is not resolved by the captured evidence.

Flagships include SRC mobile-robot controllers, lifting AMRs and autonomous forklifts, the RDS robot management system, the M4 smart logistics management system, and deployment and visualization tools ^{[1] [3]}. The distinctive model is not limited to selling a finished vehicle. Integrators and robot manufacturers can use controllers and software to assemble fleets with multiple physical forms.

SEER's official product sources establish controllers, AMRs, RDS, and M4 fleet software, but they do not provide a matched comparative throughput benchmark ^{[1] [3]}. Maximum localization accuracy and country, customer, or partner counts in official introductions remain issuer claims. They do not establish superior order throughput without an independent test that matches pallet, aisle, human traffic, fleet size, charging policy, and demand distribution.

The technology position places the “robot brain” in the controller and orchestration platform. RDS manages dispatch and traffic. M4 presents orders, sites, and equipment across a broader logistics layer. Official technical material describes open APIs, Python low-code scripts, WMS and MES integration, automatic charging, and mixed-model scheduling ^[4]. An open API claim is not the same as a complete protocol specification, stable compatibility, exposed safety authority, or full function across third-party vehicles.

The publicly verifiable developer surface is at the controller and fleet level: APIs, deployment tools, and integrator documentation. Supported official ROS or ROS 2 packages, distributions, maintenance periods, and validated NVIDIA Isaac Sim or Isaac Lab assets are unverified in the captured evidence. A general reference to a “ROS core” should not be upgraded into package compatibility. Deployment diligence needs API versioning, timing, authentication, offline behavior, fault codes, upgrade, and rollback policy.

Finance and traction require separation between issuer and exchange evidence. An official introduction names investors and claims more than 1,300 integrator or robot-manufacturer partners, more than 2,500 industry partners and customers, and coverage in more than 65 countries and regions ^[2]. SEER began trading on the Hong Kong Stock Exchange Main Board under 06106.HK on June 24, 2026. Its HKEX prospectus reports 2025 revenue of RMB441.877 million, annual loss of RMB47.066 million, adjusted net loss of RMB2.865 million, and operating cash outflow of RMB27.798 million. The 2025 mix was RMB299.911 million from robots, RMB85.165 million from controllers, RMB23.414 million from software, and RMB33.387 million from accessories; software was generally licensed as a one-off transaction. Audited revenue and loss are therefore available, while active installations, renewal, and recurring revenue remain unverified ^[5].

Maturity is assessed as a commercial industrial platform with controllers, standard vehicles, fleet and logistics software, and integration partners. Its strength is a software-centered attempt to connect different vehicle forms and suppliers. Its limit is the absence of public independent denominators for order throughput, utilization, failure, maintenance cost, and customer renewal.

An official photograph is most useful when it shows different SRC-powered AMR forms and an RDS operational screen in one scene. The official application montage below shows several physical extensions of the AMB chassis, but it cannot establish mixed-fleet deadlock handling, fault recovery, or utilization.

7.4 Deep Profile II — Geek+

The Korean rendering is 긱플러스, the English brand is Geek+, and the Chinese brand is 极智嘉. The filing entity is 北京極智嘉科技股份有限公司. Its annual-results announcement states that it was incorporated in China on February 3, 2015 and listed on the Hong Kong Stock Exchange Main Board on July 9, 2025 ^[7]. Official company material identifies Beijing as headquarters ^[8].

Flagship solutions include P-series shelf-to-person robots, RS tote and high-bay systems, X pallet handling, M transport, S sorting, F autonomous forklifts, and robot-arm picking stations ^[6]. Software centers on WES, RMS, IOP, G-Studio, and the system portal, joining warehouse design, order execution, fleet control, and operations data. The official portal describes connections to WMS, ERP, and MES through open interfaces.

Geek+ reports RMB4.137 billion in new signed orders for 2025 ^[7]. The same filing reports 31.7% year-on-year growth and nearly 80% of orders from outside Chinese Mainland. Signed orders are not recognized revenue. Delivery, acceptance, cancellation, accounting, and collection occur on different schedules, so the order value must not be presented as revenue or cash.

The exchange filing provides stronger accounting denominators. For 2025 it reports RMB3.171 billion revenue, RMB1.125037 billion gross profit, RMB10.407 million loss for the year, RMB43.822 million adjusted net profit, and RMB85.7 million net operating cash inflow ^[7]. Adjusted net profit is a non-IFRS measure and should not be confused with statutory annual profit or loss. These are the strongest financial disclosures among the three profiles, but they do not establish ROI at an individual site.

Field traction must keep the filing's units. As of the end of 2025, Geek+ reports about 950 end customers, more than 72,000 robots shipped to more than 40 countries and regions, and an approximately 78% customer repurchase rate ^[7]. The definition and period of repurchase must travel with the metric. None of these numbers is automatically the active fleet, software-seat count, or utilization by site. Shipment scale is strong commercialization evidence, while operations quality remains a separate question.

Geek+'s technical strength is joining warehouse workflows and robot forms in an execution layer. RMS manages robots and traffic, WES handles order and task logic, and IOP supports alerts and operational data ^[9]. In shelf-to-person operation, a WMS or WES order enters, RMS assigns a vehicle to move the shelf, an operator confirms a pick, and inventory state changes. Throughput depends on workstation balance, SKU placement, and human pick rate as much as vehicle speed.

The developer ecosystem includes official claims for ERP, WMS, and MES integration, REST APIs, webhooks, multiple languages, and cloud or on-premises deployment ^{[6] [9]}. Official public ROS or ROS 2 packages and NVIDIA Isaac Sim or Isaac Lab support are unverified. In warehouse operations, order semantics, inventory consistency, recovery behavior, interface SLA, and data ownership can be more direct procurement concerns than public ROS access.

Recurring economics have both a signal and a gap. The 2025 filing says growth in subscription-based service orders exceeded 90% ^[7]. It does not separately disclose absolute subscription order value, recognized recurring revenue, gross margin, renewal, or recurring revenue per customer. A large growth rate can start from a small base. The evidence supports a direction toward recurring service, not a complete subscription-business conclusion.

An official photograph is most useful when it shows a full shelf-to-person system with shelves, workstations, several vehicles, and an operational screen rather than one P-series robot. The K&V Elektro case photograph below provides physical context for an AMR traveling beneath warehouse shelving, but it cannot prove peak throughput or the definition behind a repurchase rate.

7.5 Deep Profile III — Pudu Robotics

The Korean rendering is 푸두 로보틱스, the English brand is Pudu Robotics, and the Chinese brand is 普渡机器人. An official notice names the Chinese entity 深圳市普渡科技股份有限公司. The company history records a 2016 foundation in Shenzhen and identifies Shenzhen as global headquarters ^[11]. Hong Kong is an R&D and international-operations center, while other subsidiaries and factories exist. The complete holding structure remains partially verified.

The portfolio spans four operating categories. BellaBot, PuduBot, and HolaBot support food service and indoor delivery. FlashBot targets multi-floor hotel, hospital, and office delivery. CC1, MT1, and SH1 cover commercial cleaning. T300 and T600 target industrial transport ^[10]. Official product pages list issuer payloads of 300 kg for T300 and 600 kg for T600. Floor, slope, speed, stopping distance, and carrier conditions must accompany acceptance.

Pudu reported more than 90,000 cumulative shipped units as of March 2025 in an official product brochure ^[12]. Shipment does not establish active fleet or recurring revenue. It may include channel inventory, units no longer operating, or replacements at the same customer. A later official company page claims more than 130,000 shipments, but because its cutoff and independent audit are not fixed in the same way, this chapter does not calculate a growth rate between the two figures ^[11].

The technology position reuses navigation, multi-robot scheduling, cloud services, and interaction across delivery, cleaning, and industrial transport. Route planning is only part of service. Restaurant POS and table identity, hotel PMS and rooms, hospital HIS or LIS and chain of custody, cleaning zones and inspection, and factory MES material orders define the mission's business meaning.

PUDU Open Platform separates cloud APIs, private-cloud APIs, and a robot-side OS SDK and says that delivery, cleaning, and industrial robots share interfaces ^[13]. Official documentation provides examples in Go, Java, JavaScript, Python, and C#, plus task, status, and alarm callbacks. Access is oriented toward approved dealers and self-operated customers rather than an unrestricted public endpoint. Official ROS or ROS 2 packages and NVIDIA Isaac assets are unverified.

Building integration illustrates the operating stack. FlashBot can connect to elevators, doors, and gates through cloud or hardware routes, and official cases describe multi-floor hotel and hospital delivery ^[14]. The cases establish possible integration paths. They do not guarantee identical behavior across every elevator, network, fire code, or hospital security policy. A cited forty-robot hospital deployment is an issuer case, not an independently audited service-level result.

For finance and traction, the official history claims nearly US$150 million of financing in 2026 and a valuation above US$1.5 billion ^[11]. These are issuer disclosures rather than exchange-filed audited financials. Revenue, gross margin, profitability, rental and subscription mix, recurring maintenance revenue, and customer renewal are undisclosed. A large shipment base does not identify the split between one-time hardware and recurring service.

Maturity is a stage with commercial products across several service domains, a global service surface, an open platform, and large issuer shipment claims. Strength lies in product breadth and productized building integration. The limitation is that breadth across channels and regions can make service quality, activation, battery replacement, spare parts, and contract renewal hard to observe publicly.

An official photograph is more useful when it places the robot in a real service handoff rather than showing an isolated beauty shot. The El Portón case photograph below shows food being loaded onto a physical BellaBot, but it cannot reveal human reset count or daily utilization.

7.6 Three Scaling Models Under the Same Operating Questions

SEER, Geek+, and Pudu overlap in mobile robotics but capture value at different points. SEER supplies controllers and software to integrators and manufacturers so multiple forms can be connected. Geek+ scales warehouse workflows, vehicles, and systems as fulfillment projects. Pudu distributes standardized service-robot families and cloud or building integrations across many sectors and regions.

“Leader” cannot be resolved by one unit count. A controller platform can sit inside partner vehicles without counting each as a direct shipment. A warehouse-system provider can capture value in software and integration rather than the vehicle alone. A service-robot supplier can have broad distribution while low hardware price, replacement cycles, and regional support cost constrain recurring economics.

The correct comparison begins with a buyer's bottleneck. A factory with many integrators may prioritize interoperability. A large fulfillment center may need mature order execution and peak-throughput design. A hotel group may prioritize elevator integration and a regional field-service network. The strongest company-level disclosure may still be irrelevant if it does not address the intended task.

7.7 WMS, MES, and Building Systems Define Mission Meaning

A warehouse management system (WMS) owns inventory location, orders, lots, and priority. A warehouse execution system (WES) decomposes demand into picking, replenishment, sorting, and workstation activity. RMS turns those activities into vehicle missions and manages traffic. In a factory, MES knows production orders, process state, and material consumption, while ERP handles higher-level planning, purchasing, and finance.

An interface failure can turn physically successful motion into a business failure. A robot can place the right pallet at the right location, yet if WMS state does not update, the next order requests it again. A network retry can duplicate a task. A vehicle can arrive while the machine is not ready and block an aisle because the handoff condition was never modeled.

The integration contract needs idempotency, ordering, timeout, retry, cancellation, and partial completion. When “create task” times out, creating a new ID versus querying the existing ID has different consequences. Business locations also need separation from map coordinates. Shelf A-17 is an operational identity; it should not be permanently equated with one map point.

Service robots extend the contract into buildings. Hotel PMS owns rooms and occupancy. Hospital HIS or LIS owns authorization and specimen information. POS owns order and table identity. Cleaning management owns zones and quality. An elevator or door API requires access control, fire mode, human priority, timeout, and a safe waiting position—not just a virtual button press.

An “open API” should be evaluated with a fault-injection script. Disconnect the network after task creation, send duplicate callbacks, move a destination, and reboot a vehicle with a load. The answer is not in endpoint count but in whether the physical and digital states reconcile without losing custody.

7.8 Utilization, Charging, and Maintenance Are Hidden Fleet Capacity

Theoretical fleet capacity is not robot count multiplied by speed. Demand timing, overlapping paths, loading time, charging policy, and workstation ability jointly constrain it. Maximizing average utilization can remove reserve for peak orders and make many batteries reach low state together. The target is minimum total cost while meeting service level, not maximum motion.

Charging policy changes the entire flow. Opportunity charging uses short idle windows but can add charger travel and queues. Deep charging removes a vehicle for longer but simplifies the cycle. Swappable batteries can increase machine availability while adding human work, inventory, fire safety, and state tracking. Temperature, age, load, and floor conditions change usable energy.

Maintenance includes more than post-fault repair. It covers wheels, brushes, lidar and camera contamination, bumpers, lift chains, forks, batteries, networks, map change, and software versions. Cleaning robots add water, detergent, wastewater, and brush handling. Food-delivery robots add hygiene and tray damage. Hospital robots add disinfection, locks, and chain-of-custody checks.

MTBF and MTTR require fixed definitions. Does a wheel replacement count as a failure? Is remote restart a repair? Do parts waiting and customer approval belong inside restoration time? A vehicle can have strong mechanical MTBF while one software deployment stops an entire fleet. System availability needs common-cause failures and recovery drills.

Maintenance data should link serial number, component lot, firmware, site, task mix, temperature, and fault code. Otherwise a fleet operator cannot distinguish one bad part batch from a layout problem or a software regression. Predictive maintenance is useful only if the intervention costs less than the avoided failure and does not create excessive planned downtime.

7.9 Recurring Economics: What Remains After the Hardware Sale?

Recurring economics cannot be inferred from a subscription price page. Software licenses, orchestration seats, cloud usage, remote monitoring, maintenance contracts, spares, batteries, cleaning consumables, field service, and outcome-based pricing may all recur. Conversely, warranty work and field incidents can make service cost grow with shipment faster than service revenue.

Customers also face recurring cost. They maintain networks, servers, interfaces, maps, batteries, consumables, safety inspection, training, and regression tests. Rental or robotics-as-a-service can lower upfront cost, but minimum term, usage, SLA, data rights, early termination, and asset retrieval become central.

Three questions test supplier recurrence. What is the absolute recurring revenue and its share of total revenue? Do customers renew and expand? What field-service and cloud costs are needed to produce that revenue? Subscription order growth alone cannot answer them.

Geek+ provides clues through repurchase and subscription-based order growth. SEER presents a platform and integrator ecosystem. Pudu presents an open platform and global service surface. There is no public matched table for recurring revenue across the three. Leaving that comparison unresolved is more useful than inventing a ratio.

7.10 Evidence Ladder: Issuer Claims and Independent Operations

An official product page is primary evidence for product names, features, interfaces, and issuer specifications. An exchange filing adds responsibility for legal entity, reporting period, and accounting figures. A customer case can establish one configuration but has positive-case selection. A research paper gives methods and experimental denominators but usually not commercial maintenance or profitability. Independent operations data is valuable only when site and task conditions match.

Units must be aligned even before evidence tiers. Geek+ signed orders and revenue, Pudu shipments, and SEER partners and customers cannot share one ranking bar. A market-share number from an outside analyst still needs a denominator: revenue, shipment, installation, or one product category. When a filing cites an analyst, the filing does not automatically validate the analyst's category design.

Demonstration video is useful for discovering routes, obstacle behavior, elevator interaction, or cleaning coverage. Without total attempts, reset, remote operation, battery, and network conditions, it is not uptime evidence. A “24/7” description also differs from measured continuous service after charging, planned maintenance, consumable change, and fault recovery.

The strongest procurement evidence is often a buyer-owned pilot with raw logs. It can hold task distribution, layout, operating hours, staffing, and acceptance constant. Company-level scale helps assess supply and support risk, but it cannot replace the local denominator.

7.11 Manufacturing Walkthrough — Line-Side Kit Replenishment

Consider an electronics factory where kit boxes move from a materials supermarket to several assembly lines and empty containers return. Workers and manual forklifts share aisles during demand peaks. Production sequence changes, and some boxes are heavy. The objective is not visible AMR motion. It is the correct kit arriving before its deadline while empty-container and inventory records stay consistent.

Step 1: Fix order semantics. MES production orders and WMS inventory create a transport ID, kit and lot, quantity, origin and destination, deadline, priority, and handoff confirmation. Define cancellation and replacement for a quality hold or sequence change. Keep map coordinates versioned separately from business location identity.

Step 2: Measure the baseline. Record completed manual-cart or forklift orders per hour, labor minutes, travel, waiting, misdelivery, damage, and safety incidents. Preserve distributions by shift and peak window, not only the mean. The robot pilot's ROI must compare the same order population.

Step 3: Select vehicle and carrier. Use box dimensions and mass, pallets, conveyor height, aisle width, slope, floor joints, and turning space to select a lifting AMR or autonomous forklift. A SEER approach places diligence on controller and integrator ownership. A Geek+ approach includes the warehouse workflow and software. A Pudu T-series approach emphasizes the standard industrial product and service boundary.

Step 4: Connect orchestration and business systems. WMS or MES creates demand, a WES or logistics layer coordinates order and stations, and RMS assigns vehicle and path. Give every message a unique ID and explicit state transition. Inject a network timeout and verify that the systems reconcile without duplicate transport.

Step 5: Design traffic and safety. Map people, manual forklifts, doors, intersections, fire routes, and blind corners. Set one-way zones, priority, no-passing rules, speed zones, and safe waiting poses. Local safety sensors must stop during central failure. Orchestration must reroute or isolate a stopped vehicle before it creates deadlock.

Step 6: Simulate charging and reserve. Use demand waves, loaded energy, charger location and count, and battery aging to size the fleet. Test a synchronized low-battery case that creates a charger queue. A reserve vehicle can be capacity for SLA and maintenance rather than waste.

Step 7: Inject recovery faults. Skew a pallet, occupy the destination, close a door, disconnect one vehicle, and fail a charger. Before towing a loaded vehicle, transfer location, custody, and task ownership explicitly. Confirm that a substitute does not duplicate the original order.

Step 8: Operate maintenance and change. Inspect sensors, wheels, forks, and battery; plan periodic work and spares. Attach map, orchestration, vehicle firmware, and WMS interface versions to one execution ID. Canary a software update to part of the fleet, run regression tests, expand, and measure rollback.

Step 9: Convert pilot to production acceptance. Across shifts and peak demand, measure on-time completion, wrong delivery, damage, line starvation, utilization by state, traffic and charger wait, intervention-free time, automatic recovery, human minutes, and MTTR. Include resident supplier labor and manual data correction in cost.

Step 10: Decide expansion and contract. Before doubling fleet size, simulate aisle and workstation bottlenecks and reproduce the interface in a second zone. Contract definitions should include active vehicle, service window, parts lead time, security patching, data ownership, software renewal, performance shortfall, and termination.

Manufacturing Cell Checkpoint

The task schema needs order ID, item, lot, quantity, origin, destination, due time, priority, carrier, vehicle requirement, handoff owner, and cancellation and recovery authority. Missing one can allow a physically correct movement to complete the wrong business task.

Logs should connect WMS and MES state, orchestration assignment, map and route, vehicle pose, speed and battery, safety stops, doors, chargers and station reservations, load detection, errors, retries, and human interventions under one execution ID. Clock and software versions are necessary to reconstruct faults.

KPIs include the correct order completed on time, logistics good moves per hour, wrong or damaged delivery, line starvation, productive and empty travel, traffic, work and charge wait, uninterrupted run, automatic recovery, human minutes, MTTR, and total cost per task. Inspect peaks and worst routes, not only averages.

Ownership spans production, logistics, safety, IT and security, facilities, and supplier or integrator. Production owns material and sequence. Logistics owns missions and aisles. Safety owns hazards and stops. IT owns interfaces, network, and versions. Facilities owns doors and charging. The vendor owns contracted vehicle, software, parts, and recovery. Cross-boundary incident authority must be named before operation.

7.12 Scaling Beyond Logistics: Cleaning, Delivery, Hospitals, Hospitality

Warehouses have relatively structured orders and inventory. Cleaning, restaurants, hotels, and hospitals add unpredictable people, quality, and experience. They may reuse navigation technology, but their success definitions differ enough that warehouse throughput cannot be transferred directly.

Commercial cleaning is about quality, not area alone. In addition to square meters, water, power, and charge, measure missed zones, edges, stain rework, wastewater handling, brush replacement, and human time spent moving chairs and waste. A robot may cover 95% of a map while a person cleans the most difficult remaining 5%, leaving little labor reduction.

Restaurant delivery depends on table turns and staff flow. A person loads at the kitchen and a guest or employee unloads at the table. Congested aisles add experience, sound, hygiene, and hot-food safety. Robot travel can fall while handoff waiting rises, producing no improvement in total service time.

Hotel delivery links room authorization, doors, elevators, phone or app notification, and front-desk work. Multi-floor success is an elevator-priority and security problem as well as a mapping problem. Fire mode or a full car needs safe waiting and human transfer.

Hospitals require stronger traceability and infection control. Specimens, medicines, or surgical supplies may need locking, identity, temperature, and custody records. Patient priority, elevators, wireless shadows, disinfection, and privacy matter. “Deployed in a hospital” does not establish clinical labor savings or lower error.

This diversity helps explain Pudu's product breadth and the narrower industrial focus of SEER and Geek+. It also prevents a single “missions per day” number from comparing fundamentally different value units.

7.13 Limitations and Open Questions

First, disclosure is unequal. Geek+ provides exchange-filed accounting and some operating metrics. SEER and Pudu are represented mainly by official product and company sources. This difference changes evidence confidence and diligence questions; it is not an automatic ranking of company quality. Undisclosed does not mean zero.

Second, issuer scale uses different units. Partners and customers, shipment, signed orders, recognized revenue, country coverage, and repurchase cannot share a column. Maximum payload or localization accuracy also does not establish field throughput or independent uptime. Each figure retains its date, model, reporting period, and issuer qualification.

Third, core recurring-economics values are absent. SEER's software and ecosystem revenue structure, the absolute amount, margin, and renewal of Geek+ subscription service, and Pudu's rental, subscription, and maintenance mix cannot be compared publicly. Warranty and field support cost can grow with shipment, so service cost is needed beside recurring revenue.

Fourth, matched independent operations data is scarce. No source tests all three with the same demand, layout, fleet size, charge policy, and human traffic. Official customer cases and videos demonstrate possibility but cannot remove selection and hidden-intervention bias. A buyer should make its own pilot event log the strongest comparative evidence.

Fifth, media-corpus visibility is unmeasured and WRC 2026 status is company-specific. Without a complete eligible-article universe and deduplication rule, this chapter does not invent article counts or share. The organizer directory verifies SEER at C233 and PUDU at A217, while Geek+ remains unverified; none of these records verifies program participation or performance.

Three questions remain open. Do heterogeneous-fleet APIs reduce vendor lock-in, or do advanced functions return to proprietary routes? How are fleet-data ownership and the benefits of model improvement divided between customer and supplier? In a service contract under low utilization, who carries residual hardware value and field-support risk? Contracts and long-term cohorts, not demonstrations, must answer them.

Relation to Prior Surveys

This chapter extends lessons from mobile manipulation and multi-robot research into commercial operations. AutoRT's multi-robot data collection demonstrates the need to organize supervision, filters, task proposals, and intervention ^[15]. BUMBLE exposes the gap between subtask and full-mission success in a building ^[16]. Neither proves these companies' deployment, finance, or SLA. Here, their structures become procurement questions about fleet operation.

What to Learn Next

AMRs and service robots carry objects, but hands and grippers determine the quality of final contact. Chapter 8 examines grippers, multi-finger hands, force sensors, and touch: how they change slip, regrasp, insertion, damage, and safety. A fleet can bring the right component to the right place and still stop if the hand cannot grasp it or sense contact.

Carry Chapter 7's operational view forward. Do not evaluate a hand only by degrees of freedom or sensor resolution. Examine replacement time, durability, contamination, cables, calibration, consumables, recovery, and cost per task. Chapter 8 asks when the contact-intelligence supply chain becomes a repeatable manipulation service rather than an impressive hardware specification.

References

1. SEER Robotics (2026a). SEER Robotics Official Product Portal. Official company and product source.
2. SEER Robotics (2026b). About SEER Robotics. Official company profile.
3. SEER Robotics (2025). M4 Smart Logistics Management System Product Matrix. Official product source.
4. SEER Robotics (2026c). Automated Forklift: RDS, M4, WMS and MES Integration. Official technical description.
5. SEER Robotics (2026d). SEER Robotics Founder & CEO: Capital-Market Debut. Official company release.
6. Geek+ (2026a). Geek+ Robotics and Software Solutions. Official product portal.
7. Geek+ (2026b). Annual Results Announcement for the Year Ended December 31, 2025. Hong Kong exchange filing, Stock Code 2590.
8. Geek+ (2026c). About Geek+. Official company profile.
9. Geek+ (2026d). Shelf-to-Person and All-in-One Software. Official solution source.
10. Pudu Robotics (2026a). PUDU Products. Official product portal.
11. Pudu Robotics (2026b). About PUDU. Official company profile and history.
12. Pudu Robotics (2025). PUDU Robotics Product Brochure. Official brochure with March 2025 cutoff.
13. Pudu Robotics (2026c). PUDU Open Platform. Official API and SDK documentation.
14. Pudu Robotics (2026d). Elevator Integration for Hotels and Hospitals. Official technical and case source.
15. Ahn, M. et al. (2024). AutoRT: Embodied Foundation Models for Large Scale Orchestration of Robotic Agents. arXiv:2401.12963.
16. Shah, R. et al. (2024). BUMBLE: Unifying Reasoning and Acting with Vision-Language Models for Building-wide Mobile Manipulation. arXiv:2410.06237.
17. SEER Robotics (2026e). Industrial Cybersecurity Certification and Company Profile. Official company and certification source.
18. Nathan Koenig et al. (2004). Gazebo: A Dynamic Multi-Robot Simulator. DOI:10.1109/iros.2004.1389727.
19. Herman Bruyninckx (2001). The OROCOS project: Flexible toolchain for robot control. DOI:10.1109/robot.2001.932879.