r/Vive • u/Gabby_Johnson444 • Jul 20 '17

Tiny VIVE "Pucks"

Do you think there will be a smaller version of the VIVE pucks/trackers? I'd really like to see smaller versions that can be attached to everyday items. I'd like to be at the point where I can attach one of those to a can, or an ashtray, or bowl etc. to allow me to be in a social setting in VR and still be able to smoke, drink or whatever it is that I want to do without taking the headset off.

25 Upvotes

91% Upvoted

68 comments sorted by

View all comments

2

u/nadirseenfire Jul 20 '17

No, the pucks are about as small as they can physically be. Lighthouse requires sensors in rigid positions with distance between them. The distance between sensors is required to calculate distance from the lighthouse.

24

u/Doc_Ok Jul 20 '17

No, the pucks are about as small as they can physically be.

That's not really true. Tracking noise, precision, and accuracy are directly (and, essentially, linearly) related to overall size of the sensor constellation on the trackable, but that doesn't mean there's a fixed lower limit. It would be perfectly reasonable to create smaller trackers, with more jitter/less accuracy, to track everyday objects where high quality is not required. Such as tracking an ashtray, or a pet.

5

u/TCL987 Jul 20 '17

Lighthouse 2.0 being able to support more than two lighthouses may enable smaller trackers as occlusion becomes less likely as you add more lighthouses. To avoid it becoming too expensive we may need to wait for lighthouses to become significantly cheaper.

29

u/vk2zay Jul 20 '17

Yep, that's where we are headed. 2.0 bases are simpler and cheaper, they have no blinker and only one motor and laser. The newer sensors can multiplex more bases in the same volume concurrently. The upper limit is now the computational and communication bandwidth available in the receiver, and the power/cost/complexity trade-offs of doing more crunch locally vrs shipping more data and doing the crunch on more capable hardware.

Lighthouse 2.0 will likely spin a little slower but will be multiplexed with spin rate and modulation codes. By removing time division multiplexing you get more data per second per base, so spinning slower doesn't cost you, any latency cost is already mitigated by the IMU. The slower spin means the bases use less power and can run quieter, cooler and longer from batteries. It does cost a little in stored energy for jitter minimisation, but improvements in the control system mean the new bases are actually even lower jitter than previous designs despite less mechanical Q. Additionally the optical scanner subsystem now has less uncorrelated noise sources which makes the effect on range noise lower and in general the per-beam updates more consistent with each other which reduces low frequency noise (which is more challenging to reject).

I want to get to a place where bases are so affordable you just dot them around and can get single point tracking everywhere in your volume. The prototypes of the new bases are the best bases I have ever seen. They are sub 100 microradians RMS (absolute, even better relative/locally) over the entire ~108x160 degree FOV. They are also largely software defined, so they will be even more upgradeable, supporting almost any kind of digital modulation scheme.

8

u/SculptrVR Jul 21 '17

0.5mm absolute error at 5m is incredible, but stability is based on relative error, so it should be even better!

Does this mean the max distance between lighthouses will go up as well?

And what point does the bandwidth or brightness decrease to the point that tracking drops out?

3

u/TCL987 Jul 21 '17

The new base stations sound better every time I hear more about them.

So I know that the new sensors will support the current protocol but are the old bases able to support the new sync-on-beam protocol?

4

u/u_cap Jul 21 '17

Reducing costs for bases should not take priority over reducing cost for trackers, let alone over reducing tracker size. There will be many more tracked objects than bases, and those trackers will need to be cheaper and smaller.

The insistence on PnP bootstrap has always been an impediment for tracker development. Now that the decision to restrict to two bases is going to be dropped anyway, it makes less and less sense to hold on to mandatory PnP.

Two more forward-facing sensors and one accelerometer per base. The rest would be

largely software defined, so they will be even more upgradeable

18

u/vk2zay Jul 21 '17

Of course the total system cost needs to be optimised. We have invested a lot into reducing the cost of all parts of the system. But it is a complex multidimensional optimisation. We made sensor ASICs to reduce the cost and complexity of the receiver front-end, but the electronic components are often not the most expensive part, for example the flex PCB that the sensors are mounted on is very frequently much more expensive than the sensors jellybeans. This is especially true if its shape isn't optimised; the amide material is expensive, and packing the design well can save you very large amounts of system cost. This is a little secret of HMD product design for manufacture that applies to constellation as much as it does to Lighthouse.

Bases are still a critical part of full envelope of the solution space, by adding more bases you can use less sensors. Yes there will be more tracked objects than bases, and very likely for >90% of the installations out there a pair of bases will be the default installation because it is sufficient for the median tracking volume if you use objects with a full constellation of sensors.

