Final Project Week 4: Presentation/Reflection

Project Goal

For our final project, my partner and I chose to tackle the issue of toilets being too loud when they flushed, which can scare some children, removing their desire to flush after themselves. 

When we heard about this issue, we wanted to design a device that would not only ensure that children would have time to leave the stall before the toilet flushed, but also one that would still empower children to have a physical role in the process, as they would in situations where this device was not present. 

We decided that this could be achieved through the use of a button, ultrasonic sensor, and automated flushing device. These three components would work together in the following process:

1. An individual would press the button.
2. The button press would trigger the ultrasonic sensor to start reading values
3. The automated flushing device would activate based on the sensor readings:
• If a child is still in the stall, the flush will be delayed 
• If there is no child in the stall, the toilet flushes automatically. 

In this way the toilet would be flushed only when the child is ready, and has had time to leave the stall. 

Design Process

For this project, our design process included the following steps which can be read about in greater detail in my previous posts:

1) Connecting all the device components (battery pack, button, ultrasonic sensor, and flushing device) together so they could communicate:

2) CreatingMaking sure the components functioned together correctly with the final code:

Final Code

3) Setting up a place to house all the device's components: 

4) Setting up the flushing device motor within the toilet tank:

5) Attaching the device to the top of the toilet tank

The Final Product!

Below is a video of the motor of our final device in action. It's a bit hard to see the device work when it's all set up, so we removed the toilet tank's lid for demonstration purposes. All in all we were glad to see that our device worked how we wanted it to. 

In the video above, the motor component of the device lifts up the valve shown below when activated, allowing water to enter the toilet bowl, and the flush process to begin.

Here's my partner Helena (left) and I with our final product:

Final Reflection

Working on this project has been a challenging, but rewarding experience. Even though we had challenges along the way with things like coding, and having soldered wires break apart, eventually we were able to develop a device that achieved our original goal; building a button/sensor automated toilet flusher. 

With more time, however, there are a couple things we would like to improve on. For one, it would have been nice to have enough time to design and build our own flushing motor to put inside the tank, rather than to have to buy one. It would also have been good to try the device on an actual toilet with water in it to make sure that the set up of the device was alright and the timing of the motor was sufficient to allow enough water to enter the toilet bowl.

We could also experiment with different box designs to make a more secure, water tight, and small place to house our device's components.

All in all though, I am happy with how our project turned out. Having everything housed inside one box/the toilet tank means that the device is relatively easy to set up and be easily switched to other toilets. There is also little chance of individual components of the device getting individually damaged. With a little of the improvements mentioned before, this device could be ready to sell!

Thanks for tuning in to the progress of my final ENGR160 project! This may be the end of this blog but look out next spring for a whole new set of blogs!

Final Project Week 3: Building

Now that we had our code worked out, and all our materials had finally arrived, it was time to put our device together. Below is a description of how each component, as well as the final product was put together. 

Soldering/Heat Shrinking

In order to connect both the motor and touch sensor to our Arduino we first needed to attach pins to the end of their wires through soldering. In the case of our button, it was important to solder the wires onto the "normally open" connecting section on the button, as that is how the touch switch we used to test our code was set up. The "normally open" setting means that no current will flow when the button is unpressed, and current will flow through when the button is pressed. One the wires were connected, the exposed portions needed to be covered by heat shrining a section of wire covering over them. 

Arduino

One of the challenging parts of this project was to set up the Arduino and breadboard while we were coding, and determine whether is was our code or setup contributing to the device's dysfunctionality. Below is our Arduino's final setup including the wiring of the ultrasonic sensor, button, motor, and battery pack. 

The Box

In order to prevent the wiring of our device from coming into contact with water, and also to make the device more aesthetically pleasing, we decided to house all the components of the device inside one box that would rest on top of the toilet. 

The box we decided to use was a clear, plastic box we found in our classroom. While it was big enough to house all our components, it needed a couple alterations. The first was that it did not rest flat on the surface of the toilet tank. This was remedied by riveting a  a 1/2 cm thick piece of delrin to one of the box's sides to act as the new base. We wanted the box to rest on it's sides so that the lid could be facing the wall and be easily removed to allow access to the box's contents.

The box also didn't have a way to securely stay on top of the toilet tank, which we solved by adding four suction cups to the bottom of the box; next to, rather than on top of the delrin sheet to prevent the box from tipping back and forth. The base of the box including the delrin sheet and suction cups is shown below:

