Final Project with Child Study Center: Hand-washing Aid

My lab partner, Thessaly, and I worked with the Child Studies Center (CSC) at Wellesley College for our final project in Engineering 160. We utilized and built on our experience with mechanical systems like motors and feedback control systems using Arduino micro-controllers to address one of our client's concerns for the CSC. I go through the details of our weekly progress in previous posts but here is a summary.

Project Description:

Preschoolers often either neglect to wash their hands, skip important steps, or wash for less than the recommended amount of time. My lab partner Thessaly and I made an automatic system that captures children’s interest while guiding them through the steps of washing hands using light, visual cues, and movement. When a child stands on a mat that encloses a potentiometer-like conductive sheet, LEDs illuminate pictures of each step for the appropriate amount of time. During the scrubbing step, a motor powers a laser-cut hand that moves back and forth with another hand replica behind it to mimic a hand-washing motion. 

The process takes 48 seconds in total with 5 seconds allocated for pulling up sleeves, 5 s for getting soap, 20 s for scrubbing hands, 8 s for rinsing, 5 s for drying hands, and 5 s allocated for turning off the tap at the end. We chose these time intervals based on some suggestions on google and our personal experience trying to mimic a child washing her hands. 

To make using this system easy for our customers, we included a switch to turn off the entire system if needed (or at night to conserve battery power). We also included a 5 seconds delay after the process ends to allow the child to step off the mat without the the system restarting the process. The LEDs and servo motor keep going until the end of the loop even if a child steps off in the middle of the process. We decided to keep this feature to remind students to continue washing their hands for the appropriate amount of time.

It took us a little over 5 weeks to go from brainstorming, designing, ordering materials, prototyping, communicating with our client (getting feedback) to producing a final product. Below is a summary of what each week looked like.

Week 1: Choosing projects and making first proposals
We went through the list of "problems" that our client from the CSC had discussed with us during a visit to the center. Most of these were areas she believed could be better or make life easier for teachers and the children. We picked two projects for our first proposal.

1) A heart-shaped LED timer that would light up in some pattern (growing heart shape, perhaps) to give the children some sense of the passage of time either during activities or as they wait to be picked up by their parents.

2) A hand-washing aid that would encourage students to wash their hands for longer periods of time by singing to them.

We made the above slides to summarize the problems we wanted to tackle and our proposed products. By the end of the week we had chosen our hand-washing aid idea but planned to incorporate some LEDs that signal the passage of time.


Week 2: Visiting customer and getting some suggestions
We visited the director of the CSC at the center and asked what she thought about our project and how she would like us to change it. She asked us to:
i) incorporate visual cues like ones she already had on her wall but make them more attention grabbing;
ii) include a method through which she can lower the volume or completely shut off the system when they had quiet times, for example. 
iii) make the weight sensor either flexible to be put on a stool or on the ground or make two of them one on each surface to serve the shorter children as well. 
                       
These comments were the basis for our design of the visual cues with LED backgrounds and the mat we made enclosing the velostat that children or teachers can move easily.

Week 3: Ordering materials and reviewing codes to control LEDs and Servos

We sent order requests for a music maker shield, a speaker (that can function on power as small as 0.5 watts), and an 11'' by 11'' square sheet of velostat (a pressure-sensitive conductive sheet). We didn't need to order LEDs, an Arduino Uno micro-controller, delrin for our hand models, wires, or the plastic container we ended up using as the "exoskeleton" of our device because they were available in our lab. 

                                           

We also revisited "Blink" and "Sweep", sketches that we used to control LEDs and servo motors respectively in the past. We attached a cardboard model of a hand to our servo motor to see what the movement would look like.

Week 4: Controlling individual components

We built on the "blink" and "sweep" codes to control mutiple LEDs at once and then optimize the angles the servo motor covers to mimic wrist movement. We also used our music maker to play music from an SD card. We had to name our music file very carefully with strictly 8 characters. We noticed that the sound worked well on headphones but the speakers were too quiet regardless of the volume setting we chose on the code. As we communicated with Amy (via email) to deal with the volume issue, we continued to try to integrate the components in one. This was when we lost our music completely because the servo and the music maker shared the same pin on the arduino micro-controller. 

