.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> ⚡
In the following days, I was able to connect all three ADC’s to the breadboard and their corresponding joysticks. To do this, I was taught how to solder since I needed to jump the bridges at the back of the device to change the I2C address. Moreover, in order to integrate them into software, I had to write a library for the joysticks. This was fun and easy to implement using OOP, and allowed my partner who was tasked with writing the game itself to simply use the methods I provided him with.
</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>
<aside> 🛠️ With a complete overhaul of the last design, the controller was modelled much simpler, keeping all of its functionality and effect. The joysticks used a unique housing to guide the wires through the tracks they sat on and into the casing. For adjustability, a grid system was implemented with pegs that fit into holes at the bottom of each joystick housing. This provided a secure and intuitive way for executing the precise goals that we set for the product.
</aside>
<aside>
⚡ Meanwhile, my partner and I began learning the basics of pygame, a Python library intended for designing and executing simple games. We also decided and finalized the objectives of the game modes in accordance with our research. With so many files, including code and graphics, it was necessary to stay organized using version control like GitHub.
</aside>
<aside> 🤔 Collaboration in code is something that is often overlooked and can get messy really quickly. Thankfully, I knew this beforehand and therefore, in the practice of writing good code and following standards, we made the effort to consistently commit everything to GitHub so that we can communicate efficiently and in an organized manner. Looking back, this was crucial to this project, saving time and frustration.
</aside>
.png)
The updated and feasible build for the controller, still adjustable and ergonomic
A view of the files in our final repository including all working code and graphics
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.