Final Update: Week 10

We had our presentation today! After a long night of working out the kinks and practicing we presented our PowerPoint about the Smart Suit at 8 a.m. today. It was quite early but the presentation went smoothly. Since Air Products sponsored us (thanks!) we left our project so it could be handed off to them. After ten weeks we are very proud of the progress we were able to make. We came in knowing nothing but we learned a lot about electronics, mechanics, and programming. We also learned how crucial the design process is. Engineering isn't just about solving problems, it about solving problems with limited resources.

Quick Update: Week 9/10

This is a quick update right before we have our presentation on Thursday. We did some tests in water over the weekend. Unfortunately we could not use the Drexel high dive, so we had to resort to visiting a friend's house to conduct the tests. The other bad news is that we did not test the entire system when jumping in the pool. Since the waterproof box is not covered under the outside fund, we felt as if it was unnecessary to drill a whole in a box which we would only be using as a proof of concept, only to end up paying for it out of our pockets. But there is good news of course!

The good news is that everything is working pretty well together. As you saw in the previous posts and videos the Smart Suit was functioning well even with the addition of the new bladder and SD card shield. The good news that I want to add for this weekend is that we were able to successfully get data from Artemis jumping in the pool. The following video shows a short jump into a pool, yet when we looked at the data the point of impact stuck out.

Weekly Update: Week 9

With the deadline quickly approaching we have reached our goals that we set in the beginning of the term. As you saw in the Memorial Day update, we had a working SD card shield. We were also able to make the valve on the new bladder connect to the tube from the CO2 canister. As you can see in the following video, that the whole system is integrated and working!



Since we have a SD card we started doing some tests with the device on our bodies. We conducted several tests including walking, jogging, sprinting, and then walking and sprinting on stairs. The following video captures one of the test. Along with the video is a line graph of the acceleration data recorded.




If you compare this data to the data from the graph on the last post (Memorial Day), you can see that there is only one line instead of three. The previous graph had three lines because it was recording the x-, y-, and z-axises. The new graph only has one line because the data from the accelerometer is going through a low-pass filter first.

Quick Update: Memorial Day Weekend

After a week of exams its nice to finally have a break. Luckily some of the things we ordered came, allowing us get some work done. In this quick update I'm just going to talk about the SD Card Shield.

We got the SD Card Shield a week ago but didn't really have time to implement it since we were trying to work on other problems. So this weekend, I sat down and tried to get it working. It was a success! At first it was a pain as usual. But after reading some online documentation (thanks Arduino community!), I was able to get things working. We're using a 64MB sd card to save the accelerometer data on. It might seem small for today's standards but for some plain text its more than enough. I was wondering how the data would look on a graph. With the sd card recording the data from the accelerometer I did some shaking, slow turning, and jumping. The following image shows what the data looked like. It'll be interesting what filtering will do to the graph. But that's for next time!

Oh yea the waterproof case came in! We're really excited to get our hands on it but since none of us are on campus, we'll have to wait till tomorrow.

Weekly Update: Week 8

The majority of the project is complete, and only the last 10% remain. By week nine we want the device within a water proof case for testing in water. In preparation for testing in water, we have been ordering components that we deem are important.

We ordered a SD card shield over the weekend, and I arrived this week. We will use the sd card to log data from the accelerometer when it is being dropped in the water to get a better understanding of what goes on when the device is in the water. From the data, we can also try to optimize when the bladder gets inflated.

Since our original bladder was not meant to keep a person afloat, we ordered a new inflatable bladder. The bladder came in on Monday, but there was some bad news. Not only was it a bit small but it also had 3 different valves for air intake. This would not be feasible. Therefore we ordered a new inflatable bladder. We ordered a new inflatable bladder, ones that are used during snorkeling. It's inexpensive and effective. It is pictured below:

Weekly Update: Week 7

     It's been a busy past week. We finally did a full system integration. Everything is now on one board and the Arduino is being powered by a 9V battery. The Arduino then regulates the power out to the accelerometer and servo motor.

     We are still having trouble making the valve close all the way. It doesn't seem to be the motor that is causing the problem, instead the piece connecting the valve to the motor has some freedom of movement. We did add washers and a nut to help decrease that movement. It only seems to close sometimes, meaning that it is not effective enough of a solution to close the CO2 canister all the way.

     In order to help solve the problem stated above, we decided to buy a larger inflatable bladder. We had planned on buying a larger bladder since the current bladder is not large enough for keeping someone afloat. The new bladder should be able to help bring a person to the surface of the water faster. It will also alleviate the problem with CO2 leaking from the canister. We are using a Y-valve to split the air from the CO2 canister into the two bladders.

     An item we bought recently is a SD card shield. This will allow us to log data from the accelerometer when we conduct tests in the water. We can use this data to further refine our algorithm to help detect free fall and impact more clearly and effectively.

Smart Suit Prototype Build v.2

We have a video of our first test! This is Smart Suit Build v.1

Weekly Update: Week 6

     With the end of our first set of exams and papers we were able to get a lot of work done over the past few days, including the weekend. We have successfully implemented the new mechanical design for turning the CO2 canister with the servo. We also solved the problem of the accelerometer wires disconnecting from the Arduino.

     The battery pack that we ordered last week arrived in the mail on Monday.

     This is the new design for turning the CO2 canister: There is a thin steel shaft that attaches around the CO2 deploy mechanism via a small clevis. This shaft is connected to the armature of the servo. When the servo moves, the CO2 is forced up by the steel shaft and CO2 is released. when the servo moves back to its initial position, the flow of CO2 is stopped and at this point the air bladder will be appropriately filled.

     To fix the disconnection problem with the accelerometer we decided the best way was to reconnect the ribbon cables. We separated the ribbon and stripped the rubber off the end. Then we connected new wires that are better fit to fit as pins. We connected the two wires by soldering them together. On top of that, we taped them tightly with electrical tape to isolate the bare parts of the wire.

     On Monday we continued to test the motor so we could figure out how to turn it to certain positions. We ran into problems trying to figure out where it started, more specifically what it defined as "0."After a long night we called it quits and worked on it on Tuesday. On Tuesday we were more successful. We found a way to successfully make the motor start at one position and then turn to the position we needed it to. The problem was that we misunderstood how the servo was understanding out code.

    Also on Monday, we successfully found a solution to stopping the entire program after the IBS had deployed. After some confusion on how to go about doing this, we simplified the solution to just putting a really long delay.

Weekly Update: Week 5

     We made some more progress over week 5. The pace of our progress did slow down due to some design problems. We got eventually worked though the design problems and are now set to move forward with implementing the designs.

     During the weekend we had designed a mechanical design that would help the motor turn the CO2 canister. We stopped by the Machine Shop on Wednesday to help implement the design. We had thought that using one piece of metal and bending it at the right angles, we would be able to wedge the top of the CO2 release valve between the metal. This would be attached to the motor that would then turn the CO2 canister. After going to the Machine Shop we ran into problems. If we bend the metal too much, the metal would break. This problem forces us to work on a mechanical redesign.

     The design for the electrical components did change a little since we decided to stick with the motor shield since we might add more shields or sensors in the future. We bought a 4 AA battery pack that should easily work with the motor shield and power the servo. The accelerometer continues to have some wire problems. The ribbons keep falling out so we are thinking up a solution for this but haven't thought of something easy and effective yet. But we plan to get the done next week.

Weekly Update: Week 4

It was another productive week which is great news. First I'm going to talk about what tweaks we made to our project, including some decisions we made on the design. Then I'll cover the progress made over the past few days.

Design & Parts:
     During our last lab meeting we had a decision to make. We could either make our own board that would control the voltage to the RC motor or order a Arduino Motor Shield. We decided to go with the latter. The cost difference was only $10 while the potential for problems further down the road were much higher. We ordered the Arduino Motor Shield and it finally came in the mail this week.

 
    Another question we needed to answer was how we were going to power the board, sensor, and motor. After some research we decided to power the components using a 9V battery. In order to do so we needed to order a cable that would allow us to connect the battery to the Arduino. This also came in the mail this week.

     We also bought a small valve tubing to help connect the tubing to the bladder.

     Even with all this progress, there are some design problems still left to solve. One of them was how would we rotate the canister with the balloon. We think we've come up with a solution that should keep the design aspect simple and clean. I'll add another update when we visit the machine shop in a few days.

