Fire Fighting Robot [Video]

[Fire Fighting Robot: Video - 10 ft Distance, Finding & Putting Out the Candle]



This was one of our first tries on our fire fighting robot. It was able to find and locate the candle to the position where it needs to be in order for the top shell to squiz it down. The only problem with it was that it did not really put out the fire. We came to a solution that adding some forward and backward movement when the top sea shell is over the candle would really put the light out.

[Fire Fighting Robot: Video - Finding the Candle]



After the first tryout, we decided to implement some codes so that the robot can move slightly forward and backward with the top shell over the candle, so that the light gets extinguished. In this video, we have added such methods. The robot finds the candle and moves towards it, but did not fully get to the candle. We checked on our sensor readings after and, for some reason, they have changed from what they used to be in front of a candle. Anyways, it was designed to repeat the hello method (the method that drops the top shell, moves slightly forward and backward [to put out the candle light completely] and then bring the top shell back up) with some forward movement each time until the light was out. We, however, had to stop the robot because the strings were almost on fire. But, we were happy that the robot found the candle and placed it right in the middle of the two sensors.

[Fire Fighting Robot: Video - Finding the Candle with More Precision]



We fixed the sensor values by a little bit to be more precise this time. The robot found the candle, almost perfectly stopped at the position where it was supposed to and executed the hello method to drop the top shell and put out the fire. However, the robot decided to behave weirdly even though we did not touch any other code. It would just move forward with full power all the sudden, when there wasn't code like that. Lia and I did not have any idea why, and we now are supposing that the offM method possibly is the problem because our last code to this tryout was offM method. It also was supposed to repeat the hello method if the light was still on. Hmm... weird... I wish I had known what the problem was.

[Fire Fighting Robot: Video - Finding & Putting Out the Candle]



After a few try outs, we found out that our car actually consistently finds the candle without trouble, moves towards it and positions itself so that the candle is in between. The only part that we thought we needed to work on was the ending, when the top shell drops and tries to extinguish the light. The candle lights were stronger than we expected. So here is a video of our robot extinguishing the candle light with slight forward, slight left, slight right and then slight backward movement to really put out the candle. And it works so well! We were so happy!!!

[Fire Righting Robot: Video - 10 ft Distance, Finding the Candle]



Right after we had success with the code above, we tried to show Lyn our new mechanism. However... we had the similar problem that we had before with the second video above. Our robot just had decided to act weird and just move forward. We did not change a single code after the video above. After then, our hello method stopped working appropriately and we no longer were able to control our servo motor, which was really sad... But we are happy with how far we have come with the project and the outcomes!

Fire Fighting Robot [Coding]

[Fire Fighting Robot: Coding - Auxiliary codes]



There are 12 auxiliary methods. I call them auxiliary because they do not really control the motion of our robot, but either start or help the mechanism:

* brake, forward, backward = Those methods make the robot behave like their names
* lslow, rslow, sback, sfor = These methods are abbreviation for "left slow," "right slow," "slow backward" and "slow forward" (They are controlled by the low power settings from input)
* nudge = Nudge allow the car to march forward for 100 msec each time invoked
* settee = If the reading from sensor 1 is greater than the given value of the variable largest, then it sets the largest to whatever value read from sensor 1.
* getlarge = This method helps the settee method. It allows the car to turn left one full rotation and help settee method set the value of the variable largest to be the reading from sensor 1.
* startpos = This method determines the starting position and is invoked after the getlarge method. By the time this method is invoked, the variable largest will be set to the values read from the sensor 1 during the one full rotation. The robot turns left until the sensor 2 detects a number 100 less than the given largest value. (100 was a good number for it to stop facing the candle. If the number was too small, then the value of largest was often bigger than the reading from sensor 2, causing the robot to just spin and spin)
* FINAL = This method is what we double click to give all the instructions to our robot.

[Fire Fighting Robot: Coding - Main code "go-d-2" & "hello"]



