Posted on

Team Status Report for 4/8/2023

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?  

Since the PCB arrived this week and works as intended, the next significant risk would be not getting the proper data sent between the Node JS server and the WIFI Rev. This step is integral towards having a completely wireless experience when using our solution. As of now, the Node JS code is able to send data to the WIFI Rev, it’s just not the game data we want. We do want to move forward in order to get to the testing and validation stage of our project, so if we can’t get it to work by the end of the week, we will revert back to having a wired arduino to the laptop. The arduino is able to respond to Node JS data when it is connected to a specific port, as Bethel demonstrated in earlier status reports so we should have no problem if we switch to this.

 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?  

Since we had an interim demo this week, we ordered ribbon cables and the remaining PCB parts. The PCBs were a component we added on later within our design process. Our current design of our motor systems benefit from having an efficient distribution of power to our motors, which makes for both a bettered immersive experience and more distinguishable motor propagations for the user

 

Additionally, we decided to laser cut our “pocket” squares in order to achieve a more uniform look and stay consistent with sizing. This saved us a considerable amount of time as well, since we no longer have to sit and manually cut 10+ squares. We used fabric that was free and available to us through IDEATE. 

 

Provide an updated schedule if changes have occurred. 

We don’t have an updated schedule, but plan to start validation testing by 4/14. Given that the rest of the PCBs will not arrive by then, validation will take us up till the final demo.

Posted on

Sophia’s Status Report for 4/8/2021

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).  

I was able to start assembling the PCBs and start testing them. The PCBs and parts arrived Wednesday, which wasn’t in time to use them for the interim demo, but I was able to start testing them afterwards. On Wednesday, I put together one motor system and verified that it worked as intended. With the PCB assembled, Amelia was then able to size and laser cut the final motor system holders out of the final rubber material. After putting together the rest of the 5 PCBs I had on hand, I mounted one PCB to the motor system. Along with the laser cut fabric pockets, we now have our final vest assembly components. 

To move forward with the final vest assembly, I am also in charge of reversing the zipper on the best as we turned the vest inside out for our project. I was able to test removing and sewing the vest on the demo vest.

Figure 1: Soldered PCBs

Figure 2: The final motor system assembly

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?  

I would like to be further ahead on testing in order to receive more user feedback, but I am currently on schedule to finish my project. 

What deliverables do you hope to complete in the next week?

I hope that the rest of the PCBs will come in late next week. For early in the week, I will work on vest assembly and hope to reverse the zipper on the final vest, install the fabric pockets for the motor systems, and begin the final wiring if the rainbow ribbon cable comes in time. 

Now that you are entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have you run or are planning to run.  In particular, how will you analyze the anticipated measured results to verify your contribution to the project meets the engineering design requirements or the use case requirements?

For validation, I plan to check the technical side of the motors as well as collect some user data for the sensations of the motors. For the technical checks, I need to determine how quickly different responses will take to run and how to make them differentiable. This ties into the use case requirements of allowing for 10+ responses per minute and providing unique feedback patterns. Currently, I need to do a bit more work before I collect user input. I will position the motor system pockets and then ask for user feedback on the motor sensations. With only five PCBs currently, I will most likely have to rotate the motors test test the sensations for different parts of the torso.

Posted on

Bethel’s Status Report for 4/1/2023

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).  

This week I actually concentrated on helping Amelia attach the motors to their prototype mounting plate when it came to constructing our motor systems as well as aiding Sophia in wiring up our six demo subsystems to the Haptic suit. 

My planned deliverable for this week involved me testing the Node JS server on the Arduino WIFI Rev while it is wireless. I am still in the process of accomplishing this with Amelia’s assistance as our Arduino code integration is proving to take a little longer than we had initially anticipated.

 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?  

My progress is a little behind from what I had anticipated I would have done by this week, as integration is taking longer than expected. I still have to integrate my software components with the hardware components that my teammates have built in order to have a working prototype either by the time we have our interim demo or sometime after. I will also still be focusing on how to use Puppeteer to acquire data from all the remaining game actions for this upcoming week. 

 

What deliverables do you hope to complete in the next week?

This week I plan to incorporate a web scraper library known as Puppeteer in my existing software to aid in tracking the game actions of the remaining three events, namely small hit, large hit and low health. Puppeteer will help me analyze different enemy actions in order to accurately transfer data relevant to the game action taking place. For instance, we would not want a low health event to be flagged every time the life bar decreases, instead we would like this event to be activated when the bar decreases to 25% of its original length. 

Moreover, I plan to continue testing my software on the Arduino WIFI Rev after establishing a wireless connection.

 

Posted on

Amelia’s Status Report 4/1

Updates for the week

