Posted on

Bethel’s Status Report for 4/29/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).  

Since pivoting from Puppeteer, I have been able to dynamically track the remaining three in-game actions of low health, getting hit by a small enemy and getting hit by a large enemy synchronously with the forceful jump action. Moreover, I had also managed to create the frontend for the motor intensity bar. 

This week I have successfully developed the backend of the motor intensity bar, which allows the user to dynamically send their motor intensity preferences to the motor and light code for the haptic suit via our Node JS server.  

 

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 on track given the fact that I have managed to finish building the backend for the motor intensity bar before the start of demo week. Furthermore, I am going to push to complete my team’s project poster, video and final paper within finals week.

 

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

This week I plan to help my team create our project video and poster prior to our TechSpark Demo, while attempting to establish a wireless connection with the Arduino WIFI Rev. 

Posted on

Bethel’s Status Report for 4/22/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).  

These past two weeks have been particularly productive as I finished dynamically tracking the remaining three in-game actions of low health, getting hit by a small enemy and getting hit by a large enemy. This task took a longer time to accomplish than first forecast because of my determination to incorporate the Puppeteer library, which would operate as a Web Scraper within our code base.

However, we pivoted from using the Puppeteer library to track the remaining three in-game actions of low health, getting hit by a small enemy and getting hit by a large enemy, because this library does not allow us to customize the game as per our user and design requirements. An instance of this was our lack of ability to incorporate the motor intensity bar into the user interface, which was requested through our Ethics feedback session. 

Moreover, Puppeteer hindered us from synchronizing our jump event along with our low health, getting hit by a small enemy and getting hit by a large enemy event, because the former ended up listening to the game actions in a different browser than that of the latter.   

Another deliverable I have managed to accomplish is having the frontend for the motor intensity bar working. Now what remains is to have the motor intensity bar dynamically send its values to the motor and light code via our Node JS server.  

 

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 as I thought I would have the backend of the motor intensity bar finished by now. I am going to push to have it finished by this week.

 

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

This week I plan to help my team create our project video and poster prior to our TechSpark Demo, while building the backend for our motor intensity bar. 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/29

Updates for the week

This week, I switched over to using a new library for the light algorithm. The previous Adafruit library was not capable of running the code I needed at the right speed, and included delays which disrupted several other functions. I switched over to the “FastLED” library, which allows me to use non-blocking delay code, which is a step towards parallelization with the motors and lights. A video of me running different patterns can be seen here.

I also rehearsed for our final presentation on Monday and am continuing to work with our team to test the threading code, solder 3 more PCBs for the back motor integrations, and wrap up our poster in time for the Techspark demo.

Progress On Schedule

We’re behind on schedule. We said we’d finalize everything by the end of this week, but this got pushed back so I will simultaneously continue working on my parts while not neglecting my final exams.

Deliverables for next week

Finalize the parallelization code so that the motors and lights go off at the same time, finalize the light pattern for hit small and hit large, and soldering + test the remaining 3 PCBs.

Posted on

Team Status Report for 4/29/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?  

This week we have successfully managed to incorporate the rest of our motors into the back of the vest. On the contrary, we still need to make both the integration of our hardware and software components more reliable. This involves us having to parallelize our motor and light code which we plan to accomplish this weekend. Moreover, we aspire to establish wireless interfacing between The Last Spartan game and the vest (post MVP).

Another risk we are preparing a contingency plan for are wiring issues. We tried to mitigate this risk by using ribbon cable to improve clarity of cabling, making debugging far easier.

While improving upon our hardware and software integration we will simultaneously be working on our poster and project video this week. The risk here lies in our time management. We plan to delegate different tasks amongst ourselves to help maximize our productivity and minimize any risk associated with running out of time. 

 

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 block diagram was changed last week to include the PCBs. Some minor motor system numbers were changed to fit with the actual wiring of the vest. 

We also pivoted from using the Puppeteer library to track the remaining three in-game actions of low health, getting hit by a small enemy and getting hit by a large enemy within the past week. The problem with this library lies in the fact that it didn’t allow us to customize the game as per our user and design requirements. It has since been eliminated from our existing design of our system.

 

List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

Hardware

  • Recheck that each motor system works individually
  • Motor responses are correct
  • Verify that moving vest doesn’t disturb motor systems
  • Verify that the light systems have correct response
  • Check that implemented code for last two motor systems goes off with other motor code