This method called "go-d-2" is the method that commands the robot to travel a certain distance in the beginning. Once it gets close to the target line (10 feet away from the start position), it starts to check for the light. Generally, our readings on sensors were pretty consistent. They would always range in between 993-996 if the candle was in the desired position (in between the two sensors and under the top shell). Therefore, we set our if condition to be "if sensor 1 reading if less than 990," which means that the candle is not in our desired position. If the if statement is true, then the snud2 method gets invoked (snud2 method basically commands the robot to approach the candle so that it is in the desired position. It is explained in greater detail below). Otherwise, it would perceive the condition as "yes, the candle is in the right place" and would brake and then execute the method called hello.

The hello method is the one that controls the mechanism of the servo motor and, therefore, the mechanism of the top sea shell. In the beginning, we only had the servo motor turn thisway, wait for a while, and then turn thatway, causing the top sea shell to drop down, squiz the candle, and the go back up. However, many of the times, the light on candle would not go out completely and would light up again after the sea shell goes up. Therefore, we implemented some more mechanism to our hello method to really make sure that the candle light goes out. We added sfor, lslow, rslow, and sback methods, which were invoked after the top sea shell has dropped, having the candle light in between the two sea shells. With it in between, the robot would move slightly forward, left, right and then back. In this way, the robot completely put out the fire without a question. (This is also shown in one of the video clips in the next blog entry)

[Fire Fighting Robot: Coding - Main code "snud2"]



This method is our really long method. It gets invoked from the go-d-2 method to begin with. Under the condition that the sensor 1 reading is less than 990, which means that the robot still has to search for the candle, this method commands the robot to move towards the candle based on the difference between sensor1 and sensor2 (difference = sensor 1 - sensor 2). A positive or a value that is greater than 5 for the difference means that the candle is placed to the left of the robot since sensor 1 is on the left side of it. So, it would be commanded to execute lslow method or left slow method. We also wanted to have another if condition before executing lslow method because the candle may be really close to the robot and so commanding it to turn left can be suicidal for the robot. Therefore, in the method above includes another if statement that checks if the sensor 1 reading is greater than 990. If it is true, then we surely want to back up and then execute lslow method. If the difference is a negative number or a number that is less than -5, then we want to do the opposite and the same logic was applied to the coding. If the difference is fairly small, which means that the candle is pretty much in between the two sensors, then the robot is to be commanded to nudge forward.

In the beginning, we refrained ourselves from using the other two sensors, sensors 3 and 4, because we believed that they were making the coding even more complicated than it already was. However, because we had our sensors 1 and 2 angled slightly inward, the sensors were reading numbers very unexpectedly as it got closer to the candle light. When the light was placed in front of sensor 2 (on the right), sensor 1 (on the left) was reading a greater number than sensor 2 because of the shadow created from the black cover we put on the sensors. And this caused our motor to turn the other direction, again, setting itself on fire. Therefore, we decided to use the readings from sensors 3 and 4 in the beginning of the method. If the back sensors were reading larger number than the front sensors, then we had the robot turn to the side of the sensors. In this way, the robot no longer turned to the other direction.

After this method, the system will return to the forever loop in the go-d-2 method and repeat the whole process again.

Fire Fighting Robot [Design]

[Fire Fighting Robot: Design 1]



This model was our first design for our fire fighting robot. As we have decided to use wet sponge to put out the candle light, we attached some sponge onto the two shells using some strings and wires. We were concerned about the weight because we were anticipating the possibility of the strings breaking or the servo motor not being powerful enough to pull the shell up. However, thankfully, neither of our anticipation came to be true. The sponge, even though wet, was not that heavy, and our servo motor was powerful enough to sustain the weight of wet sponge. We made the surface of the sponge rough by cutting parts of it so that the sponge can really push down onto the candle light. We also covered parts of the shells by foil to make sure that nothing burns down. The ideal height of a candle was approximately 4 inches for our robot.

[Fire Fighting Robot: Design 2]



This is our second model for our model. After several try outs, we discovered that our robot would find the candle, but would miss it by 1/5 of an inch, which is a huge distance for our mechanism. The robot really had to be right in front of the candle because putting a candle out with sponge, unlike many would think, was not so easy. Even after our robot pushed out on the candle, the light would not extinguish completely and revive again. So, our thought was that if we have a wider sponge area for the robot, then even if it missed the candle by a little bit, it wouldn't matter because the sponge is now wider. However, attaching some more pieces to the sides of the center sponge was not a good idea because it kept on falling. It also continuously covered the sensors' light reading, which caused a huge problem in our mechanism.

