Firefighter: Finishing Up

I left on Sunday to go home so my partner was awesome and showed Lyn and Professor Berg our robot by herself.

Apparently there were some slight problems. Lyn changed the program for the servo motor so my partner had to change the angles for the motor so that it worked properly. She changed both the starting angle and the ending angle so that the cup did no try to go beyond the base/platform that it is resting on and so that it didn't go so far that it hit the middle sensor. Neither of these were problems before but I guess the angles got messed up when the program was changed.

She also said that changing to new batteries made the car so significantly faster although it still did not go as fast at the other cars.

Other than that, from what I heard our robot successfully put the fire out. I know that it can repeatedly put the fire out because I tested it many times before Monday. I have full confidence that, as long as the sensors are correct, the batteries are full and the candle is at a reasonable height, our robot will put out the flame. (It sounds like a lot of conditions but its really not that many... )

Firefighter: Everything Together

After got the shaker to work and everything assembled. We started our first test run with everything together. And it ended up being rather disastrous. The car fell over when the salt shaker went forward because there ended up being too much weight in the front when the cup went forwards. So we added weight to the back of the car in the form of other lego motors. This successfully solved that problem.

The next problem that we came across was that the car would continue into the next nudge and find2 loop before the previous putout process was over. We made the iteration of adding waits after all of the putout processes so that the program would wait until they were done until going on in the loop. We had to play with out how long the waits would be.

Another problem that we came across was that the car would start stalling during find1. We found that adjustments of the sensor angles fixed this. Because the program relies heavily on feedback from the sensors, the program is very sensitive to the angles of the sensors.

This is a video of our robot. It moves very slow...

Firefighter: Getting the Shaker to Work

After talking to Lyn, we figured out that we were using the wrong motor. Instead of the continuous servo motor, we had to use the regular servo motor. This was the motor that we could program to go a certain angle.

Lyn gave us this program.

Then, we just played with programming until we figured out how to get it to work and go the distance that we wanted it to. These are the numbers for the angles that we came up with.

Firefighter: To the Flame

We started the programming without the putting-out mechanism because we couldn't get the servo motor to work properly.

Luckily, when we started, we knew where we wanted the sensors to be placed and had some idea of how we were going to get the car to determine where the candle is. We used three sensors, one right in the middle, and one on either side of the car.

When looking at the car from behind:

Sensor 1 = left sensor

Sensor 2 = middle sensor

Sensor 3 = right sensor

We started out by getting a sense of how the sensors would read at different positions and at different distances. Programs to read each of the sensor readings at different positions.

We tested from close up what each sensor read when the car was looking straight at the candle, when it was turned right and when it was turned left. We did the same for when the car was 10 feet away. As we had hoped for, when the car was looking straight at it, the middle sensor read the highest, when it was turned right, the left sensor read higher and when it was turned left, the right sensor read higher. This was the information we needed for the car to guide itself to the candle using feedback from the sensors.

These were the simple procedures that we used at the foundation of our program.

The first thing that we decided was that the program had to be split into different sections. The first was getting the car to face the candle initially before it started heading towards the candle. So we made it spin in one direction until the middle sensor hit a certain number and then keep adjusting itself until the middle sensor hit a higher, more precise number.

Find1

It ended up that we probably didn't need the second part of this adjustment because in practice, the car usually just stopped after the initial turning and then went on to the next part of the program.

The next section of the program was the actual driving to the candle part. We didn't really trust any of the bang bang or proportional controls for straightness. So we decided to use feedback, not from the shaft encoders, but from the sensors to guide the car. We implemented a program similar to the bang bang control we used earlier. If either of the side sensors reads larger than the other one, the car will bear in a certain direction. This happens until the middle sensor reads a certain number and, since we knew that thresholds from the sensors are not very reliable, the count is above a certain number.

Go

Once it got to the candle we also added in a safety-net find program that would reposition the car so that it is facing the candle just in case it was not facing the candle after driving there.

Find2

We also knew that we needed a put-out mechanism but we didn't have one at this point because we needed to ask Lyn how to get that to work.

