Tracked device class of a tracker is switching between TrackedDeviceClass_GenericTracker and TrackedDeviceClass_Controller

[tomassykora]

Lately I noticed a strange behaviour in openVR (it wasn't happening before). I'm accessing the tracker's data using this code:

for (int i = 0; i < vr::k_unMaxTrackedDeviceCount; ++i) {
       vr::ETrackedDeviceClass trackedDeviceClass = vrPointer_->GetTrackedDeviceClass(i);
       if (trackedDeviceClass == vr::ETrackedDeviceClass::TrackedDeviceClass_GenericTracker) {
              // do something
        }
}

This worked fine for me until now. I have a setup with two base stations and a HTC Vive tracker. When I start the application, the returned class is TrackedDeviceClass_GenericTracker. But when I start moving with the tracker, the class of the device is TrackedDeviceClass_Controller and the returned rotation is rotated by 90 degrees. When I stop the movement of the tracker, the class is switched back to TrackedDeviceClass_GenericTracker after some time and the returned orientation is rotated back by 90 degrees.

This definitelly wasn't happening a month ago, so I'm wondering if it is a bug after an update of SteamVR or something like that. Have you encountered similar behaviour? Any idea how to fix that?

[BOLL7708]

They made changes to address this, I think, in the recent (yesterday) SteamVR beta update. See here. There have been at least three reports of it in the SteamVR forums, one from me 😋 Reading the description it might not help if you are running entirely without controllers, though... 🤔

Changed left/right hand selection for Vive trackers in “handed” mode so that they will always be selected after Vive controllers (or any controllers) if those are present. This fixes the issue with Vive Tracker users finding that their controllers don’t work to control anything.

[tomassykora]

Thanks, I just tried the Beta. Unfortunatelly it doesn't seem to be fixed completely. The tracker isn't switching classes anymore but is of a controller class and rotated by 90 degrees, which is better than before and usable, but another fixes are needed anyway.

[ethanfowler]

Am I wrong, or does this change render OpenVr clients unable to distinguish between Vive wands and trackers?

[tomassykora]

I think you are correct. I've already roll backed to the previous SteamVR version.

[JoeLudwig]

Am I wrong, or does this change render OpenVr clients unable to distinguish between Vive wands and trackers?

For trackers that are set to be "held in hand", that's right. Users can set their trackers to use a different role and they'll start returning the GenericTracker controller type. You can find more details here: https://steamcommunity.com/games/250820/announcements/detail/1697186829260359619

My best guess about why it was switch is that the trackers were swapping in and out of being selected as the right or left hand. That shouldn't have changed the tracked device class though.

Having trackers that are held in hand act as controllers is intentional. It sounds like you can no longer reproduce the switching behavior. Should we close this one?

[tomassykora]

The tracker management UI is available on in-headset dashboard in the settings UI. Just click the "Manage Vive Trackers" button and change any trackers to "Disabled".

Can I set this somehow in OpenVR without a headset? My application doesn't use one, so I'm not sure how in-headset settings may help in my case.

[ethanfowler]

So as a workaround for this baffling SteamVR decision, we've been using SteamVR version "v1527117754 - 6/21/2018 Hotfix". As of today, this option has been removed.

Is there still no way to differentiate trackers and controllers via the OpenVR API?

[JoeLudwig]

@ethanfowler You can differentiate (controllers + trackers acting as controllers) from (trackers acting as something else) with the device class. If you have trackers that you don't want to act as controllers you can configure them with the "Manage Vive Trackers" option under the devices menu in the SteamVR status window. (Or in-headset via the settings panel in the dashboard.)

[ethanfowler]

Right, but importantly, is there no way to distinguish between actual controllers and trackers acting as controllers?

[BOLL7708]

@ethanfowler as Joe mentioned you can check the device class for the index of the tracked device. It'll stay as Generic Tracker while the controller role is what changes dynamically. They're two distinct properties.

[JoeLudwig]

@BOLL7708 Not exactly. For trackers that are configured to be controllers (which is the default) they return the device class controller. If that tracker is reconfigured to be a left foot or disabled it'll start returning generic tracker.

[BOLL7708]

Huh, seems I have not messed around enough in the binding interface with Trackers. Will do so to avoid spreading more misinformation 😅

Edit: Thinking about it I believe my project makes the assumption the device class never changes so they are cached after first detection. I should probably update this behavior 🤔

Edit2: While I've now made the device class to update on the proper event(s) I get no change in class. Then I realize I'm making a companion background application, and of course setting bindings for a wholly separate game would not affect how anything is reported in my application. Currently there's no way to even create bindings for background applications using the interface so ¯\_(ツ)_/¯

[CharlesHolbrow]

It seems like for higher lever APIs (Ex Unity) automatically re-assigning the class and role makes sense. But for those of us using the OpenVR directly, this is very inconvenient.