[Fire Fighting Robot: Design 3]



Besides the unsuccessful result from the fire fighting robot design 2, the robot got itself on fire during one of the tryouts. As a result, the 4 strings holding the top shell piece were all burnt down and everything was a mess. However, after a few hours of repairing, we were able to restore all the ruined parts. To not get it on fire EVER again, we decided to cover every parts exposed to the dangers of fire with aluminum foil.

After we threw away the idea of widening our sponge pieces, we needed to come up with a better scheme to put out the candle light reliably. We decided to polish on our code and make the robot move slightly forward, slightly left, slightly right and then slightly back, during which the top shell will stay down. This is better explained in the video section with some cool video clips :) Anyways, our Design 3 model is the final design that we decided to stick with.

Fire Fighting Robot [Setup, Modeling, SolidWorks]

[Fire Fighting Robot: Setup]

For our fire fighting robot, we implemented four sensors, two on each side. Sensors 1 and 3 are on the left side of the robot, while sensors 2 and 4 are on the right of the robot. Sensors 1 and 2 are the front sensors. Sensors 3 and 4 are the back sensors. We also added some Lego parts on top of our MotorCar so that we could attach to-be-cut delrin parts of our design later. We also had the servo motor hooked up to our Lego chip all ready to go!



[Fire Fighting Robot: Modeling]

We made our ideas into a model using the foams and basing on the sketches we had. The pictures below show our model. The top shell would have six holes in total, four in the front and two in the back. The four holes in the front help keep the balance of the top shell piece when up in the air, hanging from the string. The back two holes allow the top shell piece to be hanging from the base piece.


We knew that pinching the candle light in between the two delrin cut pieces would not extinguish the candle light but rather would start a fire. So, after a few hours of brain storming together, we came up with the idea of using a wet sponge in between the shells. Thanks to Lyn, he was able to get some colorful and pretty sponge for our robot!

[Fire Fighting Robot: SolidWorks]

Here are the three pieces for our fire fighting robot. They were to be cut from delrin, using the laser cutter, so we produced them in SolidWorks. They are exactly how we envisioned them in sketches, although the sea shell piece does not really look like a sea shell. Printing the parts out, we encountered some difficulties. Our first try was a failure because it printed the tiny stars in SolidWorks sketches. Also, it cut the lines that were different from the drawing (especially for the sea shell piece). We found out that it was because the sketches were either under-defined or over-defined (it showed red and gray lines for outlines of our drawings). We fixed the problem just by re-defining every dimensions, using smart dimension. Then, we were finally able to get our parts printed out!

Fire Fighting Robot [Sketch]

[Fire Fighting Robot: Sketch]

My partner and I wanted to create a sort of a squizzing mechanism to put out the candle. In the process of brain storming we came up with the idea of a bird wings. The wings would be up in the air hanging (connected to the servo mortor) and once the MotorCar finds the candle, the two wings would come together and squiz the candle in between. However, we knew that it would require much power from the servo motor, which we were not sure how powerful was. Therefore, we decided to have one wing stay still and have the other wing move down and up to put out the candle.



The image above illustrates the idea of just using one wing, whose one end is attached to the servo motor hanging. It would travel the 10 feet hanging up as high as possible, and once the candle is placed in between the two wings, the servo motor would spin and drop the hanging wing. In order for the wing to drop reliably, we needed a supporting piece that would allow the hanging wing to come up vertically and not diagonally. Therefore, we decided to make a supporting piece that would stick out from the top of the MotorCar. This is shown in the lower right corner of the picture above.



I personally did not like the idea of side ways wings because it would look just weird. Birds fly forward and it would look so awkward if we made our design into a side way bird opening up and down only its one wing. Therefore, we decided to make our design into sea shells. The sketch above is a distorted sea shell design to fit the width of our MotorCar. So, the top and bottom of the sea shell would squiz the candle in between. The second picture is a simplified version of it. It has two small circular holes on the top. They are the string holes to connect it with the base piece.