We  additionally wanted to make sure that kids would not be tempted to play with what was inside the box, so we decided to spray paint it silver (originally it was clear). 

The box also need to be able to accommodate the button, ultrasonic sensor, and motor wire which needed access to the outside environment to function. We decided to achieve this by making two different circular cuts on the outside front portion of the box (opposite the lid), and then a small rectangular cut at the base of the lid. The rectangular cut was made using a bandsaw, and sandpaper was used to smooth the edges. For the two circular cuts, we first measured the diameters of the button and sensor, then used a compass the trace out matching circular stencils. These stencils were place on the appropriate places on the box, and a drill press with a small drill bit was used to trace the circumference of each circle. Once this was done we used a box cutter to finish up the cutting process and sandpaper to smooth out the holes. The image below shows the sensor and button fit through the two circular holes on the front.

Once these holes were complete, we could then secure the rest of our components inside the box using hot glue, gorilla glue, and electrical tape. When setting up the inside of the box, we took care to make sure that the battery pack could easily be removed when needed. The box was set up as below:

Motor Set-Up

Once the box was ready to be put on top of the toilet , we could then set up the motor inside of the tank. We set the motor up using the video shown below:

Our Set-up:

All that's left now is to present/demo our device to the rest of the class!

Final Project Week 2: Coding

At this point in time we did not have a lot of materials yet (button, motor, ect.) as they were still being shipped, so we focused on completing the Arduino code that would allow the button, ultrasonic sensor, and motor to communicate in the way we wanted them to (to flush the toilet). 

The actual coding process was done step by step to correctly incorporate each of these three devices, but ultimately we wanted a code that would keep the motor at a stationary position until the button was pressed. Then, once the button was pressed, the ultrasonic sensor would start reading values. If the sensor reads a value that indicates a child is present, the toilet should do nothing for a certain amount of time, allowing the child to leave the stall, and then flush. Alternatively, if the sensor doesn't sense a child, it will flush immediately. This whole process would be independent of the toilets handle's normal function, so the toilet can still be flushed manually if need be. 

The first version of our code had statements for all three devices, and four main functions it performed. The first function was a "while" statement that set up the default setting of the motor as "off." The next three functions fell under the condition that the button was pressed. Once the button is pressed the code breaks out of the "while" statement and does one of three things: (1) if the time is less than two minutes and there is a child in the stall, the motor does nothing, (2) if it has been less than two minutes and there is no child in the stall, the motor will flush the toilet, and/or (3) if the time is greater than two minutes the toilet will flush, regardless of whether or not there is a child in the stall.

At the point in time when we made this code, we did not have a motor to test on, but we could tell this code would not work as the ultrasonic sensor would only read values when the button was being held down, instead continuously after it was pressed. We tried putting "serial print" function that communicated sensor reading values in different sections of the code, but, depending on where we put it, the sensor would read one value when the button was pressed and wait until the code had run through its full loop to read a second value. 

Not too long after creating our first code, our motor device came in, so we opted for removing the sensor portions of our code until we made sure that the button/motor were communicating properly.  

The above code as able to correctly move the motor the way we wanted to. This allowed us to determine that the previous issue regarding our sensor readings was probably the result of the Millis functions we used. We ended up removing them from our code, and using delay functions in their place. When editing our code, we also realized that we technically only needed two statements for when the button is pressed rather than three (one for if the child is still in the stall, and another for when no child is in the stall).

The resulting code worked roughly in the way we wanted it to. All that was left was to fine tune the sensor values and change the delay time of the flush to 10 seconds. These values were based on our previous visit/meeting  to the preschool, which is detailed in the previous post. Our final code is as follows:

Tune in next week to see the physical setup of our device!

Final Project Week 1: Focus and Prototype

For our final project, my partner and I chose to tackle the issue of toilets being too loud and scaring children, leading to them not flushing after themselves. 

To remedy this, we decided to create a device that would give children time to leave the bathroom stall before the toilet flushed. This device would work by first having the child press a button (rather than the flush handle), which would then trigger an ultrasonic sensor to start sensing if an individual is in the stall, as well as a timer to start timing. If the sensor senses that a child is in the stall, the toilet will not flush. If it senses that there is no child, the toilet will then flush. We also wanted to make sure that the toilet flushes in a  timely manner, so we would also have the toilet automatically flush if two minutes have passed without it flushing. 

