Talk to us
← PracticesFlagship practice

Robot-learning data hardware

Egocentric headsets, body and object trackers, UMI grippers and synchronised multi-camera systems for teams training robot foundation models.

Robot-learning data hardware
The problem

Robot-learning teams need capture hardware that produces training-grade data: every camera, IMU and tracker on a known clock, raw streams that their own algorithms can consume, and calibration they can trust. Most off-the-shelf devices were built for XR or security, not for learning. They interleave frames, timestamp on the host, compress by default and lock the SDK.

What we deliver
  1. Spec translation: turn a research team's requirement into vendor-testable acceptance criteria (timing, raw access, calibration, bandwidth).
  2. Vendor landscape and qualification across Shenzhen, Dongguan, Shanghai and Hangzhou — existing products first, custom builds only when nothing fits.
  3. Timing and validation testing on real units before you commit (exposure alignment, camera-to-IMU offset, dropped frames over long runs).
  4. M1 prototype programmes with milestone gates, then fleet production with QC and logistics.
  5. Camera-system engineering: MIPI→GMSL2, multi-camera synchronisation on Jetson and Rockchip, raw data paths to a backpack computer.
Our standard

What we write into the specification.

Tracking camera ↔ tracking camera< 100 µs (exposure-aligned)
Tracking camera ↔ head IMU< 500 µs
RGB left ↔ RGB right< 500 µs
RGB ↔ tracking clock< 1 ms
Timestamp referenceExposure / acquisition time — never host receive time
Data pathRaw or minimally processed, documented format, open calibration
Questions
Can you supply an existing egocentric data-collection headset instead of a custom build?

Usually yes. We start from devices that already ship — 2-camera stereo RGB-IMU headsets, 4–6 camera SLAM headsets and modular ego/wrist/gripper kits — and only scope custom engineering for the specific gaps (frame rate, IMU rate, exposure timestamps, raw output).

How do you verify synchronisation claims?

We test units with a timing rig: a pulsed LED visible to every camera and a sharp mechanical event seen by cameras and IMU. We report measured offsets in microseconds and dropped frames over a 30-minute capture, not vendor statements.

Do we own the data and calibration?

That is a contractual requirement we write into every vendor engagement: raw data access, per-unit calibration in an open format, and no licensing tied to the vendor's algorithms.

Start a conversation

Building hardware that has to learn? Talk to us.

Send a spec, a sketch, or just the problem. We reply within 24 hours (HKT), usually the same day.

We reply within 24 hours (HKT). Your details go only to the HOLON team.