This week, I focused on perfecting the forceful jump and low health light algorithm, the code for this can be found on our Github. A video of it can be seen here.

I also worked on ensuring that the lights had their own power supply since each LED draws a significant amount of current (20mA), and there was a common ground between them. My schematic for this can be seen here. I used a 6V power supply and used multimeter to measure the output voltage after this connection, which was ~5.12V. The rating for the lights is max 5V so  for the final, I will use buck converter in order to get exactly 5V from 9V.

I also tested that the lights are able to be controlled wirelessly, which can be seen here.

I then laser cut 5 sets motor mounting plates out of cardboard since it is easy to prototype and we do not have the PCBs yet in order to use the rubber material I demonstrated last week. These plates will be only be used for prototyping and for the demo on Wednesday.

Lastly, I worked with my team to mount + wire all the motors to their mounting plate in order to fit them onto the vest properly.

Progress On Schedule

So far I’m on schedule, it became clear that there needs to be a lot of wiring management and tiny fixes for our final design. For instance, we only noticed today while integrating the motors to the mounting plate that I need to fix the CAD model for the motor mount slightly, they should be rotated 90 degrees so that the wires don’t break off as easily. I also need to continue working on integrating the wireless code with Bethel.

Deliverables for next week

  • I need to laser cut a box out of 3mm acrylic to hold the two battery supply systems
  • laser cut another box for the Arduino itself so that the wires connected to the Arduino pins don’t come lose and detach.
  • Continue working on getting the JSON data from bethel and parsing it so that the vest works wirelessly with the game data.

 

 

Posted on

Team Status Report for 4/1/2023

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?  

Keeping an organized wiring system is one of the most significant risks going forward. For our demo, we have 22 gauge wires from the Arduino to each motor. This takes up a lot of space and for the 6 motor systems we have, the cable management is getting pretty messy. We currently have 5 colored wires for the 6 systems, but when we reach 18 motor systems we’re going to need a better system. For the demo, we’ve made a wiring diagram to reference that can be found here. Moving forward, to manage these risks for the final, we plan on using ribbon cables and crimp pin connections. With ribbon cables, we can have one bus of cables which are flat and organized. When the cable reaches a motor system, it will branch out to connect to the system. 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?  

The orientation of the motors within their casing needs to be turned 90 degrees to the left (clockwise) in order to minimize the risk of breakage.

For the interim demo, we are changing how we implement the motor holders, power system for the lights, and motor system driving device. For the motor holdings, we are using cardboard instead of the rubber we plan to use for the final. This is to save money in our prototype system. We are using a 6V battery supply made up of 4 AA batteries instead of the 9V battery with a buck converter we plan to use in the final. This is because we are currently waiting for the buck converter to come in. Lastly, we are using the Arduino to power the motor systems instead of the servo driver device. This is for several reasons. The servo driver device does not provide enough power to drive the motor systems until we receive our PCB boards. We want to deliver a product that can provide the sensations we want for the final project so we are instead wiring the motor systems directly to the Arduino board. The board is limited to 6 PWM outputs so this solution will not work for the final. 

Provide an updated schedule if changes have occurred. 

Individual tasks of each member will be updated to be taking place simultaneously with our integration of the software and hardware components. 

With regards to the software side of things, we are still looking to track the low health, small hit and large hit game events. Moreover, we look to incorporate our PCB to our original design the moment it arrives. 

This is also the place to put some photos of your progress or to brag about a component you got working.

 

Cascading lights

 

Progress with wiring up our motor systems

Posted on

Sophia’s Status Report for 4/1/2023

Accomplishments

I started turning my motor system functions into a library we could easily import and use. I also worked on vest assembly. I sewed some demo pockets which will hold the vibration motor systems. This required to to relearn how to sew after maybe 5 years on not using a sewing machine. I also helped Bethel with wiring up our six demo subsystems, as well as editing my current Arduino code to use the Arduino instead of the servo driver.
Figure 1: cut-out pockets for the vest
Figure 2: sewed pockets
Figure 3: mess of wires for the six motor subsystem

Schedule Update

I believe we are on schedule. We just have to you do user testing as well as making ours subsystems more robust.

Deliverables

I plan to help integrate the final parts of our project for the interim demo. I also plan to wire up the PCPs, which should come in early to mid next week.
Posted on

Bethel’s Status Report for 3/25/2023

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).  

My team and I attended Wednesday’s Ethics Lecture and meticulously made notes on the ethical considerations brought up by our peers within our Pods discussion. We do plan to incorporate the feedback we received to our existing design as expressed within our Team Status Report. 

