Short answer
Data center hardware demonstrations record racking servers, patching and dressing cables, and swapping drives or modules. The environment is structured and dense, so recordings can support step recognition, part and port identification and procedure checking. They cannot provide robot actions, insertion forces or anything the operator's security rules forbid recording, and those rules often limit what can leave the site.
Why this task family is special
A data center looks regular: standard rack units, standard rails, labeled ports, repeated layouts. That regularity helps perception and planning. The difficulty is in the details. Rails must be aligned and latched, cables routed without strain, connectors seated with the right feel, and a drive carrier pulled and inserted without damaging adjacent equipment.
The environment is also controlled. Access requires approval, devices are logged, and camera policies are strict because images can show customer equipment, labels, badge readers or network topology. Those constraints shape the dataset more than the task does. They are the reason this page exists separately from general opening containers and packaging or maintenance pages.
Task anatomy
| Task | Steps | Hard parts |
|---|---|---|
| Server racking | Unpack, lift, align rails, slide in, latch, secure | Weight, alignment, two-person lift, rail variants |
| Cable patching | Identify ports, route, seat connector, label, verify link | Dense bundles, small latches, labeling accuracy |
| Cable dressing | Bundle, tie, route through managers | Bend radius, access in tight cabinets |
| Drive or module swap | Locate faulty unit from alert, release, remove, insert, confirm | Correct slot, hot-swap order, tool-free latches |
| Verification | Check LEDs, console status, ticket update | Reading small indicators |
Failure modes: wrong port, partially seated connector, bent pin, dropped screw, wrong drive pulled, and an unlabeled cable that sends the technician down a trace.
Procedure layer
Data center work is often written down as a method of procedure, with checks and rollback steps. These documents are a natural companion to video; see data center methods of procedure. IT tickets may record which unit was swapped and why; the catalog entry on IT service management tickets describes related records. The O*NET database includes task statements and detailed work activities that can help name the tasks consistently across suppliers (O*NET Resource Center), though it does not describe motions at the level of a robot step.
What the data can support
- Step and procedure recognition. Video tied to a method of procedure lets a model follow ordered steps and detect skipped checks.
- Part, port and label recognition. Close-up images of connectors, drive carriers and rack labels support identification; see object recognition vs manipulation data.
- Layout understanding. Rack-unit positions and cable paths.
- Hand and tool use. With wrist or head cameras, finger placement on latches and carriers is visible; see wrist camera human demonstrations and in-hand manipulation from video.
- Evaluation of task completion. Ticket or console confirmation provides success labels independent of the video.
What it cannot support
- Insertion force and feel. Seating a connector, snapping a latch or sliding a heavy server depends on tactile feedback. Video does not carry it; see when video is not enough.
- Robot actions. Dexterous finger movement on tiny latches cannot be replayed on a different hand; see the embodiment gap.
- Internal state. Whether a link came up or a RAID rebuilt is on a screen or in a log, not in the hands.
- Visibility inside cabinets. Rear-of-rack work is dark, cramped and occluded by cables.
- Transfer across vendors. Server, rail and carrier designs vary by manufacturer. One site's hardware does not cover another's.
- Anything the security policy removes. If rack labels, customer names and screens are redacted, learning signals can disappear with them.
Capture and security constraints
Typical rules include no personal devices, escorted access, and approved cameras only. Footage may be reviewed by the operator before release. Plan for these steps:
- Decide before recording what must be visible (ports, carriers, LEDs) and what must not (customer labels, screens, badges).
- Use sealed or approved cameras and agree the storage location on site.
- Record under a ticket or work order so each clip is linked to a task and an outcome.
- Review redaction effects on training value; see redaction in demonstration video.
Illustrative collection spec
# Illustrative only; synthetic values
dataset: dc_hardware_v0
tasks: [rack_server, patch_cable, dress_cable, swap_drive]
sites: dc_site_002, dc_site_005 (colocation halls, synthetic IDs)
hardware: 3 server families, 2 rail types, 2 patch-panel types
capture:
head_camera: approved device, 30 fps
wrist_camera: optional, on technician
rack_camera: tripod, rear view where permitted
labels:
procedure_id: links to a method of procedure
steps: start/end per step; checks flagged
parts: connector_type, drive_form_factor, rack_unit_range
outcome: ticket_closed / reopened / retry
redaction: customer labels and screens masked at source; mask coverage logged
splits: by site and hardware family
excluded: robot actions, forces, network topology, credentials
Acceptance criteria
- Every clip links to a procedure ID and a ticket or work-order outcome.
- Redaction masks are logged, and a sampled review confirms ports, latches and hands remain visible.
- Hardware families and rail types are listed with counts.
- Retries and corrections are preserved.
- Evaluation sets are held out by site and hardware family.
Permissions and provenance
Recording in a colocation facility touches several parties: the facility operator, the tenant who owns the equipment, and the technicians. Ask who owns rights to footage that shows tenant hardware and labels, and whether the tenant agreement restricts it. The EDPB guidelines on video devices are a reference on notice and proportionality (EDPB, 2020). This is not legal advice. Redaction can reduce what is exposed but does not by itself settle contractual or security obligations; see worker consent and identifiable people for the worker side.
Questions to ask suppliers
- Which operator policies govern cameras, and have they approved recording for AI training?
- Who owns rights in recordings that show tenant hardware, labels or screens?
- Which hardware families, rail types and connector types appear, and how many clips per task?
- Are clips linked to method-of-procedure IDs and ticket outcomes?
- What redaction was applied, and was its effect on hands and ports tested?
- Are retries, errors and rollbacks included?
- Can the supplier support a scripted session on staging hardware outside a production hall?
- Who stores the footage during and after recording?
Discuss your requirements
If you are scoping data center hardware data, describe the tasks, hardware families, modalities and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. If nothing existing fits, SourceX can scope a commissioned collection of new recordings. A request does not guarantee a match; SourceX follows up about potential sources.
Start with the humanoid training data guide or the workplace task demonstration hub. Related catalog entry: first-person video of skilled manual work.
Describe the workplace demonstration data your robotics project needs
Sources
- ONET Database (ONET 29.1 per search snapshot): Task Statements and Detailed Work Activities — O*NET task statements and detailed work activities as a task taxonomy
- Guidelines 3/2019 on processing of personal data through video devices (Version 2.0) — Guidance on personal data processed through video devices