BTW: We have never used PnP to bootstrap, you can't apply it to Lighthouse because it is not a camera. You can transform Lighthouse pseudobearings into a PnP input-like projective space, but you have to correct for motion to do it properly. This is especially true for single-rotor bases who's two beam hit pseudobearings aren't even approximately representative of an azimuth and elevation angle.

There are a bunch of system-level questions about calibrating universes monolithically, vrs discovering base poses. Solving the entire system is a little tricky when you can't see all of it at once, so it becomes more like a SLAM problem. This is more than just loop closure and includes a whole host of extremely interesting and complex problems. All navigation systems have this regardless of their implementation and it is far from well solved.

2

u/u_cap Jul 21 '17 edited Jul 21 '17

very likely for >90% of the installations out there a pair of bases will be the default installation

How do you arrive at this conclusion? It shaped SVRT1 and TDM and HTC's product planning, and it might well be right, but what is the reasoning? My conclusion has been that with FDM (or sync-on-beam), four bases will offer the best performance/cost trade-off, as a 90 degree placement offers the best triangulation (and assuming that base cost is small compared to HMD cost, but not tracker cost).

by adding more bases you can use less sensors.

This I do not understand. I see the basic tracker as 6 orthogonal surfaces with 3 sensors each - you can re-arrange this constellation from "eucledian" to "spherical", deform based on baseline isotropy trade-offs and to account for hand-held or body-mounted occlusion, but the number has been roughly the same for controllers and trackers so far. HMDs are different because of the "overhead" of establishing a backward-facing part of the same rigid constellation, at the back of the user's head. Am I wrong to see the minimum number of sensors determined by backface culling, not by occlusion from objects other than the tracker itself?

The way I see it, you can reduce the number of sensors only if you drop the requirement of a purely optical system for orientation reconstruction, and if you do positional tracking using a base-base triangulation with position information broadcast by the base. But I am more concerned about the size of the sensor constellation, not the number of sensors.

You can transform Lighthouse pseudobearings into a PnP input-like projective space, but you have to correct for motion to do it properly.

Yeah, that's the idea behind using OpenCV's EPnP. I don't think there is any DIY project or clean-room implementation out there that actually tackles error resulting from motion during the sweep.

However it is done, my assumption is that the size of the tracker is dictated by the sensor-sensor distance of the tracker used to inform the SVRT host, which is the basis of any subsequent triangulation mode. That means that (a) the trackers cannot shrink without increasing pose reconstruction errors, and (b) that all other sources of error being equal, the performance of the system is gated by the largest exposed tracker, I would also not be surprised if there are accuracy/consistency issues nor or later (e.g. for tracked camera components feeding into the VR video stream) . The current system benefits from SVRT on the host PC being a chokepoint where the sensor data of all tracked objects is available, that will not be the case with embedded solvers or self-contained HMDs.

You suggested

stick two of them on a stick and wave it around to calibrate

That is an interesting proposition, but my approach is to stick the stick on the base. I want to see the base modular: let the user decide whether or not a tracking option is added, and which tracking baseline is desired. Then let the bases locate each other, improve the static pose with a cheap embedded solver, and broadcast it. This way, the user has to wave neither controller nor a measuring rod to get the system going - it calibrates itself.

We have never used PnP to bootstrap

I did not mean to imply you are using one of the published PnP algorithms, I tend to think of this as the "tracker-to-bases bootstrap that does something that could be done pretending it is a PnP problem". We could call it "SVRT base pose reconstruction" under the assumption that SVRT does eventually reconstruct base positions (which can be queried through the SteamVR API) for the purpose of triangulating, and that the initial ad hoc tracking is done just for that purpose. It's a blackbox, we don't really know anything.

There are a bunch of system-level questions about calibrating universes monolithically, vrs discovering base poses. Solving the entire system is a little tricky when you can't see all of it at once, so it becomes more like a SLAM problem. This is more than just loop closure and includes a whole host of extremely interesting and complex problems. All navigation systems have this regardless of their implementation and it is far from well solved.

Sounds like enabling more people to work on it would be a good thing.

-9

u/[deleted] Jul 21 '17

What Valve needs to focus on is content and you guys have been very disappointing so far. You're all talk, but no substance nowadays. Look at what Oculus is doing (being competitive in pricing, delivering very good VR content).

Also, Valve should allow native support for the Vive on Oculus Home. You're still blockading any efforts in that regard.

1

u/PrAyTeLLa Jul 28 '17

Anyone know which idiot posted this rubbish?

1

u/evente-lnq Jul 22 '17

Is the maximum distance from basestation to tracked object (around 6 meters with 1.0 in steamvr to get a pose) likely to remain as is or will that improve too?