Thursday, May 14, 2015

Final Project: The Final Post

Here is a description of our project, which includes highlights from all previous posts:



Our device is intended to be a teaching device in the bathroom, showing proper steps with adequate timing of hand washing. A few things we kept in mind while designing the project include the needs of child development, the versatility of the device for other similar uses, accessibility/ease to change batteries and other parts inside, and the environment where the device will be installed (water proof ability).

The device consists of a box made of Delrin that supports and contains all the structure and electronics of the device. The top is open for easy access of the battery box and Arduino, since versatility and flexibility are key to our client. The sides are covered by plastic wrap, which allows the child to observe what happens inside the device for curiosity reasons but also prevents water from coming in. The visual demonstration is secured in the front by velcro.

The input of the device comes from the ultrasonic sensor at the bottom of the device facing forward. It is secured by screws, lego, and velcro. It reads whether there are objects in front of it every 0.1 second. Once it detects a person at the sink, it would re-confirm after 4.5 seconds to make sure the person is still at the place, so that people walking by would not trigger the washing process.

The output of the device includes a servo and an LED. The servo starts turning after the 5-second reconfirmation. It would rotate 16 degrees for each step of the washing process. This circular movement is translated into a linear motion by a 1:5 gear train (8-tooth and 40-tooth gears) attached to a chain, which moves the indicator by around 2''. The LED blinks when the ultrasonic sensor detects someone in front of the device. It will then remain on for the whole process once the sensor re-confirms the person is still present. This helps troubleshoot. In case the indicator does not move, we can know if it's the problem with the mechanics of the gear train, or it is the sensor that fails to detect.

Here is a video of how our project works. Note that the first hand wave represents a person walking by but not stopping.

Here is a picture of us with our project!

Reflections


To be honest, our final product is not what I'm most satisfied with for the semester. Nonetheless, I still learned many things.

The first lesson we learned is reality! As I mentioned in my first post, I was very obsessed with the idea of using a tree the turns green as the children wash their hands for long enough. Now that I think about it, while it is a smart and simplistic idea, it is certainly not as effective as our current model for our purpose, which is to teach the children. We also initially wanted to include a sensor that detects whether the water is turned off. This turned out to be too much to be done given the time we have. There are numerous instances when we had to adjust our goals based on the reality (even with time or material available). I think this is the most interesting and challenging part about engineering (and the most different from Math, my major)! I can dream big in ideal situations, but I also must be flexible in reality. This is certainly a change for me, since I am the kind of person who likes to plan things out perfectly. I would say that my skill with planning ahead allowed me to come up with multiple alternatives before I start building things, and makes it easier for me to be flexible. However, I cannot always predict everything. My experience with engineering so far really taught me how to deal with unpredictable circumstances calmly and with patience.

What I appreciate the most about this project is how we got to use almost everything we learned this semester. We incorporated laser cutting, lego, Arduino, sensors from Sciborg, as well as some soldering, filing, cutting, and heat staking. I was very pleasantly surprised how well we remembered each technique at the right time to apply to different parts. This project definitely created a chance for us to understand the materials we've studied in a holistic view.

Another thing we really learned is how important details are. Our project is not the most complicated among all, but it was by no means done in one try. There were so many details we had to pay attention to, such as what paper to use for the visual, what color to use for the indicator, what is the exact measurement between the axles, etc.

In terms of the product itself, there are a couple things to improve on, mainly the aesthetics.
I would like to build a complete box without the top. The front would have one slit open for the indicator to move. The visual would be secured by velcro to the rest of it. I would like two sides with big windows that allow children to watch the inside of the device. These windows can be sealed by plastic wraps from the inside. We can also color the box or have the children color the box, so it looks more than a plain white box.
I also feel like our project is not the most complicated. Granted, it does everything required, but I keep wonder if there are other things we could add to it. We could potentially add some sort of reward after the child successfully finishes the cycle. We could try to figure out sensing the water on and off. (This may be easier with sinks that have handles as opposed to a knob.)

Sunday, May 10, 2015

Final Project Part 3

Here is where we were at:
  • Fixed the servo
  • Have the code written out (though numbers are not exact)
  • Have the supporting structure ready in SolidWork
  • Indicator installed
This blog post covers:
  • Re-visit CSC to find out the correct values for the code
  • Finish the supporting structure
  • Finish the visual demonstration
  • Revise the code
  • Install the devices
  • Any other touch ups

