MoRoOp 数据集公开：连接单台 AMR 的作业、调度事件与机器人状态

Abstract

Autonomous mobile robots (AMRs) increasingly perform material transport in production logistics, where their operation is governed by job generation, dispatching and robot control. We present MoRoOp, a dataset of AMR operations recorded in a laboratory kit preparation and supply scenario over nine eight-hour shifts. During each shift, an AMR executed stochastically generated kit supply, empty-box refill and charging jobs. The dataset links job specifications, the operations constituting each job, dispatch events documenting operation state transitions and outcomes, and robot-state observations comprising position, orientation, velocity, per-wheel state of charge and diagnostics. It contains 1,382 jobs, 4,815 operations, 19,352 dispatch events and 140,386 robot-state observations together with the kit specifications used during job generation. The dataset was recorded in an operating laboratory environment, and technically valid observations of delays, obstructed navigation and unsuccessful operations were retained. Both raw and cleaned robot-state tables are provided. Documented reuse directions include the evaluation of AI agents on operational decision records, disturbance detection, operation prediction, data-driven simulation and event-log analysis.

Background & Summary

Production logistics comprises the storage, handling and transport activities that supply and connect production processes. Increasing product variety, smaller batch sizes and more frequently reconfigured production structures raise the complexity of internal material flows and the effort required to manage them [1]. Autonomous mobile robots (AMRs) have become a widely used resource in this context. In contrast to automated guided vehicles, which follow predetermined paths and are coordinated by a central controller, AMRs localize and plan their motion autonomously, and transport tasks can be assigned to them dynamically during execution [2, 3]. The associated planning and control decisions, including task allocation, dispatching, routing and charging, have been studied extensively in intralogistics and warehousing research [2, 4, 5].

Operating an AMR in such a system generates data at several levels. At the planning level, transport jobs are specified with attributes such as job type, requested content, release time and due date. At the execution level, a dispatching component decomposes jobs into executable operations, resolves their dependencies, and records state transitions, execution outcomes and termination reasons as discrete events. At the resource level, the AMR reports its position and orientation, velocity, navigation targets, battery state and diagnostic information as a time series. These levels differ in structure, temporal resolution and semantics, and they are typically produced and stored by different software components. They are consequently also analysed separately. Order and event data are treated in planning, control and process analysis, while robot telemetry is treated in navigation, diagnostics and maintenance. Making such heterogeneous sources jointly usable is a recurring requirement in production logistics [6, 7].

The motivation for this dataset follows from that separation. A job record states what was requested and when it was due. The associated operation and dispatch-event records state how the request was decomposed and what happened to each part of it, including timeouts and unsuccessful executions. The robot-state observations describe the physical behaviour of the resource during the same period. When these records are available together, the executed behaviour of the system can be reconstructed and related to what was planned, for instance whether a late job followed from a delayed release, an extended waiting period at a station, a navigation disturbance or an intermediate charging decision. The same correspondence between plan and execution is the input required by digital shadows and digital twins of material handling systems [8, 9] and by methods that construct simulation models directly from recorded operational data [10]. A recent review of publicly available manufacturing datasets groups them into machine-level sensor recordings on one side and management-level production records on the other, and notes that documentation of the monitored processes is often incomplete [11].

The dataset was recorded in the laboratory demonstrator associated with the concept of Self-Organizing Production Logistics (SOPL) [12]. SOPL addresses production logistics systems that are exposed to variability, dynamic interdependencies and frequent disturbances, and proposes multi-agent architectures in which embodied and non-embodied agents coordinate through event-driven interaction, shared semantic knowledge structures and digital twins. The order-driven kit preparation and supply scenario introduced in that work is the scenario used here, although no data from the present campaign were reported there. During the data-collection campaign, jobs were generated by fixed stochastic rules and executed under a rule-based dispatching policy rather than by agent-based decision-making. The released records therefore document the operation of the demonstrator under a rule-based control policy and provide a reference for later configurations of the same physical system.

Publicly available datasets involving mobile robots in shared indoor environments are largely oriented towards perception and navigation. Datasets such as THÖR-MAGNI provide human and robot trajectories recorded with motion capture and on-board sensors [13], and comparable recordings have been published for a mobile robot performing retail tasks alongside human operators [14]. A second group of datasets releases machine-level signals without the work that produced them, ranging from high-frequency signals of a stationary manipulator recorded per motion cycle [15] to long sensor recordings of a single industrial asset annotated with reported failures [16]. Event logs published for process mining research provide case and activity structure with administrative timestamps, but contain no physical state of the executing resources [17]. Datasets combining both perspectives are less common. Examples include a multiphase flow facility benchmark that pairs an operation log with process measurements [18] and a smart-factory dataset that pairs OPC UA logs with sensor measurements of stationary stations [19]. In research on AMR dispatching and routing, evaluation is commonly based on generated benchmark instances [20].

