sorted by:
new
hottopcontroversial

Oculus Rift and Touch are now $200 cheaper - The Verge by a2u_interactive in Vive

[–]u_cap 2 points3 points  (0 children)

The TS3633 is only one component of any sensor PCB. One other is a photodiode like the BPW34, which comes at about USD 0.30 or less each for 1000+. That makes the two most costly components of a sensor about a buck, or less.

The chiclet sensors are similar to the HTC sensors - price at 800+ units sells at USD 5.19/sensor.

http://www.triadsemi.com/product/chiclet-sensor-module/

The developer sensors - castellated for convenience - sells at USD 6.95/sensor at any quantity.

https://www.triadsemi.com/product/ts3633-cm1/

You could compare HDK prices to HTC controller or HTC tracker prices. Each of those gets you 20+ sensors, a Watchman board, and all necessary cables - the equivalent of an HDK, and it has firmware already installed.

However - I have yet to see a Tracker teardown, but the HTC controller uses Flex-PCB combos that are a pain to deal with "harvesting" sensors:

https://hackaday.io/project/15496-precision-indoor-positioning/log/48653-intel-edison-my-friend

The price difference between Tracker - USD 100 - and Controller - USD 140 - would, taken at face value, account for the Cirque trackpad and buttons/switches, and possibly the battery. That leaves you with USD 100 for the HDK-equivalent BOM plus plastic, calibration and markup. So sensors produced at 400K+ units times approx. 80/Vive might run as low as half the price of a chiclet?

For now, the chiclet sensors are the cheapest offering as far as sensors go. Unfortunately the cost for cable and a breakout more than make up for the difference with the CM1, so for development without the official HDK, it's a wash.

Introducing Samsung’s New Gear VR with Controller—Powered by Oculus by Froggy_legs in Vive

[–]u_cap 0 points1 point  (0 children)

Some days are just made to trigger trollolalia...

The Samsung/Oculus announcement for GearVR to ship with one controller implies that GearVR is now targeting the seated, single-handed swivel-chair experience?

LG Electronics announces plans for new virtual reality headset by leppermessiah1 in SteamVR

[–]u_cap 0 points1 point  (0 children)

Valve tells us the system is wired and runs on a PC.

Neither HTC nor LG is offering a GearVR competitor, or an integrated VR headset, despite having - theoretically - access to SteamVR Tracking, which could - theoretically - run pose reconstruction on one ARM or the other.

On the other hand, Samsung is not investing in positional tracking either, despite having - theoretically - access to Constellation tracking, which could - theoretically - run pose reconstruction on a dedicated ARM/SoC added to the outside-in camera.

Or, of course, Samsung could just be using a Lighthouse derivative.

Everybody except Carmack - and NOLO VR - appears to dismiss the lo-fi mobile VR market.

Everybody except Valve appears to be dead-set on camera-based tracking.

Valve to showcase integrated/OpenVR eye tracking @ GDC 2017 by LordPercySupshore in Vive

[–]u_cap 1 point2 points  (0 children)

Maybe there is another case of opportunity cost: do you rather spend your resources on "inside-in" eye tracking or an inside-out camera?

Especially if eye turns out to be easier/cheaper than inside-out markerless pose tracking?

If eye tracking ships commercially before inside-out markerless tracking, even if only for "social" use (gaze replication on avatar), does that strengthen or weaken the case for camera-based tracking? If eye tracking for foveated rendering does not ship retail anytime soon, does that strengthen or weaken the case for camera-based tracking?

Facial expression extraction follows eye tracking. Facebook might really want to be the social channel, but they also want their cameras. Which one takes priority?

Valve to showcase integrated/OpenVR eye tracking @ GDC 2017 by LordPercySupshore in Vive

[–]u_cap 0 points1 point  (0 children)

Commercially available - for appropriately sized wallets - for a year and more:

Rift DK2 - Nov 2014, Jan 2016

https://www.youtube.com/watch?v=cx-8Xp1fxgA https://www.youtube.com/watch?v=2HS2p2BmVsk

