#not-your-typical-engineering-class

Our final Final solution choice: App + Website + Wearable device

App

For the app, we really want the ability for the user to have all the necessary information right with them. We believe the software of the app should have these points below:

1. Patient’s Profile

Patient’s Name, age, diagnosis, details etc

2. Treatment Plan

Medication, outline, diet info, doctor's notes etc

3. Book a GP/Doctor

Being able to request a GP in case of support with treatment plan

4. History

Previous visits, medications, treatment plans, etc

5. Current Medications

Alerts and notifications of the patient, outline of medications to take etc

6. Journal

Questions to answer, keeping up to date with medication and tracking

Website

The website really is an extension of the app. Similarly to the app, the website is more optimized to be used on a pc rather than a phone. Depending on the patient’s needs, they may find the website much more user-friendly than a phone app. The website will consist of the same components as the app above plus a few things: 

1.Home Page/ Dashboard

Photos and user reviews, Patient profile

2.Company Page

Company Description/ About section/ more info in General

3. Doctors Page

All the partnered doctors that signed up to become a legal doctor affiliated with MeDE

Wearable Device

Below is the list of major components of the design 

Screen

Heartbeat monitor

Emergency button

Speaker

LED light

Vibration motor

Home button

Charging port

Transmitter

 Accelerometer

GPS

Battery

Below is a quick sketch of what we envision in our minds when we thought about a wearable device that fits our requirements.

Plan for Future:

Explore existing solutions

Wearable device development

Week 3 brings with it a chance for fresh development! and also a closing deadline for our statement of need…

After our first Tuesday lecture of the week Andy closed up at about 1140 giving us time to have a brief team meeting and to work on finalising our Statement of Need. Its hard to tell if i was in a bad mood, or if i just wanted things to move a bit faster but i must admit i was feeling a little bit negative about the whole project. The problem wasn’t with the content or detail we were exploring or with the members of my group (in fact i am especially happy with my group!); but rather that I felt as though we were behind and we should be looking forward to our next task, User requirements rather than still scrambling around step 1 of our design brief. 

Unfortunately for myself and for the rest of my team, this mood carried through the rest of the week… 

Our Wednesday meeting provided a nice change of venue, this was our chance to discuss what had come of meeting with Mitchell and Monique’s Grandparents, the rest of the teams research and also a chance to finalise our design brief. Monique asked me to take minutes at this meeting and for future meetings, as a point of reference for our design journals. This was a very efficient period where we discussed problem areas from motion (Big and Small), eye sight and how these actually make people feel excluded from everyday society.

One issue in Particular that Monique’s grandparents faced, was actually simple tasks like putting on socks or stockings. This is something that we take for granted as it is a task we undertake 2-3 times a day and i never would have thought of without actually talking to someone struggling with movement. This helped us define our focus to specifically oblique movements such as lifting and reaching. 

As i stated earlier however my mood was not desirable over the week and so when we arrived in the lab to start looking at our user requirements and felt that we were taking steps backwards i started to get a bit frustrated. To reiterate, it was not a problem that i had inherently with any of the team members or with our content but just the threat of falling behind looming over the hour that it took us to make a decision. 1 Hour into the lab we decided to focus on the Sock issue that Monique’s grandparents had, and wrote our statement of need.

“People who find it difficult to put socks on due to pain, strength, co-ordination, or range of motion need a solution to put on and take off socks”

Once we had surpassed the point of choosing our statement of need, everything seemed to ease off and ideas began to flow again, the User requirements came easily even though they are unfinished as of me writing this. I will put more about the user requirements when they are finished in my next blog post.

Overall i am very proud of the way our final product turned out. Was it stressful? Yes. Was it hard at times to understand? Yes. Was it hard not knowing what direction to go? Yes. Was it the most stressful subject? One of my most frustrating subjects this entire year. But having said all that, was this course enjoyable? Yes it was. I did this course with rapt attention, since it pushed me to the boundaries. With Andy Connor advocating for us to think of ideas that not just solved one idea or to be a “widget” that is niche, but multiple ideas that had multiple applications. It was really cool how we could let our minds loose to see what we could come up with.

The difference on how this course was extreme, going from a lecturer standing in front of a massive class showing calculations, to lectures where you would do interactive exercises to break up presentations.

Obviously it was not a perfect experience as there were setbacks and a quite a few there were with the journey being ultimately very very vexing. There were a few instances where people were misinformed which made us behind most of the course even by just a lesson in terms of project work. I admit i was one of them, being so overconfident in completing everything for the first assignment that i relaxed and therefore made the group as a whole delayed. Even when i was gone for 2 and a half weeks for the 2nd half of the semester that again severely delayed our progress. There other times that this course did indeed take its toll.

One thing that i would do differently is to communicate with my group more often to see what they know that i don't know or to tell them what i know that they don't. Also with just as group being on the same page but also making sure to be on top of things. Just getting things that need to be done right no matter what.