The two images above are the remaining parts of our mechanism. The top picture is the base that will be placed on top of our MotorCar. It has two small circular holes and two rectangular holes. The circular holes will be used to hang the top sea shell, and the rectangular holes are where the supporting pieces (the bottom picture) will be puzzled in. There is a circular hole in the supporting piece for the teflon rod to go through. The string connecting the bottom end of the top sea shell and the servo motor will rest in between the supporting pieces. Therefore, we designed the holes in the supporting pieces to be tight fits.

Thermal Systems [Part 3]

Proportional Control

Lia and I worked on the MATLAB proportional control. We experimented it by using the heater on MotorCar and by simulation. It was interesting to see the similarities and differences in our simluation and experimented results. We used 20, 5, and 2 for the gain to be used in our system. With each gain, the system reached the target temperature differently.

Below are the experimental results of the system with the gain of 0.5W/K, 0.2W/K, and 0.05W/K. We found the system with the gain of 0.2W/K to be optimal because it reached the target temperature gradually without much oscillation. The system with 0.5W/K was provided too much power in the beginning and, as a result, it overshoot the target temperature. The system with 0.05W/K was not supplied with enough power to reach the target in the given time. (Also, it is interesting to note the unexpected dot plotted on our 0.5W/K graph. We do not know how it happened, but it happened!) We have submitted our deliveries to the Conference Drop Folder, and there should be all of our results for simulations for those systems.





Proportional and Integral Control

I found this exercise very interesting, maybe because I like the word "proportional" as I have explained in my blog entry for the MotorCar proportional control. With the gain that we found optimal in the previous exercise (gain = 5 in the units of our system), we were able to experiment the proportional integral control.

Here is the result of our experimentation on proportional integral control. In the beginning, full power is being supplied to the system to bring up the temperature to the target temperature. Once it reaches the target temperature of 340K, the power drops to near 0 to not over shoot the target. As time passes, there is more fluctuation in power setting because of the Law of Cooling. I just found it invigorating how the system adjusts its power setting proportional to the temperature or the error (target state - present state). It is amazing how the temperature is being kept almost constant at the target temperature throughout the time interval!


We also have the simulation of our Proportional integral control in the Conference Drop Folder. (I am only discussing about our experimental results here because they are more interesting!)

Thermal Systems [Part 2]

MATLAB Simulation of the Heating

For the thermal challenges, we first had to calculate the physical constants of the heating system. In order to do so, we had to get a graph (temperature vs. time) of our thermometer in the process of heating up. Here is the graph that we used to calculate the constant.



To calculate C, we used the interval between time=20 and time=40 because there weren't much fluctuation and, therefore, was more reliable than the other. Also, because we were told to do so. Here is the equation we used to calculate C:

Change in temperature = 20 degrees
C = heat capacity = dE/dT
dE = P * dt = 6.48 * 20 = 129.6
C = 129.6 / 20
C = 6.48

To calculate Rth, we used the whole interval for change in temperature and applied the values to the equation below:

dT = 80 degrees
Rth = dT / dE
dE = P = 6.48
Rth = dT/dE = 80/6.48
Rth = 12.34

Below is our graph of simulation heatsim.m.

We believe that the simulation agrees almost with our experimental results in that it starts and end in similar places and that it has the similar curve to it. However, we found that when we saw some delay in the beginning of our heating system in experiment, the simulation did not. Right off from the beginning (intervals from time=0 to time=20), the temperature continued to rise without any delay.

Bang-Bang Control

The image below shows our graph to simulation for Bang-Bang Control:



The image below shows our graph to experimental results to Bang-Bang Control.



Our implementation was different from the simulation in that it had gentler oscillations and gradual changes in slope each time.

Matlab Challenges

Here are our solutions to the MATLAB exercises:

[Exercise 2.1: fibonacci1]
sq5 = sqrt(5);
n = 10;
ans = (1/sq5) * ((((1 + sq5)/2)^n) - (((1-sq5)/2)^n))

[Exercise 2.3: car_update]
a = round(a - (a*.05) + (b * .03))
b = round(b - (b*.03) + (a*.05))

[Exercise 3.1: car_loop]
for i=1:52
car_update
hold on
plot(i,a,'ro')
plot(i,b,'bd')
end

