VR Disability Accessibility Proposal

Introduction

As technological advancements propel the evolution of virtual reality (VR) devices, including the introduction of sophisticated full-body capture devices and haptic feedback mechanisms, there emerges a promising landscape for expanded gaming, educational, and resource applications. However, the current state of VR technology presents significant challenges for individuals with disabilities, particularly those affecting the arms or hands.

Addressing accessibility concerns for people with disabilities requires a multifaceted approach. The proposal we present aims to specifically tackle these challenges encountered by individuals with arm or hand disabilities. Our solution involves creating a foot-controlled controller equipped with pressure sensors, enabling both continuous and rapid inputs. To facilitate this, a USB driver will be developed to interpret and recognize signals, while software will manage the calibration process by storing and standardizing an individual’s weight and pressure data. The sensors will operate on their own battery packs to ensure power supply and minimize cable entanglement. Additionally, a potential option involves using a single Bluetooth device for wireless data transmission, albeit with increased power consumption. The system will rely on an ATMega32 microcontroller and a USB-to-Serial adapter for signal transmission, with the provision for a Bluetooth-to-Serial adapter if Bluetooth connectivity is adopted.

The proposal details various approaches to enhance adjustability and accessibility for users, elaborated further in the subsystems section of this proposal.

To determine the most accessible design, rigorous testing is imperative. We aim to explore three primary input options: a stationary hub serving as a base for electronics and power, a wearable combination of strapped-on sensors and battery packs, and a fusion design that incorporates sensors on a pad (similar to the Dance Dance Revolution game pad) with physical markers aiding users in navigating the controller. Our project will focus on testing and designing prototypes for the first and third input options.

Background

Several disability-specific controllers are available in the market, such as the QuadStick FPS game controller and the Microsoft Adaptive Controller. However, these options tend to be costly and aren’t specifically designed for VR use [1][2]. Presently, there exists just one foot controller intended for VR—the 3D Rudder Foot Motion Controller. Despite some commendations, including positive feedback from individuals with upper body disabilities, criticisms revolve around its challenging control and tendency to slide during use [3]. Our design aims to rectify these limitations.

Developing controllers for VR poses unique challenges, contributing to the scarcity of suitable options. VR controllers operate on a different software development kit (SDK) compared to established systems like PS4 or Xbox controllers. Thus, any new controller must be compatible with the VR headset. On the hardware front, it’s crucial for the controller to be usable without visual guidance since users have their headsets strapped to their faces. Ensuring stability and comfort during prolonged use is vital. If a user can’t navigate the controller without sight, it becomes impractical for VR use. General VR development concerns, such as maintaining a natural feel for users to enhance immersion and ensuring peripheral durability to accommodate user movements during intense engagement, also need careful consideration. This includes managing wires and peripheral components to avoid tangling or collision with other objects.

Physical Design

Figure 1: Representation of a sensor pad based approach to controller design with location of subsystems. Each wire has its own type defined by color: Blue – Pressure sensor output, Orange – Power Supply, Purple – Serial data from microcontroller, Maroon – USB data.
Figure 2: Artist’s rendition of a hub based approach.

1.4 High Level Requirements

The primary project requirements are outlined as follows:
– Signals from the pressure sensors are transmitted to a computer.
– The computer is equipped with a driver capable of interpreting these signals (e.g., mapping the left foot heel signal to a ‘left_foot_heel’ variable) and making them available to other programs.
– The controller’s interface should be accessible to users with upper body disabilities who are wearing a VR headset.

2.0 Design

2.1 Block Diagram

Figure 3: High-level block diagram

The depicted block diagram provides a comprehensive overview of the device’s functionality. It begins by receiving input from the user through a pressure sensor. This input signal is then transmitted to the electronics hub before being forwarded to the PC driver and software. Here, it undergoes processing to generate a functional xInput device signal usable by various programs. This block diagram effectively meets all the high-level requirements by successfully detecting user input and transforming it into a signal compatible with games or other software applications.

Functional Overview and Block Requirements

  • Pressure Sensors

This segment comprises four load cells along with four HX711 24-bit analog to digital (AD) converters. Each foot utilizes two cells, providing the user with four separate inputs via the balls or heels of their feet. Every load cell connects to an HX711 24-bit AD converter, transforming analog load cell signals into digital ones for processing by the ATmega32 Microcontroller. Wires establish the connection between this subsystem and the ATmega32 Microcontroller.