Visiting the CSC


We had three main tasks visiting the CSC. First is to double-check with Becky to make sure that our visual makes sense. Next is to observe how children wash their hands to make sure that the time we used for each step makes sense. Our last objective is to do some reading with the sensor to find the correct values for our code.
The first is with the visual. At this point, we made two versions. The only difference is whether the child needs to turn off water before they get soap and rub their hands. Becky suggested that we omit turning off water, because it would be a lot for the children to do. Also, health code also tells us that the step should be omitted.
Next is watching the children. I must admit that I'm most excited about this part. It turned out that while everyone knows that they should use soap and then rinse off the soap, we did not observe any child that follows the proper steps and use the correct timing. In fact, they all washed their hands incredibly quickly. No one exceeded 20 seconds while most finished at around 10 seconds. It's no surprise that our device would be helpful! However, we still want to make sure that we give the children enough time for each step, because they might have been rushing because they were nervous to "show" us how children wash their hands. Also, we observed that some children may miss the soap or the tap at the first try.
Our last task was to measure the width of the counter and to get some reading from the ultrasonic sensor. The counter is 20.25'' wide and the reading one gets when someone is pressing against the counter is around 25-28. 
**During this time, a child became very interested in our installation. Becky told us that he was very interested in how things work. This became important when we finished the rest of the installation.

The Supporting Structure


Even though our box could not be simpler, we still encountered some problem. First is that the front wall is too close to the edge. Our idea of installing the visual is to stick it against the edge of the bottom. Our first drawing had the front wall too close to the edge and the visual would run into the gear train. We re-measured our dimension and moved up the slots for the front wall by 2cm.
Before

After
Another problem was that the pegs on our walls for heat staking were too short. This was very surprising since the measurement worked fine for the indicator, which is what we used as our test piece. But since it didn't work on the bigger pieces, we had to fix the measurement again, elongating the pegs.
Before
After
After we finished the box, we then installed the gear train with bushings and the servo with hot glue.
Installation of the servo.
We initially wanted to use the super glue we used before to secure the servo. However, that glue takes a long time to dry. We do not have the luxury to set the installation aside for hours to dry, since we must make sure that our servo stay horizontally so that the axles can go through, and that the input gear must meet the output gear correctly. We then used hot glue, which secures just as well and dries much faster.

The Visual Demonstration


After our visit to the CSC, we decided on the 7-step hand-washing demonstration with each picture having the width of 2''. Each picture is outlined with thick black line to avoid confusion. The strip is in two lines in Word because we could not fit the whole strip in one piece of paper.
Now keeping in mind that we want everything to be as water proof as possible, we decided to laminate the picture. First we wanted to use card stock because it is thicker and stiffer. It turned out that printing color on the card stock we have with the printer at the Science Library, the quality is very bad. We then thought we can print the picture on regular paper, and back it with card stock. However, when we laminated the strip, it turned out that the material is too thick, and the laminate would not melt properly to seal the paper in. We eventually had to settle with visual on a regular piece of paper and then laminated. This turned out to be fine, since the lamination makes the paper thicker and stiff enough to stand up straight. 

The Code


Here is our final code.

There are a few changes in this code. 

First of all, for all numbers in the code: 
- We changed the code into a 7-step process since we initially wrote it in 8. We put in the correct value for the sensor and the delays for each step. 
- Recall that our reading was from 25-28 when someone is right against the counter. Here we decided to use 30, in case the counter is wet and the child does not want to press against the counter. Also in case, for some reason, the child is not standing right in front of the sensor. 
- For each step, although we noticed that most children do them fairly quickly, we still left enough time for the children to make mistakes. We would rather to have them wait for a few seconds than to panic because they cannot catch up with the machine.
- Based on our installation of the servo, the position of the servo in fact should start at the higher number and then goes down. We also repositioned the chain at this point to make sure that when the servo starts at 175, it starts at the center of the first picture. It turned out that from 175 --> 10, the indicator would move perfectly from the center of the first picture to the center of the last picture.