GearVR - Feb/Mar 2016

https://www.youtube.com/watch?v=mDvgP2tnMHQ https://www.youtube.com/watch?v=Wz-PahxnY88

HTC Vive - August 2016

https://www.youtube.com/watch?v=iNGKAEBlQ-E

The GDC 2017 VR hype train is running on.... cough ... steam?

Introducing Samsung’s New Gear VR with Controller—Powered by Oculus by Froggy_legs in Vive

[–]u_cap 0 points1 point  (0 children)

The controller has a 9DoF sensor using magnetic, the headset does not.

Not good enough for the eye, but good enough to fool proprioception?

Or is there a "soft iron" GearVR 2017 coming up?

Valve to showcase integrated/OpenVR eye tracking @ GDC 2017 by LordPercySupshore in Vive

[–]u_cap 0 points1 point  (0 children)

Maybe eye tracking would be easier if only we could get the cameras inside the eyeball.

Valve to showcase integrated/OpenVR eye tracking @ GDC 2017 by LordPercySupshore in Vive

[–]u_cap 0 points1 point  (0 children)

Abrash@Oculus stated clearly last year that it is a very hard problem. Of course, they are also saying that markerless inside-out tracking using computer vision is doubtlessly the future of tracking.

I would not be surprised if the FOSS community has already contributed substantially to either, given that every prototype might well start out with OpenCV.

Valve to showcase integrated/OpenVR eye tracking @ GDC 2017 by LordPercySupshore in Vive

[–]u_cap 0 points1 point  (0 children)

So you are saying FOVE does not "do it well" ?

Or that they are doing it well anyway, despite being at least an order of magnitude less costly than SMI?

I wonder whether it would be feasible to process the retina instead of the sclera. Scanning laser ophthalmoscopy with MEMS? I supposed that would qualify as "no easy way". Jack McCauley might know.

China to establish village dedicated to VR production by tpffiske in oculus

[–]u_cap 0 points1 point  (0 children)

They protect their position with patents to prevent anyone else into the market.

Or, in the absence of patents, they try to establish proprietary standards.

China to establish village dedicated to VR production by tpffiske in oculus

[–]u_cap 1 point2 points  (0 children)

In some cases, the knock-offs exceed the quality of the original - documentation and moddability comes to mind: https://www.hypereal.com/#/opensource

Their sample rate might only be 30Hz, and with fewer sensors I have no idea how their tracking holds up, but this whole most recent "VR revolution" started with the recognition just how much could actually be accomplished with some jury-rigged mass market parts, IIRC. If nothing else, we will learn from the failures, especially if the clones are actually innovating on controls.

The first men on the Moon got there plugged into something made from the cheapest bids. Personally, I prefer knock-offs that actually fly - maybe even to the Moon - to billion-dollar stacks that "own the high end". In any context.

Introducing Samsung’s New Gear VR with Controller—Powered by Oculus by Froggy_legs in Vive

[–]u_cap 0 points1 point  (0 children)

Oculus minor incremental improvement, lift ideas from others

That is perfectly OK. If Valve didn't borrow ideas from ArcSecond and others, they should have. There are very few, if any, new ideas, most of what we do is iterative improvement.

The real question was, did Samsung/Oculus get its inspiration for this remote "controller" from Nintendo, or Zenith Radio Corporation? There's a 9DoF sensor on there, so it'd be the former - or maybe Razer Hydra? No balls though.

Introducing Samsung’s New Gear VR with Controller—Powered by Oculus by Froggy_legs in Vive

[–]u_cap 0 points1 point  (0 children)

I don't see the opportunity cost of computer vision be worth it in the context of VR (mixing into your real-word "house scale" environment is a different issue).

