Final Project Phase 2, Sciborg

We completed a number of tasks this previous week. Our objectives were:

1.     To install a 40 tooth lego gear onto the servo motor

2.     To create an appropriate program and set up the feedback and control input method

3.     To set up a protoboard that connects servo, sensor, and Arduino

4.     To design the indicator component in Solidworks

5.     To design the box in Solidworks

We also ordered a battery holder and created the sciborg line-following proportional control program.

We began the week by revising our method of attaching the lego gear to the servo motor. Previously, we used piano wire. We decided that glue was a better option, as it did not inhibit the range of motion nor did it allow the lego to “wiggle” upon the rotating disk.

Next, we worked to:

1. create an Arduino program to move the indicator across the visual

2. design a box to hold the electronic components and keep the gear train and visual steady.

The Arduino program incorporates the servo program and uses the servo to move the indicator across the visual via the gear train. In the program, the servo is activated while the ultrasonic sensor reads certain values, and maps its position. Delays are added to the servo’s movements to give different waiting periods for specific steps to be fulfilled.

 

We began with a while loop: as long as no one is in front of the sink (ultrasonic sensor reading > 400), the sensor will keep sensing until the condition is fulfilled.

Our next while loop occurs when the ultrasonic sensor reads less than 400, not satisfying the previous while command. Now, the sensor reads a value and waits 5 seconds before reading it again. If the value is still less than 400, this means a person is most likely standing in front of the sink waiting for the program to begin instead of just passing by. This also provides the change to roll up sleeves.

As we have 8 steps to our hand washing process, we needed the servo to move seven times. Knowing that the range of the servo’s motion is limited to ~180 degrees, we chose 175 degrees of total rotation to make the math easier. Now, each step required the servo to turn 25 degrees. The result helped us to further refine the size of our visual. Each step will have a picture 1.75” wide.

With a rotation of 25 degrees for each step, our program was repetitive in nature. We structured every step to delay for a certain amount of time (specific to the step in question), rotated the servo 25 degrees in positive 1 degree increments and updated its position, with a delay of 15ms to keep the servo motor from moving too fast. The variable delays were decided upon by taking the time adults would take to complete the step and multiplying by 2.

The final steps included the servo returning to its original position of pos = 0 from pos = 175 with negative 1 degree increments. The position was updated, and the ultrasonic sensor reading was also reset.

We ordered a small protoboard to connect the circuit:

 We used the A0 and 9 output pins, as well as the 5V and ground terminals.

Our circuit and its electronic components

~

We had previously hoped to create a sub-system of feedback and control which would check to see if the water was turned off at certain points in the process. Due to time and feasibility, we decided to focus our attention on the ultrasonic sensor and viable program.

Alongside this program development, we also brainstormed how our box would look like. This box is intended to have a back, bottom, and front. In front of the front of the box, we will position our lego train and visual. One of the sides of the box will feature the battery pack for easy access, and both the front and back faces of the box will have holes to position the axles of the gear train and hold them steady. The electronic components will fill in the space between the front and back walls, with the exception of servo and the sensor. Servo will be dropped into position via a shaft to hold it in place with the first gear in the train. The ultrasonic sensor will rest beneath the visual.

Using our gear train and visual prototype as a model, we began to construct measurements integral to the box’s function. The axles about which the gears were fastened were 0.7cm in diameter, which helped us create the right sized holes in the delrin a correct distance apart.

We made this piece 4.3 inches high and 45 cm long, to provide enough space for the axle holes and enough length to exceed that of the visual. To this length, we added four small tabs. We then decided to use 1/8” thickness of Delrin. This caused our tabs to be .2” in height and 0.6cm in length. We measured the diameter of the heat-stake to be ~9cm, so we chose 0.6cm so the tab wouldn’t be incompatible with the machine.

To this front piece, we incorporated a 0.6cm channel directly above one of the axle holes. This allows us to lower the servo into place above the first gear in the gear train. The distance between the center of the axle and where the servo meets the Delrin was found to be .94.”

