The OSVR Software Stack at CES

When Razer and Sensics announced OSVR at this month's Consumer Electronics Show, most of the attention was focused on the OSVR HDK - the $200 open-source goggle. However, OSVR open-source software platform is at least as important as the HDK. In this post, we'll explore some of the inner working of the OSVR software platform in the context of the CES demos.

OSVR Architecture

By way of introduction, the OSVR software platform provides an easy and standardized way to discover, configure and operate hundreds of devices: VR goggles, position trackers, depth cameras, game controllers and more. OSVR supports multiple operating systems, plugs into leading game engines and is freely available under a permissive Apache 2.0 license. 

The full OSVR architecture is shown in the figure to the right and is described in greater detail in this technical white paper

Of course not all of these blocks were required for the CES demos. The demos used the OSVR HDK (Hacker Developer Kit - the open-source goggles), and some combination of the Razer Hydra, the Leap Motion Controller and the Nod Ring. Some of the OSVR HDKs were equipped with its built-in tracker (Bosch BNO070) and others were equipped with the YEI 3-Space Sensor. Various software demos were written, some using Unity and some using the Unreal Engine.

CES demo architecture

The block diagram of some of the CES demos is shown on the right. Similar diagrams could show the usage of the Leap Motion or Nod device. All demos were running on a Windows platform though Linux and Android ports of OSVR also exist.

OSVR has a client/server architecture. The server connects to the hardware devices and performs the analysis if required. The client uses this information. In the diagram to the right, the Unity and Unreal engines are clients, through an OSVR Unity plugin and an OSVR Unreal plugin. Everything else is the OSVR server.

Often, the client and the server would reside on the same machine, but there are also some additional possibilities including:

• Client on one machine, server on another. For instance, you might have the client running on a mobile phone while the server would be a PC that has more processing power and better connectivity to the various peripherals
• Multiple clients connecting to one server on the same machine. For instance, OSVR includes a graphical utility called "Tracker Viewer" that show the orientation and position of the various tracked devices and has proven to be a useful debug tool. TrackerViewer is an OSVR client and it can run concurrently with other applications such as the demos, connecting to the OSVR server.
• One machine running client and server, a second machine running a client. This can create a 'shadow' experience on a remote machine.
• One client connecting to multiple servers. This is useful in some high-end situations where OSVR applications wish to connect to devices (such as ART SmartTrack) that embed a server.

The 'device plugins' layer of OSVR connected in the demos to the various hardware devices and provided an abstract interface to the higher layers, so that the application does not care - for instance - whether the Bosch or YEI trackers are used. This proved to be useful during the show as our booth had a sofa used for demos and one of the trackers did not like the metal rails of the sofa. Swapping in the other tracker was extremely simple. More importantly, the same application can work across multiple trackers without change. OSVR supports for the Oculus DK2 orientation and position trackers which is helpful for those that wish to write cross-platform applications or for those that wish to debug their OSVR code using an HMD they already own.

An interesting software component on the OSVR stack at CES was the "1 euro filter" that is part of the analysis layer. The analysis layer serves to perform post-processing or high-level analysis on data that comes from the lower layer. In this case, the 1 euro filter is a low-pass filter that can be used to smooth and improve data coming from the Razer Hydra positional information.

One feature of OSVR that allows this to happen is the "path tree". Similar to a URL or file system path, the path tree is how all the sensing and rendering data is made available. Aliases are configured in the server to essentially redirect from a semantic path (a path with a meaningful name) all the way back to the system-specific hardware details. For instance:

• Position of the left hand: /me/hands/left/position
• Orientation of the left hand: /me/hands/left/orientation
• All resources associated with the left hand: /me/hands/left
• Position of the “0” controller of the Hydra: /razer/hydra/position/0
• Output of the first smoothing filter: /analysis/smooth_filter/0

OSVR subsequently allows defining the connection between the various components. In our specific example, /razer/hydra/pos/0 feeds into /analysis/smooth_filter/0 (1 euro filter) which feeds into /hands/left .

This allows to re-route information or insert or remove software components as necessary. For instance, if the 1-euro filter is not desired, simply map /razer/hydra/pos/0 into /hands/left. If a new filter is available, insert it back.