At the end of the week we left with little hope for our system to work as a unit but the next week was a little more hopeful and productive. We did manage solve certain issues like the fact that we were unknowingly using a continuous servo motor that keeps rotating in ways a human wrist wouldn't. Refer to my blog post for week 4 to see the sketches we used to control our music maker.

Week 5: Putting together components in code and physical model
This was the most productive week during which we were able to make a fully functional code and a more aesthetically appealing physical model. 

At the beginning of the week we visited our client again with a half functional system. She asked us to limit the servo movement to the scrubbing step to better guide the children on when and how long they should scrub their hands. This meant we needed more control over our servo and we figured that using an attach/detach command works best to stop and start the servo when we want it to.

We made a "shell" for our system where we posted a visual cue on the surface we planned to make "the face" and arranged to tape an LED at the back of each (of six) picture representing a step. 

Once we figured out how to better control our servo motor, the servo doesn't interfere with the functionality of our LEDs, and that our circuit as built on the breadboard was correct, we soldered our LEDs to a grounding wire and longer wires that lead to their respective pins. We made sure we would have enough spacing between them to be arranged behind their respective steps. 

We also tested our velostat as a potentiometer and used its dropping values as a person stands on it as a cue for the system to start operating. We insulated our velostat with a yoga mat to make it both safe and comfortable.

We used vinyl to cover up the "brain" of the system that sat behind the visual cues in the plastic container. In the end all our components worked well together.

Here is the final code we used:




I have circled above the very subtly points that gave us a hard time to operate the velostat and the servo motor respectively. Once we figured these out, the task became much easier.

Parts of final product:

                       

Video showing our working hand-washing aid:

Reflections on final design & things I would improve with more time.

1) Our original plan was to include music as the major output to attract children's attention as they wash their hands. But we couldn't get it to work with our servo motor and LEDs on the same Arduino. It also appeared not to work at all after we tried to integrate the components. So with more time, we would definitely work to incorporate music. That would also necessitate a control mechanism that allows the teacher to reduce the volume - another input such as a knob. 

2) We would also optimize the timing better for children of this specific age group and child center by observing them. While adjusting the timing by simply editing numbers in the Arduino sketch and running the code again, we may also find that we need to adapt the system better to the children's habits and reactions. 

I have learned through this process that the client's opinions and feedback are essential in making a product better suited for their needs. There were many points of improvement that only appeared to us after our client mentioned to us and ended up making our product a reality and not just a thought.  

 I have also learned to be patient when working with new materials and took the lesson that one should always have a back up plan. In our case, the lights and hand movement were more of an addition to the music but ended up being the major outputs.

The team posing with scrubby buddy:

Picture Credits: Prof. Amy Banzaert 

Child Study Center Final Project: Week 5 (and a mini Week 6)

The fifth week (and a quarter) was the busiest by far as we tried to finalize our plan, make a fully functional code and physical setup, and make the system aesthetically appealing. In this blog, I will be talking about a range of our experiences this week from hours of debugging our program to discovering the many uses of tape.

Tuesday, April 26th: 
          Presenting Prototype to Client
We took a mode with working LEDs and servo motor but no music to show to our client. We had hoped to include music and a more aesthetically appealing prototype. But with all the program and hardware debugging we had to do last week, the best we could present at the time was a breadboard with 6 LEDs that light up in a sequence and a cardboard hand attached to a servo that moves from the beginning to the end of the hand-washing session.

We got the following feedback from our client that we later incorporated into our improved model:

i) Make large visual cues that would attract the children's attention but also appear as clear guides.

ii) Control the servo motion such that the hand-scrubbing movement it mimics only happens on the corresponding step when we expect the children to scrub their hands. This is important because they would look forward to that step and have a better sense of when to start and stop scrubbing their hands.