We decided that rather than create another Delrin part to form the back of the box, we would instead use the Solidworks design for the front for the back of the box as well. This decision allowed us to design the bottom of the box.

The bottom of the box features holes in positions and widths that exactly match that of the front/back piece. We plan to insert the 8 tabs into the 8 slots and heat-stake them.

We designed an indicator which deviated from our prototype. Originally, we were using foam core and used vertical cuts to hold the two parts (parallel and perpendicular) of the indicator together. We then thought about how Delrin has low friction, and that it would be more feasible to actually create a tab-in-slot form that we could then heat-stake.

  

We printed these parts out and heat-staked them.

To attach this indicator to the gear system, we glued the piece onto a single lego chain link, which we then incorporated into the entire chain on the gear train system.

Next, we will print out the visual, put the box and electronic components together, and try to get it working!

~~~

Finally, we rewrote our line-following bang-bang control code into one using proportional control

Bang-bang from before:

     

Here, we looked at the bang-bang control program and translated those values into the proportional control program in a form consistent with proportional control.

We used our values of -40 and 220 from the bang-bang control to set our gain for motor 1. By using the minimum and maximum values read by the sensor (540 and 620, respectively), we were able to write linear functions to determine this gain. For example, we started with 620K+B = 220; and 540K+B = -40. Eliminating B, 80K=260, and the gain factor was 3.25 for this motor. Going back to find B yielded 1795, which makes sense because the reading does not start with a value of 0 (why there is a y intercept).

For motor 2, our bang-bang program assigned it one of two values: -48.5 or 228.5. We followed the same process as above and found a gain of 3.4625 and a B value of 1641.25.

With our calculated gains and B values, we were able to assign motor 1 a proportional control method of "reading*3.25-1795" and motor 2 "reading*3.4625-1641.25."

Final Project: Week 1

This past week and a half, we began to work on our final project. Before break, we visited the place we would implement our projects and brainstormed ideas that addressed some problems we saw/heard about.

Xixi and I came up with two ideas – one that would monitor water levels in the water play area and one that would make sure hands were washed properly.

We were assigned the topic of using feedback and control to ensure proper hand washing.

Now that we knew what topic we would pursue, we began to brainstorm different ways of presenting the process visually, as our targeted users interpret information better when it is visual. This made us prioritize the visual aspect, as we knew that we would be able to figure out the programming and mechanisms behind it after selecting the best prompt geared toward our audience.

We came up with a few ideas, with variations.

In each, we needed to have 8 sections on the visual to prompt the 8 successive steps of washing one’s hands.

The first idea we had was a rotating wheel with an arrow that indicated what the current step in the process was.

The first design had the indicating arrow pointing down and the second had the arrow pointing up with a light directly above it. The idea was to have the servo rotate the wheel showing the steps of washing while the light drew attention to where the audience is supposed to look to see the picture of the step.

 

The second idea was to have a system of arrows and lights that lit up in order. We realized that this was a little too abstract; an arrow pointing to the faucet that means turning the water off may not be clear to our audience.

The next idea we had showed a more linear approach to depicting the steps.

A strip with all the steps would run through a box, into which was cut a window so that the current step was framed inside the box.

The final few ideas we had were generated on this design:

The basic idea was to have a linear strip that moved laterally, with an arrow that indicated the current step.

We thought of having lights to further draw attention to the step: Either lights on top of each step lighting up in succession, or backlights that did the same thing.

We also thought briefly about how we might get the arrow to move across the strip. We immediately thought of gears, but were unsure of how to realize this idea.

Before we could go further, we needed to make an appointment to get feed back about our project. We met with the head of the program to ask questions.

Our first and most important question was to ask for input about which design would be best for our audience.

A: Our specific audience interprets visuals much better when they are linear, rather than rotating. (That narrowed it down to 2 ideas.) It is also important that they can see what will follow the current step.

Based on this answer, we went with our last idea.