In order to delay the time at which the toilet flushed, we also needed to design a device to flush the toilet in the child's place. We originally thought to use a Lego Bricktronics motor device to manually push down the flush handle of the toilet. This device would be activated when the sensor or timer indicates that it's time for the toilet to flush. When activated, the Bricktronics motor would turn a handle attached to it that would in term push down the flush handle for a couple of seconds. The motor would then reverse directions, bringing the flush handle to its original position. This processed is demonstrated in the video below. 

Before creating a more detailed prototype of our device, we paid another visit to the preschool we were working with to get more details on the toilets we would be designing the device for. In addition to taking measurements of the toilets' dimensions and pictures of the toilets, we also talked a bit with the school's director, Becky Geer. During this meeting we leaned that the delay needed for flushing the toilets was only about 10-20 seconds rather than two minutes. 

Toilet in the Preschool:

Closeup of Flush Handle:

Once we had more details on the toilet's dimensions, we then set out to build a more detailed prototype of the flushing device using a Bricktronics motor. The to-scale prototype featured the motor, the pushing attachment, a flush handle, and a box to cover the device to prevent children from touching it and water from getting on it. 

One thing to note is that the pushing attachment for the motor is designed to reach around the lip of the toilet tank cover to properly reach the flush handed. 

Once we had the overall design of the device worked out, we then had to think about the applicability of it, specifically whether or not the motor had enough torque to successfully push down the flush handle. To test this we used a spring scale to measure the force needed to pull down the flush handle on actual toilets. What we found was that the the force needed to push the handles down was more than our current motor could handle. 

We considered changing motors or creating a gear train to remedy this issue, but eventually our instructor, Amy Banzart, suggested we use a device that worked to flush the toilet from inside the tank, rather than by pushing the toilet handle from the outside. Due to time constraints we ended up ordering an automatic flushing device to use its motor rather than creating our own .

Device Used: Santeen Home Office Indoor Sanitary
 Automatic Hands-free Sensor-based Flushing System

The above device actually contained a sensor of its own, but we took it out in order to use our own ultrasonic sensor. 

Next week we will focus on creating a code for the motor, button, and ultrasonic sensor

MATLAB Day 2: Thermal Systems

In an effort to further learn the uses of MATLAB, today Helena and I explored using it to investigate simple thermal systems. Using a guide created by Robert Bert and revised by our professor, Amy Banzart, Helena and I went through several heating and cooling simulations.

In the scenario we used, we sought to analyze the heating and cooling of a cup of coffee. In order to do this, we first needed to understand a couple of the equations used to model the heating/cooling of systems. 

Heat Capacity (C)

Heat capacity (C) is the number of heat units needed to raise the system's temperature by one degree. It is defined by the ratio of dE/dT, which models the change in energy against the change in temperature (T).

C=dE/dT

dE = energy change of the system during time (dt)

dT = temperature change during time (dt) 

Thermal Resistance (Rth)

Thermal Resistance is  a measurement of a temperature difference by which an object or material resists a heat flow. This property is affected by the temperature difference between and  the system's heat flow. 

Rth = (T-Tair)/(dE/dt) = "effort"/"flow"

T= Temperature of the system at time (dt)

Tair = temperature of surrounding environment

dE = energy change of the system during time (dt)

dT = temperature change during time (dt) 

dt = change in time/time step

Temperature Change (dT)

In order to model the heating/ cooling process of our system, we also needed to understand how to calculate the change in the system's temperature over time.

 dT = (dE/C)= -((T-Tair)/Rth)/C*dt = (T-Tair)/(RthC)*dt

dT = temperature change during time (dt)
dt = change in time/time step
C= Specific heat capacity
dE = energy change of the system during time (dt) 
T= Temperature of the system at time (dt)
Tair = temperature of surrounding environment
Rth = thermal resistance

Question 1: Varying Thermal Resistance and Heat Capacity

In order to better understand heating and cooling systems, we wanted to see how varying the MATLAB parameters of thermal resistance (Rth) and heat capacity (C) affected the cooling behavior of our "cup of coffee". By examining the temperature change equation detailed earlier, one can hypothesize that decreasing Rth or C will increase the cooling process (or dt), while increasing these values will decrease the change in temperature (dt), as Rth and C are both located in the denominators of the equation. 

Using the below MATLAB code we then modified Rth and C, confirming our hypotheses

Original Code/Graph:

Increasing Rth or C resulted in a graph like the one below:

Decreasing Rth or C resulted in a graph like the one below:

Question 2: Adding Thermal Energy to a System at a Constant Rate P

