top of page

Prosthetic Pressure Sensors

20240427_064036976_iOS.jpg
leave 5.png
leaf.png

Almost every engineering student at CU partakes in the tradition (or requirement, depending on how you want to view it) of a Senior Capstone project. The details vary by major, and year but the gist is that students form small teams to use the engineering skills they learned in college to solve a real engineering problem. Usually, you do the capstone with other students from your major but CU offers a special opportunity for some software students to join in the mechanical engineering capstone, as many of the projects frequently involve some level of code. Given my love for writing code that controls physical things, I jumped at the opportunity and had the incredible fortune of getting placed on a truly wonderful team and equally wonderful director working with an industry partner on a fascinating challenge. Not only did we have a blast working together, (there were baked goods that showed up to almost every meeting), but in the end, we designed and built something we were very proud of and even won the 1st place people's choice award at the end of year expo! I truly couldn't have asked for a better experience.

Now you're probably wondering what we actually built. Well, the one line answer is we built a system of sensors to help fit a custom prosthetic socket by showing a near-live 3D map of pressure data. There's a lot going on there so in order to explain it in a little more detail, let's hop back a few steps and start with what the actual problem was. A prosthetic is made up of several different pieces, one of which is the actual socket that attaches to the residual limb, what is left above the amputation, etc. Despite some incredible advances in prosthetic technology over the last 100 years, it's still difficult to get the fit of the socket right. The current most common process is to create a test socket using a mold of the person's leg and then have them spend a few hours in the practitioner's office testing it and adjusting. Once they are happy with it, a daily wear socket can be made using the final shape of the test socket. This process works and with the skill of the talented practitioners, you can get a good fit this way but it's time consuming. This is especially frustrating as the size of your residual limb can change quite a bit due to several different factors causing you to have to get a new socket fitted possibly as often as every 6 months to a few years. The other problem with this process is it relies heavily on the patient being able to communicate pain and pressure points which can be a challenge, especially when there is nerve damage from say, an accident, involved. With this in mind, we set out to build a tool to both make the process faster and give a second method of gathering data about pressure in the socket.

SDGraphic-2.png

Drawing of our system

Our Design

leaf.png
leave 5.png
laptop+software.png

Our final design consisted of three interconnected components. The first was a set of 8 strips of flexible PCB (printed circuit board) with a total of 70 pressure sensors attached. In order to not mess up the fit of the socket, all of the sensor strips had to be less than a millimeter in thickness. Because you can't really get a microcontroller that thin (at least not easily), all of the strips were long enough to run out of the top of the socket and attach to a larger circuit board housed at the patient's waist. This circuit board consisted of a microcontroller and a battery power/charging system. The microcontroller read all the data from the sensors and then transmitted it over Bluetooth® Low Energy. Totally unattached to this system was our software running on a laptop which could read the data being sent out by the microcontroller, process that data and then display it in a 3D model of the socket.

The user interface

I was the software lead for the project which consisted of several roles. The first was being the architect of our software system including making overarching design decisions, determining the scope of our software, researching and selecting the different libraries we were going use, diagramming how the two different software systems (one running on the microcontroller in Arduino and one running on a laptop in Python) talked to each other and what each of them was responsible for, and working with the hardware team to ensure I understood the hardware constraints we were working with. The second responsibility as software lead was organizational and involved project management for the software team using Jira, mentoring and helping two of our mechanical engineers who stepped up to help with the software, delegating tasks, doing code reviews, and working with our overall project manager. The third responsibility was writing the framework for the code as well as handling all the code running on the microcontroller and the receiving and unpacking of that data on the laptop. The biggest challenge I faced writing this was learning how to work with Bluetooth® Low Energy which is a form of Bluetooth® that is usually used for things like your smart watch that need to be battery efficient but don't need to send a ton of data. In our case, we did need to stream 70 sensors worth of data so I spent a good number of weeks in the weeds of BLE trying to figure out the fastest and most efficient way to get our data to the screen. I also spent a good deal of time near the end of the project documenting and commenting the code so that the next developers to pick up the project would be able to understand where we left off.

20240427_002957283_iOS.jpg

My test platform, aka my sea creature that I used to develop most of the code until the final parts came in.

leave 5.png
leaf.png

Wrapping things up

Finally, we've made it to the end of the project and the big finale: Expo. Every year engineering teams from across the disciplines set up in the indoor football field with posters and demos to show off their work to the public. There are judged presentations and lots of telling the same story repeatedly until your voice starts giving out. We were able to set up a couple of demos at our table that people could interact with and I'm proud to say that with only one minor hitch, the demos ran constantly for hours and got a lot of people engaged in our project. Thanks in part to our demos, a good story, and probably a good deal of luck, we walked away from the day with the 1st place people's choice award and a huge sense of accomplishment. Oh, and we helped our industry partner file for a preliminary patent on our design...

bottom of page