Operational Logs from Deployed Robot Fleets as Training and Evaluation Data

What fleet logs contain and why they differ from demonstrations

Fleet logs record robots acting autonomously under production constraints, which makes them a different asset from teleoperated demonstrations. Demonstration corpora such as those pooled in Open X-Embodiment were collected to teach skills, with consistent episodes across many embodiments [1]. Operational logs instead record what happened when a deployed policy met real aisles, pallets, people and shift patterns, including the failures. For demonstrations, see robot teleoperation data and the owner page on robotics training data for embodied AI.

A typical operator holds several layers, often in different systems:

• Fleet manager and WMS/MES events: task requests, assignments, completion or cancellation codes, timestamps and station IDs.
• Vehicle state streams: pose, velocity, battery, load state, operating mode, safety state and active errors. Fleets that speak VDA 5050 publish this as JSON over MQTT on a state topic alongside order, instantActions, visualization, connection and factsheet [4][5].
• Onboard recordings: ROS 2 bags, increasingly in MCAP, holding laser scans, odometry, costmaps and sometimes compressed images [6][7].
• Interventions and maintenance: remote-assist sessions, manual pushes, e-stop events, CMMS work orders and part replacements.

Where the training and evaluation value sits

The main value is real success and failure distributions across facilities, which simulation and lab demonstrations rarely reproduce. Fleet research stresses that useful generalist models must learn from heterogeneous data across sensor modalities and embodiments [2], and deployed fleets are one of the few sources of that heterogeneity at production scale.

Buyers usually target four uses:

• Policy fine-tuning on navigation or pick sequences, weighted toward hard cases such as narrow aisles and mixed traffic.
• Failure analysis: joining fault codes and interventions to the sensor context just before them. See robot failure, intervention and recovery data.
• Real-world evaluation: held-out facilities or time periods with ground-truth task outcomes, kept separate from training. See private evaluation sets for multimodal models.
• World models and forecasting: predicting congestion, battery depletion or fault onset from state sequences, often paired with operator notes as covered in paired time-series and text data.

Retention, sampling and format gaps to check first

Most fleets do not keep full-rate sensor data, so assume logs are sampled, truncated or event-triggered until the operator shows otherwise. Fleets can generate terabytes of video and LiDAR, and uploading all of it from the field is impractical [3]. Some operators keep fleet-manager events for months but rotate onboard bags within days, saving only snippets around faults.

Common failure modes buyers find late:

• Ring-buffer bags: only the seconds before an e-stop survive, so successful runs have no sensor context and the class balance is skewed.
• Clock drift: vehicle, fleet-manager and WMS clocks disagree, breaking joins between a fault code and its scan.
• Firmware and map churn: error codes, map IDs and coordinate frames change between software releases without a version field in the export.
• Schema drift between protocol versions: VDA 5050 messages carry a protocol version in their header, major versions differ in fields, and mixed fleets may run more than one [4].
• Lossy exports: CSV dumps from a vendor dashboard drop the MCAP schema and channel definitions that make recordings self-describing [7].

Who owns robot telemetry

Ownership is often split between the operator, the robot OEM and the facility owner, so rights must be traced before pricing. Some robots-as-a-service and fleet software agreements give the OEM rights to telemetry for product improvement, and some restrict the operator from sharing it with third parties. Buyers should read the operator's OEM agreement, not only the operator's own consent.

Terms can also shift over time. FTC staff have warned that quietly changing terms of service to permit AI training on previously collected data may be unfair or deceptive [8], which matters if an OEM or operator relies on a recent terms update. Public datasets carry license risk too: an audit of 1,800+ text datasets found licenses omitted or mislabeled at high rates on popular hosting sites [9], so check open robot data the same way. For the full ownership analysis, see who owns robot data and chain of title for AI training data.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

People, layouts and other sensitive content

Camera and LiDAR snapshots from working facilities capture workers, visitors and site layouts, so de-identification has to cover more than log fields. Faces and badges in images, operator IDs in intervention records, and named stations or customer SKUs in task data are the usual direct identifiers. Floor maps and rack layouts can reveal a supplier's operations even when no person appears.

Practical controls include blurring or dropping image frames, hashing operator and vehicle IDs consistently so sequences still join, and coarsening map coordinates or transforming them into a local frame. The owner guide on how to de-identify sensor and IoT data covers methods in more depth.

Request template for a fleet log dataset

A precise request names the robot class, tasks, fields and retention you need, so suppliers can say quickly whether their logs fit.

Illustrative example: invented to show structure; it does not describe an available dataset.

Before payment, run the acceptance checks in acceptance checks for robot datasets: verify join rates between events and recordings, outcome-code consistency and timestamp alignment on a sample.

How SourceX handles requests for fleet logs

SourceX sources operational datasets from US companies on request and manages the commercial process, including licensing and ongoing purchases. Fleet logs are not held in stock, and a request does not guarantee a match. You describe the data, SourceX looks for US businesses that hold it, and every release is approved by the supplying company. To start, describe your target logs on the SourceX buyer page.

Each dataset is rights-reviewed for ownership and consents, then delivered under a license that defines the records, uses, term and delivery. Personal details are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect. Delivery runs through private, access-controlled workflows after an executed agreement and supplier approval. SourceX does not train models and does not publish prices. More context on the wider category is in the multimodal training data hub and the owner page to license sensor and IoT data.

Source deployed robot fleet logs for your models

SourceX finds US companies that hold the operational data you describe, assesses data and licensing permissions, and agrees pricing and allowed uses in a license before anything is delivered. Nothing is contracted until a supplier agrees. Describe the fleet logs you need on the SourceX buyer page.