My third engineering design project was centered around the use of sensors and the Raspberry Pi. Our objective this time around was to select a target demographic and design a wearable or home device that could meet one of their needs. My team and I chose to design a device for stroke patients, as one of our members had a family member suffer from a loss of speech as a result of a stroke. More specifically, we chose to target stroke patients with aphasia (loss of verbal understanding and/or communication), and muscular weakness. Our device, the Melodic Intonation Tapper or (MIT) was designed to allow patients to practice melodic intonation therapy without the assistance of a therapist, thereby increasing their independence. We utilized force sensing resistors as input devices, and LEDs and a servomotor as output devices. Patients would initialize the program by tapping on one of the force sensors to input the number of syllables in the phrase they would like to practice. Then, after confirming their input was read correctly, they would tap on the other force sensor, and a countdown would begin, indicated by a blinking green LED. The servo motor would then activate, raising and lowering the patient’s hand for them.
Initial prototype of the Melodic Intonation Tapper shown at our design expo
| Personal Contributions | Learning Opportunities |
|---|---|
| Collaborative idea generation | Organizing flowcharts |
| Verbal communication | Debugging code |
| Planning and writing programs in Python | Wiring circuits |
| Pragmatic design |
In the brainstorming phase of the project my group was split between selecting narcoleptic individuals and stroke survivors as our target demographic. At first I was biased towards narcolepsy, as I had suggested the idea. However, after my group decided to pursue designing a solution to aid patients suffering from aphasia, I quickly shifted gears and contributed my thoughts to the discussion. When one of my group members explained the concept of melodic intonation therapy to me, I decided to investigate other stroke side effects that could possibly influence our design.
Through my research, I discovered that paralysis and a loss of fine motor control were common symptoms of a stroke. I communicated this to my team to ensure that our design accommodated for this potential need. This informed our direction, as we realized that we could make a device to allow stroke patients with aphasia and poor motor control to practice melodic intonation therapy independently. This experience allowed me to grow as a team member, as before I would typically fixate on my own ideas in an attempt to make them succeed. In this project, I was able to more easily let go of my own aspirations and focus on contributing in a way that suited the needs and interests of my group.
Section from a milestone worksheet outlining our preliminary research
.png)
My flowchart outlining the high-level functionality of our Python program
As a part of the coding sub-team, my partner and I were responsible for producing the computer program for our prototype. I played a critical role in the planning phase of the project, where my partner and I outlined each function we needed to program. In order to streamline this process, I suggested that we create a shared planning document where we could clearly describe each of our functions. Organizing our thoughts using this document was beneficial, as it removed some of the ambiguity from our plans and allowed us to clearly lay out a logical sequence of operations. Additionally, my robust written communication skills were especially helpful in this situation, as I was able to translate each function we generated into a concise list of inputs, operations, and outputs.
Once this phase of the planning was complete, we moved on to generating flowcharts to flesh out our initial ideas. My partner and I both made separate depictions of our program (mine can be seen on the left), and then came back together afterwards to discuss our plans. This allowed us to consolidate our plans and ensured that we were on the same page before we started to write our code. It also served as an invaluable reference that we consulted frequently throughout the project.
After my team and I solidified our initial concept we sat down with one of our professors to have him critique our design. While he appreciated the idea behind our device, he explained that it was mechanically unfeasible. Our initial design involved two servomotors connected to two gears, which were on a dowel. This dowel would be attached to a wooden platform, which would turn with the motors, raising and lowering the user’s hand. A visual representation of this initial design drawn by my team member can be seen to the right. Keeping this in mind, I suggested that we modify our design to situate the user’s hand on the edge of the platform to reduce the strain on the motors. Additionally, I brought up the fact that using a singular gear didn’t make sense, and that we would benefit from using a gear train to improve our mechanical advantage. This, in combination with some cams would allow us to easily raise and lower the platform periodically.
Original concept design for the MIT with a singular gear, drawn by my teammate
Revised concept using gear trains and cams, drawn by my teammate
My original flowchart was highly disorganized. I listed inputs and outputs twice, which made it difficult to understand. Additionally, the non-linear formatting was not standard. After receiving feedback from my TAs, I revised the flowchart to make the one seen in the previous section. This was a valuable learning experience, as being able to create clearer flowcharts will allow me to plan more effectively in future projects.