The released dataset comprises nine eight-hour shifts recorded on five consecutive days and contains 1,382 jobs, 4,815 operations, 19,352 dispatch events and 140,386 robot-state observations. One further shift was recorded but excluded from the release because of an implementation error in the job generator, as documented in the Technical Validation section. Three characteristics of the released data are relevant for reuse. First, the data were recorded in an operating laboratory in which personnel could cross or temporarily obstruct the planned trajectory of the AMR. Waiting, delayed execution, obstructed navigation, operation timeouts and unsuccessful operations occurred during normal operation and were retained. The quality-screening procedure removed only technically invalid robot-state records, such as invalid localization states or physically implausible values, and the raw records are released alongside the cleaned ones. These records were retained deliberately, since they document the operating conditions under which the campaign took place. Second, the robot state was polled at a fixed frequency but stored only when a reported value changed, so the robot-state tables form an irregularly sampled time series. Third, station processing times were assigned by the job generator and represent waiting periods of the AMR rather than measurements of physical human work.

The recording documents the operation of a single AMR. This reflects the configuration of the demonstrator at the time of data collection and keeps the correspondence between dispatching decisions, executed operations and robot-state observations unambiguous, because every state observation belongs to the resource that executed the operation under consideration. Effects arising from the interaction of several vehicles, such as congestion, right-of-way conflicts and fleet-level task allocation, are consequently not represented. The demonstration roadmap defined for SOPL foresees increasingly distributed configurations [12], for which the present recording provides a single-resource reference.

The combination of job specifications, operation records, dispatch events and robot-state observations from the same system allows several forms of reuse. Agents built on foundation models are increasingly proposed to plan and supervise the operation of physical logistics resources, which is also the direction taken by SOPL [12]. Assessing whether such an agent decides well requires a record of what was requested, of the executable plan that followed from the request, of what the resource physically did while carrying it out, and of what happened when execution was disturbed. Work on grounding language model plans in the actions a robot can perform [21], on replanning from execution feedback [22] and on explaining failures from recorded robot experience [23] rests on records of this kind, and applications of such models in manufacturing and supply chain operations are being surveyed [24, 25]. In this dataset each job is present as the original request with its type, requested content and timing, as the ordered set of operations into which it was decomposed together with the dependencies between them, as the sequence of dispatcher events that queued, started and closed those operations, and as the robot-state record of the execution that followed, including the periods in which the AMR reported an obstruction. The decisions of an agent placed in the same situation can therefore be compared with the operations that the rule-based dispatcher produced and with the execution that resulted.

The robot-state tables constitute multivariate time series recorded during operation that included periods of obstructed navigation, and are therefore applicable to time-series anomaly detection and to fault detection and diagnosis for industrial robots [26, 27]. The reported stuck conditions, navigation states and per-wheel states of charge allow disturbances observed by the AMR itself to be located in time and, through the recorded timestamps, related to the operation that was being executed. The recorded release, start and finish timestamps, together with the due dates and execution outcomes of the jobs, support the prediction of operation durations and job lateness in analogy to predictive process monitoring on business process event logs [28].

Job and operation records also provide the arrival, routing and processing information required by methods that generate discrete-event simulation models and digital twins directly from operational data [10, 29, 30], subject to the qualification noted above that station processing times originate from the job generator rather than from measured physical work. Dispatch events can be converted into event logs in which either jobs or operations serve as cases, which makes the data accessible to process mining techniques that have been applied to internal logistics event data in automotive production [31] and surveyed for Industry 4.0 settings more broadly [32]. Because jobs, operations, kits and stations are interrelated object types, the records can equally be prepared as object-centric event data. Finally, the scenario is small, physically interpretable and completely specified, which makes the dataset usable in teaching on production logistics, discrete-event simulation, process mining and industrial data analysis.

The dataset is released following the FAIR principles [33]. Version 1.0.1 is archived in the KTH Data Repository [34] and mirrored on Hugging Face [35], and example code for loading and analysing the released tables is archived with the dataset toolkit [36].

Methods