With each of the above software components, comes a JSON file, which is a human- and machine-readable descriptor file. The JSON file could provide device-specific information (for instance, for an HMD it would indicate what is the resolution, field of view and distortion correction coefficients). For a software component, it could define the semantic path of the inputs and outputs which can help in determining available information routes or facilitate auto-routing. Over time, the JSON descriptor could grow to include other parameters such as device-specific calibration data and so forth.

The CES demos used only a small portion of the OSVR components, but even so, the architecture proved to be useful for both development and ongoing operation. The OSVR community led by Sensics and Razer, continues to add and demonstrate components to OSVR. Whether it's a "locomotion device" (to support products from Virtuix and Cyberith), "eye tracking" or others, the capabilities of OSVR continue to grow very nicely.

The post "The OSVR Software Stack at CES" first appeared on the VRguy's blog:www.vrguy.net

How Things Work: the Dual-Element Optics of the OSVR HDK

When the OSVR HDK was unveiled last week, one aspect that received a lot of positive reviews was the quality of the optics - clear to the edges, no pre-distortion required. Since the Open-Source Virtual Reality project is indeed open-source, and its Hacker Development Kit will have the full production file available to download in a couple of weeks, I can talk openly about how Sensics designed it for those that are interested.

What's all the fuss about? Take a look at this comparison photo:

Test pattern photographed using an iPhone 4 camera through a dual-element design (left) and single-element design (right)

I took these photos a few months ago when we received the first batch of HDK optics. I found a test pattern on the Internet and displayed it on a 5.5" display, much like the one inside the HDK. I then used an iPhone 4 camera to take both photos. The left photo shows the test image through the HDK dual-element optics. The right photo shows the same test image through a popular single-element eyepiece. I was trying to get the best image in both cases, Is this a scientifically precise comparison? Probably not, but it's quite telling as is.

As you can see, the test pattern is in nice focus at the center of both the left and right photos. However, as you look towards the edges of the photo, the image remains in focus on the dual-element photo but is blurry in the single-element photo. Compare the "gmail" header on the left, quite readable, with the "gmail" header on the right, quite blurry.

You can also see that colors also break up on the right image. You start seeing the separation between red, green and blue. The colors stay intact on the left image. Last, if you look at the three bands of test pattern (right half of left image), you can see that they remain pretty much straight, whereas the same bands on the right image appear curvy.

In short, we are seeing a blurry image, chromatic aberration and geometrical distortion in the single-element design and not so much on the dual-element one.

Is the dual-element design in the HDK perfect? The best Sensics has ever done? The design to beat all designs from here on? Of course not! It's just a good design and solid engineering. Let's look at what makes it better in some aspects than the single-element design.

When we start an optical design project, we look at the requirements. How much field of view are we looking for? What is the screen size we are trying to image? What are the materials we are allowed to use (e.g. plastic? glass?) How much is it allowed to weigh? What are our cost constraints? How much eye relief (distance from cornea to first optical element) do we want? What is the desired eye box (how much the eye can move from the optimal location without significantly losing image quality)? Are we allowing aspheric optics? How wide or deep do we allow the optics to be? and so on...

All of these are constraints and every design has them. But the constraints are different from design to design, much like some cars are built for gas mileage and others are built for super-quick acceleration. That's why there is no single design that is good for every optical problem.

Usually, optics for HMDs have lots of constraints. You typically don't want to make them from glass because glass is heavier than plastic. You have limits on the lens diameter and size because you want to use them in a binocular setting. You don't want them to cost too much because you are aiming at some price target. When you give these constraints to the designer - after he or she finishes pulling their hair out - the design starts.

An optical lens has two sides. The exact curvature of each side can be different. If you have two lenses, you have four surfaces to work with. If you have 5 lenses, you have 10 surfaces to work with. More surfaces mean more degrees of freedom and more degrees of freedom mean that you can meet more of the constraints. So, having more optical elements usually means you can product a better image. In our case better meant less distortion, more focus, less color aberration.

It's almost like curve fitting: trying to fit a polynomial (e.g. y= a + b*x + c*x^2 + d*x^3 + ...) to set of (x,y) points. The more parameters you are allowed to use, the better your fit will be. If your curve is only "y = a", you'd often be in trouble. If you can use "y= a + b*x", you'll have a better fit and if you can use "y= a + b*x + c*x^2" you'll do even better.

So, we decided that a single-element design did not give us a good-enough answer to our constraints and decided to add a second element and give our designers additional degrees of freedom.

Here is what the design looks like

