I've been testing a setup with four base stations today and due to the lack of documentation been testing different channel configurations. I've ended up configuring the space with channels ranging from S-0 through S-3, but while the base stations are recognized during room calibration, I had some trouble with the game world suddenly flipping or tracking becoming very jittery, usually when I was in the relative center between the four base stations. Unlike the BS1.0 setup, controllers that started to fly away did not come back after a while, but stayed at a positional offset away from the hands.
Is the channel config relative to the spatial setup, do they need to be ordered in any specific way or what might cause this?
Base station 2.0 channel configuration
Something went wrong while displaying this content. Refresh
Error Reference: Community_9708323_
Loading CSS chunk 7561 failed. (error: https://community.fastly.steamstatic.com/public/css/applications/community/communityawardsapp.css?contenthash=789dd1fbdb6c6b5c773d)
Report this post
S-0 through S-3 are the right channels to choose for now. It doesn't matter how they are ordered.
The firmware supporting the full 16 channels as well as other improvements for BS 2.0 should be available soon. If you're working on a large space (10x10m, for example) then this update is probably relevant to your issues.
Right now the limitation for large tracked spaces is that you need to be able to track from all of the bases in some area (say in the middle of your play space) with the HMD. If you see persistent large offsets on a controller, that means that there is cached information about where the bases are that is wrong, but we haven't yet seen the corrected information. This can happen if you re-aim a base while SteamVR is running, or re-aim a base but then restart while in a corner (rather than in the center).
I'm not in the office right now, but here's a sketch of how the space is configured: http://files.holocafe.de/temp/chaperone_space.png
The only thing that is probably uncommon is that we have placed two of the stations (S-2 and S-3) lower than the others (1vs3 meters height) as an experiment.
The controller offset wasn't there right from the start. I suddenly had the world tilting and a controller flying away while I was in the center. The controller came flying back, but never adjusted itself back to the actual physical position. But I noticed something that could well be connected to cached information. When I first did the room setup, the station S-1 was drawn at pretty much the same position as S-2. After I started walking around, the station suddenly snapped into the correct position and I've redone the room setup thereafter. But the tracking issues persisted. The controller offset (or a tilted game world) only reset when I restarted any VR application.
Some more general questions/remarks:
If SteamVR recognize each base after a while... the more BS are connected, the more the drift we have... An awful motion sickness large drift in fact...
Due to the lack of informations we are not able to set the BS 2.0 channel, anyway it's seem's that it would have changed nothing...
Ben are you working on a SteamVR Pro with the opportunity for us to change each of the 16 BS 2.0 channel? In this way and as Holocafé is asking for... Will we be able to add more than 4 BS 2.0 in the same space, or will we be oblige to separate each of different 4 BS square to navigate through?
The BS1.0 used a fixed timing for sweeps so the sensors could always differentiate between the two stations. This method wasn't quite suitable for more base stations, since the timing between sweeps coming from one station would increase with every new station being added to the setup. If your sensors can only see one station (e.g. because of occlusion) and its tracking frequency becomes that low, the tracking wouldn't be good anymore.
Ben can certainly explain the details of the new tracking algorithm better, but the way I understand it is that each 2.0 station sends its ID (or channel) along the beam so the photodiodes are able to distinguish what station the beam is coming from.
Now imagine that your sensors located the position of two base stations which send the same identifier. The sensors see the first base station, correctly derive their own position in the room. Now you turn around and there's another base station that sends the same identifier, but has a different angle / distance than the sweep from the first base station. The sensors will still think it's the same origin coordinate and will thus offset your own tracked position accordingly. It's basically the same effect as multiple BS1.0 setups side by side without any occluder. Your tracked devices will always jump forth and back the different signals.
In another hand, you seem's to have found a way to move the 4 actual channel of the BS 2.0 from S-0 to S-3... I can't figured out how to manage with the BS 2.0 to change this channel? Could you give me a short explanation or give me a link to a documentation, Holo?
Last thing about BS 2.0.
We assume that as the channel ID of the new BS 2.0 is only a modifed frequency of the laser, and since the new TS4231 in the HMD are able to detec infinite change in this frequency, we should be able to use more than 16 BS 2.0 in the same way ^^.
In my point of view those limitations are only due to the Valve Roadmap... But unfortunately, only profesional as us needs this kind of settings :s I'm curious about your point of view on this point?
So I'm really curious as well about whether 16 channels are a hardware limitation or a software choice for the time being.
Hope this helps :)
I can figure out why Bendotcom didn't help us in our difficult process to Access 4 or more BS tracking :s
As there is no visual feedback when you press the button in the little hole behind BS 2.0, you have to increment them only one channel each time(one pression on the button), before checking in the SteamVR if the BS 2.0 increment really his channel from S-0 to S-3...
It's seem's that each time the BS are on the same channel as the first one, they didn't appear on the SteamVR.
We are currently meeting the same issues as Holocafe :/ the tracking is often instable and we encounter some drifting with the HMD and the controllers, even when we are in the center of our tracked square.
I hope that the next SteamVR update will resolve this issues quickly now Oo.
We're doing a stress test this weekend at DoKomi with 40.000 visitors, showing our latest common-space multiplayer game and so far, the tracking works like a charm after the initial setup: https://twitter.com/holocafe/status/997806661111812096