So we put it all together and ended up with this (only we did not have the waits at this point, those were an iteration that we added on after we got the put out mechanism to work). We figured that that the car did not get to the candle every time depending on how much it swerved. We programed the car so that once the 'go' function was over, it would nudge and put out until the sensors sensed that the candle was out.

One thing is that the car drives very slowly but we don't quite know why it does this.

Firefighter: Putting out the Flame

One of the first ideas that my partner came up with was using borox (which is a type of laundry detergent) to put out the fire. We also came up with ideas like using the spray bottle and smothering the flame. But we ended up just running with the borox idea.

We experimented with a bit of borox. When we mixed it with water we found that we didn't really need to hit the flame directly at all to get it to go out. The only way that we could think of for getting the dissolved borox onto the flame was using a spray bottle so we kept thinking.

We also thought of ways that we could just use powdered borox. We came up with the idea of just tipping over a cup containing the borox. We also came up with a clever idea of having a cup with holes at the bottom. We could then have a fan-like thing start spinning once we got over the flame so that it would hopefully disturb the powder so that it came out the bottom. One of the concerns we had for this design was the way that that the weight would be distributed. In this design, all of the weight from the mechanism and the motor are on the front of the car.

What we ended up with was a shalt shaker design. This consisted of caging a cup in with a delrin top that has holes drilled into the top. The caged in salt shaker would be connected to a servo motor which would carry the cup over the top of the car onto the flame in front.

This piece is what connects to the servo motor.

This is the second part of the cage portion. This one would line up perpendicular to the other piece and the notch on th bottom of this piece fits into the notch at the top of the other one.

The hooks on the tops of the previous two pieces would fit into the four rectangles at the top piece. This is what covers the top of the cup and acts as the salt shaker. My partner expertly drilled holes all over this plain circle using the drill press to make it into the salt shaker.

When we first printed all of the pieces out, we realized that we couldn't really get the pieces to all fit together because the cage was too tightly fit. We just needed a simple iteration for it to all fit together though. We just shortened the 'teeth' (that fit into the shaker top) of the first piece above (the one with the arm that connects to the servo motor) so that the cup would pop into the cage. It was a pretty frustrating problem that ended up being solved by a very small iteration. It was just a couple of millimeters off of that portion of the piece.

This is what the salt shaker looked like after it was all assembled.

We connected our salt shaker to a continuous servo motor (which we later learned was a the wrong motor we wanted the regular servo motor). In order to get it to go the distance we wanted we tried to use a time. But as can probably be predicted this didn't work very well. The angle changed every time the motor went back and forth and it was extremely unpredictable.

We knew that the servo motor could be programmed to go a certain angle because other groups had done it in the walking robot challenge but we couldn't figure it out.

So we just decided to go on and start creating the program for finding and getting to the candle. And then we could ask Lyn about the motor the next day.

Later on, the salt shaker ended up being a very useful mechanism because it allowed the car to try putting the candle out multiple times. The putting-out mechanism was not a one shot deal and this was good because our program ended up making good use of this feature of the salt shaker.

Final Logochip Challenge 9: All Together Now

This was out complicated program for combining the proportional straightness and proportional distance with nudging. As we said before, the straightness with proportional control did not seen to work very well and the same was true with this program. The distance was okay but the car did not seem to control its straightness very well.

Final Logochip Challenge 8: Distance with Nudging

This program would nudge the car until it got to the line. We needed to add this onto the proportional control for distance because the car would always stop short. This is because the motor would not have enough power by the end to overcome friction. With the nudging, the car power on the motors would turn on and off and the car would inch up the the line until the shaft encoders hit a certain number.

The program worked very well just on the ground of the lab. Going uphill the program worked reasonably well but was always a little bit short of reaching the full ten feet. The nudging also was very crooked on the uphill for some reason. The car was constantly veering off in its nudges. On the other hand, going downhill, the program seemed to always overshoot by a little but and also have some trouble stopping.

Final Logochip Challenge 7: Distance with Proportional Control