Having said nearly everything though, i did indeed relish this course and the  project as a whole.

To finish off this project on a high note, enjoy some dancing below ;)

In between classes most of us set a time to meet up and tried to decide on the disability that we want to tackle. I listed out my suggestions i had, which were:

-MS (Multiple Sclerosis)

-Arthritis

-Parkinson's disease

 From the get-go i could feel that this class would be different from the general, monotonous schedule of some other engineering papers. Partly because our lecturer, Andy, was extremely organised online and seemed enthusiastic to teach. Sending an email out before our first class of where to go and when to be there. A good sign which left a great first impression and got me excited to see what was to come. Also when arriving at class for the first time, Andy made it explicitly clear that this was no ordinary class with the usage of a pretty smart hashtag #not-your-typical-engineering-class.

 The first two hour long class consisted of the introduction of our lecturer, course outline and the such but after that was when the similarities with a normal engineering class. Andy probed and prodded us with simple questions that you would think have simple answers but in reality we really had to think about it. “What is Mechatronics? What is Design?”. He encouraged us to not only think and comprehend what was being asked but also question what was being asked. Andy also did this with the Washington accords for example. This line of thinking eventually led to the idea of creativity or more precisely the limitation of creativity as engineers. Why do engineers have to just be a problem solver? Can’t we make up the problems as well as solve them? The thought process intrigued me as Andy had shown us what this class was intended to do. One of the points was “Challenge your (our?) perceptions of the role of engineers in solving large, complex and open ended problems”.

 The format of this class was different as well because Andy gave us a quick exercise after talking for a bit. We were asked to design 3 bridge concepts around a river separating a mining facility and its respective processing plant.

 These were the concepts i came up with, keeping them rough as was encouraged and as we finished Andy said to us why we couldn't just move the plant to the other side of the river. This was to further push us to be creative.

Hi Andrew

As explained in my email Tumblr is not letting me add photos to my post so i sent you a Pdf version of my work which has the photos as i intended them. please mark that instead

With our design finalised we moved on to evaluating it based on our requirements specification document. Overall the shoe fitted well with all our system requirements and we were proud of how the final design looked.

We did a presentation of the EXO-Shoe to our class and lecturer and explained the features of the shoe and some of our design process that helped shape our design. We then took questions about our design and it was interesting to see what parts of the design people were unclear on and suggestions on how we could improve the design, such as our lecturer Andy’s suggestion of removing the tactile button on the back of the heel and replacing it with an accelerometer program to register when the user made a certain gesture. This would allow the shoe to be completely sealed and would allow us to make the product water proof without the need for ‘O’ rings.

With our DSM and FMEA done and a clearer picture of the concept we worked to flesh out the design and improve on elements that we identified in the FMEA. Among the changes included we removed the transmitter which could connect the shoe to a phone as we felt that this was an unnecessary complication to the design as it required users to have a phone to connect to it and would require them to open an app which would be a lot more complicated than simple open and close buttons. We decide to keep the proposed button under the users heel which would be activated when the users foot is inside the shoe which will close the shoe. To open the shoe, we added a button on the back of the heel which would be unlikely to be accidently knocked and mimics the way some people take off shoes or boots which means that it would not look un natural.

To tighten the strings which close the shoes flaps we chose to use a simple drum winch powered by a worm and spur gear driven by a small 5V DC motor. The advantage of this configuration is that the drum will only move when the motor powers it, meaning that the strings will stay tight when the motor is not powered. This is due to the mechanical qualities of the Worm and Spur gear configuration which only allows motion to be transferred from the worm gear, attached to the motor, to the spur gear, attached to the drum. The configuration of the drum allows the parts of the strings from both sides to be tightened at the same time and balances the moments around the centre axle by creating a couple. This means that the drum and related componentry would be under less stress and therefore have a longer lifespan

Other design decisions we made included:

Sole of shoe made from shock absorbent rubberised plastic

Making all parts replaceable in easy to assemble pieces which could be swapped out if the users feet grow or if a component such as the sole wears out over time

Microcontroller on a custom motor controller board saving space in the shoe and reducing the risk of communication errors between the microcontroller and motor controllers

Making the shoe waterproof to IP 67 this would help our shoe survive in harsh conditions that could be found in the outdoors

3d printed ABS membrane forms the basis of the shoe and allows mounting of pulleys, this gives the shoe greater strength and rigidity compared to fabric alone

On either side of membrane is cushioning material creating a comfortable fit for the user and protects the membrane from external damage

Inner and outer skin for appearance and user comfort. Sewn together to hold the membraned and cushioning in place and to give further strength

Rubber V shape edging on surfaces where the flaps meet, seals shoe for accurate closing and waterproof seal

String non-elastic to hold pieces tight and prolong life expectancy