iii) Make sure every electrical component is enclosed in water proof material that is an electrical insulator.

Another lesson of the day: Don't forget your batteries when taking a trip to demonstrate things like LEDs and servos. We forgot but luckily some of our more insightful classmates had brought batteries we could borrow.


Later on Tuesday: Oh no! No more music! (Bad news...with a blessing in disguise)
After we got back to class to work on our music component, we learned that incorporating music, although not impossible would be very time consuming. So, unfortunately, we had to drop the idea of having music. But this was also good news because then we could focus on perfecting the rest of our output and input methods rather than dividing our attention between music and the rest and ending up with a product not completed to our satisfaction.

Wednesday, April 27th: This was one productive day!
Since we couldn't trick our clients with nice music anymore, we had to make sure everything else works fantastically and looks a lot more appealing than a bundle of wires on a breadboard. We broke down our tasks as follows:

          Making functional components coexist: 
A major problem with incorporating the servo and the LEDs in one was that the 1 second trial time we set for each LED to light up was less than the minimum time our servo took to "sweep" between certain angles. After some trial and error, we figured that the servo needs at least 3 seconds to oscillate once. This wouldn't be a problem in the final product because we give 20 minutes for the light and the servo alike during the hand scrubbing step.

Another important improvement to our code that allowed us to control the servo motor better was using the detach command to disconnect the servo completely (instead of telling it to go to a certain angle and stay) and only commanding it to attach for the duration of the hand scrubbing step. This is highlighted on line 58 of our final sketch below.

          (Re)testing our velostat as a potentiometer: 
We tried using our velostat as a potentiometer by recycling a code we had worked with earlier this semester. This gave us unrealistic values of resistance such as 0. It also didn't show a consistent difference between the resistance of the pinched velostat and that without any pressure applied. We were able to get better results when we used a very specific way of introducing the velostat as highlighted in line #26 of the final code below.

We used the velostat as an input that reads the resistance due to the pressure applied to the sheet by people standing on it and initiates the system.

This was a much better option compared to a switch or a light sensor which we had considered as alternatives in the event that the velostat didn't work. We only had to cover the sheet of velostat with pieces of yoga mat (on either side of the sheet) that can serve as protection for the sheet, insulation, and comfort.

         Assembly and packaging:
Once we made sure that the all the input and output components work together as planned, we started building a more stable and appealing physical model. We soldered the LEDs appropriately, with all the negative sides connected to a grounding wire, positive sides connected to resistors and longer wires that connect them to their respective pins on the Arduino.

Wiring inside the box

Face of the system

Delrin hands attached to a servo motor

Velostat covered with yoga mat with foot prints to guide children

Switch to control power supply to system

 We made a relatively larger visual cue with six steps, posted this at the bottom of one of our small storage boxes and aligned the LEDs with their respective steps. We drilled holes on the side of the box to attach a switch that interrupts the connection between the battery pack and the Arduino so that our client would have the option of completely turning off the system from the power. We set up the "brain of system" (arduino, battery pack, and LED) to sit in the box. To make sure children wouldn't be too distracted by all the wires inside, we covered the box with colorful vinyl.

We used tape to attach LEDs to their places, to insulate some wires, bind the two long wires that run to the stepping mat, and for aesthetics. Tape does wonders.

Thursday, April 28th: We made the following poster:

Friday, April 29th and Monday, May 2nd: 
And of course we couldn't send cardboard hands to the adventurous land of splashing water. We converted an outline of a child's hand we found in google images (the same one we used to trace our cardboard model) to a Corel file and edited it to fit our setup. We printed two hand replica: one to be glued to the front of the servo and another to be fitted to the body of the servo motor behind the fully visible hand like a piece of a puzzle. We made each hand slightly bigger than 5 inches in length, keeping the proportionality for the rest of the dimensions. We cut out a circle in the middle of the front hand to avoid the bump in the servo motor with a screw and have a larger area of contact for gluing. We replaced the circle we cut out after gluing the rest of the hand. We cut out a rectangle on the back hand to fit over servo motor and used hot glue to secure it further.

