.png)
✅ Python Programming
✅ Object Oriented Design
✅ Hardware Integration
✅ Software Version Control
✅ Game Design
✅ Resource Management
✅ Adaptability
✅ Time Management
✅ Creativity
<aside> 🕹️ With the fourth design project, my team and I were assigned a completely real patient that suffered from Multiple Sclerosis (MS). Despite living an active and free life, her diagnosis has significantly impeded her movement abilities, especially the dexterity in her fingers. Thus, in a pursuit to gift her the control of her life again, my team and I created the most engaging customized form of therapy: a videogame. Dexterity Dash is a two-part controller and software solution that aims to repeatedly stimulate the use of her fingers in certain motions that would help her regain the fine motor skills in her hand.
</aside>
🎮 Dexterity Dash uses:
🔌 Devices and Electronics used:
Starting off our design, we need to have an end goal, and as part of the engineering process, we first developed our general and rough need statement. At this point in the project, minimal research was done on the feasibility of a video game solution, hence the solution not being described here. (See further down for justification)
Design a new, unique and portable solution for (patient) that increases her quality of life by improving her everyday movement. The solution should improve either her hand dexterity or her foot drop issue so that she can run with less pain.
In the initial weeks, as we narrowed down our decision to create a video game, we gained more information and built upon ideas for the prototype. My team and I concisely broke down and compiled our visions of the product into our goals and where we were limited.
| Objectives | Functions | Constraints |
|---|---|---|
| Should create an engaging and fun experience for the patient | Consistently target finger movements in a healthy manner | Must not harm/overstimulate fingers |
| Should stimulate the patient’s fingers in fine movements | Track user’s high scores to encourage playtime | Must comply with relevant videogame regulations |
| Should be as intuitive and accessible as possible for all users | ||
| Should be lightweight |
Given that our solution would require intense work in both the physical and computing aspect, my team and I broke into sub-teams again. I was on the computing/electronics side of the project, where I took it upon myself to figure out the ADC’s and somehow manage to make use of our joystick.
<aside> 🛠️ Our initial idea for the controller was to build out the support for both hands until we realized how expensive and unnecessary this would be in terms of prototyping. As for the design, we planned for a simple non-adjustable joystick configuration that more closely matched our patient’s hands, along with a small armrest for prolonged comfort.
</aside>
<aside> ⚡ In terms of the electronic side of things, it took quite a while to make sense of connecting multiple of the same part to a Raspberry Pi. This was because they all had the same connection and thus I taught myself memory addresses and I2C connection for breadboards which allowed me to finally translate movement from the joystick axes into a prototype game (see video). Game design wasn't important to us at this point, as we focused on getting things working.
</aside>
<aside> 🤔 We were also considering the implementation of EMG sensors to detect muscle contractions while playing the game, which in hindsight could have provided some valuable statistics and ‘next steps’ for the patient. However, it realistically would have been tedious and beyond the scope of our project, as we would require research to back our statistical calculations and inferences of the collected data to make use of this feature.
</aside>
The first sketch of the controller, containing support for both arms, 10 joysticks, and further explanation of our proposed video game
Video demonstration of the joystick movement being translated into moving a sprite in pygame.
Video demonstration of the joystick movement being translated into moving a sprite in pygame.
.png)
The first prototype was modelled in Inventor with many small, moving parts that were subject to failure
.jpg)
The complete wiring setup of our joysticks to properly interface with our Raspberry Pi
<aside> 🛠️ Immediately, the modelling team took to Inventor to create a preliminary working prototype for joystick implementation. However, this time it was reduced to only 5 joysticks allowing a realistic build. At this time, my team and I agreed that they should be adjustable to allow for comfort and customizability, and thus incorporated them onto a track and housing using many small pieces.
</aside>
<aside> ⚡
</aside>
<aside> 🤔 In reflection, the modelling sub-team had fell victim to the perfect world of AutoDesk Inventor. We quickly realized how incredibly difficult it would be to execute these millimetre precise parts on a level of fidelity that our goals were set towards.
</aside>
Adding the final tweaks to the product, the modelling sub-team started crafting using laser cutters and 3D printing, while my partner and I tested the code in all game modes. Once everything was sure to be error and bug-free, we simply joined the two parts together. Turning the Raspberry Pi on, the game was in full function.