This week has been particularly productive, in that I was able to complete both of my planned deliverables while also using the STEAM platform to configure the wireless controller to game play settings with the generous help of both of my teammates as shown in the video clip titled “Controller_to_Game_Integration.MOV” within our Google Drive. One of my two deliverables for this week involved me having to integrate the Node JS server with the forceful jump event’s game data. This helps confirm whether the Node JS server can relay our game data successfully to our simple motor circuit. This was successfully achieved as result of the effective testing of the Node JS server I conducted last week which allowed me to easily pinpoint the bugs within my integrated code and fix them.   

My second deliverable for this week consisted of testing the Node JS server on the Arduino WIFI Rev while it is still connected to my PC, before proceeding on to establishing a wireless connection. This was efficaciously achieved on Friday, 24th March with the assistance of my teammate Amelia. 

I also changed the game action keys on the frontend of the game to match that of our controller configurations as an added customization to The Last Spartan. We utilized the mappings expressed within our design report whereby the W-A-S-D keys correspond to the left-most joystick; the “k” key corresponds to the left trigger/ left bumper; “j” key right trigger/ right bumper; “p” key corresponds to the “Options” buttons; “SPACE” key corresponds to button “A” and the “ENTER” key corresponds to button “B”.

I eventually played the game wirelessly to test all the integrated components together while also measuring latency of our system by taking a video of the motor activations that occur in response to forceful jump events. According to the video I believe that my software system has minimal latency as shown in the video clip titled “Game_Data_to_Server_Integration.MOV” within our Google Drive. 

 

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?  

My progress is somewhat back on track since I have managed to successfully integrate the Node JS server and the JavaScript listeners that track the forceful jump game action. I still have to integrate my software components with the hardware components that my teammates have built in order to have a working prototype by the time we have our interim demo. I will still be focusing on how to use Puppeteer to acquire data from all the remaining game actions for this upcoming week. 

 

What deliverables do you hope to complete in the next week?

This week I plan to incorporate a web scraper library known as Puppeteer in my existing software to aid in tracking the game actions of the remaining three events, namely small hit, large hit and low health. Puppeteer will help me analyze different enemy actions in order to accurately transfer data relevant to the game action taking place. For instance, we would not want a low health event to be flagged every time the life bar decreases, instead we would like this event to be activated when the bar decreases to 25% of its original length. 

Moreover, I plan to test my software on the Arduino WIFI Rev after establishing a wireless connection.

 

Posted on

Amelia’s Status Report 3/25

Updates for the week

This week, I worked on getting the RGB lights (Adafruit DotStrips) to turn on in a specific pattern, placing them inside the vest, laser cutting the motor mounting plate, integrating the wifi REV with Bethel, and integrating the light system wiring to the vest with my entire team.

To turn on the lights, I used the Adafruit_DotStar library on the Arduino IDE and connected the datapin to 4, clockpin to 5, power to Vin, and ground to GND on the Arduino. Next, I set the all the LEDs’ red channel to high.  From there I did a simple flashing motion to simulate a “low health” event.  The low health light show only turns on when a user is below 25% health. As the user’s health decreases from this threshold, the faster it will flash red until the user dies, upon which the LEDs will stay red. For the forceful light response, we will have a cascading wave moving up then down to showcase this event occurred. I isolated the light indexes into rows/cols and which can be shown in the figure below (60 LEDs, 30 on the left and 30 on the right).

Figure 1: Light system on, separated by rows

Next, I worked on de-threading the bottom of the vest so that I could put the LEDs inside the lining of the vest and see how they shine. A video of this can be seen here. Since the lights need to be accessible to me (so that I could move them in/out of the vest as need), this meant that I also need a way to open and close the part of the vest I just de-threaded. For this, I placed Velcro strips on the inside lining that I could just pull/push together in order to open/close. I found this made the design still look seamless, and I could apply this solution to securing the light/motor systems to the vest, rendering my “pocket” solution I brainstormed in earlier weeks obsolete.

I also began experimenting with a different material for the motor mounting plate. I landed on rubber since it is cheap and flexible. I worked on laser cutting the .dxf file I made last week on this material, and the output of that can be seen in Figure X and X+1. I added additional space to the right of the motor holes so that we can place the PCB once it’s ready.

Figure 2: Motor mounting plate

Eventually, the motors will have a spring attached to the back that will make sure there is contact with the motors and the torso of the user, regardless of their size. A rough idea of it is shown in the figure below.

Figure 3: Coin motor with a spring attached

Lastly, I worked with Bethel this week to ensure her part of the project was working with the Arduino Wifi Rev. We worked together so that she didn’t have to repeat any code that’s already written and so that we are able to see if the Arduino is able to receive a simple JSON message (“1” or “0”) she is sending. We were able to see the message, but need to work on sending more information-rich messages that explain an event like forceful jump, low health, getting hit by a small enemy, etc. etc. that are relevant for motor and light responses. After talking it through, we decided the simplest message that the JSON could send are 2, 1-hot vectors since her event precedence algorithm will mean that only one event is registered at a time .This moves away, but has the same essence of the message I worked on parsing last week.

