Posted on

Brooke’s Status Report – 4/6/24

This week, I mainly was finalizing the construction of the board with the parts I was not able to get done last week, and I am beginning to set up the low-power and Bluetooth aspects of the microcontroller. Now that the sensors are set up and functioning, these other parts and integration with the other pieces are now going to be the focus, along with the game aspect being set up with the passcodes. I don’t have any photos this week, as nothing has changed visually from the previous week; it’s just behind-the-scenes stuff.

I am currently scheduled to complete my parts. The focus now is the board’s aesthetics and the wireless connectivity with the application and door lock. I will spend the next week on both of these two parts. However, the main focus will be the wireless connection and low power, as functionality needs to come first for verification and testing.

Verifications:

  • Ensure the consistency of the sensors and that they work with every step, and ignore instances of the user standing on the board, NOT stepping. This should work nearly every time without fail.
  • Ensure an extended battery life using the low-power system to minimize the time required to charge the device. Ideally, I would like the board to last a bare minimum of a few days of heavy usage.
  • Ensure the device is durable from dust, dirt, water, and usage. We will have to throw water and dirt on the device, poorly treat the device by stomping way past the weight limit, etc. This device needs to last and be reliable for everyday use, so we must go a bit extreme in this area.

Validations:

  • Ensuring a quick and low-latency Bluetooth connection to the door lock and the app so that there is no difference in time to traditional lock systems and there isn’t a delay causing a malfunction. This needs to work every time without fail or else it can’t beat out a conventional locking system.
  • Ensure that the entire system works with a smooth flow that you can verify on the app, use the board, and then unlock the door as desired. This does not have metrics and is more of a test of comfort and ease of usage with multiple users with varying experiences with the device and/or Dance Dance Revolution.

 

Posted on

Zoe’s Status Report – 4/6/24

This week, I got Bluetooth working on our app! It was able to scan for devices and connect to my iPhone.  Below are photos showing 1) my iPhone being connected to the Android phone and b) connecting to my iPhone (named mtn dew) from the Beatlock app on my Android phone. 

This means our app is mostly done. To finish it, we need BLE implemented on the Seeed XIAO microcontroller in our mat. So, after the app was working, I went back to working on the mat code. Once BLE works on the mat, I will change the app code to not scan for devices but simply locate and connect to the mat. Getting BLE working in the mat and then making them work together is my goal for this week, since I have already finished most of the code for the mat. I just need to try out the code on the microcontroller and debug any problems that arise. I also have other code to test out (the code to deal with the dance input) that I will debug as soon as the mat is functional.

I am on schedule, because I have made the progress that I was hoping to make. There is still lots of work to be done, but since Booth and one of my classes will be done by this Wednesday, I will have even more time to work on it after then.

Posted on

Jada’s Status Report – 4/6/24

This past week, I have been working on the Bluetooth module and the microSD card module. I was able to solder speaker connections to the Bluetooth module as well as manipulate two audio files for testing the system; however, I’ve run into two problems that set me slightly behind schedule. Once the microSD card module and microSD cards arrived, I had some difficulty finding an SD card adapter until this morning (Saturday); once I had the adapter, getting test song mp3 files downloaded and wiring the microSD card module for testing was straightforward. The other, still standing, issue I’ve run into is getting the Bluetooth module to see the files that are on the microSD card. I believe the current library for the Bluetooth module was made for a specific adaptation of an Arduino Uno that includes built-in memory, so I’m currently researching how to get the BT module to reach the files. One step I’ve made towards getting this working is verifying that the microSD card module works; I found that Arduino has built-in example code for memory cards, which can both verify that there is a connection to the card as well as list files on the card (as seen in the photo at the bottom). I plan to take time tomorrow to learn from the example code how to see the files so that I can copy the paths for the BT module.

Another potential issue that may come up once I solve the file issue is wiring the speaker to the BT module since it has a useful audio function library. In the diagram given for the BT module, there are three connections (GND, VCC, and DACL) going from the BT module to the speaker; however, our current speaker only has two connections. This may be as simple as wiring only GND and DACL, but I won’t know until after I can get the BT chip reading from the SD card.

Because of these main issues, my progress is slightly behind schedule. To catch up, I plan on working most of tomorrow to get the BT and microSD card communicating, and maybe testing my speaker hypothesis if I have time. If the speaker doesn’t work, I will look for a speaker to order.

This upcoming week, I hope to have the speaker, microSD card module, BT module working together. After this, I hope to have these items integrated into the main lock system as well as begin testing the BT connection between the app and the lock.

Additional Discussion

