David’s Status Report for 2/21

What did you personally accomplish this week on the project?

I spent a decent amount of time in the early week with DJ on beginning the software for our project. We setup our RPis, but our V2T onto the Pis and began attempting GPIO modulation code. Unfortunately, the Pi 5 has a much more difficult time with hardware level GPIO than past Pis. As a result, I also spent time reformulating some design to use a pico for led control. This should be a far far easier way to actually get code to modulate the light. Aside from that, I did some work on getting the LCD screen interface coded. I have also spent about 5 hours beginning design report.

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

We are still ahead of schedule. Along with DJ we have packet encoding and decoding programs made. With our switch to pico, our scheduling may definitely be shifting a little bit in the next week or 2 depending on how difficult that is to work with.

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

Next week my main focus is working on pico integration. I (we) would like to get the modularized light working so that we can begin integrating with the V2T and our encoding / decoding software. Based on research this week, we think the pico should be easy to work with for this as it is designed more as a hardware-level microcontroller. Aside from this, I am also working on design report which we will complete by Friday.

David’s Status Report for Feb 14th

What did you personally accomplish this week on the project?

I was out of town for much of the week so most of my accomplishments were remote accomplishments (plus we were waiting on parts anyways). I spent a decent portion of time creating and then going through batches of edits for the slides so that DJ is ready to present next week. I was largely ahead of my gantt schedule but I went ahead and continued research into signal Rpi protocol libraries. I have researched the gpiozero / libgpio library and went through example codes that proves that it should be able to hit our design requirements of light modularization.

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

I am ahead of schedule, we got through V2T relatively fast and can now start transitioning to hardware components as all of our parts should now be here to pick up!

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

Next week my main focus is working on packet protocol. I would like to use the GPIO library(s) to actually write the code for the led modularization and be able to code our encoding scheme into the RPi. Along with todd, we would also start some hardware implementations such as putting the V2T onto the Rpi and beginning to test light modularizations.

Team Status Report for Feb 7

  • 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? As of now, we think our main risks will be related to noise sensitivity and light interference. While we do not fully know these risks until our parts arrive, they are being managed currently by having a wide array of options to test in our system. For example, we have multiple different light sources either ordered or in a backup list to order if needed. Overall, our IR protocol will function somewhat like a TV remote. Because of this, we have some documentation available for potential risks and these will help us to mitigate issues as they arise. For the IR components, our contingency plan is to try to switch to a more well documented transmission protocol, like RF. For something like our microphone, our contingency plan is to switch to a more reliable high sensitivity bone microphone and mitigation plan is to perform basic pre-signal processing if we have too much noise. 
  • 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 only change we made so far is ordering 950nm LEDs instead of 1450nm. We plan on using the 950s for testing and then switching to 1450nm. Originally we had planned on 1450nm the whole time but they are expensive and we didn’t want to throw budget away for testing parts. After more research on LED safety, we know that 950nm LEDs are also safe. But because of some potential added risk, we are now definitely adding IR filters as a fail safe. No other main changes were made to the overall design system. However, we were able to get 8GB RPis (which is something we were debating), giving us more leeway to put on larger software processes. Because this was loaned to us, there is no cost to our budget or design.
  • Provide an updated schedule if changes have occurred.NO SCHEDULING CHANGES THIS WEEK

 

    • This is also the place to put some photos of your progress or to brag about a component you got working.-Proof of concept VOSK, we are also close to live test translation software. 

David’s Status Report for Feb 7

I began the week off spending time fine tuning both our proposal slides and the actual presentation. Because I was the one presenting, I added some notes for myself and practiced for a few hours prior to actually presenting. After this, I spent the middle of the week researching and coming up with a parts list, specifically focusing on the voice to text components of our project. I began with research on specific lighting components and searched through digiKey for their respective parts lists. Along with DJ, we determined that 950nm was sufficient for testing and had good directivity and ability to modulate frequency. After, I did research on open source models such as Open AI Whisper and Vosk, before ultimately choosing Vosk as the most promising V2T software to begin with. I then made the first proof of concept Vosk model that translated chunked up audio files into English test. This was a good enough proof of concept that we felt comfortable selecting Vosk as our primary focus for open source V2T. Following this, I did research on how to make V2T compatible on raspberry pi with some of DJs modulation specs. I have now been researching and playing around with the pigpio library for RPi and its ability to potentially be our way to accurately modulate eyeR.

My progress is on or ahead of schedule. Most of my scheduling for this week was regarding determining the parts we would use for our project. Not only did I complete this, but we put in order forms and have begun making Proof of Concepts for some of our system components. Mainly, the V2T software seems easier to use than we initially thought so we (DJ/I) are in a good position on that. We are still waiting for confirmation of our ordered parts but hoping that those are also as expected.

Next week, I hope to begin integrating the V2T software and the Rpi. If our microphone is here by then, I would like to get the RPi to take in microphone waves and convert to text. Otherwise, I would like to deliver a similar system but with the microphone replaced by computer audio files. I would like to have the software on the RPi for live translation as well. From here, I can then (not necessarily next week) coordinate with DJ and start to mesh together software components.