Generic spatial accessory receives LED reports but never produces an AccessoryAnchor

Question

Created 8h

Replies 1

Boosts 0

Participants 2

We are developing a generic spatial accessory for Apple Vision Pro using the “Working with generic spatial accessories” sample and a trained .referenceaccessory file.

Environment:

visionOS: [version/build]
Xcode: [version/build]
Hardware: Apple Vision Pro + nRF52840-based BLE accessory
IMU: 6-axis IMU, 400 Hz HID reports
LED constellation: 8 x 850 nm IR LEDs, driven through MOSFETs

The BLE/HID and timing path appears to be working:

The accessory connects successfully over BLE.
ASA/HID enumeration succeeds.
The firmware receives continuous LED Output Reports from visionOS.
The Accessory Tracking Clock reaches READY.
PWM scheduling reports no late events and no queue overflow.
In the Accessory Tracking Debug View, multiple independent IR LED blobs are visible and stable at approximately 0.7 m.
At least 4 LEDs are visible from normal viewing angles.
The app resolves the .referenceaccessory and starts AccessoryTrackingProvider.

However, ARKit never produces an AccessoryAnchor. We also have no diagnostic signal indicating whether the failure occurs at:

LED candidate-point detection,
constellation matching against the .referenceaccessory, or
IMU/optical fusion.

Questions:

Is there a supported diagnostic API, log category, or Debug View indicator that distinguishes candidate-point rejection from constellation-match or fusion rejection?
Are there known acquisition prerequisites in the current visionOS beta beyond the published Accessory Design Guidelines?
Can Apple recommend a minimal validation procedure using the generic spatial accessory sample to confirm that the LED constellation is accepted by the tracking system?
Is this expected to work in a volumetric window, or are there additional lifecycle/session requirements that can prevent initial acquisition?

I can provide sanitized HID LED-report logs, timing data, Debug View captures, and a minimal reproducible project if useful.

Answer 1

Vision Pro Engineer OP

Apple

7m

Hi @tony5423

A few things to try:

Run the Working with generic spatial accessories sample unmodified against your hardware and .referenceaccessory to rule out any unintended bugs introduced by your app.
Use the Tracking Camera Debug View. With Developer Mode enabled: Settings → Developer → Debug View → Tracking Camera. Your accessory should appear under Connected Devices. If you do not see the accessory listed, there is an issue with initial recognition. You can click on your device to bring up an expanded view, where you can do some verification on the Uniform Type Identifier (UTID), the IMU, and the LED visibility.
- UTID: ensure that the UTID received via Bluetooth matches what your trained model and app expect.
- IMU: as you rotate the IMU, ensure that the correct axes are showing movement.
- LEDs: toggle Illuminate LEDs to sync the LEDs with the tracking-camera exposure. As a rough heuristic: if blobs are missing, merged, or saturated in that feed, detection is the likely bottleneck; if they look clean and no anchor still appears, look at the reference file and constellation geometry, paying particular attention to scale and coordinate systems used to define the LED points and the IMU. Also make sure that the size of the LED glow in the Debug View is similar to the size of your LEDs in the training object relative to the rest of the object. You may have to adjust the brightness of the LEDs if the blobs are too small or too big.
We expect sub-millimeter precision in the provided locations of the constellation LEDs. From looking at the screenshots of the trained vs. built model, the LEDs you are using are offset from the PCB itself. In modeling the LED constellation, make sure that you are putting the center of the modeled LED at the center of the emitting LED. In this case where the LED looks to be raised, you might have to add a perpendicular offset along the face of the LED to better represent the constellation.
A volumetric window is fine as a host; the sample itself demonstrates this with its VolumeView. Just confirm the ARKitSession and AccessoryTrackingProvider both reach a running state and your app has Accessory Tracking authorization.
Walk through the Accessory Design Guidelines, specifically the Spatial Accessories section (Reference Tutorial and Spatial Accessories Verification) for the checklist confirming the constellation and .referenceaccessory are accepted.

If the sample also fails, please file a Feedback Assistant request with a sysdiagnose captured shortly after the failure, and reply here with the FB number.