Design journal

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

To help us in our further development of our design we chose two of the techniques we learnt about in class these being a Design Structure Matrix or DSM and a Failure Mode Effect Analysis of FMEA.

A FMEA id a table which helps identify possible failure points in a system and describes their severity to help designers to reduce the chances of these potential failures happening and coping with them if they do. It is useful to do this at this stage in the design process as it can identify flaws which can be fixed early and cause less rework, it can be done even earlier but we decided that it was not necessary to do FMEA on different concepts for this project as flaws would easily be able to be fixed due to the projects simple nature.

                           The FMEA identified some areas which could lead to flaws, including the transmitter which if it fails then depending on how the shoe is controlled could mean that the shoe is inoperative.

    The DSM allowed us to identify which elements of the design affected each other and would need to be considered when making changes to a component. One way of solving the dependencies of elements would be to create a standardized interface between two elements which means that the element could be changed as long as it still met and interacted with the other element in the same way.

A key element in our design which had links to most of the other elements was the sole as most of the elements would be placed inside the base of the shoe their design would need to work in with that shape of the sole and the sole would need to have hollow areas to house these elements.

With our 3 initial concepts created we started to prototype them using cardboard, string, hot glue and old shoes. These materials allowed us to do rapid prototypes and evaluate and modify the designs in real-time very cheaply. Using a regular shoe as a base we could prototype elements of the concept that we wanted to get more understanding and clarifications on their functionality. We could prototype 2 of our concepts successfully with the third becoming two hard to make it was decided that this design was unfeasible.

One of our concepts that was feasible used two rotating shafts in a winch like fashion to tighten a series of laces which would be positioned like laces in a normal shoe. We prototyped this by using an old shoe and string which we holt glued onto cardboard strips. The concept worked well however we observed that the foot would have difficulty getting into the shoe if the shoe had no method of opening more than a regular shoe as the heel was kept solid and tongue was still in the way.

                         Out second feasible concept was radically different to a standard shoe and removed that commonly associated laces and lace structure and replaced it with a large padded flap where normal laces would be and another flap that held around the heel of the foot a sting would pull these flaps tight around the user’s foot by way of a winch under the heel. Making a prototype was useful in our development of this concept as we were unsure of how the string should be routed to achieve the desired closing movement. The flaps which we modelled in cardboard needed some modification to work correctly but after that was done the prototype functioned better than we were anticipating.

After we finished prototyping with two successful models built we evaluated them using the system requirements and listed whether they met these requirements to decide which shoe met the brief best

Morph chart

With our user requirements completed and an idea of what type of solution we wanted to create we started to think about how we could solve individual aspects of the problem and the different solutions and parts we could use to create any solution. By drawing these solutions in to a morphological table it would allow us to quickly draw up a range of initial concepts quickly and create concepts that may be completely different to those that we would have otherwise created. Personally, I found it difficult at first to think about specific elements of the system without thinking of a full solution, it became rewarding when I started to think of the various options to solve one individual component of the problem.

After feedback from our lecturer our group decided to modify our SSoN to better fit what we wanted to solve.

 “ People with limited mobility need to be able to put on adequate footwear because they need to protect their feet during daily life ”

 Our new statement uses simpler but more descriptive terms which are less likely to be confused

With our user requirements completed and the SSoN updated, the team moved on to creating the system requirements which detailed the requirements of the system which would allow it to meet our user requirements. This process challenged us to stop thinking about thinking about possible solutions but instead what the requirements of the system are. One major problem started to arise as we talked about the requirements of the system stemming from the fact that we had not yet decided whether our product would tie the laces on regular shoes or if it was a completely new shoe or modification to a regular shoe that meant that the user did not need to tie their laces. We thought initially that we could make this decision later in the design process however to do so we would need to keep our requirements very vague to cater for both types of solution. Requirements that related to the system being worn and walked in had no relevance to a system which sat inside. To solve this problem our team, discuss which type of system we preferred to design and which one would be the best and it was decided that a system that the user wore would be more useful as it allowed the user to put their footwear on and off anywhere they wanted. This system would require us to design a shoe that was durable enough to be worn in different environments. We then created 10 system requirements, these are attributes which system must have to meet our user requirements and would help us in our conceptual design phase to identify which proposed solutions best met the brief. For each system requirements, we created a test criterion this will allow us to verify that the final solution meets the system requirement and gives us targets to design towards. The system requirements and test criterion we came up with are as follows:

To check that the system requirements fitted our user requirements we created a requirements traceability table. We used this table to check that all our systems requirements had a user requirement that they fitted to and that each of our user requirements were represented by at least one system requirement.

31st July and 2nd August- Meeting and Design lab

On Monday, we met to discuss our options for problems and choose our favourite. After much deliberation, we decided that our problem would be ‘putting on footwear for people who add limited bending capabilities or trouble tying laces’. This problem would give our project adequate scope and give our team the chance to incorporate mechanical, electrical and software elements into our design.

In our design lab on Wednesday, we formed our single statement of need or SSoN, and then developed 3 user requirements. This task our team found surprising challenging as we did not want to limit the solution one train of thinking which meant keeping the user requirements open and realising that the user requirements may need to change in the future as our project develops.

26th and 28th Design Lab and Meeting

As I missed my first week of the course I was excited to get into this course, we were given the brief “Design something that will improve the quality of life for people with disability”. The group was challenged with the open nature of the brief and chose to do a brain storm to think about different options for projects.  Among the problems, we came up with, were kitchens designed for non-disabled people not been suitable for a person in a wheel chair, as many cupboards and appliances are out of reach or not easily used from a wheel chair. Intrigued I tried using my kitchen siting in a desk chair and found most the kitchen was unusable without getting out of the chair. So, this would be an interesting topic for our team to solve with many avenues for different solutions.

Other problems included getting into a car and having a shower, both thing many non-disabled people take for granted but can be a real struggle for people with a disability. Many people find opening jars and bottles difficult and this problem is even more difficult for people who only have the use of one hand or have trouble gripping items. A solution to this problem could be marketed to people without a disability which would increase sales and decrease the cost of the product.

When putting on shoes many people don’t stop to think about how difficult the process would be if they could not bend over to tie their shoe laces or simply cannot tie a knot due to decreased fine motor control in their hands. This is a real problem for people living with some disabilities so if our team was to develop a shoe that does not require laces but is still easy to take on and off and stays secure when walking, then it would be useful to a range of people within the disabled community. These shoes could also appeal to people outside the disabled community which in turn would reduce the stigma surrounding disability.