[Exercise 3.2: car_loop with plotting]
a(1) = 150;
b(1) = 150;

for i = 1:52
a(i) = a(i-1)+ round(.03*b(i-1)) - round(.05*a(i-1));
b(i) = b(i-1)+ round(.05*a(i-1)) - round(.03*b(i-1));
end

x=1:52;

hold on
plot(x, a, 'bd')
plot(x, b, 'ro')

[Exercise 3.5: fibonacci2]
f1 = 1;
f2 = 1;
prev1 = f1;
prev2 = f2;
result = 0;
n=10;

for i=3:n
fnew = prev1 + prev2;
prev1 = prev2;
prev2 = fnew;
end

prev2

[Exercise 4.6: Plotting fibonacci ratios]
F(1) = 1;
F(2) = 1;
n = 10;

for i=3:n
F(i) = F(i-1) + F(i-2);
hold on
plot(i,F(i),'ro')
end

for i=3:(n-1)
ratio = F(i+1)/F(i);
hold on
plot(i,ratio,'bo')
end

ratio

LogoChip Challenges [FC.7,8,9]

[FC.7: Distance with Proportional Control]

I found this challenge very exciting because I was to use a proportional control onto the MotorCar. I liked the word "proportional" because it means that the mechanism adjusts itself to the desired output according to the given condition. We counted the number of rotations on each wheel, which we found to be approximately 3300. In a forever loop, we had it constantly update the error, which was to be used to control the power supply in each motor or "x". Our MotorCar did a pretty good job in going exactly 10 feet, although it did not really move straight. It was also interesting to see how the car behaved on carpets. We couldn't record it but, it would go for exactly ten feet on carpets as well. And this was something new because with distance-bang-bang control, we were only allowed to control the distance with timer.

Here is a video of our "Distance with Proportional Control."

[FC.8: Distance with Nudging]

Here is our code for nudging. The count+ of the Motors after traveling 10 feet was approximately 6300, so we set the error to be 3140 (half of count+) minus the average of the rotations on the two motors. At first, we had the last if condition (when error_ > 10) nested in a second forever loop, not realizing that the count+ gets initialized in the loop. So, our MotorCar wasn't really nudging but was stopping when error_ equaled to 600 (our first if condition). We had our gain set to 25 (a huge number for gain) to control the power supplied to each motors. We had a new variable called "x" which was a product of the gain and the error. However, with a large number for the gain, the "x" was decreasing so rapidly that no power was being supplied to the motors long before it could reach the target. So, we decided to set the gain to 3, a small number. With a small gain, the MotorCar would nudge when the wheels were in the air. But, when on the floor, because it was getting so little power by the time the error_ became so small that the car would not move forward. Therefore, we got rid of proportional power control, and manually set the power equal to 10,000 when not so near the target, and nudge when near the target.

Here is a video of our car nudging to the target.



[FC.9 All Together Now]

Above is our code for the challenge, "All Together Now." We simply incorporated the bang-bang-control into our nudging program for straightness. When we tried the code on the MotorCar, it would go straighter than when it was applied with the nudging program (FC.8), but still it was not perfectly straight. We later found out that the size of each wheel differs by a slight bit, which caused the car to bear a little bit left. We tried switching wheels to get the same sized wheels, but did not have any luck with it. So, we had to give a little push on the MotorCar to have it go really straight. It would have been nice to have the car go really straight without the push but we decided to stick with our wheels and work our way through our fire fighting robot!

Here is a video of our MotorCar on floor for the final challenge.

Here is a video of our MotorCar moving up the incline for 10 feet.

Here is a video of our MotorCar moving 10 feet on carpet.

LogoChip Challenges [FC.4,5,6]

[FC.4 Simple Distance]
&
[FC.5: Simple Back and Forth]

Here is our code for "Simple Distance" and "Simple Back and Forth." For the simple distance challenge, we just had the MotorCar move forward to a given time (wait of 130) and brake. For back and forth method, we applied the same idea. It was our first encounter with the wait variable and how powerful of a tool it was.

Here is a video for "Simple Back and Forth."

[FC.6: Distance with Bang-Bang Control]