Q: Would an arrow suffice to indicate the step? Or would lights help? We noticed that the bathroom is well lit so backlights will not be that helpful.

A: Too much visual stimulus would detract attention from the picture. The arrow will be more than enough.

Q: Is there any specific color that draws attention, but not too much?

A: Stay away from pink/purple, stick with primary colors if necessary. A bold black arrow would probably be the best.

Q: Can we clarify what the 8 steps of washing your hands are?

A: Roll up sleeves, wet hands, turn off water, get soap, rub hands, rinse hands, turn off water, dry hands.

We asked to see the bathroom. We began to formulate ideas about where to place sensors.

Q: If we placed a sensor beneath the edge of the counter, a little behind flush with the plane, would they notice?

A: Not very likely.

Q: Do they lean up against the counter while they wash their hands?

A: Yes.

We then took pictures of us completing the 8 steps and went back to the lab to compile our information.

We had our design and valuable information that would help our design process. We then began to think about the mechanics of our idea.

We brainstormed about what we would need for this project.

In order to incorporate feedback and control, we thought of two ways that would use input from the audience to run our idea.

1    1)Ultrasonic sensors recognize when somebody is “ready” to wash their hands. We would have the ultrasonic sensor take a reading, and if the reading is below a certain value (indicating proximity), the program would start.

      2)   Another sensor that would determine if the audience had turned off the water. It would prevent the program to run further without this step being completed. This is to conserve any water that may otherwise be wasted.

Looking at the other mechanics:

Our first challenge was to recognize the limitations of servo. We originally overlooked that servo can only turn 180 degrees. This created a problem with our idea of using gears to move the indicator. This limitation made us change the length of our picture strip while also creating the need for a gear train so that the indicator could move across the strip of pictures in 180 degrees of turn in the servo or less.

Each step of the process became 1.75” wide (8 steps, = 14” total).

Our gear train had a 1:5 ratio: Each turn of the 40 tooth input gear would result in 5 turns of the next 8 tooth gear. This gear was directly attached to another 40 tooth gear, so that gear would also turn 5 times every time the input gear turned once. However, Servo is only capable of turning a gear 180 degrees. This leads to the second 40 tooth gear turning only 2.5 times. But this correlates to the 14” visual strip.

After initially exploring gears and pinions, we had decided to advance with gears and treads to keep the design compact. We played around with the number of individual links in the chain. With exactly the number of links to complete the gear-pulley system, the system would work. However, if we added a single link to the chain, it became much easier (torque required decreased) to move the gear train.

Here, there is the extra link in the chain.

We created the indicator in white for now. We will use delrin and press fitting to create the two parts.

We decided to place the indicator on top so that it would make the design more compact. The chain, having that extra link wouldn’t sag below the picture strip because of the weight of the indicator. This allows us to place the strip in front of the gear train/pulley system to decrease the amount of mechanisms that show. This minimizes the distraction to the audience.

Our final adjustment of the day was to connect the input gear to the servo motor. We used piano wire to attach the gear to the rotating face of servo. We have yet to test this modification.

We will need to construct a shelf and/or support system for this, because it will be mounted on the wall for easier access.

Next, we want to address where we would put our sensors. We have an idea for a system of ultrasonic sensors, but we may only need just one.

MATLAB, Day 2

This day, we explored how MATLAB can run hypothetical simulations and model progress as time continues on. Beginning with Newton’s Law of Cooling, we considered the rate of energy loss of a system and attempted to use MATLAB to recreate the situation.

To begin with, we ran the program that simulated the cooling of a system. We used coffee as the system and looked at the code and the graph it produced to form hypotheses about the effects changing specific factors would have on the results.

 

We considered two variables in particular, Rth (thermal resistance) and C (Heat capacity).

We hypothesized that an increase of Rth caused the system to cool more slowly. This is because when considering the energy change in the system for time dt, Rth is in the denominator. Thus, when Rth increases, the change in energy for that time dt gets smaller, which means that there is less of an energy change relative to a larger Rth. This causes the graph of K v t to become less steep and take a longer time to reach the cooled value.

