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 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.
- Spec translation: turn a research team's requirement into vendor-testable acceptance criteria (timing, raw access, calibration, bandwidth).
- Vendor landscape and qualification across Shenzhen, Dongguan, Shanghai and Hangzhou — existing products first, custom builds only when nothing fits.
- Timing and validation testing on real units before you commit (exposure alignment, camera-to-IMU offset, dropped frames over long runs).
- M1 prototype programmes with milestone gates, then fleet production with QC and logistics.
- Camera-system engineering: MIPI→GMSL2, multi-camera synchronisation on Jetson and Rockchip, raw data paths to a backpack computer.
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 reference | Exposure / acquisition time — never host receive time |
| Data path | Raw or minimally processed, documented format, open calibration |
Devices and parts we track for this practice
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.
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.





