Egocentric Office Printer and Shredder Data

Egocentric office printer and shredder data is real-world video recorded from the point of view of a person who is working with a printer tray, a paper jam or a shredder. The camera shows what the person sees: the hands, the sheets, the tray and the opening they feed. Alongside the video, each episode follows the Firsthand episode schema, with depth, 3D hand pose, contact events and frame-accurate action segments aligned on one hardware clock.

Teams search for it under several names, including office robot training data, egocentric printer paper jam clearing video and a document shredding dataset. They all describe first-person demonstrations of the same office jobs, collected to a written spec. This page covers only what the Firsthand site states about it, and marks everything else as Not stated.

Two rows in the site task catalog cover this work, both in the Office Document Station environment. The first is "Load tray + clear jam", described as "Load a paper tray and clear a jam." The second is "Shred documents", described as "Feed sheets into a shredder." Both are rated Easy, both use a multiview rig with handheld grippers, and both are listed as Available on request.

Anything outside those two rows is Not stated. That includes copying, scanning to a file, replacing consumables, emptying a shredder bin, and any named type of jam or shredder, so none is claimed here. If your policy needs one of them, you write it into the spec and we scope it, because the catalog rows are a starting vocabulary, not a fixed menu.

The site defines Available on request as work that is scoped and recruited to spec when a buyer asks for it. Neither row is listed as Active collection or Ready to deploy, so the site does not say that a printer or shredder capture stream is running today. A first batch is therefore quoted against your spec rather than drawn from a stream that already exists.

The site describes the Office Document Station as a desk-and-document station with a printer and tray, binders, a stapler, a label maker and mailers. Its rows use the multiview rig with handheld grippers, which the site describes as a staged working set recorded by a multiview rig while the operator performs the task with handheld grippers, so demonstrations map onto a robot end effector.

The environment examples name a printer and tray but do not name a shredder, even though the Shred documents row sits in that environment. The site names no office, company or building, and does not state the number of sites, the regions or the venue type. It does not state capture at a customer own facility either. Environment, access and schedule are agreed in the written spec.

The catalog states the capture mode for both rows: a multiview rig with handheld grippers. The site also states, for the printer, tray and jam task, that two wrist cameras, hand pose with per-joint visibility and depth from the calibrated stereo rig address the problem of a hand disappearing inside the device. It does not state a per-environment stream list, so which of the ten streams an order carries is decided in the skill spec.

Camera count, resolution, frame rate, desk layout, paper volume and the type of printer or shredder are Not stated, so raise any of them in the spec.

Each episode follows the Firsthand episode schema: ten streams synced under 2 ms, with head and wrist RGB, depth, 3D hand pose with per-joint visibility, contact and grasp events, and frame-accurate action segments. Feeding a sheet into a shredder is a short contact event with a fast release, and the site pairs it with contact events on grasp and release, an IMU on one clock and action segments. Reaching into a tray or a jam is marked by action segments that include the recovery.

Object labels use the terms your spec sets. Paper sizes or stock types, jam types, shred types and equipment makes are Not stated. Task durations, cycle times and the number of episodes are Not stated too. Success or quality labels, such as whether a jam is fully cleared, are Not stated, as are certifications and robot results. The site makes no safety-compliance claim for this work.

The catalog rates both rows Easy, so the site does not call them Hard, and this page makes no claim about robot results. What the site does say is where the capture is difficult. Reaching into a printer hides the hand from the head camera, and feeding a sheet is a short contact event with a fast release. The site also describes paper as thin and flexible, so a sheet changes shape every time it is touched.

The viewpoint matters too. The site states that a robot or humanoid perceives from a head- or wrist-mounted camera, not a static overhead shot, and that egocentric capture matches that geometry.

A good spec treats each named job as its own task. Loading a tray, clearing a jam and feeding a shredder each get a start state, an end state and a set of accept criteria. For the jam, the site lists a jam start state and a failure and recovery case, so the spec can say whether a clean run is enough or whether the fault and the recovery must both appear. That keeps action segments consistent across contributors and lets you ask for more of one job without re-collecting the other.

Delivery formats are RLDS, LeRobot and WebDataset, plus HDF5, zarr and Rerun .rrd. These episodes use the same schema as every other Firsthand collection, so a loader that reads another Firsthand dataset reads this one without changes. The format table below sets each format against what its official documentation states.

Every batch is validated against signed accept criteria before it ships, with a reject log, and delivery is rolling, per validated batch. Rejected items are recaptured at our cost, and billing is per validated hour.

Every episode links to a signed contributor release through a documented consent chain, and the consent record is part of the delivery. A vision model runs on every frame at ingest, flagging faces, heads, licence plates and any legible screen or document. The site describes the documents class as phone and monitor content, forms, badges and mail that would leak names, addresses or account data. Those regions are irreversibly blurred, and a human reviewer confirms the result before footage ships.

If the reviewer is unsure a region is fully covered, the episode is held or discarded, never downgraded and shipped. So legible names, addresses and document content are not in the delivered pixels. If your pipeline needs document content, raise it before the spec is signed; whether any engagement can keep specific content is Not stated. The site states no other privacy, compliance or legal terms for this work, and no in-home capture.

Where coverage is already deep, the first validated batch lands in a median of 48 hours from signed spec. Thin environments typically take three to four weeks, because vetting operators there is the bottleneck, and we quote that up front. The site does not state how deep coverage is for these two rows, and they are Available on request, so plan on a quote rather than assuming the 48 hour figure.

The site also states program milestones. A pilot reaches its first delivery in two to three weeks, and a standing program reaches full rate in four to six weeks. Those assume capture coverage is already in place. On-demand top-ups run against the same spec and accept criteria after each training run. A batch size and a later-batch turnaround are Not stated, so both are quoted against your spec.

You describe the printer and shredder jobs, the environment and the sequence your policy needs. We turn that into a written spec covering tasks, environments, capture tier, annotation depth and accept criteria, then quote reach, timeline and price before any capture begins. This is the custom egocentric data collection route that every Firsthand task family follows.

A Spec Pilot, a small and fast first batch, can prove the spec and accept criteria before you scale. Every collection ships under a perpetual, buyer-owned commercial license, with a reject log and signed accept criteria on every batch.