Software

  • Test that the Node JS server prints out the data we want it to relay
  • Verify that the Node JS server can relay data from a generic website
  • Check whether the Node JS server can send correct data to control a single motor circuit 
  • Validate that the Node JS server can send the information generated by one in-game action, namely forceful jump
  • Validate that the Node JS server can send the information generated by all the in-game actions, namely forceful jump,  low health, getting hit by a small enemy and getting hit by a large enemy
  • Test that the latency of our system lies under 100 ms
  • Verify that our precedence algorithm correctly dictates the outputs we want to see in the chronology of the importance of events

Implementation

  • Verify that motors systems and lights go off at the same time
  • Try the software 10x times to determine reliability
  • Try the software on 2+ laptops to determine reliability
  • Have 10 people play the game to gain more user data, feedback, and check the vest is operating correctly

 

Provide an updated schedule if changes have occurred. 

We have attached our updated schedule in this link. We are working to parallelize our motors and lights as well as achieve wireless interfacing between the game and vest (post MVP).

 

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

Link to image of the PCBs at the back of the suit

Posted on

Amelia’s Status Report 4/22

Updates for the week

I got the serial monitor to read the incoming bytes from the nodeJS and parse the data into a struct so that all functions can access this data. The relevant data is: action type, health level, and desired motor intensity. I worked on this integration with Bethel and tested playing the game to see if each relevant action would correspond to a unique light response, and it did which meant we could test the delay.

Afterwards, I integrated this code w with the light and motor control code and began testing it outside the vest. It worked then, but unfortunately, after we placed it inside the vest it didn’t work. There were some code changes when w placed it inside the vest so it could either be a wiring or software issue.

Aside from these primary tasks, I’ve also been laser cutting more boxes so that the wire systems do not come loose from the i2c or buck converter, helping strip/crimp the motors, and doing general integration with my team.

Progress On Schedule

The primary risk as of now involves the light and the motor timings, I realized that they are not occurring at the same time so I need to incorporate threads into the code so that it appears as though they are occurring at the same time. Of course, the user won’t see the lights, but this is to ensure that there is synchronization and the timings isn’t skewing off other queued up actions.

 Unfortunately, Bethel and I couldn’t get wireless communication between the nodeJS and the wifiRev, so for the sake of time and completing integration, we decided to hold off on this until after MVP. We understand this means we will not pass one of our design requirements, but felt it was more important to have a finished product rather than a half complete system.

With this, I’m slightly off schedule as integration meant we discovered new problems that need to be addressed urgently. I hope to get back on schedule before finals week.

Deliverables for next week

As Gary noted, the vest light should incorporate some animations, so I’m working on animations for the getting hit action while also integrating with the team. I’m hoping this animation will be in the form of a random pixel turning on and the k pixels near it blurring until they turn off.

Moreover, the delay between each game action is extremely small, so I need to update the timing of the lights so that the corresponding light action has ample time to display, and isn’t just gone in a flash. This requires some tuning and playing around with the numbers till we get a delay that isn’t too small or too large. As mentioned above, I will also be incorporating threads into the integration code.

Finally, I will work with my team to finish the final powerpoint, and poster for the upcoming week’s deadlines.

Posted on

Team Status Report for 4/22/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 need to make the integration more reliable. 

One of the risks we could encounter is a problem we didn’t foresee. We hope to mitigate this by doing more user testing so other people can help uncover unknown problems. We completed about 1 hour of user testing today. As a contingency plan for if any hardware breaks, we have about ½ of our hardware resources as backups in case something breaks or something goes wrong. 

Another risk we are preparing a contingency plan for are wiring issues. We tried to mitigate this risk by using ribbon cable to improve clarity of cabling, making debugging far easier. 

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?  

We finally changed the block diagram to include the PCBs. Some minor motor system numbers were changed to fit with the actual wiring of the vest. 

We pivoted from using the Puppeteer library to track the remaining three in-game actions of low health, getting hit by a small enemy and getting hit by a large enemy. The problem with this library lies in the fact that it didn’t allow us to customize the game as per our user and design requirements. An instance of this was our lack of ability to incorporate the motor intensity bar into the user interface as was expressed through our Ethics feedback session.  

Provide an updated schedule if changes have occurred. 

Schedule

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

 

 

Posted on

Sophia’s Status Report for 4/22/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).  

