Jada’s Status Report – 3/23/24

This week, I ended up spending more time on the door lock than anticipated last week. Due to the interim demo coming up on April 1st, I wanted to get the lock to a more functional state in relation to the rest of the system; meaning that I needed to figure out Bluetooth, power for the device, setting up the speaker, and figuring out a solution for storing the songs on the device. The majority of the week thus was spent researching how to get the Seeed microcontroller to work with the keypad. After hours of researching and testing different libraries and methods, I was still unable to make a successful switch to the Seeed and therefore pivoted to researching different Bluetooth and microSD storage modules to use with the Arduino Uno R3 that currently works with the keypad and solenoid lock. However, I did make a small victory, successfully integrating a simple speaker and a short tune into the main Arduino script, as seen in the picture at the end.

Two main issues have come up in researching these alternatives to the Seeed, one being having enough of the necessary pins on the Arduino to operate the various modules, and the other being power consumption. There appear to be multiple modules needing to use the same clock pin, which I am uncertain about dealing with. And the issue of power doesn’t seem like it can be solved with a couple of AA batteries in series, as even four AAs only get the Arduino to 6V, where it needs 7-12V. This is a minor issue for the interim demo compared to getting Bluetooth and song storage figured out, as these are more important to demonstrate that the product will be complete by the final demo.

I currently feel that my progress is behind, due to the uncertainty about which parts I need to order. The main issue is that the parts needed for the lock change depending on whether we stick with the Arduino or continue to try to get the Seeed to work. To catch up this upcoming week, I plan to solidify what microcontroller I will use for the lock and order the necessary modules, minus the battery power supply.

Next week, I hope to have ordered the necessary parts to finish the lock, minus the battery power supply. While waiting for the parts to arrive, I can update the CAD model for the door lock housing and begin to figure out how the electronics will be placed in their final position. I may also look into designing a PCB to replace the breadboard and cut down on the size of the door lock, as well as researching a servo motor to replace the solenoid, as I found that the solenoid doesn’t truly lock.

Team Status Report – 3/16/24

  • 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?

The most significant risk at the present moment is that the FSR packs that we ordered not working as we anticipate them working. They will be tested this upcoming week, but we only have two weeks before the interim demo. Because of this, we will be testing the FSRs at the beginning of this upcoming week to allow us enough time to make a quick Amazon purchase request for backup components.

The other main issue, as stated during last week’s report, is getting Bluetooth connectivity between the three components in our system. We have enough time to integrate this by the final demo, though it may still be in the works for the interim demo.

  • 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? Schedule changes?

There were no changes made to the existing design of the system, and there were no changes made to the project schedule.

Brooke’s Status Report – 3/16/24

This week was spent working on finalizing the design of the mat and building the prototype for demo week. We tested out using wood as the material for the mat with the design being complete and tested out how durable it was. I wanted to make sure it was easy to work with and also strong enough to experience excessive force when being used. To do this, we printed out mounts for the sensors and laser-cut plywood to act as the board. Attached is a photo of me standing on it. After using as much force on it as possible and jumping on it, I am confident enough to continue with this design and build the final board using similar principles.

Progress is somewhat on track. Now that the design is figured out and tested not to break, building the prototype on time and working out the software issues that will inevitably arise should not be too much of a problem. For the next week, the plan is to build out the design further to somewhat resemble the final dance pad and see if I can actually get the electronics to work properly and remain unharmed by the process.

Zoe’s Status Report – 3/16/24

This week, I worked mostly on the code for the mat and the door lock. I spent some time researching Bluetooth for our app, and ultimately decided it may be easier to run our app on an Android phone instead of an iPhone. Since I have an old Android phone at my apartment, I plan to charge it and download the development build of the app onto the phone, if possible (the phone is pretty old). I have not yet tested this, but I intend to do it by Monday. After this research, I moved my focus once again to the mat and door lock software. Jada has been testing the door lock electronics using starter code online, and I have been brainstorming how to rewrite that code for our exact purposes. Further, I updated the mat code so it will be ready to test as soon as the physical components are connected to the mat board. This should be very soon, since Jada and Brooke have been working on making prototypes of the footpads to connect to the weight sensors. I am confident with the current control flow of the program, so I am just waiting on a mat prototype to be put together so that I can develop the feature integration.

I am slightly behind schedule, because I did not anticipate spending as much time trying to get Bluetooth to work and because I have not had a physical prototype to test with while developing my code. However, I have made consistent progress, and I think it will be easier to write the code once Jada and Brooke construct the first prototypes.

Next week, I intend to try running my app on my Android phone, or to find an alternative solution if that doesn’t work. In addition, I am going to test my code on the mat and lock prototypes and fix any problems that arise.