Final code used:





Final video with instructions and pretend user:

I will follow up with my reflections on this process on my next blog post. 

Child Study Center Final Project: Week 4

This week, we tried our music shield, our lights, and our servo separately and then attempted to run them simultaneously. While each component worked individually, the combination failed. We figured later that this was because the music maker shield was using the pin we attempted to use for our servo. This means that we either had to use two separate Arduino micro controllers (1 for music only and another for LEDs and a servo motor) or that we had to be extra careful about which pins we used if we were to keep using the same Arduino for all our outputs. Before we hit this hurdle, however, there were a few accomplishments and mini failures we went through.


Soldering the music maker shield:
Because our music maker shield came in pieces, we had to solder the parts according to Adafruit's online instructions. Since solder includes lead, we were careful not to breath in the fume and used a fume extractor whenever we soldered.

We then inserted an SD card with two files of music carefully named to match the format in the code. We had named them incorrectly before this to find that the music doesn't play unless it is named "Tracknnn" where is an integer 0-9. We also needed exactly 8 characters in our name. We connected a headphone to the black port and ran the following code:

The songs played while the serial monitor showed "played." When the music stopped playing, the monitor printed "done playing." Since this worked well, we tried connecting our speaker to the blue ports and ran the code again. While the music played and the serial monitor showed the appropriate status reports, the volume was really low. Circled in the code above is a part that controls the volume. As it is the volume is set to (20,20) and it says that the lower these numbers, the higher the volume. So we ran the code over and over with much lower numbers but still couldn't adjust the volume. 
                                    

We asked for Amy's help at this point and moved on to work on the servo and LEDs.

Servo and LEDs in one:
We used the following code to operate the servo and LEDs together. Because we defined PreviousMillis (the total time that has passed since the program started running) as an integer and not as an unsigned long, we had problems on the second or third rounds of running the system. The value of previousMillis would get stuck and give us only one LED lighting up instead of the expected pattern.

We also had a hard time making the servo stop after a certain amount of time. As we tried to troubleshoot the servo's tendency to never stop running, we learned that we were using a continuous servo motor that keeps increasing its angle with each round. Even as it oscillates back and forth, its net position shifts. This is not ideal for a movement we plan to resemble that of human wrists, because wrists don't keep on rotating infinitely. Once we switched our servo motor to the correct type, we still noticed that the command that tells it to go to a specific position and stay didn't work. Part of our goal for the next week is to work on controlling the servo better.

Lastly, our music maker stopped working after we connected it to our servo. It started reading "done playing music" even when it obviously didn't and we couldn't hear anything from the speakers. This may mean we have erased some data regarding the pins the music maker shield needs to use in order to play music. This could involve adjusting parts of the library and may take lots of time (unrealistic to our timeline), but we have our fingers crossed.

CSC Final Project Week 3

This week, we ordered our materials, identified those available in the lab for us, and started making prototypes. 

The materials we ordered were:

i) A "music maker" shield, an SD card, and a 0.5 W speaker

ii) A sheet of Velostat 

Ordered Materials

i) A music maker shield

Since we wanted music to entertain the children while encouraging them to wash their hands properly, we searched for shields compatible with Arduino Uno that can play recorded music. We found "Adafruit 'Music Maker' MP3 Shield for Arduino w/3W Stereo Amp - v1.0" (shown in the images below) that can take an SD card and play different tracks of music saved in mp3 format. We also ordered the SD that would go with the music maker.

To go with our music maker, we also ordered an 8 Ohm, 0.5 Watts speaker thinking the low power would save us battery life.

Although this speaker looked tiny and exposed (without a case), we believed it was appropriate for a project of our scale and budget. We also planned to either build a container for it or mount it higher up to prevent children from splashing water on it. 

ii) An 11'' by 11'' Pressure-Sensitive Conductive Sheet/Velostat

We had originally planned to use a force sensor (force plate) that reads the weight of the person standing on it and allow us to only activate the actuator if a child (under a certain weight) stands on it. However, we couldn't find any force plates within our budget and of the appropriate size.

