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.)

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.

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.)