Group 10
SimU-AR: Automated User Interface Testing for Augmented Reality Head-Mounted Displays
Background
Client: SentiAR
SentiAR is a medical device company specializing in integrating augmented reality (AR) and extended reality (XR) technology with cardiac mapping systems. Their innovative solutions enhance visualization during medical procedures, improving procedural accuracy and efficiency. In addition to supporting clinical practice, SentiAR also provides precise and effective learning and training solutions for healthcare professionals, advancing their approach to cardiac care.
SentiAR’s mission is to transform the experience for both patients and clinicians in interventional procedures.
Population of simU-AR
The main target population of our product is SentiAR. Sentiar’s quality and software development team has a high interest in this product because they are looking for a way to streamline the UI testing of their devices. Physicians would have a moderate level of interest in making sure that the UI of the device is workable as they are the target audience of CommandEP, the headset product. Our product will also be targeting AR headset competitors, who would be interested in faster ways to test the UIs of their devices.
Need Statement
There is a need by quality engineering teams for a user interface (UI) testing system of Augmented Reality head-mounted displays (HMDs) that reduces human interaction by eliminating the need to wear the headset, which will allow for automation of the testing process and thus faster identification of UI problems through repeatability of test conditions, improving efficiency.
Project Scope
There is a need for an automated UI testing system of Augmented Reality headsets by quality engineers and developers to improve the efficiency of the device and quality testing. The ability to test the headset’s UI without wearing it will allow for iterative testing to ensure the precision and accuracy of the device’s UI. The system will be capable of gripping the headset securely and performing 360º rotational movement in the yaw axis and 200º in the pitch and roll axes with motion speed not exceeding 780º per second to mimic human head movement. It will also be capable of carrying a minimum load of 300 g to compensate for an average weight of HMDs and repeating the automated testing movement at least 100 times continuously without requiring recalibration. The project will be considered complete once the device is able to reliably hit the confirm button on the home screen to enter the headset. A mechanical prototype of the system along with software and circuitry along with a user-instruction manual and short tutorial will be delivered to our client by April 7th, 2025.
Team
Anna Asako
Hardware Development, Design Lead, and Record Manager
BS in Biomedical Engineering
a.asako@wustl.edu
Jane Liang
Software Development Lead and Primary Client Communicator
BS in Biomedical Engineering
j.k.liang@wustl.edu
Jenny Yoo
Mechanical Development, Website Lead, and Schedule Manager
BS in Biomedical Engineering
jaehee.y@wustl.edu
Preliminary Design Specifications
| Metric | Value |
|---|---|
| Maximum System (Fixture) Weight The device should be mobile. | 10 kg |
| Physical Dimensions The device should be not too bulky but should be able to hold the HMD weight. | 25 x 25 x 30 cm3 |
| Minimum Load Capacity The device should be able to bear at least 300 g of weight | 300 g |
| Rotational Motion Range (of Fixture) Yaw, Pitch, and Roll | Yaw: 360º ± 1º Pitch and Roll: 200º ± 1º |
| Translational Motion Range (of Fixture) Cartesian (x, y, and z) | 20 cm ± 0.1 cm |
| Minimum Motion Increment (of Fixture): The smallest amount that the fixture is able to move | Rotational: 2º ± 1º Translational: 1 cm ± 0.1 cm |
| Maximum Rotational Speed (of Fixture): Based on the median peak velocity observed during vigorous voluntary head rotations in human subjects1) | 780º/second |
| Minimum Iterable Instances: Scripted behaviors should be repeatable | 100 instances |
| Compatible Computer Interface: Arduino and C/C++ are easily accessible and developer-oriented. | Arduino, C/C++ |
| Device Power (via wire): Based on standard 20A, 120V circuit capacity | ≤ 2400 W (Wall Power) |
| Positional Accuracy After Each Instance: The system should return to the initial position to ensure consistency across repeated tests | Rotational: ±1º Translational: 0.1 cm |
| Total Cost: Low budget, 3D printing, Arduino provided | Should not exceed $600 |
Schedule
Below is the schedule for our group throughout the semesters (fall and spring), with the tasks divided equally among the team members.
| Task | Start Date | End Date |
|---|---|---|
| Problem Discussion | 8/25/24 | 8/29/24 |
| Design Notebooks | 8/26/24 | 4/24/25 |
| Design Specifications | 8/28/24 | 9/11/24 |
| Identify Project | 8/30/24 | 9/1/24 |
| Scope | 9/2/24 | 9/11/24 |
| Team Contract Website | 9/3/24 | 9/4/24 |
| Website | 9/13/24 | 4/28/25 |
| Find Existing Solutions | 9/16/24 | 9/25/24 |
| Preliminary Paper | 9/16/24 | 9/27/24 |
| Presentation 1 (Preliminary) | 9/22/24 | 9/29/24 |
| Progress Report | 9/25/24 | 11/26/24 |
| Initial Hardware Design Delivery to Client | 10/1/24 | 10/22/24 |
| Initial Hardware CAD Model Delivery to Client | 10/1/24 | 10/29/24 |
| Hardware Prototype Completed | 10/1/24 | 11/29/24 |
| Initial Budget | 10/7/24 | 12/11/24 |
| Hardware Materials Purchased | 10/30/24 | 11/5/24 |
| Presentation 2 (Progress) | 11/22/24 | 12/1/24 |
| V&V Paper | 12/10/24 | 2/28/25 |
| Budget Finalization | 12/11/24 | 11/26/24 |
| Yellow Stickies | 1/12/25 | 1/13/25 |
| Presentation 3 (V&V) | 2/26/25 | 3/3/25 |
| Risk Analysis | 3/24/25 | 4/17/25 |
| Presentation 4 (BME Day Poster) | 4/15/25 | 4/28/25 |