Progress On Schedule

I’m still on schedule, especially now that I’ve gotten the light system up and working. I have also been integrating more with my team, which is a good sign as interim demo is coming up in the next two weeks.

Deliverables for next week

Next week, I plan on finalizing the forceful jump and low health light show timings with Sophia’s motor responses for the same events. The idea is that they last about the same amount of time with their respective motor event.

I will also continue working with Bethel to ensure the Wifi Rev is responding to her message wirelessly and with minimal latency that is within our design requirements.

I will also laser cut a set of motor mounts using cardboard to have ready for the interim demo. If the PCB arrives before Thursday, I will laser cut the mounts using the rubber material.

Posted on

Sophia’s Status Report for 3/25/2023

Accomplishments this week

I finished the PCB and submitted the order for printing as well as the order for the necessary parts. I went through many iterations of the PCB with lots of help from Professor Fedder and Omkar. I was able to learn how to choose different parts for the PCB and check on Digikey for those parts in the specified packaging and requirements. I worked with Amelia to design the PCB to fit into the laser cut patterns she is making to hold each motor system. The length of the board takes up the length of the two motors while allowing a minimal width of the PCB.  Finally, I submitted the PCB fabrication design on JLCPCB and the parts list on Digikey. I also met with Amelia and Bethel Friday and Saturday to discuss and begin implementing our individual contributions. 

Schedule Update

I am on schedule. The PCB hadn’t fully incorporated itself into the schedule so I did free some time up by delaying when I will upgrade my motor control algorithm. The current mindset for last week and next week has been on creating everything semi-functional for the interim demo. The current motor control is a bit clunky code-wise but the outcome is sufficient to show a working demo. I was able to work on control more today and plan to continue to refine it in between the critical tasks would keep the project from moving

Deliverables for next week

I hope the PCB board and parts will come in early next week so that I have time to solder and test them. This way we are able to produce strong vibration feedback for the interim demo. If the PCB comes in later in the week I will have time to work on my code and integration with Bethel and Amelia to prepare for the demo. 

 

Figure 1: The PCB wiring diagram

Figure 2: The PCB part layout

Figure 3: The PCB 3D rendering

Figure 4: PCB fabrication design

Posted on

Team Status Report for 3/25/2023

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?  

We were very careful and sought a lot of feedback from our TA and professor when designing our PCB for the motor systems. However, there could still be an unforeseen problem when we start to test them next week. Without the PCB, our vibrational feedback will not be as effective and may jeopardize the sensations we want our users to feel. 

We also noticed that the RGB lights draw a significant amount of current, so much so that the 6V battery supply to the microcontroller was not enough to keep all the lights running at a high brightness setting. If we add a second power supply, the lights are able to run at a high brightness and there is some heat emission. The heat emission is not noticeable or uncomfortable when you put on the vest, only if you place your hand directly over the lights. We don’t anticipate the heat of the lights being a risk factor, but we did want to acknowledge it. 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?  

This week, we had our ethics discussion. The other groups brought up several points we did not originally consider in our design. One of the biggest concerns brought forward was the idea that someone could remotely control the vest using the wireless controller. When we decided to move to a fully remote system, we had not considered how incorporating a remote controller might be dangerous to the person inside the vest. To avoid this, we plan on implementing an emergency stop switch into the vest which can turn everything off immediately. This will allow people who feel uncomfortable to stop the vest. This emergency stop will be a physical system between the power and the devices that are running, preventing any delays sending a signal to the Arduino may cause. 

Other concerns included how hot the vest would get and how accessible our product would be for people who have limited arm mobility. For the heat, we were able to test it out, as stated in our risk factors. We interpreted the latter as a concern of putting on the physical vest. To make putting on the vest a smoother experience, we decided to put optional Velcro strips that run horizontally across the middle of the vest (under the zipper) so that a user is able to secure these strips instead of the zipper, which may be hard to use.  

A design change we made this week was the inclusion of Velcro strips to the inside lining of the vest in order to vertically secure the light and motors systems. The user will not see these strips, but it does allow us as the designers to easily access the motors/lights, provides minimal movement, and a seamless outside look that avoids any additional sewing. 

Provide an updated schedule if changes have occurred. 

We are on schedule. Next week, we will focus on integration and cleaning up our individual contributions. 

What we got working. Video of putting on the vest can be found here. 

Figure 1: Vest light integration
Figure 2: Vest on mannequin
Figure 3: Clean wiring through suit