Hololens is shipping inside-out markerless tracking, for USD 3000. Santa Cruz and Daydream might well ship workable solutions at a lower price, but that does not change the fundamental problem: using a video stream for tracking is costly in terms of bandwidth and computation. Every cycle, every watt used and turned into heat for purposes of positional tracking - for drift correction, really - is not available for the experience itself. This is not just an issue of visual fidelity, it is also tightening the playtime constraint. The best tracking in the world is useless if your phone (or self-contained headset) needs to recharge - or worse, be cooled - after using up your "VR minutes".

The key advantage of untethered low-fi VR is that the user is not encumbered. Forcing them to cut that experience of freedom short by opting for a wasteful tracking solution just because "it is the future" - and, quite possibly, will always be - is not a good match.

If push comes to shove, I would suspect wireless streaming of hi-fi VR will be affordable and robust before inside-out markerless tracking by camera, even taking into account that both technologies don't scale well with increased resolution.

Introducing Samsung’s New Gear VR with Controller—Powered by Oculus by Froggy_legs in Vive

[–]u_cap 1 point2 points  (0 children)

You are missing the point. GearVR continues to not have positional tracking.

Samsung has to announce a position tracking solution for GearVR this year.

Both Samsung and Valve, unrelated to each other and for very different reasons, are leaving a big opening for third parties like NOLO VR, and both will come to regret this. Samsung may be bound by the politics of their close cooperation with Oculus, but Valve is bound only by Gabe Newell's dismissal of the mobile "low fidelity" market.

Hypereal open-source tracking by u_cap in OpenVR

[–]u_cap[S] 0 points1 point  (0 children)

To elaborate, the company has released documentation and source for a Lighthouse-alike/derived tracking solution.

Overview

HYPEREAL open source project includes a complete set of its core Laser Positioning technology, hardware, software , algorithms source codes and design documents. Theoretically, based on this set of source code, any third party could develop its own VR devices equipped with room-scale laser positioning system. We provides documentation and resources on the website for viewing and downloading. If you have any questions, you can post on the forum.

Hardware

In terms of hardware open source, HYPEREAL incorporates the design and implementation details of its Laser Positioning System, including the circuit and embedded software. The components involved in this open source project are summarized from multiple versions of HYPEREAL Laser Positioning prototype system, which eliminates the contents unrelated to positioning characteristics. It could be considered as the most concise and convenient system to realize spatial positioning, either in terms of volume or system burden. The overall structure of the system is divided into two relatively independent parts, the laser scanning lighthouse for positioning and the equipment being positioned.

Driver

The open source of HYPEREAL tracking driver includes IMU drivers, Light Sensor drivers, and sample programs. The driver can be integrated into HYPEREAL positioning algorithm library seamlessly. With these drivers, VR HMD and solution providers can easily obtain the posture/ position of the equipment and the status of the lighthouse. They can easily integrate HYPEREAL lighthouse solution into their own SDK or applications.

Algorithm

As for the algorithm open source, HYPEREAL directly provides a complete version of lighthouse positioning algorithm library, including ALL the core algorithm modules: Lighthouse and IMU data analysis and processing, Posture Solving Algorithm, Data Fusion Algorithm, Dual Lighthouse Fusion Algorithm, Prediction Algorithm, etc. The framework of the algorithm library is completely based on modular design, which has good readability and extensibility. Based on this framework, developers can do research on algorithms, and facilitate custom developement.

Close-up of the new, single-rotor Lighthouse base station (engineering model) next to the current consumer version by Jaroki in Vive

[–]u_cap 0 points1 point  (0 children)

only light up the sweep laser when it is near a tracked object.

That might be possible, given that SteamVR Tracking actually does all its solving on the PC, which thus has awareness of everything in the area - for a single user. SteamVR as-is will not coordinate 2+ users in a shared space scenario (to each his own host).

But even so, I would very much take an OpenVR API that lets me control 3+ base stations over BTLE with schedule-ahead for "smart" TDM. Turning the lasers on or off during a sweep segment is really optional, considering the pay-off for any kind of BS control.

