.png)
My fourth and final design project was centered around designing a solution aid a real person. My group chose to work with Kevin, a stroke survivor who has trouble walking for extended periods of time. To allow Kevin to travel more easily, we wanted to create a device that would decrease the mental strain associated with walking. To do this, we designed STRYDE - a device consisting of a leg band with an orientation sensor, and a housing unit that attaches the electronic components to Kevin’s walker. The orientation sensor tracks the angle his leg swings through when he is walking to determine if he is walking properly or not. If the angle is too small, the program deduces that he is shuffling and plays an audio clip from his wife, Rose, to remind him to pick up his feet.
| Strengths | Learning Opportunities |
|---|---|
| Coding in Python | Conflict management |
| Organization/Note taking | Failing to take more initiative |
| Advocating for my ideas | |
| Flexibility |
A sample of the output values yielded from our initial test functions
Although this project was more open-ended, my team still decided to divide ourselves into unofficial hardware and software sub teams to avoid any diffusion of responsibility. After successfully completing the code for my third design project, I felt that I was capable of contributing to the software sub team. Additionally, I figured that it would be an effective way to test what I had learned, and to increase my familiarity with Python and different types of sensors. This time around I made sure to be more thorough in understanding the sensor before we started to code. My partner and I spent the first few days experimenting with the absolute orientation sensor and marking down any patterns we observed. After that, we started to write functions to collect and process data. However, we quickly ran into issues with manipulating the values we were receiving. Initially I thought that we needed to use the x-values of the Euler angles, however, after some more experimentation, my partner found that the y-values were more indicative of the stride angle. From this, I learned that I needed to avoid making assumptions when trying to understand new concepts. If I had tested the sensor more thoroughly from the beginning, I could have saved myself and my partner the time it took to edit our functions later on.
One major success I had while working on the code was getting the audio output to work. After doing some research into the capabilities of the Raspberry Pi, I discovered that I could use the pygame library to output audio through headphones. At first I ran into some difficulties with hearing the audio, but after speaking with the lab tech, I was able to set the output to play from the audio jack instead of the HDMI port.
As the coordinator for my team, I was responsible for taking notes during our meetings. I ensured that the documents were well organized and easily accessible for later reference. Furthermore, I took an active role in keeping the team on track by coordinating team meetings outside of our regularly scheduled design studio time. One success I had in this role was in formatting and storing my notes in an organized fashion. Keeping a folder where I could store the documents and relevant screenshots streamlined the process of creating and pasting meeting minutes into the design report.
However, one thing that I could improve upon in the future is completing the notes during or immediately after the meeting. During busier points in the project I found that I would be preoccupied with other tasks like writing the code or filming the prototype demonstration instead of taking notes. Instead of waiting until later to update the meeting minutes, I should have consistently completed them immediately afterwards to prevent myself from forgetting details.
A section from one of my meeting minutes documents
A picture of our initial brainstorming, my writing can be seen on the right
One of the main things I struggled with in previous design projects was my inability to express and defend my ideas in a group setting. This is because I’m typically observant and tend to avoid conflict whenever possible. However, during this design project I was in a group with a few dominant personalities who would speak for the majority of the meeting. In this scenario, it was necessary for me to be more vocal and occasionally interrupt others if they had been expressing their ideas for an extended period of time. Taking action like this was beneficial, as there were multiple instances where I had to remediate disagreements between my group members during the design generation process. Furthermore, advocating for a more realistic approach helped us to stray away from unfeasible ideas, like creating spring-loaded shoes that would help Kevin walk, for example. On the whole, I think that I was able to guide my group towards the right path and effectively navigate conflicts for the most part.
While I did grow more effective at expressing myself in collaborative settings, I would say that I could still greatly improve when it comes to properly handling disputes. For example, when I was addressing certain ideas that I thought were unrealistic, I was likely too dismissive. Instead of outright disagreeing with my group members, I should have taken the time to properly acknowledge the idea before explaining why I thought it wasn’t executable. Another issue I could work on is ensuring that everyone in the group is included in group discussions. During meetings I found that two of my group members spoke most of the time while I tried to occasionally interject my opinion. Instead of just advocating for myself, I should have played a more active role in involving my other group members who rarely conveyed their views.