🚚 WIA Delivery Robot Standard Ebook | Chapter 1 of 8

Chapter 1: Last-Mile Delivery Robots and Where WIA ROB-010 Fits

A delivery robot is easy to picture and surprisingly hard to integrate. The machine itself—a small wheeled box that rolls along a pavement or a hotel corridor and opens its lid for the right person—is the visible part. The invisible part is the stream of data that tells a fleet platform where the robot is, what it is carrying, which route it has committed to, and whether it is safe to send it the next job. When every manufacturer invents that stream independently, an operator who buys robots from two vendors ends up running two fleet platforms. WIA ROB-010 exists to remove that duplication.

This chapter sets the scene for the rest of the book. It explains what kind of machine the standard is written for, how such a machine is built in layers, why interoperability is the problem worth standardizing, how the four phases of WIA ROB-010 are organized, how the standard relates to neighbouring ISO, OASIS and ROS work, and what the regulatory landscape looks like in broad terms. It closes with conventions and a small set of sample identifiers that every later chapter reuses.

1.0 Simulator map: five panels, eight chapters

The standard ships with an interactive simulator (simulator/index.html in the delivery-robot package). It is a teaching aid, not a reference implementation, but it is the quickest way to see the concepts of this book in motion. It has five tabs, each switched by the JavaScript function showPanel(). Table 1-1 maps them to the chapters where the underlying rules are explained.

Because the simulator is a demonstration, it takes liberties that a conformant implementation must not. Three are worth noticing now, because they illustrate exactly the kind of drift this standard is meant to prevent:

• Identifiers. The control panel shows a robot called ROB-001-2025. Phase 1 requires robot_id to be a UUID. A human-friendly label is fine on a screen, but it is not the identifier that goes on the wire.
• Units. The panel displays speed in km/h and lets you set a maximum speed in km/h. Phase 1 expresses speed in metres per second, and the route constraint is max_speed_ms. A dashboard may convert for display; the payload may not.
• Checklist items. The safety panel lists items such as "GPS Accuracy: < 2m" and "Weather Resistance: IP65". Neither is a requirement of the four normative phases. The Phase 3 target is a position error below 0.5 m at the 95th percentile, achieved by fusion rather than by GPS alone, and the standard says nothing about ingress protection ratings. Treat these lines as the simulator author's illustration.

The same comparison between "what a screen shows" and "what the contract says" recurs throughout the book. Being able to spot it is one of the most practical skills an integrator can take away.

1.1 What a delivery robot is

For the purposes of WIA ROB-010, a delivery robot is a low-speed, wheeled, autonomous ground vehicle that carries goods in a closed, access-controlled compartment over the final segment of a delivery. Each part of that sentence narrows the scope.

Low-speed and wheeled

The robots in scope move at roughly walking pace and share space with pedestrians: pavements, pedestrian crossings, campus paths, building lobbies, corridors and lifts. Speed is not fixed by the standard as a single number—Phase 1 carries the robot's actual speed in m/s and a route-level max_speed_ms constraint, and Phase 3 specifies behaviour such as slowing to 0.5 m/s in crowded areas and crossing a road at 1–2 m/s. The consequence of low speed is that stopping is usually the safest reaction to uncertainty, which is why the emergency-stop and "waiting" behaviours in Phase 3 are so prominent.

Closed, access-controlled compartment

Unlike a courier who hands over a parcel, a robot has to decide who may open its lid. The Package model in Phase 1 therefore carries an access_control object with an access code, an optional QR code, and flags for biometric or signature confirmation. That makes the cargo compartment part of the data contract, not just part of the hardware. It also creates a security obligation: an access code is a secret and must be kept out of telemetry and logs, a point Chapter 3 returns to.

The last mile

"Last mile" is the logistics term for the final leg of a delivery—from a local hub, store, kitchen or locker bank to the recipient's door. It is the leg with the most stops, the least consolidation and the most varied terrain, which is why it attracts automation. A delivery robot typically covers this leg in one of three settings:

• Outdoor sidewalk delivery from a store or micro-hub to nearby homes and offices.
• Campus delivery across a university, hospital, industrial or residential estate where paths are private or semi-private.
• Indoor delivery inside hotels, apartment blocks, offices and hospitals, often involving lifts and doors.

The standard does not treat these as separate robot classes. The same schemas apply; what changes is the configuration—for example, sidewalk_only and elevator_allowed in the route's navigation constraints, or which localization source dominates.

What a delivery robot is not

Two neighbouring technologies are often grouped with delivery robots but are outside the scope of WIA ROB-010. Table 1-2 contrasts them qualitatively.

The comparison matters because it explains several design choices. A drone standard would need airspace coordination; a road-vehicle standard would need to reason about lane-level traffic at speed. WIA ROB-010 instead concentrates on pedestrians, crossings, safety margins around people and objects, and building infrastructure.

1.2 Layered system anatomy

Every delivery robot, whatever its brand, can be described as a stack of five layers. Understanding the stack is the key to understanding where a data standard can help and where it cannot.

1. Hardware. The chassis and drive train; the sensor set—typically LiDAR, cameras, ultrasonic rangers and an inertial measurement unit (IMU), plus a GNSS receiver outdoors; the battery with its battery management system (BMS); the lockable cargo compartment; lights, speaker and an emergency-stop button.
2. Firmware. Motor controllers, BMS firmware, sensor drivers and the low-level safety loop that can cut motor power without waiting for higher software. This is where the Phase 3 emergency-stop target of motor cutoff in under 100 ms is ultimately met.
3. Middleware. The messaging and process framework on the robot's computer. The README of the standard lists ROS 2 Humble (Open Robotics) among its reference frameworks, and many robots use ROS 2 for sensor topics, transforms and navigation nodes. Middleware conventions—such as the ROS coordinate frame rules—are not the same as the standard's wire conventions, which is why Chapter 2 spends time on conversions.
4. Autonomy application. Localization and mapping, perception and obstacle tracking, global and local path planning, the behaviour state machine, and the delivery workflow (pick-up, travel, hand-over).
5. Cloud fleet platform. Fleet manager, route optimizer, analytics, operator dashboard, customer tracking, charging management and software updates, connected to robots via a message broker and to business systems via APIs.

WIA ROB-010 does not tell you how to build any of these layers internally. It defines the interfaces between them, and a few behavioural rules the autonomy layer must honour. Figure 1-1 overlays the four phases on the stack.

+--------------------------------------------------------------------+
|  CLOUD FLEET PLATFORM                                              |
|  fleet manager | route optimizer | analytics | operator dashboard  |
|     ^  Phase 4: telemetry topics, dispatch, charging, OTA          |
|     |  Phase 2: REST /api/v1/... (auth, robots, packages, routes)  |
+-----|--------------------------------------------------------------+
      |   MQTT / HTTPS  -- payloads are Phase 1 JSON documents
+-----v--------------------------------------------------------------+
|  AUTONOMY APPLICATION                                              |
|  localization | perception | planning | behaviour state machine    |
|     Phase 3: localization, obstacle handling, A* / DWA,            |
|              crosswalk and sidewalk rules, emergency stop          |
+--------------------------------------------------------------------+
|  MIDDLEWARE  (e.g. ROS 2)   -- internal topics, not standardized   |
+--------------------------------------------------------------------+
|  FIRMWARE    motor control, BMS, low-level safety loop             |
+--------------------------------------------------------------------+
|  HARDWARE    chassis, LiDAR, cameras, ultrasonic, IMU, GNSS,       |
|              battery, cargo compartment, e-stop button             |
+--------------------------------------------------------------------+
  Phase 1 (data format) cuts across every arrow that leaves the robot.