In terms of verification of the lock subsystem, I have tested or plan on testing the following measures:

  • Keypad functionality – this was completed by hardcoding a correct PIN and verifying that the keypad outputted a “correct” signal when the correct PIN was entered.
  • Solenoid lock functionality – this was completed by connecting the solenoid to the 5V pin of the Arduino and verifying that it unlocked when powered.
  • Bluetooth connection – this was initially confirmed by connecting my iPhone to the module without the rest of the system. Better validation will come by testing the connection between app/lock, and mat/lock.
  • Audio quality and level – this will be verified in two parts. Quality will be qualitatively measured by listening to the audio files through my laptop and comparing to the audio quality from the speaker. Level will be measured hopefully through a decibel reader, likely through a downloaded phone app.

Posted on

Brooke’s Status Report – 3/30/24

This week has been focused primarily on really finalizing the prototype of the dance pad for demo day. After acquiring some of the main things we needed from Home Depot that could not be shipped, the assembly was finished, and a rough version of the final planned board was made. I have decided to go a very affordable route, with many of the materials relying on wood for most parts of it. As it is so thin, it also enables us to wrap this and use it for the final design if necessary. I have attached a photo of a nearly complete version of the board. On the software end and electronics end, most of the time was spent integrating them and making sure the electronics were wired correctly and installed. I have a bit more finalizing to do with the firmware, but by Monday, we will be ready to show what we have made.

(It is not the prettiest, but it should work for now; a lot of the aesthetics will be a plan for the final model)

With all of that said, I am thankfully not behind, and everything has been finished as planned (and is required for the demos). For the next week, the main focus will now be put towards finding ways to make this board a complete and professional-looking product and integrating it with the other parts Jada and Zoe are working on. One focus with them will be on having a secure wireless connection between all of the devices that is low power and does not bleed energy. That shouldn’t be too difficult for this board, but we may have to investigate low-power modes for the Arduino used in the lock.

Posted on

Team Status Report – 3/30/24

The most significant risk for the lock remains to be Bluetooth integration. To manage this risk, we’ve moved from the Seeed microcontroller in the lock to the Arduino Uno and have ordered a BT module that is looking promising. This is also the case for the app, because we might run into unexpected errors that would delay our timeline.

The lock block diagram has officially been changed to reflect the microcontroller switch and additional modules needed for full functionality. As reflected in the wire diagram in Jada’s status report, the new additions aside from the microcontroller include the BT module and the microSD card module. This diagram may still change depending on song functionality, potential future switching from lock solenoid to stepper motor, and adding a battery connection. This most recent change has incurred a small cost, but for parts that will hopefully be kept for the final product.

Updated Schedule:

April 1 – April 8

Finish mat construction: Brooke and Jada

Order rubber cover for mat: Brooke

Get BLE working: Zoe

Play song through lock: Jada

April 8 – April 15

Get one song functioning on a complete system: All

3D print lock housing: Jada

April 15 – April 22

Testing: All

Posted on

Zoe’s Status Report – 3/30/24

I spent a lot of time this week working on our app. First, I setup my Android phone to have the Expo app. It could run an Expo Go app fine. However, when I created a development build (image below) and downloaded it on my phone, it always crashed upon opening.

To debug the app, I used two tools. The link to the build contains information about the build, so it can tell you if an error was encountered with the package.json, dependencies, app config, expo doctor, and gradlew, and more. While debugging, I ran into issues in all of these areas, but the logs provided allowed me to fix the errors. However, sometimes there were no errors in any of these, but the app still crashed. To fix this, I downloaded Developer Tools on the phone (which I believe are now integrated into Android phones, but since the phone is so old, it was a separate app) and turned on Debug mode for my phone. Then, when the phone is plugged into my laptop, I was able to see a log of all errors coming from the phone. I saw that the same vague error was encountered every time I tried to open the app. After doing research online, and having no luck with any of the quick fixes suggested by other people encountering the same error, I decided to uninstall all the packages I had installed, and then reinstall the required ones. I did this in case 1) I was using incompatible versions of packages together or 2) one of the packages was causing a problem, and I would be able to isolate it. After reinstalling the necessary ones (not related to BLE), the app finally worked on my phone! Image shown below. This process took too long, but I have never made an app before, so it was cool. Now, I have already written the code for BLE, and I know which packages to install. I have not yet actually implemented it, but that is my next step. I anticipate running into more problems, but at least I know how to deal with them now. I also plan on polishing the app design. It is currently a prototype of the real design.

In addition to the app, I made sure my software was up-to-date with Jada and Brooke’s work.

My progress is on schedule. I wanted to have the app complete before the Interim Demo, and it is at least partially complete already. Tomorrow I will start integrating BLE functions again.

In the next week, I should have the app completely finished and communicating with the mat. This will require adding BLE connectivity to the mat too, which I have been working on but have not completed yet. While I am adding this connectivity, I will also add connectivity to the lock, since Jada has been getting BLE to work on the lock.

Posted on