The screen is on the right side. The eye pupil is on the left side. The two lenses are in between: a 32-mm diameter lens closer to the eye and a 43mm diameter lens close to the screen. Note the interesting left-side surface of the bigger lens. It is made this way to optimize the image quality.

Here is what this looks in 3D:

Both lenses are made from optical-grade plastic. The smaller lens is from a material called Zeonex F52R and the larger one is from Polystyrene . There are hundreds of types of optical-grade glass but just a handful of plastics, but plastics are lighter and sometimes cheaper to use. One more constraint to worry about.

Why doesn't everyone use dual-element design? Because others might be focused on different constraints. For instance, dual elements roughly cost twice as much to make as a single element. Dual elements are heavier than a single element. Dual element eyepieces do a better job of controlling color and geometric distortion, but one could correct for color and geometric distortion with the GPU (though I don't know how one can correct for blurriness with the GPU). So, when we designed the OSVR HDK we were focused on some constraints and that's why we chose two elements.

Why not three or four or even five elements? Same story. We don't want it to cost too much. We don't want the optical path to be longer. We want to keep the weight down. Is someone going to soon write a blog post on their 7-element design? Maybe so. I can't wait to read it!


The post "How Things Work: the Dual-Element Optics of the OSVR HDK" first appeared on the VRguy's blog: www.vrguy.net

For additional VR tutorials on this blog, click here
Expert interviews and tutorials can also be found on the Sensics Insight page here

Open-Source Virtual Reality - a week after CES 2015

It's been a week since Sensics and Razer announced OSVR, the open-source virtual reality initiative at CES 2015 (see press release and supporting companies here). I thought it would be good to share some more details on what it is and what we have heard at the show and since then.

OSVR has two independent parts, an open-source software, a powerful software platform built for virtual reality devices and an open-source HDK (Hacker Development Kit), a lightweight, high-resolution HMD that will be shipping by June 2015 for $199.

The OSVR software platform is designed to encourage innovation and make it easier, simpler and safer to write virtual reality applications. Today, authors of VR applications have to decide what hardware they plan to support and then write to the specific API of these vendors. For instance, if you write to the Facebook/Oculus HMD, you need to use their API; if you want to use an Tobii eye tracker, you need to use their API; and so on. This approach carries a couple of challenges:

• Choosing to support specific hardware limits the number of users that can use the application
• If the API changes, you need to upgrade the application
• If new hardware, such as a new HMD, is released in the future, you will likely need to modify the application to support it

Is this a good approach? Probably not. Take a look at this Wordperfect Printer Driver page for a trip down memory lane. Years ago, you had to download a printer driver for your new printer to work with your older application. Today, do you upgrade your word processor when you get a new printer? Of course not. When you plug a new printer into your computer, the operating system typically recognizes it, fetches the appropriate driver and makes this printer available for all applications

OSVR solves a similar problem for VR. OSVR provides software plugins (think device drivers) for hardware that abstracts each type of hardware - such as head orientation trackers, position trackers, eye trackers - and makes the interface the same for the higher-level application. While the performance of different position trackers may be different, the interface to the application is basically the same. While some eye trackers are better then others, the application usually just needs to know gaze direction, blink detection and perhaps pupil size. By abstracting each type of hardware, the application does not need to change when new hardware becomes available. All it needs is a new plugin, the equivalent of a printer driver.

Because the OSVR software is completely free and open-source, one does not have to wait for Razer or Sensics to provide new plugins. Often, the hardware vendor will provide these plugins, but someone from the community can also write such driver and make it available to others. Just look at how many drivers were written for VRPN, a popular open source package focused on trackers. 

Even at CES, we were demonstrating the OSVR HDK with two different trackers. We could disconnect a unit and connect another one with a different type of tracker and the application would not care. We had VR demos running on top of Unity Pro and on top of Unreal Engine. We had OSVR running underneath Unity and Unreal and we had various plugins powering OSVR.

Of course, OSVR plugins are not limited to hardware plugins. We also have a class of plugins that we call 'analysis plugins' which turn data into better information. For instance, at CES we had units with the Razer Hydra controller. Information from the Hydra was then fed into an "analysis plugin" which implemented the "1-euro filter", a data smoothing algorithm. This could be added or removed at will. If you have a better smoothing filter, you can plug in instead of the 1-euro filter. 

