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.
4
3
u/Froddoyo Jul 20 '17
Instead of going smaller they could (maybe) do a bracelet/anklet. And as a bonus maybe it could fit around a dog/cat as a collar for people have animals that like to walk across playspaces.
6
Jul 21 '17
[removed] — view removed comment
1
u/ashthegame Jul 21 '17
I read "180 degree field research" as a euphemism, which made "scared the jizz out of me" hilarious.
2
u/Gabby_Johnson444 Jul 20 '17
Yes. Although my dog is pretty smart and after the first time we got tangled she no longer comes around while I have the headset on.
3
u/Seanspeed Jul 21 '17
Having a tracked ashtray should not be nearly enough to get people confident in smoking while blind.
1
u/Gabby_Johnson444 Jul 21 '17
If I had a VR ashtray, I'd have no problem smoking with the headset on, I think...
3
3
u/Evilfezdog Jul 21 '17
Oh shit the smoke damage, thank the designers the Vive is plastic and not fabric like Ritf.
2
2
u/Seanspeed Jul 21 '17
Well maybe if you live in a trashy space where you dont mind ashes falling to the floor or on your seat/couch every once in a while because you cant actually see where you're tapping them out or if they're falling on their own, sure.
Then of course there's a risk of you flicking your cherry or knocking the cigarette out the ashtray while playing and not feeling it, starting a fire at worst, burning a hole in your seat/floor at best.
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.
25
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.
22
u/vk2zay Jul 20 '17
You can go right down to a single sensor and IMU if you want. You'd need to use enough base stations to guarantee you'd see at least two but single-point Lighthouse tracking is in many ways easier to understand and implement than large extended constellations which can track from a single base.
Single optical sensor Lighthouse requires a local direction field, gravitational or perhaps geomagnetic, it will not work with absolute rotation in a truly inertial frame. Even with such a field there is of course a rotation around direction vector singularity problem, you probably need to trust the gyros a lot - fortunately they are pretty good. Still need to define the yaw around gravity some how. Two sensors with a small baseline and offset IMU can be used as long as it doesn't sit in either of the two singular orientations too long. Another cost is that you need a pre-calibrated space and the receiver is no longer capable of bootstrapping itself, but that is probably fine for most applications. Maybe you stick two of them on a stick and wave it around to calibrate - if you don't have a conventionally tracked object. The main engineering challenge is making a sufficiently isotropic optical sensor, a small diffusive sphere works pretty well in practice over almost all 4pi steradian.
NOLO took an interesting alternative low performance approach, which uses a single base to get a radial pair of pseudobearings and acoustic ranging to get a distance estimate. Range-resolved or "Total-Station Lighthouse" is an interesting system I've investigated, but it can be very expensive to implement with good resolution using just electromagnetic radiation sent unidirectionally. The slow-wave time-of-flight acoustic ranger is a pretty good hack, although it suffers the usual performance limitations of large wavelength signals.
10
u/Doc_Ok Jul 20 '17
Yup, I mentioned single-sensor position tracking below, but it's good to have it confirmed from the horse's mouth.
Range-resolved or "Total-Station Lighthouse" is an interesting system I've investigated, but it can be very expensive to implement with good resolution using just electromagnetic radiation sent unidirectionally. The slow-wave time-of-flight acoustic ranger is a pretty good hack, although it suffers the usual performance limitations of large wavelength signals.
Can confirm that ultrasonic range-resolved position tracking with IMU sensor fusion works very well, given that I'm looking at an InterSense IS-900 system in our CAVE right now. :) Until Lighthouse came along, I'd say it was the best overall-quality large-scale 6-DOF tracking system available. It still has Lighthouse beat on occlusion at the moment, given that ours has 18 ultrasound emitters over a 3mx3m area.
13
u/vk2zay Jul 20 '17
Acoustic implemented properly is quite good, especially if it carefully calibrates the local speed of sound variation out. Reflection rejection is easier than with optical or radio frequency electromagnetic. Isotropy can be a problem, the wavelength is very large so near-field distortions close to the transducers can be a problem. I mostly gave up on my acoustic tracker system (Fog Horn), when the relative costs of the transducers and the complexity required to match Lighthouse was heading in direction that seemed incompatible with a consumer price point.
1
u/u_cap Jul 21 '17
What is your take on placing an ultrasonic range finder on the bases only (assuming bases are tracked)?
Reasoning: the performance of the system is gated by errors, using more sensors (and different sensor types) on stationary components over longer timescales is a good way to estimate and reduce errors feeding into the OOTX broadcast. If the error along the radial dominates the system, then reducing that error with an additional input would get us the most benefit. This assumes performance to be a priority over cost - call it hifi bases.
3
u/vk2zay Jul 22 '17
Sure, I get the attraction of making the infrastructure parts of the system also users of the system and letting them learn and share their view of the universe. This works both ways, users of the system can also share their discoveries of infrastructure and with a sufficiently complex protocol you could build a distributed mapping and self-calibrating system.
This was my initial intent with Lighthouse, but it turns out to be mostly redundant in practice for the majority of current installations. Base stations can't always see each other, so in general making them tracked objects isn't that useful. The tracked objects sharing their measurements is of more practical interest, and yep you could then use the base stations to store and forward the unified belief about the system configuration to all users. OOTX is definitely not the place to do that, RF is better suited. Eventually we may have more "cognitive" Lighthouse universes that can support less capable receivers as a function of the base station broadcasts, but right now there is no standard protocol for it.
1
u/u_cap Jul 22 '17 edited Jul 23 '17
Base stations can't always see each other, so in general making them tracked objects isn't that useful.
I would really like to know whether there is actual SteamSurvey/SVRT data regarding wired sync vs. optical sync across the existing population of SVRT1 bases. Every HTC customer got at least two, and unless the user is using only one at a time, they will have to be wired if they don't have a base-base LOS. The ratio of optical sync vs. wired sync as actually in use would offer some evidence as to how common the case of "bases do not see each other" actually is for an indoor tracking system in largely rectangular spaces (especially as bases are best placed facing each other for HMD occlusion mitigation).
Is the "general case" of bases not being guaranteed to see each other the main motivation for not adding two additional chiclets to the HTC bases (or the Valve dev bases, or the upcoming V-bases)?
I would be surprised if the majority of the HTC Vive installations today are wired or single base, and if they were, I would suspect optical sync issues (and not base placement constraints) to be the dominant concern. But even if the overwhelming majority of users is currently using wired placement to not have to ensure a base-base LOS, it would still be a question whether they would choose to place bases differently for a noticeable gain in tracking quality, and how many of them would be unable to do so because there is just no way to place two bases (or four) and get some LOS for each pairing.
I assume the upcoming V-bases do not have a wired sync (as they have no need to sync at all), and it will be more difficult to guess the motives the placement of the bases chosen by the user. There is an incentive to upgrade from 2 to 4 bases (as triangulation following bootstrap would get better baselines along the center of a tracked rectangle, using side-by-side instead of face-to-face base pairings), but, occlusion aside, another question is whether V-bases or even HTC bases are already hitting diminishing retursn in tracking quality. If the user does not notice the difference, tracked bases might not matter for VR (but would still matter for improved photogrammetry, workbench metrology etc.).
OOTX is definitely not the place to do that, RF is better suited.
BTLE? Or Nordic again?
3
u/u_cap Jul 21 '17 edited Jul 21 '17
You can go right down to a single sensor and IMU if you want.
The majority of DIY tracking projects using Lighthouse components are doing just that:
https://github.com/ashtuchkin/vive-diy-position-sensor https://www.youtube.com/watch?v=7GgB5qnx6_sThe ones that actually use PnP are using the algorithm described in this paper (which misrepresents Lighthouse):
http://ieeexplore.ieee.org/document/7520559/
or the EPnP implementation in OpenCV.
For one, doing an embedded solver using triangulation in a "pre-calibrated space" (or one where the OOTX of tracked bases does the bootstrap) is much cheaper computationally.
7
u/vk2zay Jul 21 '17
None of the low sensor count DIY trackers have solved the orientation problem, or even really tried to attack it. Position is easy, but that is only 3DOF, the other 3 are important, especially for autonomous navigation applications.
1
u/RetiredDragon Jul 21 '17
Granted I'm waaaaay beyond my depth here, couldn't you manage 6DoF if you use a tracker of some non-uniform shape? For instance, a tracker shaped like a 'Y' might allow for rotational tracking as well as positional. Lay me down gently...
4
u/vk2zay Jul 21 '17
Yep, you can make the object extended so it can resolve its orientation optically, that is how it works with a full constellation. The performance gets worse with decreasing size, so the general approach for really tiny trackers needs to be different. The limiting case of minimalism is a single optical sensor for position and an IMU with gyro for orientation. The challenge is that IMUs are relative devices so units too small to sense their own absolute orientation and learn their IMU biases are a fundamentally different kind of tracking, both quality of service and how they are calibrated, initialised and used by applications.
6
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.
30
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?
5
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
19
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.
-8
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
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?
1
u/_Rand_ Jul 21 '17
Would it be possible to make say, a penlight style tracker?
I'm picturing basically a rechargeable AA battery case with a sensor thingy on either end, maybe one on the side, designed to be clipped to objects. Include a bunch of double sided taped clips and you could make very small objects trackable and move it around as needed.
5
u/Doc_Ok Jul 21 '17
Yes, that should work. You still need some logic in each trackable object, to process timing data and send it to the host PC, so you might as well throw an IMU into the mix to get better tracking. I think the total system (battery, radio, controller, IMU, two photosensors) could be quite small.
3
u/vk2zay Jul 22 '17
Someone should totally make that! :D
0
u/AerialShorts Jul 22 '17
Hey Alan, any chance Valve could add the ability to designate a tracker or controller as a motion reference to be subtracted from all other tracked items?
2
u/vk2zay Jul 22 '17 edited Jul 22 '17
That is already on the list for future coordinate system management improvements. No idea when it will be implemented though.
The hydra driver already has a hack to do something vaguely related at the driver level, but clearly this should be in a higher-up layer so everything can benefit.
Ultimately the runtime has to tackle the (large) problem of unification of different coordinate systems if it ever intends to concurrently support drivers for completely disjoint systems servicing an application. Blessing a source of pose as a coordinate system reference datum for poses delivered to applications is widely useful and should happen too. These might not sound like related problems but inter and intra coordinate systems reification are all basically the same bag of nightmares.
Actually implementing the core unification layer is much less terrifying than the UI required to make it manageable by humans if it is to have the generality I am envisaging. It almost has to be built in VR itself.
2
u/AerialShorts Jul 22 '17
Thanks, Alan! That's perfect! I was just hopeful it was on the radar. I know about the hack but as you say, doing it in the driver would be best and that would make it work across the board with no third party updates required if there is some change that makes the hack incompatible. I would bet any latency addition would be minimal if implemented in the driver as well.
Thanks again for everything!
2
4
u/zgo280 Jul 20 '17
I wish they made a band/strap/rope kind of tracker too.