First, we settled for a button under a hard lamina that would push the button as a person stands on it. But since this would involve building a platform that is both stable and effective in pushing the button even if the child stands slightly beside the button, we went with Amy's suggestion of a Velostat. 

A velostat is a sheet of material whose electric resistance decreases when pinched. This allows us to put conductive wires on either side of the sheet and have the sheet act as a poor conductor when relaxed and a better conductor (low resistance) when stood on. This, if it works, would be a cheap and convenient input method for our design. 

This is what a sheet of Velostat looks like

Early Prototyping

We started our prototype by reviewing and building on some of the Arduino exercises we had done before. 

We built on the "Blink" example from the Arduino program to control first one and then multiple LEDs. This prepared us to to set up the LEDs that would shine at specific times behind each instructional picture to help students focus on the appropriate step of hand washing at a given time. 

We also revisited our "Sweep" example with servos and adjusted the angles of rotation of the servo motors to resemble a more realistic wrist rotation. We cut out cardboard and foam board models of tiny hands (almost real-life-sized models of a child's hands) and taped them to the servo to simulate moving hands, which when put next to each other look like they're washing. 

First, we had attached a servo to each hand and oriented the hands such that they face perpendicular to the wall. Later, Amy suggested we use a servo on one hand and keep the other stationary. That way, we can orient the hands better for visibility, and minimize power consumption by only using one servo. The relative motion between the hands would still make them look like they are scrubbing/washing.

Overall, this week was spent ordering and trying components of our design for functionality. We were also able to solder parts of our music maker shield in preparation to use it the next week. 

CSC Final Project: Week 2

This week, we visited the Child Study Center again to observe the children washing their hands and introduce our plan to Becky, the director of the center. While we got some constructive comment from Becky on our rough proposal, we couldn't observe the children washing their hands due to a temporary problem with the tap water. 

The importance of customer feedback/suggestions and adapting our model to the existing setup

As a reminder, our original idea was to help 2 to 4 year olds wash their hands more effectively and for long enough by building a feedback control system that would detect the weight of a child in front of the sink and activates three outputs:

i) a voice that encourages them to wash their hands followed by a shong about washing hands

ii) a row of LEDs that resemble the "loading..." bar and signal the passage of time

iii) Small cutouts of hands attached to servos that move back and forth resembling the motion of washing hands. 

Becky told us that the idea sounds doable but added a few tips to better serve the center's needs and interests. Here are some of the features she recommended:

i) A way to either shut off or reduce volume for "quiet times" in the building

We plan to build a potentiometer into our system to give the teachers at the center this control.

ii) To incorporate pictures (like they have in front of the sinks at the center) into the "loading..." LEDs. This is important because the children tend to forget the visual cue exists after they get used to it and they need something to draw their attention. 

We plan to enlarge their visual cues (figure 1) and orient the LEDs such that each LED stands above or behind a cartoon that describes a certain procedure and lights up only when it is time for the child to be that particular stage of washing their hands.

Figure 1: Existing visual cue at the center

iii) To make the weight sensor or button we would use to sense the presence of a child in front of the sink flexible to sit on a stool or on the ground. Some kids are shorter than others and need to stand on a stool to reach the sink. By either building two buttons as sensors (one on the stool one on the floor) or by building one that can be moved to either level, we will serve children of all heights.

Figure 2: Stools for shorter children at the center

We incorporated these tips to our plan before we formally presented our idea to the client on Friday, April 8th. 

MATLAB: Thermal Systems Part 2

In this section we applied our experience with the first part of our thermal systems lesson to a real thermal system. We used a serial port to pass information between our MATLAB code and a circuit with a heater and a temperature sensor. 

Objectives:
1) Simulate temperature vs time graphs and compare them to the data from the heater
2) Calculate values of Rth and C such that our temperature approaches 340 K within 300 seconds
3) Modify our code into a bang-bang control and compare the simulation to data
4) Modify our code into a proportional control and compare the simulation with data