Likewise, a decrease in Rth causes the system to cool more rapidly.

It is somewhat intuitive that when the thermal resistance increases, it is “harder” for thermal energy to transfer, which would slow down the rate of transfer and make the coffee take longer to cool.

We next looked at the effect on the energy change when C was increased in value. The system then takes longer to cool, which goes with the intuitive thought that increasing heat capacity allows the system to retain more heat and for a longer time. The curve is shallower.

When C was decreased, the system takes less time to cool, resulting in a curve with big changes in energy with each dt that quickly reaches close to the desired temperature.

Next, we were asked to consider the addition of a heater to the system. We were given a specific equation that relates the change in thermal energy to the change in energy/heat capacity. By recognizing that dT = 0, and dt cannot = 0, then (skipping algebraic steps) P = (T-Tair)/Rth. We then used it in the simulation of heating coffee to the desired temperature.

Until time has reached the maximum recording time, 

Power * small change in time = change of energy put in;

change in output energy is delta T/Rth *change in time;

Total change in energy is change E in-change E out

Updates T and t for the next loop and plots on the graph. 

The simulation's graph:

At this point, we were able to understand how to find Rth and C. As P = deltaT/Rth, Rth = (Tequilibrium-Tair)/P. To find C, one has to focus upon the initial slope of the graph created by Temperature vs time. As the slope is equivalent to P/C there, dividing P by the slope at the initial points yields C.

 

~

We then moved on to feedback and control. Our first challenge was to create a simulation of a temperature controller that functioned by the means of bang-bang control. Either the heater was on full or completely off to meet this requirement.

My code ran as follows (see comments for details):

When graphed, the plot yielded:

Zooming in on a section on the “horizontal” part of the graph:

Here you can see that as the temperature rises, when it gets too high, the controller is off (implied by the next point dropping down to below the “high temperature” value until when the heater turns on again (rises once more).

This approach seems appropriate for many temperature control systems because it is energy efficient when it comes to shutting off the heat. Once a reading is above a certain threshold, the controller immediately shuts off the heat. It is unlikely that the room’s temperature will change so dramatically that the controller is constantly switching between off and on. Realistically, in a typical, closed room, temperature will not fluctuate noticeably. This approach might be inefficient in temperature controls that operate on a very fine level of precision (e.g. for scientific experiments). The delay between readings might prevent action being taken in time to change temperature levels to within parameters.

Our proportional control program uses the characteristic gain*error format. To begin with, we needed to find what the gain was. We assigned it the value “K.” See comments for further information.

 

This yields a graph that proportionally creeps toward the desired value. The increase in temperature begins as large and then proportionally grows smaller. However, as we saw in the proportional control program with the sciborg, small forces such as friction prevent the system from reaching the desired value. This calls for a “nudge” program – but for the coffee system.

To create the nudge factor, we had to incorporate a delay in our bang-bang and proportional programs.

For the bang-bang control program, we defined the value of the delay. Basically, we assigned the T value used in the loop calculations (Ti) to be the T value of x seconds previous, where x is the delay. So, we assigned T(i) = T(i-delay). So every T value recorded is used in the next calculation because of the delay. This caused slight confusion when updating what T(i) becomes for the next loop, but I figured it out in the end. See comments for further details.

Our graph by-and-large looked the same. However, there should be a horizontal shift to the right to account for the delay. The delay accounts for the time between the system reaching the temperature and when the sensor stores that temperature.

Next up was proportional control with a delay.

Although it took me a while to figure this program out, it turned out to be a rather simple addition to the program. Aside from condensing Tmax-T into the term “error,” it was a matter of changing T to become T(i-delay) in most cases, and updating the loop.

The graph:

The delay functions as a “nudge,” and allows the temperature to reach the target and hold it for 1 second before using the value to realize that it has reached the desired number.