We created this program for distance using proportional control. It was hard to figure out what 'n' should be set as because the direction were kind of confusing to us. However, we made this our program. The distance was very close but would never quite get there because the power in the motors would be too low to overcome the friction. We could tell because we could hear the high pitched sound of the motor trying to turn.

Final Logochip Challenge 6: Distance with Bang-Bang Control

This was our first complicated program. We had a lot of trouble with this challenge and mostly because we were not doing the right challenge. We had thought that we needed to combing the bang bang straightness and the bang bang control so the program that we were trying to do was rather complicated.

However, we did eventually figure out that the program was for bang bang distance and was relatively simple. So this is what we ended up with. The distance was always pretty good but it would always overshoot or undershoot by a little bit.

Final Logochip Challenge 5: Simple Back and Forth

This program uses the shaft encoders to have the car go ten feet and back again. Works much better than using the time. It was similar to when we had the one wheel turn ten times and then turn back ten times only this time it was with both wheels on the car. The car comes very close to where it started. However, it does not come as close if it is going up and down hill. In an inclined situation, if the procedure is invoked three times, the car gets further and further from the starting point.

Final Logochip Challenge 4: Simple Distance

Controlling the distance with time did not work well at all. Especially if any of the other variables were changed.

If there was any slipping or sliding of the wheels, the shaft encoders would not be accurate in determining the distance that the car traveled.

Final Logochip Challenge 3: Straightness with Proportional Control

Final Logochip Challenge 2: Straightness with Bang-Bang Control

This was straightness with bang-bang-control. We liked this straightness control. The car does wiggle a little bit and more when there is friction on the wheels but the car does drive very straight.

Final Logochip Challenge 1: Simple Straightness

For this we just implemented the 'forward' function that we created in the previous challenge. The forward function goes fairly straight when there is no friction on either wheel. However, when we put friction on either or both wheels the car did not go so straight anymore.... at all.

Logochip Challenge 8 – MotorCar Construction and Programming

These are some pictures of our completed motor car.

And these are the procedures that will make the car go forwads, backwards, coast, brake, spin right, spin left, bear right and bear left.

Logochip Challenge 7 – Shaft Encoding

We finally connected to the lego motors for this challenge. Getting everything connected correctly was a bit of a challenge because we had so many wires in the board at that point. Once we got everything connected and working we realized that we had to use the oscilloscope. So we had to get help with that... again. Finally, after we got everything set up correctly, the program that counts the shaft encoding is in the upper-left hand corner.

The other stuff is a failed and very complicated version of getting the shaft encoder to determine the direction of the motor.

We ended up with this program which counts up when the motor is turned forwards and counts down when the motor is turned backwards.
The top few programs control the motor in making it coast, brake, go forwards (thisway) and backwards (thatway).

The program below makes the motor go thisway for ten revolutions and then thatway for ten revolutions. We did this by determining the count for one revolution and then multiplying that by ten. Then we had the motor turn thisway until the count reached ten revolutions and then thatway until the count went back to zero.

Logochip Challenge 6: Detecting Multiple Edges in a Single Thread

In this challenge we couldn't use the 'waituntil' functions because then the code would stop at the 'waituntil'. This means that it wouldn't read if the other switch was pressed. We had to use something else and the clever solution is the 'if-then' or the 'if-then-else' statements.

Logochip - Challenge 5: Shadow Detector

For this challenge we had to wire into the photocell which was not too hard. But was also had to use the oscilloscope again. Which was, again, a problem. I just don't think we are getting too used to this oscilloscope thing. But we had to ask for help again in getting the oscilloscope to work correctly. But after that things went smoothly. This challenge was really similar to detecting edges with a switch. We just had to read what the values were when there was a shadow and when there wasn't a shadow. For this challenge, we counted how many fingers passed over the photocell which was similar to counting how many times we pressed the switch.

Logochip - Challenge 4: Zero to Sixty

We had to wire a transistor into the board for this challenge. After that, actually making the program wasn't too hard. It was more of using the 'n' and figuring out how to effectively change the value of 'n' every time through the loop.