Solutions · Emerging category · Reference architecture
Display-free is the point.
Display-free capture eyewear for robotics and embodied-AI training data. An original design manufacturing (ODM) project in scoping.
Embodied AI Data Capture Glasses is a display-free reference architecture for robotics, physical-AI and vision-language-action (VLA) data collection. XY-DC is scoped as an original design manufacturing (ODM) project. Stereo capture, camera and inertial timing, per-unit calibration, companion modules, continuous-record power, privacy controls and capture-point provenance are engineering requirements to evaluate; they are not published specifications or standard capabilities of an existing SmartXY product.
Reference architecture in scoping; not an orderable SKU. Device specifications, supported interfaces, calibration outputs, synchronization accuracy, runtime and production readiness require project-specific validation.
For robotics teams, physical-AI teams, VLA model teams and training-data project owners.
01 / Design intent
Display-free is the point. The proposed capture architecture has no waveguide, projector or near-eye display. Its design review prioritizes useful synchronized recordings, calibration records, a defined recording duty cycle and controls for responsible data collection.
Proposed stereo cameras and inertial data feed the capture host with an agreed timestamp model.
Associate recordings with unit calibration records and evaluate capture-point signing where required.
Scope encoding, buffering, connectivity and data export against the actual recording workflow.
The project owner defines downstream data handling, consent records, access controls and training or research use.
Camera arrangement, interfaces, clock relationships and data formats remain subject to project-specific feasibility and validation.
| Review area | Display-oriented workflow | XY-DC design target |
|---|---|---|
| Wearer output | Plan near-eye visual information for the wearer. | Exclude the waveguide, projector and near-eye display from the proposed capture design. |
| Capture priorities | Review capture and display together where the application needs both. | Evaluate stereo timing, inertial timestamps, calibration records and recording integrity. |
| Duty cycle | Define power needs around the selected display and application workload. | Model continuous recording, encoding, storage and transfer; validate the requested duty cycle. |
| Acceptance evidence | Agree visual-output and application requirements. | Agree data-quality tests, privacy-control behavior and downstream verification. |
Use the architecture to frame an RFQ for egocentric data capture glasses, robot training data glasses or a VLA data capture wearable. Confirm the recording workflow before selecting hardware.
02 / Engineering requirements
These blocks define proposed ODM development work. Each needs agreed interfaces, acceptance criteria and evidence before it becomes a capability commitment.
Evaluate rigidly mounted forward stereo cameras, sensor-level trigger alignment and the ISP/MIPI integration path. Define how frame timestamps and inertial samples relate to the capture clock.
Document the sensor and host interfaces, then measure synchronization error and timestamp behavior on the agreed prototype.
Define intrinsics, extrinsics, distortion and rectification outputs, serial-number association and machine-readable delivery. Scope the calibration station, tooling and line integration as project work.
Agree calibration procedures, output formats, acceptance criteria and repeatability checks before committing production delivery.
Evaluate wrist, body-worn or tool-mounted companion capture modules as separate development items. Define the relationship between head-unit and companion clocks, reconnection behavior and cumulative drift.
Measure alignment and drift across the intended recording duration and wireless conditions; no synchronization accuracy is published.
Model concurrent camera capture, encoding, storage and periodic upload against the requested working-shift duty cycle. Review battery architecture, heat paths, fit and the resulting weight budget together.
Validate recording duration and thermal behavior under the agreed workload and environment before confirming device specifications.
Evaluate an externally visible mechanical camera shutter and a mechanical microphone mute. Define how each control changes capture state and how the wearer and people nearby can verify that state.
Review the physical controls and capture-state behavior alongside the project owner's consent, retention and intended-use requirements; hardware alone does not establish deployment compliance.
Evaluate secure-element signing at capture, key ownership, controlled provisioning and verification by the receiving system. Include relevant cryptographic and intended-use review in project definition.
Agree the threat model and recording-integrity checks, then validate the signing and verification path on the selected hardware and software.
03 / Platform context
Review the relevant platform with SmartXY to identify what may transfer and what requires new development. Existing product configurations do not establish stereo, synchronization or calibration support for XY-DC.
An existing camera-glasses platform to discuss camera integration and wearable form-factor constraints. It is not a validated stereo or calibration platform.
An existing field-operation platform to discuss first-person capture and external-power workflow requirements. Transfer to a new capture architecture requires review.
An existing standalone Android camera-and-display platform with its own Wi-Fi connection and off-device model inference. Its dual-eye display architecture is distinct from the proposed display-free XY-DC design.
An existing head-worn platform to discuss video-path and fit requirements. Its product-specific configuration does not establish a validated dataset-capture workflow.
04 / ODM development
The engagement model is ODM. Scope the device, companion modules, calibration process and receiving software together, with commercial terms confirmed for the agreed project.
Pilot volume, schedule, prototype costs, NRE, tooling and any BOM disclosure terms are agreed per project after feasibility review. Read about SmartXY OEM, ODM and JDM engagement or explore the engineering review areas.
05 / Technical questions
They are a proposed display-free reference architecture for egocentric recordings used in robotics, physical-AI and VLA training-data projects. XY-DC is an ODM scoping direction, not a published product SKU.
Forward stereo cameras and sensor-level trigger alignment are requirements for feasibility review. Sensor selection, host interfaces, synchronization accuracy and acceptance tests must be agreed and validated per project.
Raw camera access, timestamped inertial samples and their clock relationship belong in the SDK and interface requirements. Availability, data formats and delivery scope depend on the selected hardware and software and require engineering confirmation.
The project can scope machine-readable intrinsics, extrinsics, distortion and rectification records associated with each unit serial number. Station design, procedures, acceptance criteria and delivery formats require agreement and validation.
Companion capture modules can be evaluated as separate development items. The feasibility study must define cross-device clock alignment, wireless behavior, reconnection and drift acceptance; no accuracy or ready-made module is promised.
No device runtime is published for this reference architecture. Define the recording duty cycle, camera workload, encoding, storage, upload schedule and operating environment, then validate power and thermal behavior on the agreed build.
Pilot volume, schedule, prototype costs, NRE, tooling and any BOM disclosure terms are agreed per project after feasibility review. The reference architecture does not publish a fixed MOQ, mass-production date or pricing formula.
Mechanical camera and microphone controls, capture-point signing, key provisioning and downstream verification are requirements to evaluate. The project owner must define intended use, consent and data handling; applicable market and cryptographic review is part of scoping, and hardware features alone do not certify a deployment.
06 / Start with your capture requirements
Share the intended use, capture modality, downstream dataset use, interface needs, recording duty cycle and target markets. SmartXY can use that brief to discuss feasibility and the validation work to scope.
Architecture scope reviewed . Reference architecture in scoping; not an orderable SKU. Device specifications, supported interfaces, calibration outputs, synchronization accuracy, runtime and production readiness require project-specific validation.