Specified Requirements:
– HX711’s operational voltage: 2.6-5.5V
– HX711 AD converter’s signal conversion delay should not exceed 5ms
– Load cells need to sustain weights of up to 100kg

  • Electronics Hub

This segment comprises an ATmega32 Microcontroller paired with a Serial-to-USB adapter. The microcontroller receives inputs from the HX711 AD converters, processes the signals, and forwards them to the Serial-to-USB adapter. Subsequently, the microcontroller establishes a connection with a computer through USB, enabling the processed signals to be accessible to a driver or compatible software.

Stipulated Requirements:
– The ATmega32 should operate within a voltage range of 4.5 to 5.5V.
– The ATmega32 must efficiently process and transmit the signals to the Serial-to-USB adapter within a maximum duration of 5 milliseconds.

  • Power Supply

This subsystem offers flexibility, capable of integration with the Serial-to-USB adapter or functioning as a distinct power source. Its primary role is to energize all other electronic elements within the device, conforming to specified voltage parameters. While the Serial-to-USB adapter aligns with the USB standard by providing 5V power when connected to a PC, an alternative scenario involves transforming the device into a wireless variant that connects via Bluetooth, necessitating a battery or alternate power supply to sustain operation within the prescribed voltages.

Stated Requirements:
– Sustain a continuous output of 500mA at 5V with a tolerance of +/- 0.5V.
– (If powered by a battery) Possess sufficient power to sustain operations for a minimum of 5 hours.

  • USB Driver

The USB driver and accompanying software serve the purpose of interpreting incoming data from both the microcontroller and sensors, converting it into a format usable by PC applications. This driver must proficiently interpret the transmitted data from the microcontroller and present it in a manner accessible to secondary software, allowing for appropriate inputs into games or other applications. Furthermore, the software should offer the capability to establish activation thresholds for individual pressure sensors, ensuring comfort for users across various weight ranges.

Specific Requirements:
– The driver must process incoming signals within 10 milliseconds upon reception.
– The driver must segregate distinct inputs for each foot input, such as left_heel, right_heel, left_toe, right_toe, etc.
– The software should include functionality to modify weight thresholds.
– The software must transmit xInput signals to other programs.

Risk Analysis

The component posing the most significant challenge to the project’s successful completion is the USB driver and its corresponding software. Creating a USB driver from scratch is intricate, requiring flawless functionality to ensure minimal to zero errors in device communication. This task can be particularly challenging considering the project’s time constraints. Another hurdle lies in developing software that accurately configures activation thresholds for the device. Following extensive documentation is crucial for successfully emulating an xInput device, which may present complexities. In contrast, implementing the remaining subsystems should be comparatively straightforward as it primarily involves adhering to provided datasheets for each subsystem.

3.0 Ethics and Safety

Given the VR-focused nature of the project, several significant health considerations arise. Virtual reality headsets are known to induce nausea and anxiety, particularly after prolonged use, posing a heightened risk for individuals with disabilities. Additionally, these headsets can lead to eye strain and heightened stress stemming from immersion in the virtual environment. It’s imperative to recognize these issues as we develop this technology, ensuring our project doesn’t exacerbate these concerns, whether unintentionally or deliberately.

Regarding testing procedures, only project members will assess the technology due to limited development time. This limitation prevents certainty regarding readiness for beta testing with the intended audience. Hence, extensive self-testing will precede any such phase.

Ethical aspects relevant to the project align with the IEEE Code of Ethics Section 1.1, prioritizing public safety and health. It’s crucial to ensure the project’s safety for all users, especially considering our target audience includes individuals with disabilities. Clear understanding of the technology’s effects and associated risks, accompanied by proper consent through waivers, will guide our testing procedures. Moreover, the ACM Code of Ethics Section 2.7 emphasizes public comprehension of the technology’s workings. Educating the public fosters greater attention and potential for advancements, particularly in assisting disabled individuals. Through responsible conduct, safety measures, and public awareness of the technology’s impact, we aim to enhance societal understanding and contribute to the field’s evolution.


About The Author

Ibrar Ayyub

I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.

Follow Us:
LinkedinTwitter

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top