Similarly, you could think about plugins that do gesture analysis, face recognition, eye tracking and much more. Not only that, but you might have multiple gesture engines or multiple trackers or multiple eye tracking algorithms. Select the best for your application, just like you select the best email application or photo enhancement app on the Google Play Store.

OSVR software runs on Windows, Linux and Android and I am sure it will be ported to additional environments as well as improved and enhanced.

The OSVR HDK (Hacker Development Kit) is also open-source. In a few weeks, you can go to osvr.com and download the schematics, bill of material, all the source code, the production files for the optics and so forth. You are allows to make these goggles, change them or incorporate elements in your own design. You think the goggles are cool but you have a better screen? Integrate it. Are you an optical expert and can make better optics than our dual-element, low-distortion eyepiece? Go for it! Want to change the front panel? Revise the head strap? Knock yourself out.

Of course, you can also buy a complete assembled unit from Razer ($199, shipping by June) and hack it from there. It is designed for hacking. We put USB3 ports on it, a powerful FPGA that allows changing the video processing and many features that encourage experimentation and improvement.

Why are people excited about this?

OSVR has received several 'best of CES' awards (thank you Popular Science, Tom's Hardware and others) but even more important, our inbox has been flooded with partnership requests whether from industry or academia. People love this concept. They love the freedom to choose. They love the freedom to innovate.

With OSVR, you can showcase your particular VR expertise without having the build a complete HMD to show it. With OSVR, you have a bigger market:

• If you develop an application (e.g. a game) on OSVR, you have access to a wide range of hardware
• If you are a hardware developer, by creating an OSVR plugin you can access all OSVR application. You don't have to go directly to the application developer to ask to support your hardware, just like a printer manufacturer does not have to ask Adobe to support a new printer in Photoshop.
• If you have a unique algorithm, you can test and showcase it with OSVR

At the end of the day, I love that we are tapping into the power of the community Think about it - if you were creating an encyclopedia today, would you prefer the curated model of Encyclopedia Britannica or the community model of Wikipedia where everyone can contribute their own expertise?

Is OSVR perfect? Of course not. Are there many plugins that still need to be written? Naturally, But the open-source approach allows this to happen quickly and reflect the preferences of the community.

How Eye Tracking can impact Head Tracking

I'll be visiting the Society for Neuroscience meeting this weekend in Washington, DC and will surely see some of the latest advancements in eye tracking.

Many times, people ask why is eye tracking useful beyond the obvious applications of facilitating research and providing user interface for people with disabilities.

One interesting application is in using eye tracking to minimize head tracking latency. Consider the following graph:

The graph shows the position of an eye (black line) and the position of the head (red line), provided in degrees over time. Let's look at some areas of this graph:

• From about 6.5 seconds to 6.7 seconds, we see rapid eye movement from about -5 to +25 degrees. During this period, the head did not move.
• From 6.7 to about 7 seconds, we see the head moving and, in the same time, the eye moving in the opposite direction. Notice that the sum of the head position and eye position is approximately constant throughout this period.
• From 7 to 8 seconds, both the eye and the head are stationary
• From 8 to about 8.2 seconds, the eye moves in the opposite direction
• From 8.2 to about 8.5 seconds, the head follows and the eye reverses direction

What is happening? It turns out that eye movements precede head movements. When the body wants to look in a certain direction, the eye jumps ahead (to a direction over +20 or under -20 relative to the 'straight ahead' position). Then, the head starts to follow while the eye compensates with a movement to the other direction so that the gaze direction (head orientation + eye orientation) stays the same. During the head movement, the eye remains locked on the same target.

Why is this useful? It is useful because significant eye movements signal the intent to move the head. If we wish to minimize the latency of sensing head movements, it might be very useful to use the hints provided by the eye. It shows us that a large movement is coming, and we can use this information in anticipating head movement, and thus reduce latency.

The (brief) Return of Tiled Displays

I've probably told the beginning of this story hundreds of times: in the late 1990's, a team of researchers led by Prof. Bob Massof at Johns Hopkins University, set out to achieve a seemingly-impossible task: to design a head-mounted display that was had both super-wide field of view as well as super-high resolutions.

The state-of-the-art display at that time was the eMagin SVGA OLED (800x600 resolution) that was just coming into production. One of the most popular mobile phones at the time was the Nokia 5110 which had an 84x47 black and white LCD display. The first HDTV broadcast in the US was in 1996 and displays were very large and heavy.

The solution was to use a tiled approach: bring together many small micro-displays, arrange them in a circular fashion so that they all point at the center of rotation of the eye, put an array of small "magnifying glasses", one magnifier in front of each display, and carefully align them to produce a nearly seamless image. The lenses were needed both to allow the eye to focus on an object so close to the eye as well as to eliminate the physical edges and borders between adjacent displays, magnifying each display so as to create an optical overlap. Keep in mind this optical overlap - it is going to be important later in this post.

See the images below for an illustration and a photo of an actual tiled module.

Concept of tiled HMD

Display module with 6 tiled SVGA displays

The performance was quite amazing. The original model had 16 800x600 displays per eye (4 rows of 4 displays each), so about 7.7M pixels. Commercial models of this, the piSight and xSight would go on to deliver >150 degrees field of view and 6 million pixels per eye. The image overlap between adjacent screens was about 30%.

There were a few downsides to this design: careful calibration was required to get both the geometry and colors nicely aligned across displays; a lot of computing or FPGA power was needed to reformat an image so that it displays inside the HMD because each display shows a somewhat different perspective of the 3D scene and because images in adjacent screens had content overlap. The result: some people loved it, some people not so much, and these products have generally been superseded by newer products that use either high-resolution microdisplays or high-resolution smartphone displays, both offering about 2 million pixels or more per eye using a single display.

A couple of months ago, I was invited to speak on a panel at the Siggraph 2014 show in Vancouver. While at Siggraph, I had the opportunity to visit some of the talks and technical exhibits and was delighted to see tiled display technology being used again.

The first example was a demonstration called Hapto MIRAGE from Tachilab in Keio University, See their demo video here

Hapto MIRAGE used three active-shutter LCD displays arranged so that their optical axis were intersecting. Large Fresnel lenses were placed in front of each display to magnify the image and take care of removing the seams. This was far from a wearable unit, but the concept seems identical to the original Johns Hopkins University work.

Another example was actually from 2013, though it was discussed again in an HMD session: the near-eye light field displays from NVIDIA:

In this demo, a small OLED was used and an array of very small lenses was placed in front of it. Small lenses allow for very small focal length, which makes it easy to place near the eye in a very lightweight package. The demo is very compelling but there is a catch: the overlap between the images displayed in each micro-lens is very large - approx 80% if I remember correctly. This means that the effective resolution of the display is reduced dramatically because so many pixels are overlapping. Thus, one might start with a 1280x720p micro display but end up with effective resolution of about 320x240, thus somewhat limiting the practical use of this particular configuration.

Are tiled displays making a comeback? Probably not, given high-resolution smartphone displays (including curved displays). But, it was certainly fun to see other implementations of the same fundamental principles developed at Johns Hopkins some 15 years ago.

The Sensory Explosion

At last week's SIGGRAPH conference, I had the pleasure of contributing a "Sensory Explosion" presentation.on the "Sight, Sounds and Sensors" panel.

Below are the key slides and some speaker notes. Enjoy!

The panel featured several contributors:

• Cynthia Traeger. Pacific
• Mark Mine, Walt Disney Imagineering
• Chris Mayhew, Vision III Imaging, Inc.
• Becky Oh, PNI Sensor Corporation
• Myself

Sensics has been doing VR for a long time. Historically, it has mostly focused on enterprise applications (government, academia, corporate) and it is considering how to best leverage its technologies and know-how into larger markets such as medical devices and consumer VR.

Traditionally, head-mounted displays had three key components: a display (or multiple displays), adaptation optics and most often an orientation sensor. Most of the efforts were focused on increasing resolution, improving field of view and designing better optics. The orientation sensor was necessary, but not the critical component.

Recently, we are seeing the evolution of the HMD as a sensory platform. On top of the traditional core, we see the emergence of new types of sensors: position trackers, eye tracking, cameras (either for augmented reality and/or depth sensing), biometric sensors, haptic feedback, sensors that perform real-time determination of hand and finger position and more. Increasingly, innovation is shifting to how to make these sensors deliver maximum performance,  lightest weight (after all, they are on the head), and utmost power-efficiency (both for heat dissipation reasons as well as battery life for portable systems)

Above and beyond these on-board sensors, VR applications can now access sensors that are external to the HMD platform. For instance, most users carry a phone that has its own set of sensors such as a GPS. Some might wear a fitness or be in a room where a Kinect or some other camera can provide additional information. These sensors pose an opportunity for application developers to know even more about what the user is doing.

Integrating all these sensors can be pretty complex pretty quickly. Above is a block diagram of the SmartGoggles(tm) prototype that was done by Sensics a few years ago. These days, there is a much greater variety of sensors, so what can be done about them?

I feel that getting a handle on the explosion of sensors requires a few things:
1. A way to abstract sensors, just like VRPN abstracted motion trackers.
2. A standardized way to discover which sensors are connected to the system.
3. An easy way to configure all these sensors, as well as store the configuration for quick retrieval
4. A way to map the various sensor events into high-level application events. Just like you might change the mapping of a the buttons on a gamepad, you should be able to decide what impact does a particular gesture, for instance, have on the application.

But beyond this "plumbing", what is really needed is a way to figure out the context of the user, to turn data from various sensors into higher-level information. For instance: turn the motion data from two hands into the realization that the user is clapping, or determine that a user is sitting down, or is excited, or happy or exhausted.

We live in exciting times with significant developments in display technologies, goggles and sensors. I look forward to seeing what the future holds, as well as to make my contribution to shaping it.

Positional tracking: "Outside-in" vs. "Inside-out"

Optical positional tracking for goggles uses a camera (or cameras) and a known set of markers to determine the position of the camera relative to the markers. Positional tracking can be done using the visible spectrum but is more commonly done using infra-red markers and a camera that is sensitive to IR light.

There are two main options:

• Inside-out tracking: where the camera is based on the goggles and the IR markers are placed in stationary locations (e.g. on the computer monitor, on the wall, etc.)
• Outside-in tracking: where the camera is placed in a stationary location and the IR markers are placed on the goggles.

In both cases, the targets sometimes flash in a way that is synchronized with the camera. This allows reducing power consumption for the targets and helps reduce tracking noise from IR sources that are not the targets.

Sensics dSight panoramic HMD with IR targets for "outside in" tracking

How do these approaches compare?

• Tracking volume: in both cases, at least some of the targets need to be visible to the camera. When the user rotates the head, an "inside-out" system needs targets that are physically far apart. If the targets are, for instance, placed on the bezel of a notebook PC, it is easy to see how head rotation could easily take these targets out of the field of view of the camera. A wider lens could be used in the camera, but this would reduce the tracking precision as each camera pixel would now cover a greater physical space in the world. In the "outside-in" system, targets could be placed on most sides of the goggle, allowing reasonably large rotation while still having targets visible on the camera. Advantage: outside-in
• Tracking inside an entire room: if we want to allow mobility within a room, an 'inside-out' system would require additional markers on the walls, whereas an 'outside-in' system would require additional cameras. Both systems would require room calibration to make sure the target and/or cameras are placed in a known position. Additional cameras require additional processing power. Slight advantage: inside-out
• Where is data being processed? In "inside-out' tracking, the camera data is either processed on the goggle or the camera is connected to a computer that is either carried by the user or stationary and connected via a wire. In 'outside-in' tracking, the data is processed on a computer that could be stationary. Advantage: outside-in
• Can this be used with a wireless goggle? If the goggle is not tethered to a computer, "inside-out" tracking requires that the data is either processed locally or that the camera signal is sent wirelessly to a base station. In contrast, an 'outside-in' approach does not require wireless data of the camera. At most, a synchronization signal can be sent to the IR LEDs to make sure they flash in sync with the camera. Advantage: outside-in
• Ability to combine with augmented reality system. Sometimes, the goggle will already have an on-board camera (or cameras) for the purpose of augmented reality and/or 3D reconstruction. In that case, using the same camera for positional tracking may have some cost advantages if positional tracking can be used with visible targets or if the camera already has IR sensitivity. Advantage: inside-out

Note: tracking accuracy is also an important comparison parameter, but this is more difficult to generically compare across both approaches. Very often, accurate tracking is achieved not just through the camera data but also by integrating ("sensor fusion") rotational data and linear acceleration data from on-board sensors. The sensors used and the quality of the sensor fusion algorithm would determine which approach is better.

Bottom line: for most applications, an 'outside-in' approach would be better, and thus we expect to see a greater number of 'outside-in' solutions on the market.

What has been your experience?


For additional VR tutorials on this blog, click here
Expert interviews and tutorials can also be found on the Sensics Insight page here