Collecting industrial teleoperation data in a lab is straightforward. Collecting it on a working factory floor, around people, machinery, and a production schedule that does not care about your dataset, is a different discipline entirely.
This guide covers why in-situ industrial data is worth the difficulty, the constraints you inherit the moment you leave the lab, the safety practices that are genuinely non-negotiable, and how to collect without disrupting output.
Why factory-floor data is worth the difficulty
Lab-collected industrial data has a consistent weakness: it is too clean. Parts arrive correctly oriented, lighting is even, nothing is greasy, and no one walks through the frame. The failure modes that actually stop a production line never appear in the dataset.
Real floors supply the opposite. Misfed parts, worn fixtures, variable lighting across shifts, surface contamination, and the constant presence of people. That is the distribution your robot will be deployed into, and it is why long-tail capture in situ is worth the operational pain.
The constraints you inherit the moment you leave the lab
| Constraint | What it means in practice |
|---|---|
| People in the workspace | Safeguarding governs everything; speed and force limits apply |
| Production takes priority | Collection happens around output, never instead of it |
| Fixed cycle times | You cannot pause mid-task to reset a scene |
| Existing safety systems | Light curtains and interlocks will stop your episode mid-capture |
| Site network policy | Often no outbound connectivity from the cell at all |
| Confidentiality | Cameras see parts, processes, and sometimes people |
| Union and works council agreements | Recording people at work is a negotiated matter, not an IT one |
| Environmental conditions | Dust, vibration, temperature, and washdown affect sensors |
Safety comes before data, every time
Teleoperating an industrial arm near people is a different risk category from teleoperating a tabletop rig. A remote operator has degraded situational awareness by definition: they see what the cameras show and nothing else.
Non-negotiables
- A local person with authority to stop. Someone physically present who can halt the cell regardless of what the remote operator is doing.
- Speed and force limits appropriate to a shared workspace. Collaborative operation has established standards; teleoperation does not exempt you from them.
- Fail-safe on link loss. The robot stops safely when connectivity drops. It never continues on last command.
- Latency visible to the operator. A remote operator working through an unnoticed delay is the clearest predictor of an incident. See latency budgets.
- Documented handover. Who has control, when it transferred, and how it returns.
These requirements exist independently of the data program. Treat safety review as a prerequisite for site access, not a step in your collection plan. Work with the site’s own safety function rather than around it.
What we carry over from public-space operations
We run remote monitoring and intervention for an autonomous mobility company operating sidewalk delivery robots and self-driving passenger vehicles. Those robots operate around uninvolved members of the public, which is a stricter environment than most factory floors.
Three practices transfer directly:
- Separate supervision from control. Most incidents need a decision, not manual driving. Keeping those two modes distinct reduces both risk and latency sensitivity, as covered in remote assistance vs remote driving.
- Log every handover as a structured event. Trigger, acknowledgement time, resolution, and root cause. This turns safety records and training data into the same artifact.
- Escalate on a clock, not on judgment. If an operator has not resolved a situation within a set window, it escalates automatically. Removing discretion under pressure is what makes the process reliable.
Collecting without disrupting production
- Shadow first. Record the existing process before introducing teleoperation. It costs nothing operationally and gives you a baseline.
- Use scheduled downtime. Changeover windows and maintenance slots are where deliberate variation can be staged safely.
- Capture the exceptions, not the routine. A thousand identical nominal cycles teach less than fifty genuine anomalies.
- Instrument, do not intervene. Wherever possible add sensing to the existing cell rather than changing how it runs.
- Buffer locally, transfer later. Assume no outbound connectivity. Write to local storage and move data on a controlled schedule.
- Agree redaction rules in advance. Faces, badges, and identifiable process detail need a documented handling policy before the first recording, not after. See our approach to compliance and security.
For an in-situ programme run to a tight timeline, see our mobile manipulation case study and its 90-day path to production.
Frequently asked questions
Do we need a safety assessment for a temporary data collection setup?
Yes. Temporary does not mean exempt. Any change to how a cell operates around people warrants review, and most sites will require it before granting access regardless of your view.
How do we handle recording people at work?
Through the site’s existing employee consultation process, not through your own consent form. Requirements vary by jurisdiction and by agreement. Build in redaction capability from the start; it is far cheaper than retrofitting it. Our operator consent page covers our own practice.
Can we collect without connectivity?
Yes, and you often must. Local buffering with scheduled physical or controlled transfer is standard on secure sites and should be assumed rather than treated as an exception.
Is factory data reusable across sites?
Partially. Task structure and failure taxonomies transfer well. Specific fixtures, part geometry, and lighting do not, which is why multi-site collection beats deep collection at one site for generalization.
Industrial data is harder to collect and worth more per episode than anything you can stage in a lab. If you are planning in-situ capture and need the safety and data-handling model worked out before you approach the site, tell us what you are building.