Two observations follow from the figure. First, Phase 1 is not a layer of its own; it is the vocabulary used on every connection that crosses the robot boundary—MQTT telemetry, REST responses, stored records. Second, the middleware layer is deliberately left alone. A team that has invested in ROS 2 does not need to change its internal topics; it needs a translation step at the edge of the robot that turns internal messages into Phase 1 documents. That separation keeps the standard stable while robot software continues to evolve.

1.3 The interoperability problem

Consider an operator that runs deliveries for a large residential complex, a hospital campus or a city district. Over time it acquires robots from more than one manufacturer: one model for outdoor paths, another for indoor lift-riding, a third bought later because it carries temperature-controlled goods. Without a shared contract, each model arrives with its own ecosystem, and the operator discovers the following differences.

Each row on its own looks like a minor integration chore. Together they make it impractical to put mixed robots behind one dashboard, one dispatch algorithm and one customer tracking page. The costs also compound over time: every firmware update from any vendor can break an adapter, and every new robot model needs another one.

There is also a safety dimension. If an operations centre cannot tell, in a uniform way, that a robot has entered an error state, lost GPS, or dropped below the battery threshold at which it should return to charge, it cannot supervise a mixed fleet reliably. And there is an audit dimension: building managers, insurers and authorities increasingly want evidence of what a robot did, and evidence is only comparable if it has a common shape.

A data contract does not make robots identical. Vendors still compete on hardware, perception quality, battery life and cost. What it does is make the exchange predictable, so that a fleet platform written once can supervise any conformant robot, and a customer-facing application can show the same package status regardless of which machine carries the parcel.

1.4 Structure of the standard

WIA ROB-010 is published as four normative phase documents, each at version 1.0.0 with status "Stable". Each phase closes with three non-normative annexes. Table 1-4 is the map you will return to most often.

How the phases depend on each other

The phases are layered in the sense that each builds on the previous one. Phase 2 responses carry Phase 1 objects; Phase 3 behaviour is reported through Phase 1 fields such as mode, errors and position.source; Phase 4 telemetry is literally "JSON-encoded RobotState (see Phase 1)". An implementer can therefore adopt the standard incrementally: start by emitting valid Phase 1 documents, then expose the Phase 2 API, then document Phase 3 behaviour, and finally connect to a Phase 4 fleet platform. Chapter 8 turns this into an adoption checklist.

Normative text and annexes

Each phase document ends with three annexes, which are explicitly non-normative:

• Annex E — Implementation Notes. Field guidance on declaring operational scope, schema evolution, audit retention, time synchronization (NTPv4, or PTP for deterministic interlocks) and monthly error-budget reporting.
• Annex F — Adoption Roadmap. Defines three stability tiers—Stable, Provisional and Reference—and promises at least 90 days of overlap when a major version replaces another.
• Annex G — Test Vectors and Conformance Evidence. Describes positive and negative test vectors, an evidence package signed with Sigstore, quarterly re-publication, and the rule that a skipped test without recorded justification counts as a failure.

The annexes are useful, but they are also where the current text is least consistent. They refer to an "Annex A" for conformance tiers and to an "Annex D", neither of which exists in the phase documents. And Annex E's statement that renaming or removing a field triggers a minor version bump contradicts the Phase 1 versioning rule that breaking changes require a major bump. This book points out such gaps where they matter and recommends the safer interpretation; in this case, Chapter 3 recommends treating any rename or removal as a major change.

Conformance tiers

The README names three conformance tiers. Surface covers the data formats. Verified adds an annual third-party audit. Anchored means publishing a continuous evidence package. The tiers describe how much assurance a claim of conformance carries, not how capable the robot is. Chapter 7 explains what each tier requires in practice.

A note on the identifier

The four normative phase documents are titled "WIA ROB-010". The README and the OpenAPI file in the same package use the alias WIA-ROBOT-005; the OpenAPI server path, for example, is /wia-robot-005/v1. Both names refer to the same delivery-robot standard. This book uses WIA ROB-010 throughout, because that is the name on the normative text, and mentions the alias again only when discussing the OpenAPI file in Chapter 4. If you write procurement or compliance documents, quote both forms once so that readers searching either name find your document.