Second is that we added another if loop in the while loop for when the sensor detects someone. Initially we thought that if the sensor detects a value greater than 30 during the while (value <30) loop, it will jump out of the loop and go to while (value>30). However that did not happen. Since we want to make sure that the sensor would double-check if the person is still present (so that the process doesn't get activated each time someone walks by), we added the if loop.

Third is that we added an LED to the process. Since each step of the hand washing process takes a few seconds, it may be confusing to know whether the process is correctly activated. We decided to add an LED that would blink when it first detects someone and then stay on after the confirmation of person during the rest of the process (i.e. after the first step). We will explain the installation of the LED in the next section.

Installation of devices


The bones of the structure is already explained at the supporting structure section. We will explain the meat and the guts of our device here.
The visual
Since we want our teaching device to be as versatile as possible, we decided to use velcro to secure the visual, so that the teacher can easily change the picture to any other linear demonstration. It may require some changes in the code for timing purposes, but such can be easily done in our lab.

The guts
Initially we wanted the battery box to be one of the sides, but it turned out not to be the most ideal, because the box has to be close to the Arduino, which has to be close to the servo. If the battery box were on the side, all of the weight of the device would concentrate on one end. We then put it in between the two walls where the battery box, in fact, fits perfectly. The box would not shift easily unless shaken rigorously. However, it is still very easy to take out, in case the batteries die.
Next to the battery box was the Arduino. Since they are relatively expensive, we cannot just glue it on the Delrin. Instead, is it screwed onto lego pieces which are then secured on the Delrin by velcro. One can easily take out the Arduino to upload any new program.
Then we have the protoboard. It is the closest to the edge, because we also need to connect it to the ultrasonic sensor, which is below the bottom of the box. It also connects to the servo and the LED. It sticks on the Delrin with the sticky back that it comes with.
The Servo
This is already explained in the supporting structure section.
The Sensor
The sensor is right below the visuals, screwed onto a lego piece, which is also secured onto the Delrin with velcro. Note that we cut a window from the laminate so that the sensor would not confuse it with a person.
The window is not super visible because the laminate is transparent, but it is there! Also, it looks like the laminate on the top is in the way, but this is only because the picture was taken from above.
The LED
We soldered the red LED we used in class with wires and then secured it with electric tape at the center in the back of the front wall. The light bulb is visible, but the wiring is protected from water.

Additional Touch-ups


We colored our sensor black so that it is not distracting but still visible. We left the top open for easy access to the guts. We do not worry much about water getting into the device from the top since it is very unlikely that the children can splash water into the guts from the top. Here it's more important to allow accessibility.
To put up the device, we decided to use velcro in the back. Since the axle sticks out a tiny bit, we used some velcro command strip for thickness, and then added the regular velcro on the top. There are four command strips on the left because that is where most of the weight is. We actually have two long strips velcro. The other strip is in the box along with extra command strips for the teacher to use when installing in the bathroom.

The side was the most troublesome part. We did not want to close it, especially after seeing the boy who really wanted to know how things work. However, we are a little concerned about water getting into the side. Since we did not have much time, we decided to use plastic wrap. Clearly, this was not the prettiest design, but it does the job. If we had more time, we probably would have built a side with a window.


Here is our final product.


Friday, May 1, 2015

Sciborg Follow the Line

I must admit that this project was the hardest but also the most fun to do. In this exercise, we were asked to use a sensor, which detects the brightness of the material in front of it, to follow a white line on a brown cardboard. 

The first thing we did was to understand how the sensor works.
This code allows us to see the reading from the sensor. Having the red LED on is very helpful in terms of understanding what part of the board the sensor is detecting. We thus did some testing with the sensor and found the reading of each region. We then attempted to write our first code.
Note there is a typo in the second while() statement, it should be while (currentMills > 40500)

Our first attempt actually does not include the second "while()" statement. It makes the car go straight when it reads white, which has a value smaller than 550. It also makes the car turn right when it reads off white. We quickly realized that the code only worked before the Sciborg hit a left turn toward the end of the course. It would turn in a circle, then continue with the course. We soon realized that this became the biggest challenge of the project. 

Our first try to fix the problem was to time Sciborg. We figured that it would hit the left turn after about 20 seconds, so we added the second "while()" in our code after it moves along the course for 20 seconds. The second while() makes the Sciborg turn left when it reads off white. Note that we also added a 20 second delay at the beginning so we would have time to bring the Sciborg to the course and would be able to know when it starts exactly. However, this code requires too much precision with timing and fails very quickly.

Then it was clear that we would need to write something that would allow the Sciborg to turn left and right at any time. This would require out code to include both left turn and right turn at some point. Our next try was to ask the Sciborg to move straight when it's on white, turn right when it's half off white, and turn left when it's completely off white.

We've learned very early that the Sciborg does not actually go straight. This means that when it is asked to go straight. This results in that the Sciborg goes off course very easily when it reaches white. We were hoping that the code would compensate that by asking the Sciborg to turn back. Ideally, the Sciborg would turn right first when it reads partially off white (570 < value < 620). If it were indeed on the left side of the course, it would go back to the white. If it were on the right side of the course, it would read completely off white (value > 620), it would realize that it is not turning toward the correct direction and turn to the left, which brings the Sciborg back to the line. This became very troublesome along the course. Because the real world is not the ideal world, the Sciborg cannot make such sharp turns. Regardless how much we try to straighten up the front wheel or to make it looser, it would get stuck and stagger. This was clearly a dead end, so we decided to try another approach.

(*Note that at this point, we switched the orientation of the car. So a positive power makes the wheel goes forward.)

This new idea was to do a sweeping motion. One of the problems with the previous code was that if the Sciborg detects partially off white, it may spend so little time on that region that the sensor wouldn't have time to read and turn. As a result, we only wanted two ranges in the new code. The idea is that when the Sciborg is more than half off white, it will start to turn to the left for a bit and then to the right. If at any point the Sciborg hits white, it will go straight. In fact, our initial idea was to let the Sciborg do a small sweep followed by a big sweep, which is supposed to help the Sciborg at the turn. I could not figure out how to include two different intervals in this code and thus had to only do small sweeps. We also modified the speed, hoping that with more power, the Sciborg could overcome the friction that made it stumble. 

This, again, failed sadly. First of all, I realized that it was not the most helpful to use intervals. The initial idea was that using intervals would avoid delay, which would prevent the Sciborg from noticing its reaching white. However, since the interval is equal, the Sciborg would turn right and come back to the original position, as opposed to turning to the left and check if there is white on the left. Another problem was to set what startMillis is. We wanted it to be the reading at the moment the sensor detects off-white. This command did not work. Now that I look back, I realized that in the screenshot, "startMillis = millis();" should be in the while (value > 585) condition, as opposed to before. We made the change later and forgot to take the screenshot. Perhaps, changing that would have solved the problem with setting startMillis. However, the turning time was still a problem. In addition, the Sciborg still could not turn very smoothly.

At this point, we were pretty frustrated. It seems like Light_Sensor_Follow2 was the code that makes the most sense. The only probably we had was, well, reality. "Why can't the Sciborg go straight!" We screamed. Then we thought, wait a second, what if we just don't let it go straight then. And voila, we have a new brilliant idea.
The idea was to make the Sciborg turn right when it's more than half on white (value < 590) and turn left when it's more than half off white (value > 590). Note that the Sciborg must be placed on the right of the line for this code to work. Essentially, our Sciborg was following the edge of the line, as opposed to the center of the line. Now, since we do not have a go straight command, we must make sure that there is a velocity vector in the forward direction. The sharpness of the turn is only controlled by the difference between the power of the two wheels, so we just added some positive integer to both wheels. Another problem we encountered was that the Sciborg cannot make the first right turn because it is a relatively sharp turn. We changed the value and the delay in the code, but it did not work until we realized that all we had to do was to let the left turn and right turns of the Sciborg greater that the turn on the line. By switching the angle of the turn, our Sciborg followed the line beautifully. (Granted it does look like it's spasming a little, but it moves forward relatively quickly.)

Our next task was to use proportional control. Here is the code.


The gains of the two wheels are slightly different, because they have different powers (in reality). We calculated the gain with the following equation for m1:
  560*k+b=-40
  620*k+b=220
Note that 590 is the mid point between the value range, so that when the value hits 590, it would change the direction in which the Sciborg moves. We also needed the "b" in the equation, because the domain and range of the function do not start at 0. Similar equation goes for m2 with change on the right side of the equation based on our bang-bang control.

(*Unfortunately, we lost our video, but since we had to move forward with our final project, we did not have time to re-film this.)



Thursday, April 30, 2015

Final Project Part 2

A recap of where we are:

  1. Have the design, including shapes and dimensions.
  2. Have the correct gear train.
  3. Started attaching the servo.


Here is what this blog post encompasses:

  1. Connect the servo to the gear train.
  2. Writing the code.
  3. Constructing the wiring with Arduino, the sensor, and the servo.
  4. Building the supporting structure in SolidWork.

Since we were working on several things at the same time, it would be confusing to document things in a chronological order. I organized our process in this blog post to make it easier to understand. Bear in mind that not everything is in chronological order. This blog post is not intensively long in terms of text, because most of our time we spent on constructing structures, code writing, and other things that are pretty straight-forward. We also started creating our visual, but since we did not finish completely and have questions to ask Becky, this process will be recorded in future blog posts.

Servo

Wired Servo

Glued Servo
Side view
It turned out that securing the servo with a piano wire was not the best way to secure the gear to the servo. It is mildly wobbly and the wire is sort of in the way when the servo turns. We tried a couple alternatives, including removing the white top of the servo and inserting the gear to the axle of the motor. Eventually we decided on using glue. It was not the cleanest method, as some of the glue dripped down and almost glued the gear to the body of the motor. After we trimmed off excess glue, however, the gear on servo worked perfectly. (Sorry for destroying a servo!)

The Code

Now, the code really isn't the hardest thing to write. The basic idea is that we want the sensor to read data the whole day. Once it detects someone, it would start the program. After the first step, the sensor would re-detect, making sure that the person is still there, and continue the process. The servo will move a set amount of distance after a certain amount of time. Once the whole process is finished, it will rewind to the original position and start to sense people again. Here is the code.

There are a couple things to mention here. The number we used for value and for position are arbitrary numbers I put down as fillers. Ideally, the number in the while loops for value would be the reading for when someone is standing at the sink to wash hands. The position value should correspond to the number that would make the servo start at the first picture and end at the last. The direction may also reverse, since we are not completely sure which direction it goes yet. The amount of time each step takes is also not definite. We obtained the number by doubling the time that Meredith uses to VERY slowly wash her hands. In this code, we assumed that there were 8 steps in total.

The Arduino

Since our device only requires a sensor as an input and the servo motor as an output, we did not need extensive wiring. In fact, we used the smallest protoboard. 

The wiring does seem a little confusing from afar, but it's actually very clear and simple. The whites connects to ports that delivers the command from the code to the devices or vice versa. The greens connects to power sources. The blues connect to ground.

The Supporting Structure

We want to make a box from Delrin to support the whole structure. Things we keep in mind while designing the structure include sturdiness, lightness, and accessibility. The gear train can be secured by two axles through the vertical walls of the Delrin, while the bottom will secure the vertical walls as well as electronic devices. We have considered a bottomless box for lightness, but it would decrease the sturdiness significantly. We also need to secure the servo motor nicely, so that when the motor moves, all of the motion should go toward the gear train, as opposed to moving itself around in the box. We thus used some foam core to find the right measurement.
We want to cut a slit through the front wall for the servo to be secured. This measurement was the most important, since it must be precise to motorize the output gears with the right amount of movement. We eventually decided on a slit that is 0.6 cm wide and 2cm above the hole for the axle. 

As for securing, we decided that heat staking would be the best method for all connections, since it is permanent and steady. For our device, sturdiness is favored over reversibility. We also do not need smooth surface, since the device will be hung on a wall, not touching any surface. Here are our drawings in SolidWork.
Bottom. Note the missing corner is a mistake. We did not print a bottom with a missing corner.
Side walls. The two walls have the same shape.
Note that we actually use two walls to secure the gear train, because one wall would fail to hold the gear train due to the heavy front. We also wanted to put the electronic devices in between the two walls so that water would not affect them. The two walls will be exactly the same to ensure that everything fits correctly. We did not make the side because we wanted the battery box to be one side and have an open side on the other end for easy access, in case we need to change the code or the wiring. For lightness reason, we also chose the 1/8'' Delrin.

We also drew our indicator.
Rests on the chain.
Indicate steps.
The indicator is also secured by heat staking. It also serves as a test piece for the heat staking for walls and bottoms. We were able to print the indicator pieces out and to assemble them.
The length for heat staking is perfect. When we were testing the indicator on the chain, we realized that it would not stay perfectly still. We thus glued it to the chain to maintain precision.

Monday, April 20, 2015

Final Project Part 1

I was very excited when we were assigned to work on the project to instruct proper hand-washing, because I was very excited about my idea of making trees that would turn green. However, I was very quickly told that such an idea may not be applicable to the age group that we will be working with and that we should come up with a more direct visual to cue the children. Since our focus is the ensure what we make fits our "clients'" needs, we then sadly abandoned our tree design and decided to come up with a new visual demonstration, which, as a result, became the focus of our first brainstorm.

We came up with a few ideas. Based on all the materials we have used in class, we already figured that a servo motor would be the easiest to use for our purpose, since we can have very precise control over it. Another prerequisite for the visuals is that we clearly should not use any text, since the children most likely not be able to read.
After some reorganization and summarization, our visual designs all fall into these main ideas.

Brainstorm - Visuals

The first type resembles a clock.

Our idea is to have a circle sectioned, with each section containing pictures of the proper steps of washing hands (like a carnival wheel!). There would be an indicator to indicate which step the child should be doing. We considered using a frame to highlight, an arrow to point, and/or an LED that indicates the current step. We can either rotate the disk of pictures or the indicator. This would be the easiest visual to install with servo, since it requires a circular motion which the servo already has.

The second type is a linear model.

This idea would require a strip of pictures showing the steps of proper hand-washing. Similarly, the indicator could be a frame, an arrow, or an LED. We can either motorize the indicator or the strip itself. This visual would require a gear train that transforms circular motion to a linear motion.

Our third one is a little different from the previous designs. It involves indicators showing what objects near the sink should be used.
The idea is that we would have arrows with lights (or other form of indication) light up when certain objects, for example, the soap or the tap, should be used at the proper step.

With some brief deliberation, it was not hard to eliminate the third type of visual. It is not very direct and can be confusing even for adults. Plus we cannot demonstrate what the child should do exactly and not every step can be demonstrated in such manner (e.g. rubbing would be very hard to demonstrate). At this point we were relatively happy with the types of visuals we have, even though they are not the most creative or sophisticated things one can ever imagine of. We of course would have loved to come up with more visuals, but due to the need of our client, and based on some information regarding child development we received from Professor Banzaert, it was clear that all we needed was a simple and direct visual with pictures. That is what works the best for children at a young age.

Brainstorm - Indicator

Now that we have an idea of the core of our project, we decided to spend more time on the details. As said before, the three major ways of visual stimuli are frame, arrow, and light. Here are some comments we made about each stimulus:

1. Frame: 

the frame is a very strong indication that definitely draws attention to the current step. However, it also blocks part of the pictures next to the current step. We are unsure about how important it is for the children to see the other steps, but it would certainly be helpful if the children can do so.

2. Arrow: 

the arrow is a very typical indicator which would be helpful for the children to understand. However, it is also smaller. The color and thickness of the arrow is very important so that it would not just blend in with the back ground.

3. Light: 

the light could be a visible light bulb, or it could be back light. The light bulb is very direct and visible, but we are worried that it may distract the children. The back light, while not distracting, on the other hand, may not be as easily understood and may not be as obvious in a well-lit room during the day as the bath room is at CSC. The back light may also make it harder to find materials for the front part of the visual, since we will be printing out pictures.
While these are our thoughts, we would need help from the professional staff to decide on what would be the most helpful for the children.

Brainstorm - Sensor

Another important part of our project is the sensor. This is the feedback and control part. Here we have a few things to pay attention to.

  • We want to make sure that we can sense the child in some way when they come and wash their hands without mistaking people who walk by.
  • We need to pay attention to the installation so that it is water proof. This includes the device as well as the wires.

1. Type of sensor:

What we have worked so far that are applicable to our project include the ultrasonic sensor and the touch sensor.

  • Ultrasonic: This sensor is the most intuitive one to use. Our only concern came from the fact that our sensor had some connection issues when we used it with Sciborg. In a far distance, the ultrasonic sensor is also very sensitive and the range it detects is not perfectly clear.
  • Touch: The touch sensor can be consciously activated by having a child push on it before the child starts washing hands. However, this is not a step in the regular hand-washing process and would require the children to remember extra information. Certainly not the most ideal. Alternatively, we can install the touch sensor at the front of the counter, so if the child leans against the table, the sensor will be activated. The problem could be that if the child moves during the process, the machine may be confused.

2. Position of sensor:

Keep in mind that being water-proof is important.

  • Near the water tap: this is where many automatic taps have their sensors. This maybe problematic in our case, however, because our ultrasonic sensor is not very water proof, and we may include steps like rolling up sleeves that is not detectable by the sensor.
  • On the wall near the visual: this seems to be an ideal place. It is close to the rest of the device, making wiring easier. It's not close to water. The only concern may be how effective the ultrasonic sensor would be detecting the person. We will need some testing at the bathroom where it will be installed.
  • In front of the counter: we can use ultrasonic sensor or touch sensor at this location. The sensor would be close to the person we want to detect and would thus be more precise. However, it is far from the rest of the device and may make wiring hard (also need to consider water near wires). We also need to know whether the children lean against the counter top and how both sensors will be affected.
  • Right below the counter: to avoid children touching the ultrasonic sensor in front of the counter but also to have proximity between the child and the sensor, we considered putting the sensor below the counter. However, this may become problematic if anything is stored below the counter. We are also unsure of the range of the sensor. We will need testing in the bathroom if we were to choose this location.

Tips from the Experts

Now that we have a fairly clear idea of what we want to do and what we need to know, we visited Becky to ask some questions. and here are some important points from Becky.

  • The best visual for young children should be linear. This narrows down our visuals to type I.
  • It is very helpful to see all the steps. This eliminates frame as an indicator.
  • We do not want visual stimulus to be distracting. This makes an arrow the best indicator.
  • Children already start to associate colors with genders. We should avoid using gender-specific color (which is, of course, only a social construct, but is affecting the children at such an early stage) and stick with primary colors and/or black and white. In fact, a big, thick black arrow would work the best.
  • The steps of washing hands are: roll up sleeves, turn on water, rinse hands, turn off water, get soap, rub for 20 seconds, turn on water, rinse for 20 seconds, turn off water, dry hands.
  • We should use real photos to illustrate the steps. Thus, we took a series of photos with Meredith demonstrating the proper way of hand-washing. (Shout out to the super star.)
  • The visual on the wall should be no longer than 15 inches.
  • Children lean against the counter to wash hands.
Initial Assembly
Our visit to Becky made us decide on a very simple model of a linear visual with a moving black arrow that indicates each step. Our first step was then to figure out the gear train that would move the arrow indicator. We would build the rest of the supporting structure around the major gear train.

Our servo only turns 180 degrees. This means that a gear train is necessary to amplify magnitude of the linear motion created by the circular motion of the motor. Based on the length limitation of our device, we decided that the strip would be 14'' long. Based on this length, we used three pieces of lego beams with length of 16 lego units. We also used chains as a way to carry the indicator.

There are a few things to discuss here.
First is the gear ratio. We did some research on the servo motor and it turned out that the motor is not as powerful as the PicoCricket we used on the lego racer. As a result, even though we do not require much speed, which is good for creating enough torque, we still want as few gears as possible to reduce friction. Fortunately, since we have very precise control over the servo, we do not have to find the exact ratio that moves the indicator for 14'' after an 180 degree turn of the input gear. This means that as long as the indicator can go further than the linear distance of the chain when the input gear turns 180 degrees, we are good to go. We would only need some testing to figure out the number in the code. With a couple tries, we eventually settled down with a ratio of 1:5, using a 40-tooth gear as the input gear and an 8-tooth gear as the output gear. The 8-tooth gear is shares the axle with another 40-tooth gear which supports the chain and the indicator.
Then we look at the chain. It is fairly straight-forward to build the chain at the beginning, but the decision we actually had to make was at the last piece of the chain. When the chain is perfectly straight, it is, in fact, relatively tight on the gears. This creates more friction on the axle turning, and may potentially cause problem when connected to the servo motor. If we add one more piece of the chain, we will get a slightly saggy chain, but it is much freer to move. This is fine since we used a 40-tooth gear to support the chains so that the top and bottom would not interfere with each other. We thus put the indicator on the top chain and have it hang above the strip of pictures.
Last but not least, the indicator. We made a simple indicator of foam core. It should rest nicely on the chain and over the visual illustrations. We consider connecting the two pieces either through press fit or heat staking.

Now the next step is connect the gear train to the motor.

In the picture we can see that there are small holes on the servo for us to fasten things to it. Our first idea is to piano wire the input gear, so that it is aligned with the motor in the center and will transfer the motion into the gear train. We only had time to secure the gear by the end of class and didn't have time to test it. Here is a picture.