Team Status Report 2/18

Current Project Risks

Currently, the most significant risks that could jeopardize the success of the project revolves around our individual tasks. While we may find challenges within our individual tasks, those will be covered by our personal status reports. The main risks are: Sophia figuring out how to drive 2-wire vibration motors with the 3-wire PWM pins, Bethel tracking the actions and coordinates of the enemies within The Last Spartan game, and Amelia with pinpointing where to package the vibration motors in the vest that corresponds with existing spatial acuity data. To manage these risks, each member will focus on fitting their part. Sophia will stagger between testing the motors and determining if a PCB board could be configured to convert the necessary power. Amelia will continue reading existing research on vibrotactile stimuli on the torso as well as making sure the Arduino Wifi Uno is able to receive information seamlessly without noise interruption. Bethel will identify the event handlers dedicated towards different types of enemies within the game.  

We also foresee integration as a possible risk. To mitigate this, we plan to do basic integration tests next week. These tests will include sending data from NodeJS server to Arduino and packaging a single coin motor in the vest to ensure it does not move beyond our constraint of 1” radially once on.

Changes to Existing Design

We’ve been thinking about how we could make the experience of a haptic suit more seamless, namely with a keyboard-free experience. Our first idea was to build a joystick input device with an accelerometer that a user could use to swing vertically up and down in order to “attack” enemies in the game. After surveying various gamers and doing our due-diligence with our own research, we found that this type of input is called a “waggle controller”. The waggle controller was popularized by Ninetendo in the early 2000s, being a common feature in games such as Wii Sports, Super Mario Galaxy, Donkey Kong Country Returns, The Legend of Zelda: Twilight Princess, and Rayman: Raving Rabbids. It’s highly unpopular amongst gamers because of the general “lack of skill” it requires out of the user, only random movements to get it to work. Instead, we will be using a wireless xbox controller that a user can use to control their in-game actions. This is the most popular and well-known type of controller because of its ease of use and affordability, running around $50 for a wireless option. We will be mapping the keys on the controller to the keys on the keyboard using the platform “Steam”. We will also be changing the in-game instruction graphics to reflect the controller being the input device instead of the keyboard. 

We also spent a lot of time thinking about our design implementation block diagram. This helped us understand the interdependencies of our tasks. This will allow us to move forward with our parallel tasks knowing what has to be done to integrate the system.

As we’ve proven, moving forward, the best way to vet our design and implementation changes is to survey our users. Ask them what they want in order to improve their experience. Being that we are not gamers ourselves, we aren’t reflective of a typical user and thus can’t speak to what they would like. We can only implement changes and bring the system to life. 

Principles of Engineering Utilized in Project

We utilized multiple principles of engineering, science and mathematics to develop our design solution including I2C protocol, server design, researching spatial acuity in the body, event handling in JavaScript and Circuit design using an Arduino.  

We are employing the engineering design process in every aspect of our project. We have focused on ensuring our project is very modular with lots of parallel tasks which can be completed by our group simultaneously. We are currently working on the research and prototyping phases of the engineering design process.

 

Amelia’s Status Report 2/11

Updates for the week: 

This week, I worked on researching the best motors to provide a haptic feedback. I landed on two types of motors: pager motors and mini vibration motors. Each of the motors comes with drawbacks and advantages, with the advantage of the mini vibration motor being it’s small and has compact shape that will minimize the weight of the vest. The pager motor will be more difficult to mount to the vest because of its boxy shape, so I believe we are going to go with the mini vibration motors.

I also spent some time prototyping the design of how the motors will function inside the vest. Since the mini-vibration motors are smaller than the size of a quarter (10mm diameter), my initial thought is to arrange 4 motors into a “flower” that will function as a single feedback point. To mount this, I will laser cut a chip made out of acrylic that can support the 4 motors in a pattern (as shown in Figure 1). In order to actually get the chip into the vest, I thought of a method to get a thin, expandable material (i.e. spandex) which we could sew into the inside lining of the vest itself. We would create a “pocket” of sorts with this material in which we could take the motor chip in and out of + connect to common ground/power + connect to the STM which would rest in the back of the vest.

figure 1

Lastly, I did some research into the best RGB lights for the haptic suit, and landed on the neopixel ring light. This was best suited for our project since it will outline where there is haptic feedback point is on the vest, and is easily adaptable to an Arduino (there is a corresponding neopixel library that we can download).

Progress on Schedule:

We’re still on schedule, but need to work diligently this next week since we spent a lot of time researching. I think the biggest roadblock right now might be getting the parts in order to test them. I have a mini vibration motor in my own personal Arduino kit, so I can test and approximate if 1 motor per haptic point is enough, or we really do need 4. Once we get more motors, this will be easier to determine.

Deliverables for next week:

Over the next week, I hope to test the motor pattern and determine if it simulates a feedback that corresponds to the game and doesn’t deter from the experience. I will also determine if its too many/not enough motors or if the motor needs to be changed for a specific point (i.e. maybe the motor over the heart needs to be stronger than the rest to simulate a thumping sensation). If the motor chip design works well, I will then work on creating a “motor chip flower” class in the Arduino IDE in order to modularize the system since we will be working with a lot of motors, and they all need to be synchronized. When an instance of this motor class is called, it will activate the motor flower chip as one, so that it seems like you are controlling only one motor while hiding the fact that it is actually 4.