Body and Object Trackers for Robot-Learning Data: LED Pucks, Self-Tracking Pucks, IMU Suits and Custom Designs

An egocentric headset tells you where the head is and what it sees. Robot learning also needs to know where the hands, body and manipulated objects are, in the same coordinate frame and on the same clock. That is the job of trackers — and it is where many data-collection programs hit an unexpected wall.

Four architectures

Architecture	How it works	Strengths	Weaknesses
IR-LED constellation (outside-in from the headset)	8–12 IR LEDs on the tracker; headset cameras see the pattern; pose solved by PnP, fused with the tracker’s IMU	Light, cheap, low power; shares the headset’s frame	Lost when out of the headset’s view (feet, behind the back); LED timing must match camera exposure
Self-tracking camera puck	The tracker has its own cameras and runs visual-inertial SLAM; shares a map with the headset	Works out of the headset’s view; no constellation needed	Heavier, more power, on-device pose, map alignment errors
IMU-only	Inertial sensors on body segments, skeletal model fuses them	Light, many nodes, no line of sight needed	Position drifts; no absolute object tracking
Hybrid + UWB	Any of the above plus ultra-wideband ranging to the headset	Range constraints reduce drift and bridge occlusion	More RF design, antennas and power

What off-the-shelf delivers (2026)

Product class	Example	Published characteristics	Fit for training data
Headset-tracked LED puck	Consumer XR body tracker	~27 g; 12 IR LEDs + IMU; up to 200 Hz; 25 h+ battery; reviewers report ~5 cm average position and ~6° angular deviation	Locked ecosystem; avatar-grade accuracy
Self-tracking puck	Consumer inside-out tracker	94 g; two tracking cameras; up to five per dongle; ~7 h battery; works with PC via dongle	Good for testing body/object tracking quickly; heavy; separate frame from your headset
Self-tracking + LED hybrid	Data-collection tracker lines from Shenzhen SLAM vendors	Own VSLAM plus LED tracking; claimed sub-ms to ~100 µs clock sync; pose over 2.4 GHz	Promising; verify weight, tracker count, raw access and launch status
IMU suits	Mocap suits and IMU tracker sets	Many nodes, light	Body pose only; no absolute positions or objects
Handheld self-tracking controllers	XR controllers	~160 g class; 1 kHz IMU; on-device pose	Hand-held, not wearable; heavy

Where programs get stuck

Tracker count. Headset ecosystems that track IR-LED devices commonly support two simultaneously; dongle-based systems five. Full-body plus object tracking typically needs ten or more.

On-device pose instead of raw data. Most trackers output a pose computed by the vendor’s algorithm. A team training its own models needs raw IMU samples, LED event timing and the ability to compute pose itself — or at least to record both.

Synchronisation. Wireless trackers sit on their own clocks. Without continuous offset and drift estimation, their data slides relative to the headset by milliseconds per minute.

Occlusion. LED-only designs lose feet, knees and hands behind the back. Self-tracking or IMU/UWB bridging is needed for whole-body coverage.

Weight and wearability. A 94 g puck on each ankle and wrist changes how people move. For natural demonstrations, 20–25 g is a sensible target.

Should you reverse-engineer an existing tracker?

We advise against it. Consumer tracker protocols are proprietary and usually encrypted; LED pulses are timed to the original headset’s camera exposures; and the result inherits avatar-grade accuracy with legal risk attached. Buying a pair for teardown and benchmarking is useful. Building a data pipeline on a cloned protocol is not.

What a purpose-built tracker needs

Subsystem	Starting point
LEDs	8–12 × 850 nm emitters, non-symmetric 3D constellation visible over ~270–360°, individually or group-addressable, pulsed at high peak / low duty cycle
IMU	6-axis, 1 kHz, SPI, hardware-timestamped (ICM-42688-P class; check allocation)
MCU / radio	Cortex-M4/M33 class with BLE or proprietary low-latency radio (nRF53/nRF54 class), or a UWB SoC with integrated MCU
UWB (optional)	DW3000 / QM35-class UWB for ranging and clock alignment with the headset
Clock sync	Two-way time transfer or UWB exchange; continuous offset + drift estimation; LED pulses scheduled to headset exposure
Power	150–250 mAh Li-polymer; 12 h at 150 mAh allows ~12.5 mA average before losses
Mechanics	35–45 mm diameter, < 15–18 mm thick, 20–25 g including battery, strap / clip / tapped holes
Data	Timestamped raw IMU, LED and UWB events at 1 kHz; pose optional

The hard parts are not the components — they are LED-to-exposure synchronisation, identifying ten or more trackers reliably, bridging occlusion and hitting the weight target. A realistic path is a first engineering build in six to eight weeks, refined over three to four months, with tracking software either from a SLAM vendor that supports third-party constellations or the client’s own team.

A practical sequence

1. This month: buy a self-tracking puck set and an IMU set to test whole-body capture with your pipeline; buy a pair of consumer LED trackers for teardown.
2. In parallel: confirm whether your headset vendor can support ten or more trackers and third-party LED constellations, and at what NRE.
3. Then: scope a custom puck to your spec only if no vendor path meets count, weight and raw-data requirements.

Related: Timing Is the Spec · Egocentric Data-Capture Hardware: 2026 Buyer’s Benchmark