Jada’s Status Report – 3/16/24

This week, I completed the door lock without wireless capabilities, adding the solenoid lock so that there is locking and unlocking at the entry of a correct PIN (123456#), as seen in the photos below. Also pictured below are the demo boards I created for the dance mat. I am taking an Ideate course this semester and have access to the laser cutters and 3D printers as well as a healthy scrap materials bin; because of this, I was able to go between classes and laser cut two 9″ squares out of scrap 3mm plywood, at no cost to our team. The two squares are to be the top and bottom of a single foot pat, sandwiching the four FSRs that are placed in each corner.

I was unable to switch the Arduino in the door lock to the Seeed microcontroller, however, we have determined this step to not be a priority and will switch this if we have time after the interim demo on April 1. Since the Arduino shouldn’t affect the system aside from an increased size in the door lock 3D printed casing, it will be of little consequence to leave it as is for the final version of the product if need be. Brooke and I are slightly behind in constructing the mat, as we started laser cutting and 3D printing this past Thursday; however, once we have one foot pad working it should be relatively simple to make the other foot pads as well as the mat to hold them. To get back on schedule, I will be exclusively working on the mat this week with Brooke.

Since I have finished the basic form of the lock, I will be transitioning to helping Brooke with assembling and testing the dance mat this upcoming week, as mentioned in the prior paragraph. We are hoping to have one dance foot pad assembled and in testing by the end of next week. If I have some additional downtime during the week, I would also like to make the door lock functionally more robust and begin researching a battery that will supply the lock.

Team Status Report – 3/9/24

  • 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?

Currently, the most significant risk is implementing Bluetooth to connect our system. There is a bit of a learning curve for our team as we do not have any prior experience working with this technology. For example, we have experienced issues with integrating Bluetooth support into our mobile app, which has delayed our progress in this area. We have built buffer time into our project schedule specifically for these kinds of issues.

A smaller but noteworthy issue we are currently working on solving is understanding how the Seeed Studio Xiao microcontroller functions with respect to the door lock components. The starter code for the keypad was written for Arduino, and altering it for the Seeed has so far been unsuccessful. To temporarily get around this issue, we have swapped the Seeed for an Arduino Uno, with plans to switch back once we get to a functional state with the Seeed. If we cannot get the Seeed to work properly, we will permanently switch to an Arduino for the door lock.

  • 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

As mentioned previously, the door lock microcontroller was temporarily switched to an Arduino Uno due to needing to do more research on how to use the Seeed and getting the lock to a functional state in the meantime. We have not incurred any additional costs and will hopefully be switched back to the Seeed next week.

Global, Cultural, and Environmental Considerations

Please write a paragraph or two describing how the product solution you are designing will meet a specified need…

Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

The primary impact this has globally is accessibility, simplicity, and security. This system is approachable to any able-bodied person who wants some sort of security system for a house, apartment, office, or even a room. As long as the user can make simple dance movements with their feet they are capable of using the system. The simplicity of the system is also in the patterns. The patterns are done through movements and encourage an active lifestyle with a secure and complex dancing pattern on the security side that can be easily recognized and created by the user.

This system is not complicated, as smart home systems have become affordable and necessary in a complex and changing world. Having a doormat that can easily hook up to your door and be a unique pin system is very useful. In the end, this also comes down to cost. Many similar systems will cost hundreds of dollars and have a difficult setup, this will cost under $150 for the prototype alone, with a realistic mass production being extremely cheap.

Part B: … with consideration of cultural factors. Cultural factors are encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people.

We have considered the following cultural factors when designing the BeatLock system: beliefs and morals, languages, and symbols.

In terms of beliefs and morals, two main points of discussion are the morals presented in the lyrics of the user’s song choices and religious or cultural groups that disallow dancing. To the first point, we will ensure a sufficiently diverse collection of songs the user can select from for their dance and either an “E” or “clean” marking on the songs to indicate any profanity that users may be morally opposed to listening to or endorsing. In the most conservative case, an instrumental or classical piece will be available in the song selection; this will of course be accompanied by potentially more culturally abrasive songs. To the second point, some religions and sects such as the Quakers do not permit dancing; this is an issue that we do not believe BeatLock needs to cater to, as these groups of people will likely be uninterested in the product.

Due to the quick turnaround for this product, we will only be concerned with English. If there is sufficient time at the end of the semester, we may choose to adapt the app to include a secondary language option.

Although we have elected to only provide the system in English, we want to ensure the symbols used on the mat and lock are universally understood. Basic arrows and foot outlines on the mat as well as lock and unlock icons on the door lock keypad should sufficiently meet this need.

Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.

The BeatLock system has been conceptualized with environmental concerns in mind. In the current era of widespread consumerism, many products are designed to be cheap and delicate, so that they need to be thrown out and replaced often. This increases the amount of product the company can sell. However, it has detrimental effects on the environment, due to the excess trash that ends up in landfills, in addition to the increased water usage and carbon emissions associated with product development and distribution. We have designed BeatLock so that it will be high-quality and durable, because we do not want our users to need to replace their doormat every year. Furthermore, if someone does not want their mat anymore, they can give it away to somebody else, and that person will only need to install the lock. Additionally, we aim to use the most simple electrical components possible, as this will reduce the amount of materials that we use per mat. So, in comparison to many other products created by technology companies, we will have a smaller negative impact on the environment.

**Part A was written by Brooke Rodriguez, Part B was written by Jada Fink, and Part C was written by Zoe Rudnick.

Brooke’s Status Report – 3/9/24

A large portion of the previous week was spent working on the design report, getting feedback, and improving upon the suggestions from the design presentation. Within the report, I focused a lot on refining and writing the Architecture and Principle of Operation and the System Implementation of the dance mat itself. Currently, I am still working on the design of the interior of the mat and keeping it thin, especially now that we are moving the speaker from it. Once that is done, I should have some detailed images to show that interior. The electronics themselves work fine, so integrating them and finishing the mat will be the focus.

I am behind on the design part as well as the assembly. But if everything works as planned right now, everything should be ready for demo day to test. Finally, the plans for this week are to quickly finish up the design and actually begin putting things together for testing and demo by demo day.

Zoe’s Status Report – 3/9/24

I have made significant progress with both the app and the mat software, though I’ve run into several issues. For the app, I learned that the development environment I was using (Expo Dev) would not support Bluetooth, which we need to connect the app to the mat. To solve this problem, I transitioned to using Expo Go and EAS Build, which will allow me to export the app binary and run it in an emulator app.  I’ve been having some issues using this new workflow, so I will need to ask someone on Monday. I have finished the actual code, except for any minor changes I may make, so I just need to figure out how to get the app to run. I don’t have a background in mobile/ web app development, so this is mostly new to me and has taken some time just to learn.

For the mat software, I switched from using the Arduino IDE to using PlatformIO in VSCode, because of the limited functionality of the Arduino IDE. I continued working on the code, and it should be ready to test as soon as the Seeed Xiao is connected to the weight sensor input. I have had some problems, such as not being able to rely on built-in features that I have used before. The Seeed XIAO has a Xtensa LX7 processor, which I have never used before.

I am currently back on schedule, due to the progress I have made. To stay on schedule, I will need to continue making progress at the same rate. I will need to figure out how to get the app to work and start testing the mat software.

Jada’s Status Report – 3/9/24

Since the last progress report, I have temporarily switched the Seeed microcontroller to an Arduino to get the starter code for the keypad to work. Getting the starter code to run has allowed me to begin building off of it to create what we need for our door lock to meet functionality. Because the past week has been spring break, I have not had access to the components to test new iterations of the code, however, this will be tested as soon as I return to Pittsburgh this Monday. The main areas of modification include receiving the correct number of digits, checking the input pin against a “correct” pin, allowing the “lock” button to bypass a pin input, and outputting a signal to the lock solenoid upon receiving the correct pin. The two images included show progress made before we left for spring break.

I believe I am still on schedule; however, this is contingent on the time it takes to switch back to the Seeed microcontroller this upcoming week.

By the end of next week, I expect that the door lock should be completely functional, minus wireless capabilities.

Team Status Report – 2/24/24

  • 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?

One possible risk on the hardware side includes making sure the different parts of the project can effectively and consistently communicate. Additionally, another part that could risk jeopardizing the project is the designing and building of the dance mat itself. The mat has to be thin, strong, and fit the required electronics. Although everything currently fits in the CAD, translating this to real life could lead to some difficulties. Besides that, some delays in programming the hardware could appear as we may have to brush up our knowledge and fill in any gaps when it comes to programming and working with microcontrollers and sensors.

  • 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?

To better accommodate testing and assembly of parts, we have updated the Gantt chart to push back PCB design and move up testing and assembling the door lock and mat. We believe this was necessary, as the PCB should be created after we have confirmed the needed parts for the system. Therefore, we should still be on time in terms of hardware, and no additional costs have been incurred. These updates were seen and brought up on the most recent design presentation, along with some minor adjustments to better accommodate for spring break.

No changes were made to the software or app design.

  • Provide an updated schedule if changes have occurred