For this situation we added a heating element that would would allow our coffee to heat up to, and stay at, a temperature of 84C (357K). Before using the heating element, however, we needed to calculate the amount of power we would need to supply to the heater (P) to get to and maintain this temperature. In order to determine P, we used the below equation setting dT equal to zero, Tair to room temperature (293K), heat capacity (C) to 1000, and thermal resistance to  0.85.

The resulting P value, 75.3, was checked using the code below:

Feedback and Control

We then wanted to incorporate P-vaues into our thermal system codes to reflect a situation where a coffee pot was being heated to, and kept at, a specific temperature (in this case 84C).

Bang-Bang Control Heating

With bang-bang control heating, the coffee heats up to the desired temperature quickly, with the heating device on at a high power until that temperature is reached. Once that temperature is reached, the heater turns off completely, until the temperature falls below the desired level. This method of heating results in a wave-like pattern of heating around the desired temperature. 

Proportional Control Heating

While bang-bang control is often easier to execute, in cases where temperature needs to be more precisely maintained (such as the storage of temperature sensitive chemicals) proportional control should be implemented. Proportional control not only allows the temperature to be more closely maintained, but also eliminates the need for the heater from constantly turning on and off, which might damage it. In the code below we implemented proportional control by setting the amount of energy supplied by the system to correspond to the current temperature of the system. The resulting graph was smoother and had no wavelike pattern around the desired temperature

Bang-Bang and Proportional Control Heating with Delay

In this final exercise we had to modify the previous two codes to account for a 5 second delay between the the time when the coffee reaches a given temperature, and when the sensor records that temperature.We addressed this situation by adjusting the time portion of the codes, allowing for the time of each temperature reading to reflect the actual time the coffee reached that temperature.   

Bang-Bang Control:

Proportional Control:

MATLAB

This past week we learned how to use MATLAB by reading the first few chapters of Physical Modeling in MATLAB by Allen Downey and doing some exercises from the book. A little background, MATLAB functions similarly to a calculator, but allows for much higher processing power. The exercises describe below allowed us to learn how to assign variables, run functions, and obtain graphs from MATLAB. 

Exercise 2.1

The first exercise was to use MATLAB to compute the nth term of the fibonacci sequence. This involved coding a function for the fibonacci sequence which defines the first two terms as 1, and then each following term is the sum of it's two preceding terms. Using the code we came up with (shown below) we set n to equal 10, and were able to get the 10th fibonacci number (F=10)

Exercise 2.3

The next exercise involved working with multiple variables that were dependent on each other. According to the exercise, there are two locations that each start out with 150 cars. Each week, five percent of the cars at location (a) go to location (b), while 3 percent of the cars at location (b) move to location (a). Our job was to use MATLAB to compute how many cars were at each location after one week. For the code below, we preconditioned  (a) and (b) to be 150

Exercise 3.1

 Once we finished the car function, the next step was to insert a loop into it that would allow us to calculate the amount of cars at each location after a certain number of weeks (in this case it was 52). In order to create a loop, we enclosed our original function in a "for" command, setting the number of times the loop should run (i) to 52. While not shown in the image below, we found that the number of cars exchanged between Boston and Albany reached equilibrium when there was 118 cars in Albany and 182 cars in Boston. 

Exercise 3.2

We then added a plot command to our script to get a visual representation of the number of cars at each location week to week. In MATLAB, our plot command creates a graph where the week number is on the y-axis, and the number of cars at that location is on the X axis. In the our graph, location (a) is represented by the red circles, and location (b) is represented by the blue diamonds. 

When we got the graph above, we realized that we had switched our x and y axis. The corrected graph is shown below. One thing to note is that as the initial number of cans increases, the graph lines get smoother.

Exercise 3.5

In this exercise we returned to the fibonacci sequence, this time aiming to use a recurrent equation to compute the first ten numbers. To do this, we used a loop function that would allow us to add the previous sequence value computed to help produce the next one. For the below code, we ended up printing 12  sequence numbers rather than 10 because we didn't account of our code which dictated that we go to the   "i + 2th" term. We should have either said "i= 1:8" so that it would print the first ten numbers or we could have written "Print F(i-2)" to solve the problem. Either way, we achieved the goal of the exercise. 

Exercise 4.6

The last exercise was to write a script that computes a vector for the "n+1th" term of the fibonacci sequence divided by the nth term, and then plot this vector to determine where it converges. From the plot, we determines that the values converged around 1.6.