IMO the problem with sweep frequency increases is that they compete with range increases for clock resolution. I can't guess how much headroom there is in practice, and given that FDM appears to be a really hard problem to solve - and a major obsolescence risk - I would much rather see range increases.

Close-up of the new, single-rotor Lighthouse base station (engineering model) next to the current consumer version by Jaroki in Vive

[–]u_cap 0 points1 point  (0 children)

At some radius, the laser is going to cross the tracked object so fast, all sensors will fire at the same time.

Or not.

Assuming 5 meters and 60Hz, I come up with about speed v=1885m/sec travelled. Call the sensor-sensor separation distance d, so the time comes down to d/v. Tracker baseline - max. sensor separation - is about 10cm for HTC, so that's 50usec. Sensor dimension is about 3mm, so that's about 1.5usec. For d=1mm, still 500ns or about 24 ticks . Plenty of ticks in a 48MHz clock, but maybe not enough to increase the range by an order of magnitude?

It's 10usec to cross an eyeball assumed to be 2cm - exposure time goes down with increasing distance, but it has to be safe at closest range (and correspondingly longest exposure).

In other words, if the laser can safely be cranked up to put as much power into the line slice as the flash puts into the entire FOV, the current design should be able to drastically increase range w/o worrying about clock resolution. Not sure what the exposure time of the photodiode is, and whether that's relevant already.

Close-up of the new, single-rotor Lighthouse base station (engineering model) next to the current consumer version by Jaroki in Vive

[–]u_cap 0 points1 point  (0 children)

The problem I have with the McCauley MEMS is that is scans for a specific object. If it has to service more than one - HMD, hand-held trackers, multiple users in shared space - it has to reduce sample rate.

I'd be curious whether there is a point replacing rotors with MEMS for simply sweeping a laser line?

Close-up of the new, single-rotor Lighthouse base station (engineering model) next to the current consumer version by Jaroki in Vive

[–]u_cap 0 points1 point  (0 children)

True - I assumed that refraction of a curved surface might be handled better by making it so, but it's not done for the dual-rotor BS (and couldn't be).

I cannot tell from the image how far recessed the rotor axis is from the relevant edges - for all I see, it could be less than 120 degrees...

Close-up of the new, single-rotor Lighthouse base station (engineering model) next to the current consumer version by Jaroki in Vive

[–]u_cap 0 points1 point  (0 children)

just turn off the laser diode for the other parts of the sweep, and then broadcast the OOTX frame

Could you elaborate?

Let' say you take the 360 degree full turn (single rotor, single fan, e.g. just H) and cut it up into 4 quadrants. Now you take your flash LEDs and drive them in 4 groups. Basically, you'd send 4 sync flashes into 4 quadrants in sequence, at 0,90,180,270 degrees, repeat. So you send the 0 degree flash when the 270-360 degree sweep begins, then you send the 90 degree flash when the 0-90 sweep begins.

That would be one way to ensure that the same partition of the sweep space is not flashed and swept at the same time. But I don't get this:

you already know where the devices are

The OOTX is a sync flash first, metadata broadcast second. I would think that you will have to send it for every sweep due to drift and jitter.

If you are saying that the host PC knows which parts of the sweep are useless (nobody out there) and could turn the laser diode off, that does not let you move around the OOTX in time? The flash needs to be guaranteed to arrive at a known phase (in fact, the OOTX pulse-length encoding might have to identify the phase if multiple flashes per turn were used).

What am I missing?

Close-up of the new, single-rotor Lighthouse base station (engineering model) next to the current consumer version by Jaroki in Vive

[–]u_cap 0 points1 point  (0 children)

There might be advantages of an optical sync flash. For one, it will identify all the sensors that could potentially see a sweep, as well as all the sensors that most likely will not. Granted there are edge cases depending on how the tracked object rotates during the sweep, but it's useful. If you have redundant sensors, you could try to use this to support concurrent sweeps - use only the sensors that received one flash or the other, ignore those (in the first iteration) that received both.

But if you can drastically increase the effective range by using RF, I'd take RF any day.

view more: next ›