1.5 Adjacent standards and how WIA ROB-010 relates to them

A frequent misunderstanding is to read a data standard as a safety certificate. WIA ROB-010 is a data and protocol layer. It defines what robots and platforms say to each other and certain behaviours that should be observable in that exchange. It does not certify that a robot is mechanically or electrically safe, and conforming to it does not replace any product-safety assessment. The README lists several frameworks with which the standard is intended to be compatible; Table 1-5 summarizes how each relates.

The practical rule is to keep the tracks apart when you plan a project. The product-safety track (hazard analysis, functional safety of the stop circuit, electrical and battery safety, any national certification) produces a safety case. The ROB-010 track produces conformance evidence for data and interfaces. Some artefacts serve both—an emergency-stop latency measurement, for example—but a certificate from one track never substitutes for the other. Chapter 7 develops this distinction in detail.

Beyond the standards listed in the README, the phase documents themselves reference well-known engineering specifications: JSON Schema draft 2020-12 for data definitions, OAuth 2.0 for authorization, OpenAPI for describing the REST interface, MQTT for telemetry, TLS 1.3 and AES-256 for protecting data, and NTPv4 or PTP for time synchronization. None of them is specific to robots, which is a strength: most teams already have tools for them.

1.6 The regulatory landscape in broad terms

Law governing delivery robots differs between countries and often between cities, and it changes. This section therefore describes the kinds of rules a deployment usually meets, rather than quoting limits that may be out of date by the time you read this.

Authorization to operate in public space

Outdoor delivery robots use space that the law usually reserves for pedestrians. Many jurisdictions therefore require some form of authorization before a robot may travel on public pavements: a permit, a pilot programme, a registration, or a certification scheme. Conditions may cover where and when robots may operate, how fast they may move, how heavy they may be, whether a remote operator must be able to intervene, what insurance is held, and how the robot is identified to the public. Indoor and private-campus operation is usually governed instead by the property owner's rules and by general product-safety and workplace law.

In Korea, the Intelligent Robots Development and Distribution Promotion Act (지능형 로봇 개발 및 보급 촉진법) sets up an operating-safety certification (운행안전인증) for outdoor mobile robots, and the Road Traffic Act (도로교통법) links sidewalk use by such robots to that certification. The detailed requirements, the certifying body's procedures and any numerical limits should be taken from the current official text published on the national law information service (law.go.kr) and from the certifying body, not from secondary summaries. WIA ROB-010 conformance is not part of that certification and does not substitute for it.

Road crossing and traffic rules

Where robots cross roads, they are subject to local traffic rules for pedestrian crossings. Phase 3 of the standard encodes a conservative crossing procedure—detect the crossing, check the signal, scan for vehicles, signal intent, cross at 1–2 m/s and yield even when the robot has right of way. It also contains a sidewalk etiquette rule that says to pass on the left; as Chapter 5 explains, which side to pass on is a matter of local custom and should be configurable per jurisdiction rather than hard-coded.

Privacy and camera data

A robot with cameras records people who have not agreed to be recorded. Data-protection law—for example the EU General Data Protection Regulation (GDPR) and Korea's Personal Information Protection Act (개인정보 보호법)—applies to images in which people can be identified. Phase 4 of the standard sets relevant practices: blur faces before uploading video to the cloud, collect only necessary data, and automatically delete old telemetry after a retention period (the spec's example is 90 days). Phase 1 supports this by recommending that sensor payloads carry detections and an image_url rather than raw frames. Chapter 6 discusses retention in more depth, including the difference between telemetry retention and the retention of audit evidence.

Accessibility and public acceptance

Pavements are used by wheelchair users, people with visual impairments, parents with prams and older people walking slowly. Authorities and building managers pay close attention to whether robots block ramps, doorways or tactile paving. The Phase 3 safety margins—for example a 2.0 m margin around wheelchairs and strollers, and the rule never to block ramps or doorways—exist for this reason. Chapter 8 returns to the social questions.