1) Simulating the temperature vs time graph

We ran the given heatsim.m script:

Once we wrote these separate codes, we thought it would be easier to compare the graphs if they were on the same axes and wrote the following to "unite" them:

Data from heater

Comparing simulation with data from heater

As you can see from the graph, the simulation fits the experimental data well but not perfectly. Perhaps, with more time, the curves may have deviated from each other more.

 2) Calculating values of Rth (resistance) and C (heat capacity) such that our temperature approaches 340 K within 300 second:

We used the relations: Rth = deltaT/P and C = Power/(delT/dt) from the last part of thermal systems to find C and Rth. We found Rth = 34.076 K / 6.5W = 5.24 K/W, and C = 6.5 W / (0.33022 K/s) = 19.68 J/K.

It is these values we used to simulate the above red curve.

C and Rth are related by τ = Rth*C, where τ is the time it takes for a system to reach ~63.2% of its final asymptotic value. To find τ we took 63.2% of the difference between the maximum and minimum temperature of the system recorded. This value was only 10 units away from the value we found by multiplying the thermal resistance and heat capacity. That means the experimental data and the model used for simulation match up reasonably well.

3) Bang-bang control simulation and experimental data
We modified our heatsim.m script to include a for loop that creates a vector and made the power supplied dependent on whether or not the temperature read reaches 340 K. If the desired temperature is reached or surpassed we set power to zero, else we set it to 100% of its maximum value.

This yielded the following simulation graph:

For the experimental part of our bang-bang control objective, we modified the "test thermal" script to included a similar if/else statement to turn power on or off depending on temperature readings. 

This yielded the following experimental data:

While the simulation and the experimental graph both level off and oscillate with a very small amplitude at T ~ 340 K, the experimental curve reaches the temperature much faster. This could be because our C and Rth values were from a different day and possibly different heater. Ideally, we would use controlled conditions to make the simulation match the experiment perfectly.

4) Proportional control simulation and data:
Here, we made power supplied to the heater linearly dependent on the error (how far the current reading is from the desired value). The larger the error, the more power the system we apply to make sure the "coffee" heats up fast at the beginning, when it is cooler, but the rate of change of temperature slows down as the temperature approaches 340 K. We tried this with three values of K: 0.05, 0.2, and 0.5. While 0.5 gave the closest value of temperature to 340 K within the 300 seconds limit, it was still significantly lower than we wished. So, we optimized our parameters to reach 340 K faster. We changed the power expression to 5 + error*K to boost up the power but limited the upper bound to 6.5 so it never exceeds the maximum power the heater can supply. This worked better and gave us a graph with 340 K as an asymptotic value.

Here are the sketches and simulations:

K = 0.05

K = 0.2

When we set P = 5 + error*k, in the form power = constant + error * (proportionality constant), the graphs approach 340 K much better. This is safe because we still restrict power from exceeding 6.5 W, the maximum value, and it gets the task done better.

K = 0.5

K = 0.2

Notice, in both cases, the larger K values work better in terms of reaching 340 K.

We then modified our "test thermal" script again to incorporate proportional control. Since the power we defined was actually some percentage of the setpower command that actually communicates with the heater, we created a new variable called percentpower = power/6.5*100 and plugged it into the setpower command.

Here are the script and graph:

The proportional control simulation seem to model the experimental data curve better because the significant decrease in slope happens at around 100 seconds in both the simulations and in the experimental data. But (unsurprisingly) the experimental data looks a lot less smooth. I attribute this to the inconsistent ambient temperature and draft in the room.

My take on this:
As a physicist-to-be it bugs me a lot not being able to do this experiment under controlled conditions like the same day, with constant ambient temperature and using the same heater. However, we had to collect the first half of the data on one day and the rest on another and we had to switch between heaters while we waited for one to cool. This made the initial temperature inconsistent between different experiments. But on the bright side, we still managed to accomplish the goal of modeling and observing the experimental results of thermal systems with and without control systems.