For this challenge, we first measured the time it takes for the MotorCar to go for 10 feet, which we found to be approximately 13 seconds. Because we were supposed to use coast and not brake, we shortened the time by 1 sec because the car moved a bit forward after it has coasted. By using the variables, counta and countb, under the condition for "If" statement, we would have it either perform side-bang-bang control or move forward. The MotorCar moved very straight, which made us happy, but it stopped before it reached the end point. We discovered that controlling the distance only with timer was limited and the distance varies all the time depending on the condition of the floor.

Here is a video of our "Distance with Bang-Bang Control."

LogoChip Challenges [FC.1,2,3]

[FC.1: Simple Straightness]

When we had our MotorCar travel some distance at full power, we discovered that it would not go so straight. Especially when we added some friction on either one of the wheels, it would just spin in a circle rather than slowing down the other wheel. When we applied friction to both wheels, it would not travel the full distance that we expected it to.

[FC.2: Straightness with b-b-c]

Here is our code to "Straightness with Bang-Bang Control." Depending on the shaft encoder variables, counta and countb, the bear-left and bear-right methods were invoked to control the MotorCar's straightness. The MotorCar moved forward pretty straight, but it was not very reliable because when we applied some friction to one wheel, the other wheel did slow down but not enough to go straight, so it bore to the side of the wheel with friction.

[FC. 3: Straightness with Proportional Control]

Here is our code for "Straightness with Proportional Control." I personally liked this method so much more than the side-bang-bang method because we could control the power settings of the two motors. Since we were able to control the powers, we could have the MotorCar go even straighter when we applied friction to just one wheel. Also, compared to the s-b-b control, proportional control had the MotorCar move smoothly forward. With s-b-b control, the MotorCar move left and right a lot, but with proportional control, it did not have much left and right movement.

LogoChip [Challenge 8-1,2,3]

[Challenge 8-1]
Here we built the base of our MotorCar!



[Challenge 8-2]
To control our MotorCar, we devised multiple codes: forward, backward, coast, brake, spin right, spin left, bear right and bear left.



[Challenge 8-3]
We implemented the 'init' program from which we can use 'count+' and 'count-' system to detect the rotation on on the motor. It was a bit confusing wiring up the motors so that counta increases as left motor goes forward and countb increases as the right motor goes forward. After wiring up the motors correct, we tested out our code below so that the wheels move forward until the count count-a is 1000 and backward until count-a is back to zero. The number printed out at the bottom is count-a after the code is taken place. It is a less than one rotation backward (one rotation = 180) because the wheels have moved backward just a little bit after the brake.

LogoChip [Challenge 7-1,2,3]

[Challenge 7-1]
To sense the rotation of our two wheels, we implemented the "shaft encoders." Because we were not sure if it was sensing the rotation, we connected it to the oscilloscope and tried to capture the motion on the wheel (it is in the video below).





[Challenge 7-2]
To keep the direction in which the wheel spins, we modified our solution code for challenge 7-1. If the wheel is spinning forward, then the sensor will detect a positive number and vice versa. The if statement that we added in the code will keep track of the count by adding or subtracting 1 to it. If the detected number from sensor 2 is positive, then it suggests that the wheel is going forward and so our count will increase by one. If is detects a negative number, then it suggests that the wheel is going backward so our count will decrease by one.



[Challenge 7-3]
Following the instruction, we have implemented the idea of H-Bridge and wired up L293D motor. To have the motor spin exactly 10 revolutions one way, stop and then back to its original position, we counted the number of counts in one revolution, which we found to be 180. Keeping record of the count, we devised the code below named "10rotate" that rotates one way and when the 'rotate' count equals 10 it rotates the other way until the count is 20.

LogoChip [Challenge 5, 6]

[Challenge 5]
To detect shadows, we implemented a photocell, which detects the amount of light coming in. We used a lantern over the photocell for better accuracy. When a shadow was over the photocell, the reading was in between 910 and 940. Therefore, to count the edges of shadows, we had the count wait until the number from reading goes below and then back up above the threshold. The video below shows detecting shadow of four fingers crossing over the photocell under the lantern for two times.




[Challenge 6]
In challenge 6, we learned to use the "second wand" and applied this method to our code below in the picture. We were able to turn on and off the two LEDs separately.