{"id":95,"date":"2016-11-12T03:37:49","date_gmt":"2016-11-12T08:37:49","guid":{"rendered":"http:\/\/www.talariavr.com\/blog\/?p=95"},"modified":"2016-11-29T21:23:35","modified_gmt":"2016-11-30T02:23:35","slug":"steamvr-tracking-license-day-2","status":"publish","type":"post","link":"http:\/\/www.talariavr.com\/blog\/steamvr-tracking-license-day-2\/","title":{"rendered":"SteamVR Tracking License Day 2"},"content":{"rendered":"

Full Day<\/strong><\/span><\/p>\n

Alright! \u00a0Today was our first full on training day, and we did nothing but learn from 9:00 – 5:00; it was so amazing! \u00a0We’re all very much friends in the class at this point, cracking jokes and sharing ideas. \u00a0Synapse does a great job at creating a fantastic educational environment; I’d be eager to return here in the future if I ever have the opportunity.<\/span><\/p>\n

Highlights for the second day are that we learned how to simulate and optimize sensor placement, and we’re all getting pretty good at knowing what to look out for when designing tracked objects so they are sure to have the best tracking. \u00a0Designing for lighthouse is very much a skill that comes with practice, and over time you develop an intuition for what will work best.
\n<\/span>
\nSimulation<\/strong><\/span><\/span><\/p>\n

So before diving into any physical hardware, Valve has created a magnificent visualization tool called HMD Designer. \u00a0It’s got a few different options, but ultimately you feed it a 3D .STL model and it will spit out possible optimized sensor positions and angles for the best quality of tracking. \u00a0Another thing you can do is feed it a .JSON file with the sensor positions already defined, but we’ll get into that later.<\/span><\/p>\n

A great and key feature of HMD Designer is that it outputs multiple visualizations, primarily used to see how the lighthouse protocols interact with your object and its current sensor positions. \u00a0FYI, dense lighthouse science ahead.<\/span><\/p>\n

\"HMD<\/a><\/span><\/strong><\/span><\/p>\n

In this graphic (click to zoom),\u00a0a 2D representation of how simulated tracking performs with your specific object helps tell us where any potential shortcomings of the current design may be. \u00a0The bluer, the better! \u00a0Also, regarding the format of these graphs, we are looking at unwrapped 3D visualizations (we’ll see the wrapped versions later). \u00a0The left and right outer edges are -Z, centre is +Z, top is +Y, bottom -Y, and central-left is -X, central-right +X. \u00a0If that doesn’t make sense, bear with me until the end of this section.<\/span><\/p>\n

In the first graph, we see how many sensors can see the lighthouse at any given surface point of the object. \u00a0The more sensors visible, the more datapoints we get! \u00a0This is great because with more datapoints comes redundancy, and that really helps lock down a very definite pose.<\/span><\/p>\n

In the second graph, we’ve got a heatmap of potential rotation errors. \u00a0These errors are caused by all visible sensors residing on a very similar plane (discussed briefly in Day 1<\/a><\/span>), and because of that, SteamVR will have a very tough time negotiating minute changes of\u00a0rotations which face the lighthouse, as such rotations will frequently make very little difference to the time between contacting the lighthouse scan. \u00a0Solving this problem can be done through adding \/ modifying sensors to be out of the plane created by other visible sensors.<\/span><\/p>\n

For the third visualization,\u00a0the simulation tells us if acquiring an initial pose is possible from various positions. \u00a0An initial pose is acquired fully through the IR sensors – you can’t use an IMU for tracking if you don’t know where object was previously. \u00a0Because of this, you need\u00a0at least<\/em> four sensors visible from a position, one removed from the plane of the other three (again, as you’ll notice, this fact is very important and more or less is the core of sensor placement design).<\/span><\/p>\n

And finally, pose translation error rises from sensors being strictly colinear. \u00a0First of all, if your sensors are colinear, you’re going to run into more problems than just pose translation error – namely rotation error since if the sensors don’t even have a plane, you certainly won’t have any sensors removed from one. \u00a0Then either of those errors result in a failure to capture an initial pose. \u00a0Secondly, if your sensors are colinear and are struck by the\u00a0laser at specific times, then SteamVR has no way of understanding the rotation and position from these colinear sensors alone. \u00a0There are a lot of possible positions in which the problem sensors would be struck at those times! \u00a0Fixing this is simply pulling a sensor out of line (and hopefully out of plane as to avoid rotation errors).<\/span><\/p>\n

\"3D<\/a>\"3D\"3D<\/a>\"3D<\/a><\/span><\/p>\n

Then these images show Valve’s 3D visualization software that wraps the 2D graphs shown above onto a visualization sphere surrounding the object being simulated (in this example the object is a sort of beveled block). \u00a0In the second 3D visualization, I have enabled rendering of the pose rotation error, which means that from the user’s point of view (which is the point of view of the lighthouse), pitch and yaw have potential to be uncertain in areas with more red. \u00a0It comes without surprise that the rear of this object has complete failure to capture or estimate rotation, seeing as there are no sensors on that face! \u00a0If you look at the perspective where that yellow cusp is within the\u00a0reticle, in the third 3D viz capture, you can identify that most sensors in view reside on a plane that is normal to the perspective. \u00a0If it weren’t for that fourth sensor inside the cusp, that area would be as red as the underside of the object is!
\n
\n<\/span>JSON<\/strong><\/span>
\n<\/span><\/span><\/p>\n

So all this information is great and valuable, but it doesn’t mean much to a computer as a bunch of colourful graphics. \u00a0That’s where the<\/em> JSON comes in. \u00a0The JSON file is host to\u00a0all important information unique to the device. \u00a0Sensor positions, IDs, normals, IMU placement, render model, and a few other less important identifiers are all included in this magical file. \u00a0The JSON is stored on the device, and is then presented to SteamVR when initially plugged in. \u00a0Using the information contained within the JSON, SteamVR now knows how to interpret all incoming signal data from the device, and that means we’ve got sub-millimeter tracking in VR! (cough<\/strong> after calibration\u00a0cough<\/strong>)<\/span>
\n
\n<\/span>Optics<\/strong><\/span>
\n<\/span><\/span><\/p>\n

After all that high-level optimization and reporting, we got a brief rundown of optics and the challenges that come with protecting infra-red sensors for consumer use. \u00a0Valve and Synapse have conducted a number of scientific analyses of how IR light interacts with different types of materials in different situations, and how those interactions effect sensor accuracy when receiving lighthouse scans. \u00a0Comparing elements such as transparent vs. diffuse materials, sensor distance from cover, apertures, and chamfers, Valve and Synapse have come to the conclusion that a thin, diffuse material that is opaque to visible light but diffuse to IR is best for lighthouse reception. \u00a0Additionally, an aperture is added around the diffuse material so that the light\u00a0doesn’t activate the sensor before it should actually be “hit.”<\/span>
\n
\n<\/span>Hardware!<\/strong><\/span>
\n<\/span><\/span><\/p>\n

Then came the boxes. \u00a0The glorious, unmarked cardboard boxes! \u00a0We got a lot of goodies inside (I’ll be sharing my development with them over the next few weeks), but the most impressive tool is pictured below (thanks to Michael McClenaghan<\/a><\/span><\/span> for the photography):<\/span><\/p>\n

\"Watchman\"<\/a><\/span><\/p>\n

This is the Watchman board! \u00a0On this little thing – only about a square inch – is just about everything needed to have a fully functioning SteamVR tracked device. \u00a0The components it requires a (very easy) connection to are a battery, an antenna, a USB port, and of course the IR sensors.<\/span><\/p>\n

Other fun hardware treats we received were IR sensor suite “chicklets,” which contain an IR sensor, Triad Semiconductor’s TS3633<\/span><\/span><\/a> ASIC, and a small handful of discrete components, some breakout\/evaluation boards, input devices (including a trackpad identical to those included in Vive and Steam Controllers!), and some assorted ribbon cables.\u00a0 Oh, and of course – the reference objects!
\n<\/span>
\nExperimentation<\/strong><\/span><\/span><\/span><\/p>\n

Synapse was kind enough to give us premade reference objects (which are really dense, by the way. \u00a0One of the file names associated with it is\u00a0“thors_hammer” and it is certainly worthy of such a name). \u00a0These objects can be used as digital input devices, or if the handles are disconnected, they are large enough to fit over most modern-sized HMD’s for easy SteamVR Tracking integration! \u00a0Photoed below is a group of us testing out our reference objects.<\/span><\/p>\n

\"Reference<\/a><\/span><\/p>\n

O<\/span>ne of my favourite things about this image is how many controllers are connected in the SteamVR status window. \u00a0Also, if you don’t know who I am, I’m the lad wearing the rainbow shirt. \u00a0Hi!<\/span><\/span><\/p>\n

Another reason we’re flailing our controllers around is to calibrate the sensor positions. \u00a0When you prepare your files on a computer, all the sensors are in ideal locations. \u00a0This, of course, is not how the real world works. \u00a0So, through the magic of Valve UI, by flailing these unwieldy devices around for a minute or two, the sensors get a pretty good idea of where they are all actually located. \u00a0We then take these corrected positions and write a new JSON file to the controller via the lighthouse console (this console is the bread and butter of interfacing with your tracked objects – you can extract firmware, stream IMU data, enter calibration, etc).<\/span><\/p>\n

\"Steam<\/span><\/strong><\/p>\n

Fooling around a bit more, I decided to alter the JSON file on my reference object so it would be identified as a Steam Controller. \u00a0And lo and behold! \u00a0A Steam Controller in the SteamVR white room! \u00a0Positionally tracked in all its glory.<\/span><\/p>\n

And then to close the night,\u00a0Synapse hosted a Happy Hour\u00a0for us all to be social and inevitably geek out about VR together. \u00a0We chatted about hardware, locomotion<\/span><\/a><\/span>, multiplayer, narrative… I love this industry.<\/span><\/p>\n

As usual, please feel free to post to\u00a0the comments<\/a>\u00a0or email me at\u00a0blog@talariavr.com<\/a><\/span><\/span>\u00a0with any questions or conversation. \u00a0Be on the lookout for my summary post where I will answer community questions in bulk once the training is done. \u00a0Cheers!<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Full Day Alright! \u00a0Today was our first full on training day, and we did nothing but learn from 9:00 – 5:00; it was so amazing! \u00a0We’re all very much friends in the class at this point, cracking jokes and sharing ideas. \u00a0Synapse does a great job at creating a fantastic educational environment; I’d be eager to return here in the future if I ever have the opportunity. Highlights for the second day are that we learned how to simulate and…<\/p>\n

Read More Read More<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,6,7],"tags":[],"class_list":["post-95","post","type-post","status-publish","format-standard","hentry","category-hardware","category-steamvr-tracking","category-steamvr-tracking-license-steamvr-tracking"],"_links":{"self":[{"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/posts\/95","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/comments?post=95"}],"version-history":[{"count":26,"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/posts\/95\/revisions"}],"predecessor-version":[{"id":132,"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/posts\/95\/revisions\/132"}],"wp:attachment":[{"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/media?parent=95"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/categories?post=95"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.talariavr.com\/blog\/wp-json\/wp\/v2\/tags?post=95"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}