1.7 How to read this book

Learning paths

The chapters build on each other, but different readers can take different routes:

• Robot software engineers should read Chapter 2 (localization and perception), Chapter 3 (schemas) and Chapter 5 (navigation behaviour) closely, and Chapter 7 for testing.
• Fleet-platform and backend developers should focus on Chapter 3 (schemas), Chapter 4 (REST API) and Chapter 6 (fleet integration).
• Integrators at operators—building managers, campus services, logistics and food-delivery companies—can read this chapter, skim Chapters 3 and 4 for the vocabulary, and read Chapters 6 and 8.
• QA and certification staff should read Chapter 7 first, then consult Chapters 3–6 for the individual requirements it checks.

Notation

Requirement keywords follow the convention used in IETF documents (RFC 2119 and RFC 8174): MUST and MUST NOT mark absolute requirements, SHOULD and SHOULD NOT mark strong recommendations that may be departed from with good reason, and MAY marks an option. When this book quotes a requirement it gives the phase and section, for example "Phase 3 §6.1". When it offers the author's own recommendation, it says so explicitly. Field names, enum values, API paths and topic names appear in code font and are never translated. Numbers labelled "spec target" come from the normative phase documents; numbers labelled "typical" or "for example" are illustrations and are not requirements.

Sample identifiers used throughout

To keep examples comparable from chapter to chapter, the book uses one robot, one package and one route. The identifiers below are UUIDs in version 4 format: the robot ID is the one used in the Phase 2 and Phase 4 examples, and the package and route IDs are made up for this book; the position is an example location in central Seoul, the same one the simulator displays.

{
  "robot_id":   "550e8400-e29b-41d4-a716-446655440000",
  "package_id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "route_id":   "3b241101-e2bb-4255-8caf-4136c566a962",
  "example_position": { "latitude": 37.5665, "longitude": 126.9780 },
  "schema_version": "1.0.0"
}

This is not a Phase 1 document—it is simply a reference card. Chapter 3 builds complete RobotState, Package and Route documents around these identifiers, Chapter 4 uses them in API calls, and Chapter 6 publishes them over MQTT. When you adapt examples for your own tests, replace them with your own UUIDs; never reuse sample identifiers in production data.

What this book does not do

This book explains the standard as published at version 1.0.0 and points out where the text is incomplete or inconsistent. It does not invent requirements that the standard does not contain; where it proposes a shape for something the standard leaves open—most visibly the mission manifest and hand-off events in Chapter 8—the proposal is labelled as non-normative. It also avoids market forecasts and deployment statistics: they age quickly and are rarely verifiable. The aim is to leave you able to build, test and argue about conformant systems using the standard's own text.

Chapter summary

• WIA ROB-010 addresses low-speed, wheeled robots that carry goods in a lockable compartment over the last mile, outdoors on pavements, on campuses and indoors.
• Such a robot is a five-layer stack from hardware to cloud. The standard defines the exchanges between layers—especially everything that leaves the robot—and some observable behaviour, not the internals.
• The core problem is interoperability: without a shared contract, a multi-vendor operator needs one integration per vendor for identity, position, units, modes, packages, commands, safety states and telemetry.
• The standard has four phases—Data Format, API Interface, Navigation Protocol, Fleet Integration—plus conformance tiers (Surface, Verified, Anchored) and non-normative Annexes E–G. The normative documents say "WIA ROB-010"; the README and OpenAPI file use the alias WIA-ROBOT-005.
• WIA ROB-010 is a data and protocol layer that complements, but never replaces, product-safety standards such as ISO 13482 and national operating authorizations.
• Regulation varies by place and time; plan for local authorization, traffic rules at crossings, data-protection obligations for camera data, and accessibility of shared pavements.

Back to Index | Chapter 2: Localization and Perception Fundamentals — Turning Robot State into Numbers →