Jada’s Status Report – 3/30/24

This past week, I mainly continued work on the lock, solidifying our use of the Arduino Uno by continuing to research compatible Bluetooth and microSD modules for the Uno, writing up an updated wiring diagram (as shown below) to visualize the potential additional parts, and ordering the Bluetooth and microSD slot modules as well as 2GB microSD cards.

Beyond this, I was able to get the Bluetooth module running after downloading its respective library and example code. Surprisingly, my iPhone was able to discover and connect to it in this initial testing (as shown below). I also assisted Brooke with laser-cutting the boards necessary for the mat construction. Fun fact:  the Rabbit lasers in Ideate are superior to the Techspark Rabbit lasers (good to know, but not a fun walk with heavy items).

I feel that I am a bit behind schedule, as Bluetooth is not integrated into the system yet. As long as Zoe and I can get the lock and the app communicating by the end of this week, I should be in a much better place, as getting song selection set up and a 3D-printed container for the lock *should* be relatively straightforward and not too time-consuming.

By the end of next week, I hope to have Bluetooth between the app and lock completed, including soldering the BT module for speaker connection. After that, if the microSD cards and module come in quickly, I will begin working on getting songs loaded and playing through the lock.

 

Also, Happy Easter!

Posted on

Brooke’s Status Report – 3/23/24

This week, I made some changes to the prototype design and final design. I worked out the location and setup of all of the electronics in the device and determined the final size of the device and how we could get it. One of the priorities I have had with the device is to make it around as thick as a normal doormat, and with the finalized design of the prototype being under 15mm thick, I believe we have accomplished that.

Although the design of the final board and prototype have been going great, as with the building of it, the firmware end has not been going so well. I have been running into trouble getting the device functional and struggling a bit with the code. All that said, once I get past the speed bump of its functionality, coding the game part won’t be much of an issue.

That being said, next week is when I plan to finish the board prototype itself and finalize the code so that everything is ready for demo day. There is no room for delay, though, as the demo is coming up very soon.

Posted on

Zoe’s Status Report – 3/23/24

This week, we have been working to prepare for the interim demo. I worked with Jada to research how to set up audio and Bluetooth for the lock. We had not decided yet whether to use a Seeed microcontroller or an Arduino Uno R3 for the lock, so I looked into software options that would work for both architectures. The best way to store and play audio clips seems to be storing .wav files (generated online using a program like Audacity) to an SD card and then playing the songs using a built in module. Once we have the SD card ordered, we will be able to test the code we have for playing our songs. For Bluetooth, we had a similar problem in that how we implement it will depend on whether or not we use the Seeed microcontroller. If we do, then BLE is built into the Seeed microcontrollers and their website provides documentation for how to implement both client and server protocols. If we use an Arduino, we will have to buy and implement its own Bluetooth module to connect to the board. I spent a lot of time learning about BLE on the Seeed microcontroller, because regardless of whether we use it for the lock, we are using it for the mat, and it needs to act as a client and server in the mat.

Another thing I worked on this week was the correctness algorithm (how to determine if the input should be marked as correct). In my current algorithm, I model each correct dance move with a corresponding Gaussian curve, and performing the step before or after the required time provides ‘points’ according to the y-value of the curve. A specific percentage of total points must be achieved in order for the dance to be considered correct. In addition, if one move is outright incorrect or very badly timed (+ or – 3 seconds), the dance is considered incorrect.

Lastly, I have revisited my app with the hope of making the BLE connection work. To do this, I found an old Android phone (Galaxy Note 5) that I have and ordered a charging cable for it, because it was dead. Now that I have a working Android phone, I should be able to develop my app directly on the phone and avoid the problems that I had with iOS.

I might be slightly behind schedule, because I had to spend a lot of my week preparing for the Greek Sing musical I was a part of. However, that is done, so next week I should be able to finish a lot of the work that I started this week.

Since we have a week until the interim demo, I am going to focus on wrapping up everything to make the demo successful. This would ideally include 1) making BLE work for the app, mat, and lock, 2) getting audio set up, and 3) making sure we can get input from the foot pads, decide whether or not the dance is correct, and relay the information to the lock. At this point, we have started everything we need for the demo, we just need to make some decisions and wrap up some loose ends.

Posted on

Team Status Report – 3/23/24

The most significant risk is still getting the Bluetooth functionality integrated into each of the three parts of our system. For the door lock, at least, this risk is being managed by researching Bluetooth modules for the Arduino in the case that the Seeed (which has Bluetooth built-in) doesn’t integrate in a reasonable time. For the app, an Android phone has been acquired and set up for app development, so that we can avoid the restrictions placed on app development in iOS.

No changes were made to the existing design or schedule. In the event that the Arduino lock is kept, there will be additional modules in the door lock electronics than previously anticipated.