Autonomous mobile robot operations logistics: a dataset of jobs, dispatch events and robot states

Background & Summary

• Jobs were generated by fixed stochastic rules and executed under rule-based dispatching, documenting the SOPL laboratory demonstrator rather than agent-based control.The recording covers one AMR, so fleet interactions such as congestion, right-of-way conflicts, and fleet-level task allocation are not represented.Source: Background & Summary · pp. 3–4
• AMR datasets often cover perception, navigation, machine signals, or administrative event logs separately; datasets combining operational records with physical-state data are less common.AMR dispatching and routing studies commonly evaluate generated benchmark instances.Source: Background & Summary · p. 3
• Nine eight-hour shifts yielded 1,382 jobs, 4,815 operations, 19,352 dispatch events, and 140,386 robot-state observations.The released records include technically valid delays, obstructed navigation, timeouts, and unsuccessful operations; raw and cleaned robot-state tables are provided.Source: Background & Summary · pp. 3–4
• Linked job requests, operation plans, dispatch events, and robot-state observations allow planned work to be related to execution and disturbances.The records include operation dependencies, state transitions, outcomes, and the AMR's reported obstruction periods.Source: Background & Summary · pp. 2, 4
• The linked records support agent decision evaluation, disturbance detection, operation-duration and lateness prediction, data-driven simulation, and process mining.Station processing times come from the job generator and represent AMR waiting periods, not measurements of physical human work.Source: Background & Summary · pp. 4–5

Methods

• The laboratory scenario uses an AMR and four stations to prepare and supply requested kits, with component boxes and completed kits serving as load carriers.Kits specify components drawn from two or three colors, determining whether two or three component boxes are needed.Source: Methods · pp. 6, 9
• Kit-supply jobs use independently sampled inter-arrival times, select uniformly from 30 kits, and receive an independently sampled due-date offset.The first kit-supply job of each shift is generated at the start of the job-generation process.Source: Methods · p. 9
• Kit supply jobs follow four ordered operations—warehouse loading, kitting, assembly delivery, and warehouse return—with station processing represented as AMR waiting time.Waiting times are sampled from station-specific triangular distributions, with kitting times depending on whether two or three component boxes are required.Source: Methods · pp. 7, 9
• The generator creates empty-box refills based on accumulated boxes and charging jobs using the lowest wheel state of charge and a shift-varying charging ceiling.At shift end, it appends a final charging job after the remaining operations; that job has no target state of charge.Source: Methods · p. 10
• The dispatcher manages pending operations and dependencies, while Kafka carries job, dispatch-event, and robot-state streams; robot states are polled at 1 Hz but stored only when values change.The stored robot-state series is therefore irregularly sampled.Source: Methods · pp. 11–13
• Curation removes technically invalid robot-state records while retaining raw records, and applies no interpolation, resampling, smoothing, or imputation.The cleaned robot-state table is stored separately from the raw record.Source: Methods · p. 13

• Four linked entities—jobs, operations, dispatch events, and robot-state observations—support reconstruction of requests, operation lifecycles, and AMR status.Jobs, operations, and events connect through identifiers; timestamps align them with robot-state observations.Source: Data Records · p. 13
• The top-level kits table and nine shift directories organize the release, with five Parquet tables in each shift directory.The kits table uses multiple rows per kit to specify component variants and quantities; Table 2 describes its fields.Source: Data Records · pp. 13–14, Table 2 · p. 14
• Each operation record links to a parent job and specifies its payload, goal location, and dependencies on preceding operations.Source: Data Records · p. 15
• Dispatch-event records document changes during operation execution, with event type identifying the event and JSON-encoded changes describing affected operation attributes.Source: Data Records · pp. 15–16
• Each shift has raw and cleaned robot-state tables; records are polled at 1 Hz but stored only when reported state changes, so intervals can exceed one second.The cleaned table excludes invalid localization states and physically implausible values; no interpolation, resampling, smoothing, or imputation is applied.Source: Data Records · pp. 16–17

• Figure 5 links operation records with robot-state observations across a kit-supply job followed by an empty-box refill job.Both representative figures use records from the 2026 07 27 evening shift.Source: Figure 5 · p. 18, Data Overview · p. 18
• Figure 6 illustrates battery and localization information available in the robot-state tables.The figures demonstrate how released tables can be combined to reconstruct operational sequences and robot trajectories.Source: Data Overview · p. 18, Figure 6 · p. 19

• Across the nine released shifts, jobs ranged from 148 to 156 per shift, with comparable operation and dispatch-event counts and variation in generated workloads.The retained variation included job inter-arrival times, sampled kits, processing times, and charging activities.Source: Technical Validation · p. 20, Table 7 · p. 21
• The 2026 07 30 evening shift was excluded after a refill-job state failed to reset following a timeout, stopping further refill-job generation despite accumulating empty boxes.The resulting recording did not follow the specified job-generation procedure and was treated as a software implementation error, not a valid operational disturbance.Source: Technical Validation · p. 20
• Validation checked unique job identifiers, constituent-operation references, chronological timestamps, and operation states and outcomes against lifecycle consistency.The checks verified that relationships among jobs, operations, and dispatch events were preserved.Source: Technical Validation · p. 20
• Robot-state screening removed records with invalid localization states or physically implausible values, without resampling, smoothing, or imputation.Source: Technical Validation · pp. 20–21
• Technically valid observations of waiting, navigation changes, delayed execution, and unsuccessful operations were retained, including interactions with personnel obstructing or crossing the AMR’s path.Raw and cleaned robot-state tables are provided, and screening did not target unusual but valid behavior.Source: Technical Validation · p. 21

• Job, operation, and dispatch-event identifiers link generated jobs to execution history, while UTC timestamps align records across data streams.Source: Usage Notes · p. 21
• Robot-state observations are irregularly sampled because records are stored only when the reported state changes, even though the AMR is queried at 1 Hz.Users needing regular sampling must choose an application-appropriate interpolation or aggregation strategy.Source: Usage Notes · pp. 21–22
• Raw robot-state tables retain ingested observations, while cleaned tables omit records flagged by technical screening; the raw tables support alternative curation.Source: Usage Notes · p. 22
• Station processing times are waiting periods assigned to the AMR, not direct measurements of human or automated processing times.Source: Usage Notes · p. 22
• The laboratory recordings reflect the campaign’s particular layout, navigation configuration, job-generation parameters, hardware, and software, rather than a statistically representative sample of industrial AMR operations.Source: Usage Notes · p. 22

Data Availability

• Version 1.0.1 is permanently archived in the KTH Data Repository as the publication’s version of record.The repository contains the kit definitions and nine released shift-specific datasets.Source: Data Availability · p. 22
• The complete released dataset, including kit definitions and nine shift-specific datasets, is in the KTH Data Repository.Source: Data Availability · p. 22
• A Hugging Face copy supports programmatic access and dataset exploration, while the KTH Data Repository remains the archival source of record.Source: Data Availability · p. 22

Code Availability

• The public MoRoOp Dataset Toolkit provides example code for loading, accessing, and analyzing the dataset.Source: Code Availability · p. 23
• The toolkit repository contains scripts used to reproduce the figures presented in the publication.Source: Code Availability · p. 23
• The publication-associated code version is release v1.0.0, with an archived copy deposited on Zenodo.Source: Code Availability · p. 23

Funding

• Open Access funding was provided by KTH Royal Institute of Technology.Source: Funding · p. 27
• The work was supported by XPRES (Excellence in Production Research).Source: Funding · p. 27