Weekly Progress:
    Over the past week we've made some progress. We got the Arduino to control the motor. We played around with how the motor is controlled by the Arduino and familiarized ourselves with how it works.

     We also collected data from the accelerometer to see how its effected by movement. All these data points will be used to help the algorithm know when to deploy the bladder. It was just data collection of the accelerometer when its in different positions.

     The final part we worked on was getting the motor to turn when the accelerometer went through certain shocks. We were able to get the motor to turn which was great news. It means that we will be able to release the CO2 from the canister using data readings from the accelerometer.

Future:
     We still need to make some progress on getting the different components to work independently first. We should start integration of the parts in a couple weeks. Our next hurdle is to get the motor to turn the CO2 canister.

Quick Update: Accelerometer Issues

We've run into a problem a few days ago with the data from the accelerometer. It seemed as if the data was corrupted. We previously had tried numerous codes, ones we had done and ones from online resources. The data coming in was always looping between a certain set of numbers. Tilting or moving the accelerometer would not effect the values. We did not know what the problem was so we creased working for the weekend. That was a few days ago. We picked up working on the issue today after a few busy days of coursework. During our previous attempt we could not figure out why the accelerometer data was corrupted. So dedicated part of our time today on trying to figure it out. After numerous attempts of new code, new wiring setup, and readjusting where the ribbon was cut we were unsuccessful in our attempts to solve the problem. Our conclusion is that the accelerometer seems to be damaged in some way and this is not allowing us to continue to work on that end of the project. Our next step to get hold of a new accelerometer and then get back on track.

Weekly Update- It's Been Too Long

A lot has gone on this past week since our last update. This week was spent on the completion of the mechanical as well as electrical design. On Thursday (4/10), the accelerometer got hooked up to the Arduino and had outputted live data. We have also started coding in order for the Arduino to read data from the accelerometer. The mechanical design was finalized that Saturday (4/13). Most of the material and equipment needed was obtained as well such as CO2 cartridges, 1/4" tubing, breadboard, tube coupler, and ideal tube fastener. These parts were partially assembled. Coding for recognizing free fall as well as sudden change in acceleration started Sunday (4/14). But it didn’t go as smoothly as we wanted it to. After about a few hours, the accelerometer’s output data became corrupted. We were bound to encounter technical difficulties during this process.

Today we started the implementation of LEDs to help detect accelerometer data. The design part which twists the valve from the motor was also drawn in CAD.

Here are some photos of this week’s progress.

This past week we've been spending some time thinking on how we would do the mechanical design. It's a little harder than you would think. To release the CO2 canister we need to twist it. So far we've figured out that the Arduino can control a motor (DC or step) and that there has to be a way to twist the CO2 canister through a motor. Here is a picture of what we came up with after some discussion. It looks pretty simple and we're already thinking of improving it.

Smart Suit

Om Mahida's photostream on Flickr.

A Collection of Photos from the Smart Suit Project

Intro to the Smart Suit

 This is the presentation given to Dr.Swoboda on
Problem:

• Big wave surfers struggle to return the surface after a wipeout.
• Example:  http://www.youtube.com/watch?feature=player_detailpage&v=2473_VuXEfw#t=65s
• Commercial fishermen often fall off their boats in stormy seas.
• Coast Guard rescue swimmers often do not wear life vests as they are difficult to swim in.

Solution:

• Inflatable bladder incorporated into the wetsuit allows users to surface faster
• Sensor records data such as acceleration
• Device will process data and recognize emergency situation based on data

Spec Overview:

• Inflatable Bladder System (I.B.S.)
• Accelerometer
• Arduino

 Inflatable Bladder System (I.B.S.)

• CO2 canister inflates I.B.S.
• I.B.S. will activate upon extreme change in sensor readings
• Self-deployable

 Accelerometer

• Records extreme changes in acceleration 

Arduino:

• Information from sensor(s) can trigger I.B.S. during emergency situations 

Advantages:

• Life saving capabilities
• Recreational & professional use
• Freedom of movement vs. traditional life vests