It’s clear then that Immersive Robotics is moving on apace, with the team aiming to show off their technology at the forthcoming CES trade show in Las Vegas next month. In order to dig a little deeper, find IMR’s answers to some of our burning questions regarding their technology below.
Road to VR: It sounds as if the key USP is your compression. Is this entirely proprietary? If so, does this mean you’ve had to build custom compression acceleration for the (presumably) SoC used in the transmission and receiving devices?
IMR: Our compression / decompression is proprietary and built from the ground up specifically to tackle the problem of sending VR data between any supported devices. Call it a VR standard if you will. Our flagship product demonstrator is sending the VR video and USB data seamlessly between the PC and HMD wirelessly. Aside from the core algorithms and VR standard we have designed, the complete system is implemented on our real time electronics hardware.
We show a system end to end (compression, transmission and decompression) of less than 1 ms. Other people currently coming to market that we’ve observed have EXTREMELY high latency which is not practical for VR and will make people sick. It also has no future expand-ability.
A considerable amount of time and resources on our part has gone into actually creating this architecture that the algorithm can run on which is extremely fast and robust, we chose to do this completely independent of the computer, so it is not slowed down by any software layers it is all completely embedded. There is no software or drivers to install. This involves our own custom PCB hardware and all the supporting code that runs on the chips. All of this is proprietary. (Provisional patent filed in the USA – United States Provisional Patent Application No. 62/351738 – “IMAGE COMPRESSION METHOD AND APPARATUS”)
Road to VR: You say the process of compression and transmission adds only 1ms latency – is that motion-to-photons? How did you go about measuring the latency?
IMR: The process of compression and decompression of a single frame at around 95% introduces latency only in the hundreds of microseconds end to end. This is measured via clock cycles of our hardware, the time it takes to compress and subsequently decompress a bit of data. This measurement is a measurement of what we are replacing – ie: the HDMI cable in the video’s case for example. So the latency is added to the system latency where the HMDI and USB cable is usually connected.
Road to VR: What radio transmission technology / frequency are you using and how are you dealing with potential line of sight issues?
IMR: We are actually able to utilize a selection of off the shelf WiFi modules, we chose this path because of the strength in our compression we are able to get the data rate to an acceptable level to just take advantage of the latest existing WiFi tech, it brings the cost down and also opens up opportunities for us to partner with other companies that are already doing well in this area.
We can use anything from the 802.11 AC and for even more bandwidth and less compression we can move up to the new AD standards.
Our antenna placement on our belt allows for an antenna to almost always be in view of a base station. The line of sight issue is a little more pronounced with higher frequency and needs more care given to antenna placement.
Current model being released at CES is using 802.11 AC
Road to VR: What is the maximum range for the system, between base station and receiver?
This depends on the WiFi Frequency being used and the level of compression chosen, we can automatically scale the compression to the signal to noise ratio or the user can select a preset.
With the data-rates for this application, AC can be up to 50m theoretically and depends somewhat on environmental factors, it is certainly far enough for most play areas. We are aware that our technology also allows people to develop much larger play areas and ad many more people to them, this is something we are partnering up with interested companies to test.
We are guaranteeing with our modules the ability for multiple users to play in the same large area. VR Arcade companies we are in contact with have suggested an area of up to 30×30 would be fantastic, so we are testing to support this currently.
Road to VR: What expertise did you leverage, historical or through hiring, to allow you to engineer such an efficient codec?
IMR: The Compression algorithm was developed completely between Dr Daniel Fitzgerald and myself. Our backgrounds are Aerospace & Robotics, primarily we used to develop UAV/”Drone” technology, for high-end mission critical tasks.
This involved a lot of wireless / camera, vision processing technology as well as safety and time critical hardware and software combinations, advanced autopilot development and rapid prototyping. It worked out that we saw an evolving requirement for this sort of thing in the VR industry and had the prior skills and knowledge to apply to it and make it happen quickly.
We received investment for the company and hired skillful engineers to assist with things like PCB design, interfacing with HDMI, ethernet, wireless chips, etc and solving issues like creating the invisible wireless USB link.
Road to VR: You mention your compression skirts issues you found with pre-existing systems already out there, can you detail what those were specifically and what codecs you tried?
Existing and conventional video compression like H.264 and many others uses frame to frame compression (frame buffering) to achieve its level of compression, this is fine to view something on a screen. but for example if you used it for the HTC Vive
you would end up with over 11ms of added latency (buffering a single frame), and as the screen resolution got bigger in the future you would end up with even more.
Without going into too many proprietary details, our system is able to work on such little latency because we figured out how to do a specialized style of compression without being constrained by any of this.
This delay issue described above is the key difference between our system and what is currently being pushed by other companies on the market. We have thought of the real problem from the beginning rather than trying to push out a product fast that is unacceptable for VR. If you are developing a wireless accessory for VR you can get away with maybe 2 or 3 ms MAX delay being introduced by the wireless portion of the system.
Road to VR: You say IMR is working towards productising this technology. What price range are you looking to shoot for – a very rough ballpark is obviously fine here?
IMR: We are targeting business customers who can roll this out to consumers for applications such as VR arcades, theme parks, training etc. Price point would depend on quantities but roughly around $1200-1500.