Virtual Reality (VR)
Forklift Training Simulator

System Architecture Redesign, UX Research

A training simulator that teaches operators how to drive various forklift trucks in virtual reality while using real truck control handles. Trainers can hook up the system to a real forklift truck and start training in less than 5 minutes.

Demoing the next generation VR Simulator during launch at MODEX 2022.

Introduction

The Challenge

To launch a complete system architecture redesign in order to upgrade an HTC Vive (2016) based VR system to more modern and easy to use hardware.

Project Goals

  • Simplified Setup

    The original product included many discrete sensors, wires, and other pieces of hardware. This not only required 15+ mins of setup time but also allowed for many potential hardware points of failure, which put a strain on field service resources even for simple problems like a loose cable.

    With new VR technology enabling inside-out tracking and integrated sensors (e.g., hand tracking), the reduction in required hardware simplifies both the customer setup and troubleshooting processes.

    User Pain Point Addressed: Difficult setup

  • Increased Comfort in VR

    Simulator sickness is a well-known problem in VR systems, especially for driving-type simulations where virtual movement does not translate to real-life tactile feedback. Because driving was a key aspect of this product, clever solutions to avoid simulator sickness were needed.

    A combination of better-quality hardware and research-backed software and process modifications allowed for a reduction of motion sickness in certain eligible customer populations.*

    User Pain Point Addressed: Simulator sickness

  • Adaptability for Future Requirements

    By the time this redesign project started, the original HTC Vive (2016) hardware was already on its way to obsolescence. This not only meant that we’d be unable to secure more hardware for new or replacement parts but certain new software features would be completely unattainable without new sensors.

    We prototyped our initial system architecture solution using Oculus Quest 1&2 headsets and easily adapted to our final hardware choice, the HTC Vive Focus 3, in the final commercialization process before launch.

    User Pain Point Addressed: Accommodating future needs

* certain aspects of simulator sickness are biological in nature or highly situational, meaning complete elimination is not practically achievable for all individuals

My Role

Within months of joining the company as a research engineer, I was introduced as the new engineering project lead for VR, where I became the SME and wore several hats. This included technical project management, product design, technical troubleshooting, and UX research as primary activities.

The Design Process

VR Hardware Selection

The first step in our design process was to choose a new VR headset.

While the headset used for prototyping would not necessarily be the final released hardware, we needed to initially test several candidates to narrow down our list of key features to build the new system architecture around. These contenders needed to, at minimum, enable the capabilities of our previous simulator while also taking advantage of new features that could solve our biggest user pain points, such as difficult setup and simulator sickness.

The final contenders were selected using a weighted rating system to determine the best features match.

0 = unavailable

1 = possible, but with caveats

2 = natively available

Prior to engaging our developer team to create software prototypes, team members stress-tested various consumer games on these devices to determine whether or not the hardware lived up to its specifications.

Sample game footage (via PlayStation).

This was the start of my household reign of Expert+ high scores!

  1. If the feature already exists in our current solution (e.g., hand tracking for menu selection), the quality of the new headset must match or exceed that of the original.

    Customers have already developed expectations about our product, so we cannot regress in quality.

  2. If any desired features are missing, the new features of the new headset must solve a significant problem from the original.

    In this case, the significance of a problem is defined by the impact it has on customer sales and retention of the VR training program. In other words, if a feature can solve a deal-breaker, it is worth exploring.

Once our developers were ready to create functional prototypes for each headset, our decision was based on the following criteria:

  • Hand Tracking

    In the original product, hand tracking was used for menu selection and creating a sense of immersion, which was accomplished with a LEAP Motion sensor.

    In order for the new headset to be successful, the native sensor needed to perform as good or better on tests such as occlusion (when parts of the hand are blocked from sensor view) and the field of view (FoV).

  • Foveated Rendering

    Foveated rendering is a technique used to optimize graphics performance, but it can also have a positive effect on reducing simulator sickness. Only one headset offered native eye tracking, so it was a tall order for this one feature alone to qualify it as our headset of choice.

    Unfortunately, our testers could not notice a significant difference with or without foveated rendering so it disqualified the device from consideration.

And with that, our selection process was complete.

The chosen headset for prototyping was the Oculus Quest 1 (and later, Oculus Quest 2) for the high quality and function of its native tracking features.

System Architecture Definition

The original version of the product was using an HTC Vive headset which, from the perspective of a computer, is handled like an extra display. By selecting a wireless headset for the new upgrade, we had to make several decisions.

To answer this question, our team brainstormed several different potential configurations, and the challenges they posed, to explore options ranging from the theoretically ideal to what is most practically possible for the simplest next jump. These options were tested with stakeholders, internal users, and eventually, potential customers to find the best fit.

For this, we decided on a laptop and mini router solution that minimized form factor, gave trainers the most control over the experience, and reduced latency over the wireless connection.

Original configuration as shown in the public patent.

Some of these questions included,

  • Should we still utilize a Trainer Station*?

  • Does the Trainer Station need to be a computer?

* i.e., the device a forklift trainer uses to view and control the training session

Oops! This page is under construction!

Oops! This page is under construction!

This page is currently in progress.

Please check back later when the write-up is finished!