I’ve done a lot. I’ve completed most of the physical design of the suit in the past two weeks. This included a lot of sewing of the motor system velcro pieces into the front part of the vest.  Frankly, this took way too long as the sewing machine didn’t always work. But it was something that had to be done and was a good filler while I waited for the rest of the PCBs to arrive. Once the PCBs arrived, I used solder paste and assembled 16 more sets to be used in the vest and as backups with some help from Amelia and Bethel. Then I went ahead and wired the 8 motor systems for the front of the vest and wired the lights into the vest. Then I fixed some motor functions to update them to some wiring changes I made. 

Throughout this process, I continually tested each step to ensure that an issue on one motor system didn’t propagate to the whole vest. When learning how to use solder paste, I finished one PCB and tested it to ensure I did it correctly. After soldering all the PCBs I tested each and removed the ones that didn’t work for debugging later. Finally, I tested the motor functions before putting any motors into the vest. These steps of validation helped me remove any uncertainties and harder debugging later in the process. 

Figure 1: All the PCBs soldered and sewed into their rubber mounting plates

Figure 2: Example of the inside of the vest

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

I think we can get our project done. I’m a bit behind schedule as I need to add the velcro for the motor system holders to the back of the vest. I didn’t do it before now because 1) I wanted to get at least the front of the vest working so we could test integration and 2) I have come to hate the time sink that swing is for this project.

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

I will help Amelia debug why the lights don’t work in the vest. I will sew all the motor systems into the back of the vest. I will update the motor algorithms to handle the new motors in the back.

Posted on

Bethel’s Status Report for 4/8/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 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.

The type of wireless data transfer we have managed to achieve at this stage involves us using sockets to establish a connection with an external website that allows us to parse the incoming information to the Arduino. One caveat of this solution is that it requires us to use two separate Arduinos in order to confirm that the correct game data is being sent wirelessly to the WIFI Rev. So far we have managed to send the unique socket identifier to the WIFI Rev, however the desired game data is not being sent yet.    

I have also managed to pinpoint the variable of interest for tracking all of our remaining game events of interest, namely low health, small hit and large hit. I am displaying this variable on the HTML page of our game in order to read in its values as it is dynamically changing, however I understand that my process of retrieval is only reading this value once, when the game first loads.

 

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 before Thursday of next week. 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 dynamically track our variable of interest being displayed on the HTML page of our game in order to read in its values as it is dynamically changing, as my current process seems to only be retrieving this value once, throughout game play. 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/8

Updates for the week

This week, I focused on laser cutting the motor mounts, arduino case, and pocket squares as well as working with Bethel to get communication between nodejs and the WIFI rev.

I laser cut the motor mounts out of the rubber sheet I demonstrated last week, only now they have holes aligned with the PCB holes so that we can fasten the mounting plate to the PCB. I also fixed the tolerance of the Arduino case lid, and used fabric to laser cut 20 pocket squares to the same dimension.

I spent the bulk of my time this week working with Bethel. At first we tried sending an HTTP post request to the WIFI rev, and after several tries we were able to see the correct request message. An image of the serial monitor can be seen here. We sent “ANYTHINGGG: KJNGDFGKJD”. The only problem with this was that it wasn’t synchronized to the game event actions. When we played the game on the website, it wasn’t transmitting any sort of data to the WIFI rev. From here, we switched tactics and opened a socket connection which was synchronized to the game, it sent data at a good frequency (which we will time later since at this point we are only concerned that we receive the correct data) but it doesn’t send the game data we want (i.e. ‘F’ for jump or ‘0’ otherwise). An image of the serial monitor output from this method can be seen here.

Progress On Schedule

So far I’m on schedule, but with about ~3 weeks left, I understand that if we can’t get the wireless communication to work, then we have to revert to the wired solution. This is so that we don’t fall behind on testing and validation.

Testing Plan

The deliverables I’ve been testing so far have been the wireless range and seeing if the Arduino IDE receives nodeJS response. To test the wireless range of both the Arduino and the controller, I just moved 6+ ft away from the laptop to see if I could still see a response/play the game. Both of these currently work.

The Arduino IDE is receiving a nodeJS response, just not the one we want so that test has been forthcoming. Once this works, I’m planning on printing the time between each of the responses in the Arduino IDE and computer running the nodeJS. I will take the difference to see how long it takes for the Arduino to receive a response once it’s sent and see if it meets our latency requirements from the game to the Arduino IDE. Afterwards, we will measure how long it takes the Arduino to send the response to the motor/light systems.

Deliverables for next week

  • Continue working with Bethel on getting the relevant game data to the wifi rev before the end of the week.
  • Crimp the motor systems so that they are able to be plugged into the PCBs
  • Synchronize the timing of my forceful jump light algorithm with sophia’s forceful jump motor algorithm.