The dataset was collected at the joint IPU laboratory facility of the Department of Production Engineering at KTH Royal Institute of Technology. Data acquisition was conducted over five consecutive days, comprising two eight-hour shifts per day. During each shift, an AMR executed dynamically generated material-transport jobs within a laboratory production logistics scenario. The job generator created transport requests according to predefined stochastic rules, while the operation dispatcher translated these requests into executable operations and coordinated their execution on the AMR. The resulting dataset combines job specifications, operation records, dispatch events and robot-state observations. The following sections describe the experimental scenario, the procedure used to generate the jobs, and the data acquisition and processing pipeline.

Scenario description

The dataset was collected in a production logistics scenario previously introduced in [12]. The scenario comprises an AMR and four stations representing activities commonly encountered in production logistics environments, see Figure 1. It implements a kit preparation and supply process in which an assembly station dynamically requests predefined kits. Each kit is represented by a Eurobox containing a specified combination of components. In the laboratory implementation, the components are toy building bricks available in four colors and two sizes. Euroboxes are used as load carriers for both individual component supplies and completed kits. To distinguish these two uses, they are referred to as component boxes and kit boxes, respectively. The principal assets of the scenario and their functions are as follows:

• Assembly Station: The assembly station represents the internal customer of the production logistics process. It generates requests for specific kits to be prepared and delivered.
• Warehouse: The warehouse stores component boxes. Each component box contains building bricks of a specified color and provides the components required for kit preparation.
• Kitting Station: The kitting station represents the preparation of requested kits. At this station, the required bricks are transferred from the supplied component boxes into an empty kit box according to the corresponding kit specification.
• AMR: The AMR transports component and kit boxes between the stations. The AMR used for data collection was a wheel.me autonomous mobile robot (https://www.wheel.me/en-us).
• Charging Station: The charging station provides the physical interface used by the AMR to recharge its battery.

A kit supply job consists of the following sequence of activities:

1. The AMR navigates to the warehouse and waits while an operator loads the required component boxes.
2. The AMR transports the component boxes to the kitting station and waits while the components are transferred into an empty kit box according to the corresponding kit specification.
3. The AMR transports the completed kit box and the remaining partially filled component boxes to the assembly station and waits while the kit box is unloaded.
4. The AMR returns the partially filled component boxes to the warehouse and waits while they are unloaded.

In addition to kit supply jobs, the scenario includes two auxiliary job types: empty-box refill jobs and charging jobs. An empty-box refill job transports accumulated empty kit boxes from the assembly station to the kitting station. For this job type, the AMR navigates to the assembly station, waits while the empty boxes are loaded, transports them to the kitting station, and waits while they are unloaded. A charging job directs the AMR to the charging station, where it charges according to the charging policy described below.

Job generation

During data collection, kit supply, empty-box refill, and charging jobs were generated by an event-driven job generator according to the workflow Fig. 2. At a periodic time interval, the generator evaluated the elapsed shift time, the scheduled generation time of the next kit supply job, the number of empty kit boxes accumulated at the assembly station, and the state of charge (SoC) of the AMR. The notation and parameter values used by the job generator are summarized in Table 1.

Kit supply jobs were indexed by i and generated according to independently sampled inter-arrival times T_{\mathrm{arr},i}. Let t denote the current time and t_{g,i-1} the generation time of the preceding kit supply job. A new kit supply job i was generated when

t\geq t_{g,i-1}+T_{arr,i}.

After generation, the generation time was recorded as t_{g,i}=t, and the inter-arrival time for the subsequent job was sampled independently. The first kit supply job of each shift was generated at the start of the job-generation process.

For each kit supply job i, a kit K_{i} was sampled uniformly from the set \mathcal{K}=\{K_{001},\ldots,K_{030}\}.

Each kit specification defined a combination of building bricks and required components from two or three distinct colors, denoted by c(K_{i})\in\{2,3\}. Because each component color was stored in a separate component box, c(K_{i}) also determined whether two or three component boxes were required for the job.

A due-date offset D_{i} was sampled independently and added to the job-generation time:

t_{d,i}=t_{g,i}+D_{i},

where t_{d,i} denotes the due date of kit supply job i.

Each kit supply job was instantiated as an ordered sequence of four operations corresponding to processing at the warehouse, kitting station, assembly station, and warehouse, respectively. The physical activities at these stations were represented by station-specific processing times. From the perspective of the AMR, each processing time corresponds to a waiting period at the associated station. Processing times were sampled independently from the triangular distributions specified in Table 1. For operations whose processing times depended on the number of component boxes, the corresponding distribution was selected according to c(K_{i}). The waiting time assigned to the kitting operation was calculated as the sum of independently sampled component-unloading and kit-preparation times.

Empty-box refill jobs were generated based on the number of empty kit boxes accumulated at the assembly station, denoted by B_{A}(t). The counter was incremented after the successful completion of each kit supply job. When

B_{A}(t)\geq B_{\mathrm{th}},

the generator created an empty-box refill job. The refill job comprised an operation at the assembly station for loading the accumulated empty kit boxes and a subsequent operation at the kitting station for unloading them. After successful completion of the refill job, B_{A}(t) was reset to zero.

Intermediate charging jobs were considered during a shift. The AMR comprised four independently powered wheel units. The charging decision was based on the lowest state of charge among these units,

\mathrm{SOC}_{\min}(t)=\min_{r\in\mathcal{R}}\mathrm{SOC}_{r}(t).

During a shift, the upper charging limit \mathrm{SOC}_{\mathrm{ceil}}(t) decreased linearly from 75\% at the beginning of the shift to 40\% at its end:

\mathrm{SOC}_{\mathrm{ceil}}(t)=\mathrm{SOC}_{\mathrm{start}}+\frac{t}{T_{S}}\left(\mathrm{SOC}_{\mathrm{end}}-\mathrm{SOC}_{\mathrm{start}}\right).

An intermediate charging job was generated when

\mathrm{SOC}_{\mathrm{ceil}}(t)-\mathrm{SOC}_{\min}(t)\geq\Delta_{\mathrm{SOC}},

where \Delta_{\mathrm{SOC}} was set to 5\%. The time-dependent charging ceiling was used as the target SoC for the generated charging job. At the end of each eight-hour shift, the generator stopped creating kit supply and empty-box refill jobs and appended a final charging job after the remaining operations. Unlike intermediate charging jobs, the final charging job did not specify a target SoC.

Data collection and processing pipeline

The data collection pipeline connecting the AMR, job generator, operation dispatcher and data-storage infrastructure is illustrated in Fig. 3. Apache Kafka was used for streaming data between the software components.

The AMR provides an OpenAPI interface for retrieving its current state and submitting navigation commands. During data collection, the AMR state was queried at a frequency of 1\,\mathrm{Hz}. A new robot-state message was published to the robot_states Kafka topic only when at least one reported state value differed from the previously retrieved state. Consequently, the robot state was evaluated at a fixed polling frequency, whereas the recorded observations form an event-triggered, irregularly sampled time series.

The operations instantiated by the job generator were managed by the OperationDispatcher software module. The dispatcher maintained a queue of pending operations, evaluated operation dependencies, and coordinated their execution on the AMR. Information about generated jobs was published to the jobs topic, while operation state transitions and execution outcomes were published to the dispatch_events topic. The resulting data collection pipeline therefore comprised three Kafka streams: jobs, robot_states, and dispatch_events.

Node-RED was used as the data-ingestion component. It consumed messages from the three Kafka streams, transformed the messages into SQL statements, and inserted the resulting records into a MariaDB database. Timestamps contained in the incoming messages were converted to ISO 8601 representation and standardized to Coordinated Universal Time (UTC) before storage.

Following completion of the data-collection campaign, the database records were exported and subjected to quality screening and curation. Quality screening of the robot-state data included identification and removal of records containing invalid localization states or physically implausible values. The original robot-state records were retained as the raw data record, while the screened records were stored separately as the cleaned robot-state table. No interpolation, resampling, smoothing, or imputation was applied during this process.

Data Records

Version 1.0.1 of the MoRoOp dataset is permanently archived in the KTH Data Repository [34]. A copy of the same version is additionally available through Hugging Face [35] to facilitate programmatic access and dataset exploration. All tabular data are provided in Apache Parquet format. Parquet is a column-oriented file format that preserves the tabular schema and supports efficient storage and selective column access.

The dataset is organized around four related data entities: jobs, operations, dispatch events, and robot-state observations. Jobs represent material-transport requests generated by the job generator. Each job comprises one or more operations. Dispatch events record changes occurring during the lifecycle of individual operations. Robot-state observations provide time-stamped measurements and status information from the AMR. Jobs, operations and dispatch events can be related through their identifiers, while temporal alignment with robot-state observations is established using the recorded timestamps.

The organization of the dataset is illustrated in Fig. 4. The top-level data directory contains the dataset-level kits.parquet table and nine shift-specific subdirectories. The subdirectories follow the naming convention YYYY_MM_DD_shift, where YYYY_MM_DD denotes the date of data collection and shift identifies the morning or evening shift. Each shift directory contains five Parquet tables: dispatch_events, jobs, operations, robot_state_raw, and robot_state_cleaned. The file names include the corresponding date and shift identifier to preserve their association when individual files are accessed independently of the directory structure.

Kit definitions

The top-level kits.parquet defines the composition of the kits available to the job generator. The table uses a long-format representation in which each row specifies one component variant required for a kit. A component variant is defined by its color and size, together with the required quantity. Consequently, multiple rows with the same kit identifier collectively define the complete specification of one kit.

Jobs

Each shift-specific job table contains the final recorded representation of the jobs created during the corresponding data-collection shift. Each row represents one job and is uniquely identified by the id field. The tables include the three job types described in the Methods section. The operations field contains a JSON-encoded ordered list of the operation identifiers constituting the job. These identifiers link each job to the corresponding records in the *_operations.parquet and *_dispatch_events.parquet tables. The individual fields are defined in Table 3.

Operations

The shift-specific *_operations.parquet tables contain the final recorded representation of the operations instantiated during the corresponding data-collection shift. Each row represents one operation and is uniquely identified by the id field. The job_id field links the operation to its parent job in the corresponding *_jobs.parquet table. As each job comprises one or more operations, multiple operation records may reference the same job identifier. The payload field contains the operation specification, including the AMR goal location. The dependencies field specifies the dependencies on preceding operations used by the operation dispatcher to ensure the required execution order. The individual fields are defined in Table 4.

Dispatch Events

The shift-specific *_dispatch_events.parquet tables contain the events published by the OperationDispatcher module during the corresponding data-collection shift. In contrast to the operations tables, which contain one final record for each operation, the dispatch-event tables document changes that occurred during operation execution. Multiple dispatch events may therefore refer to the same operation. Each event is uniquely identified by the id field. Where an event is associated with a specific operation, the operation_id field links the event to the corresponding record in the *_operations.parquet table. The event_type field identifies the type of dispatcher event, while the JSON-encoded changes field describes the operation attributes affected by the event. Additional event-specific information may be included in the meta_data field. The individual fields are defined in Table 5.

Robot States

Each shift directory contains a raw and a cleaned robot-state table. The *_robot_state_raw.parquet table contains the robot-state and diagnostic data acquired from the AMR during the corresponding shift. The AMR state was polled at 1\,\mathrm{Hz}, but a record was published only when a change relative to the previously retrieved state was detected. Consequently, the robot-state tables do not constitute regularly sampled time series, and the interval between successive records may exceed one second.

The fields current_position_id, navigating_to_position_id, and last_navigated_position_id use the internal position identifiers of the AMR navigation system. Position identifiers 135, 136, 137, and 138 correspond to the charging station, warehouse, kitting station, and assembly station, respectively.

The *_robot_state_cleaned.parquet table contains the corresponding robot-state records after the quality-screening procedure described in the Technical Validation section. Records containing invalid localization states or physically implausible values were excluded from the cleaned table. No interpolation, resampling, smoothing, or imputation was applied. The raw and cleaned robot-state tables follow the schema defined in Table 6.

Data Overview

Figures 5 and 6 illustrate representative data contained in the dataset. Both figures use records from the 2026_07_27_evening shift. Figure 5 illustrates the temporal relationship between operation records and robot-state observations for a kit supply job followed by an empty-box refill job. Figure 6 illustrates the types of battery and localization information available in the robot-state tables. The figures are intended to demonstrate how the released tables can be combined to reconstruct operational sequences and robot trajectories.

Technical Validation

The experimental system and data collection pipeline were monitored throughout each shift using dedicated dashboards for the AMR and the job-generation infrastructure. This continuous monitoring allowed technical problems affecting the AMR, job execution, or data acquisition to be identified during operation.

Following data collection, the completeness and consistency of the recorded tables were evaluated separately for each shift. Table 7 reports the numbers of records contained in the respective shift-specific tables. Among the nine shifts included in the released dataset, the number of recorded jobs ranged from 148 to 156 per shift. The corresponding numbers of operations and dispatch events were also comparable across these shifts. These record counts indicate that the stochastic job-generation process produced broadly comparable workloads while retaining the intended variability in job inter-arrival times, sampled kits, sampled processing times and charging activities.

The 2026_07_30_evening shift initially contained considerably fewer records than the remaining shifts. Subsequent investigation identified an implementation error in the job-generation procedure. After an operation timeout occurred while the AMR was traveling to execute an empty-box refill job, the internal refill-job state was not reset correctly. Consequently, no further empty-box refill jobs were generated during the shift, although empty kit boxes continued to accumulate at the assembly station. The resulting recording therefore did not represent the job-generation procedure specified for the data collection campaign. The entire shift was excluded from the released dataset because the observed inconsistency resulted from a software implementation error rather than from a valid operational disturbance.

The internal consistency of the remaining records was evaluated using the identifiers and lifecycle information contained in the different data tables. Each job was checked for a valid unique identifier and references to its constituent operations. The operation identifiers were subsequently used to relate the jobs to the corresponding operation and dispatch-event records. Timestamps were checked for chronological consistency, and the recorded operation states and outcomes were examined for consistency with the operation lifecycle. These checks verified that the relationships among jobs, operations, and dispatch events were preserved in the released dataset.

The robot-state records underwent an additional quality-screening procedure. Records containing invalid localization states or physically implausible values were identified and removed. The screening criteria were restricted to technical validity and did not target unusual but valid operational behaviour. No interpolation, resampling, smoothing, or imputation was applied after the removal of invalid records. The raw robot-state tables are provided alongside the cleaned tables to make the curation process transparent and to allow users to apply alternative quality-screening procedures. The validation procedure deliberately retained technically valid observations of operational disturbances. Data collection was conducted in an operating laboratory environment in which personnel could cross or temporarily obstruct the planned trajectory of the AMR. Such interactions could result in waiting, changes in navigation behaviour, delayed operation execution, or unsuccessful operations. These records were retained when the associated robot states and system events were technically valid. The dataset therefore represents the operational conditions encountered during the data collection campaign rather than an idealized, disturbance-free execution of the production logistics scenario.

Usage Notes

All timestamps are expressed in ISO 8601 format and standardized to Coordinated Universal Time (UTC). Records from the different data streams can therefore be aligned temporally using their timestamps. Job, operation, and dispatch-event identifiers provide additional relational links between generated jobs and their execution history.

The robot-state data should be treated as an irregularly sampled time series. Although the AMR state was queried at 1\,\mathrm{Hz}, a record was stored only when the reported state differed from the preceding observation. The time interval between successive robot-state observations can therefore exceed one second. Users requiring regularly sampled data should perform resampling as part of their analysis and select an interpolation or aggregation strategy appropriate for their application.

Both raw and cleaned robot-state tables are provided. The raw tables preserve the observations recorded by the data-ingestion pipeline, including observations subsequently identified as technically invalid. The cleaned tables exclude observations identified during the quality-screening procedure described in the Technical Validation section. Users developing alternative quality criteria are therefore encouraged to use the raw tables as the starting point for their own curation.

The relationships between jobs, operations, and dispatch events can be reconstructed using the corresponding identifiers. The temporal relationship between these records and robot-state observations can be established using their UTC timestamps. When reconstructing operation trajectories, users should account for the fact that station processing times represent waiting periods assigned to the AMR and are not direct measurements of physical human or automated processing times.

The dataset contains observations from a laboratory production-logistics environment. Consequently, the recorded robot behaviour reflects the specific physical layout, navigation configuration, job-generation parameters, AMR hardware, and software components used during the data-collection campaign. The dataset should therefore not be interpreted as a statistically representative sample of industrial AMR operations.

Data Availability

Version 1.0.1 of the MoRoOp dataset is permanently archived in the KTH Data Repository [34] and constitutes the version of record associated with this publication. The repository contains the complete released dataset, including the kit definitions and the nine released shift-specific datasets.

A copy of Version 1.0.1 is also available through Hugging Face [35] to facilitate programmatic access and dataset exploration. The KTH Data Repository should be used as the archival source of record.

Code Availability

Example code for loading, accessing, and analyzing the MoRoOp dataset is available in the public MoRoOp Dataset Toolkit repository. The repository also contains the scripts used to reproduce the figures presented in this publication. The code version associated with this publication is identified by release v1.0.0, an archived copy of which is deposited on Zenodo [36].

References

1. [1] Fragapane, G., Ivanov, D., Peron, M., Sgarbossa, F. & Strandhagen, J. O. Increasing flexibility and productivity in Industry 4.0 production networks with autonomous mobile robots and smart intralogistics. Ann. Oper. Res. 308, 125–143 (2022). https://doi.org/10.1007/s10479-020-03526-7
2. [2] Fragapane, G., de Koster, R., Sgarbossa, F. & Strandhagen, J. O. Planning and control of autonomous mobile robots for intralogistics: Literature review and research agenda. Eur. J. Oper. Res. 294, 405–426 (2021). https://doi.org/10.1016/j.ejor.2021.01.019
3. [3] De Ryck, M., Versteyhe, M. & Debrouwere, F. Automated guided vehicle systems, state-of-the-art control algorithms and techniques. J. Manuf. Syst. 54, 152–173 (2020). https://doi.org/10.1016/j.jmsy.2019.12.002
4. [4] Azadeh, K., de Koster, R. & Roy, D. Robotized and automated warehouse systems: Review and recent developments. Transp. Sci. 53, 917–945 (2019). https://doi.org/10.1287/trsc.2018.0873
5. [5] Pallottino, L. Robotics for warehouses and logistics: Technologies, challenges, and future directions. Annu. Rev. Control Robot. Auton. Syst. 9, 377–401 (2026). https://doi.org/10.1146/annurev-control-032724-020213
6. [6] Tao, F., Qi, Q., Liu, A. & Kusiak, A. Data-driven smart manufacturing. J. Manuf. Syst. 48, 157–169 (2018). https://doi.org/10.1016/j.jmsy.2018.01.006
7. [7] Zhong, R. Y. et al. A big data approach for logistics trajectory discovery from RFID-enabled production data. Int. J. Prod. Econ. 165, 260–272 (2015). https://doi.org/10.1016/j.ijpe.2015.02.014
8. [8] Kritzinger, W., Karner, M., Traar, G., Henjes, J. & Sihn, W. Digital Twin in manufacturing: A categorical literature review and classification. IFAC-PapersOnLine 51, 1016–1022 (2018). https://doi.org/10.1016/j.ifacol.2018.08.474
9. [9] Pan, Y. H., Qu, T., Wu, N. Q., Khalgui, M. & Huang, G. Q. Digital twin based real-time production logistics synchronization system in a multi-level computing architecture. J. Manuf. Syst. 58, 246–260 (2021). https://doi.org/10.1016/j.jmsy.2020.10.015
10. [10] Lugaresi, G. & Matta, A. Automated manufacturing system discovery and digital twin generation. J. Manuf. Syst. 59, 51–66 (2021). https://doi.org/10.1016/j.jmsy.2021.01.005
11. [11] Golendukhina, V., Wiesmayr, B. & Felderer, M. A review of publicly available datasets from manufacturing systems. in Proc. 2024 IEEE 29th Int. Conf. Emerging Technologies and Factory Automation (ETFA), 1–8 (2024). https://doi.org/10.1109/ETFA61755.2024.10710865
12. [12] Klein, J.-F., Jeong, Y., Flores-García, E. & Wiktorsson, M. Toward Self-Organizing Production Logistics: A Multi-Agent Approach. Preprint at https://arxiv.org/abs/2604.04753 (2026). https://doi.org/10.48550/arXiv.2604.04753
13. [13] Schreiter, T. et al. THÖR-MAGNI: A large-scale indoor motion capture recording of human movement and robot interaction. Int. J. Robot. Res. 44, 568–591 (2025). https://doi.org/10.1177/02783649241274794
14. [14] Chen, Y. et al. Human mobile robot interaction in the retail environment. Sci. Data 9, 673 (2022). https://doi.org/10.1038/s41597-022-01802-8
15. [15] Brockmann, J. T., Rudolph, M., Rosenhahn, B. & Wandt, B. The voraus-AD dataset for anomaly detection in robot applications. IEEE Trans. Robot. 40, 438–451 (2024). https://doi.org/10.1109/TRO.2023.3332224
16. [16] Veloso, B., Ribeiro, R. P., Gama, J. & Pereira, P. M. The MetroPT dataset for predictive maintenance. Sci. Data 9, 764 (2022). https://doi.org/10.1038/s41597-022-01877-3
17. [17] Zou, M., Zeng, Q., Duan, H., Ni, W. & Chen, S. TV-ALP: A log dataset of television assembly line production under multi-person collaboration for process mining research. Appl. Intell. 54, 3990–4011 (2024). https://doi.org/10.1007/s10489-024-05347-8
18. [18] Stief, A., Tan, R., Cao, Y. & Ottewill, J. R. PRONTO heterogeneous benchmark dataset. Zenodo https://doi.org/10.5281/zenodo.1341583 (2019).
19. [19] Kaupp, L., Webert, H., Nazemi, K., Humm, B. & Simons, S. The CONTEXT dataset containing contextual faults of a smart factory. Zenodo https://doi.org/10.5281/zenodo.4034867 (2020).
20. [20] Meyer, A., Gschwind, T., Amberg, B. & Colling, D. BEAMI – Benchmark instances for routing electric autonomous mobile robots in intralogistics. Zenodo https://doi.org/10.5281/zenodo.14284157 (2024).
21. [21] Ichter, B. et al. Do as I can, not as I say: Grounding language in robotic affordances. in Proc. 6th Conf. Robot Learning (CoRL) 205, 287–318 (PMLR, 2023). https://proceedings.mlr.press/v205/ichter23a.html
22. [22] Huang, W. et al. Inner monologue: Embodied reasoning through planning with language models. in Proc. 6th Conf. Robot Learning (CoRL) 205, 1769–1782 (PMLR, 2023). https://proceedings.mlr.press/v205/huang23c.html
23. [23] Liu, Z., Bahety, A. & Song, S. REFLECT: Summarizing robot experiences for failure explanation and correction. in Proc. 7th Conf. Robot Learning (CoRL) 229, 3468–3484 (PMLR, 2023). https://proceedings.mlr.press/v229/liu23g.html
24. [24] Zhang, C. et al. A survey on potentials, pathways and challenges of large language models in new-generation intelligent manufacturing. Robot. Comput. Integr. Manuf. 92, 102883 (2025). https://doi.org/10.1016/j.rcim.2024.102883
25. [25] Song, Z., Xie, Y., Yang, L. & Zhao, Y. Large language models in supply chain management: a systematic literature review and application framework. Int. J. Prod. Res. 64, 7144–7184 (2026). https://doi.org/10.1080/00207543.2026.2641103
26. [26] Zamanzadeh Darban, Z., Webb, G. I., Pan, S., Aggarwal, C. C. & Salehi, M. Deep learning for time series anomaly detection: A survey. ACM Comput. Surv. 57, 1–42 (2024). https://doi.org/10.1145/3691338
27. [27] Sabry, A. H. & Ungku Amirulddin, U. A. B. A review on fault detection and diagnosis of industrial robots and multi-axis machines. Results Eng. 23, 102397 (2024). https://doi.org/10.1016/j.rineng.2024.102397
28. [28] Rama-Maneiro, E., Vidal, J. C. & Lama, M. Deep learning for predictive business process monitoring: Review and benchmark. IEEE Trans. Serv. Comput. 16, 739–756 (2023). https://doi.org/10.1109/TSC.2021.3139807
29. [29] Camargo, M., Dumas, M. & González-Rojas, O. Automated discovery of business process simulation models from event logs. Decis. Support Syst. 134, 113284 (2020). https://doi.org/10.1016/j.dss.2020.113284
30. [30] Cimino, A. et al. Automatic simulation models generation in industrial systems: A systematic literature review and outlook towards simulation technology in the Industry 5.0. J. Manuf. Syst. 80, 859–882 (2025). https://doi.org/10.1016/j.jmsy.2025.03.027
31. [31] Knoll, D., Reinhart, G. & Prüglmeier, M. Enabling value stream mapping for internal logistics using multidimensional process mining. Expert Syst. Appl. 124, 130–142 (2019). https://doi.org/10.1016/j.eswa.2019.01.026
32. [32] Akhramovich, K., Serral, E. & Cetina, C. A systematic literature review on the application of process mining to Industry 4.0. Knowl. Inf. Syst. 66, 2699–2746 (2024). https://doi.org/10.1007/s10115-023-02042-x
33. [33] Wilkinson, M. D. et al. The FAIR guiding principles for scientific data management and stewardship. Sci. Data 3, 160018 (2016). https://doi.org/10.1038/sdata.2016.18
34. [34] Klein, J.-F. MoRoOp, version 1.0.1. KTH Data Repository (2026). https://doi.org/10.71775/kth.vx0cq-w7h93
35. [35] Klein, J.-F. MoRoOp. Hugging Face https://huggingface.co/datasets/Self-Organizing-Production-Logistics/MoRoOp (2026).
36. [36] Klein, J.-F. MoRoOp dataset toolkit, version 1.0.0. Zenodo archived GitHub release (2026). https://doi.org/10.5281/zenodo.22809725

Author Contributions

J.-F.K. designed the study, collected the data, developed processing scripts, and wrote the manuscript. Y.J. designed the study, wrote and reviewed the manuscript.

Funding

Open Access funding provided by KTH Royal Institute of Technology. This work was supported by XPRES (Excellence in Production Research).

Competing Interests

The authors declare no competing interests.