Fire Fighting Robot- Part 10 videos

Here are some videos of our test runs after our best trial runs. We were having problems with sensors detecting the candle, so most of the videos show the MotorCar spinning around trying to detect it.

In order to fix this problem, we had to re-print the values that the sensors read at those locations. It was a bit hard to do this because there was limited space for us to use because a lot of groups were using the floor space, so we weren't able to hook up our MotorCar to the computer whenever we wanted.

Another problem that we had was that the car deviated to the right after it centered on the candle at the starting line. We didn't really know why this occurred and we changed our program to try to fix this, for example we made our nudge smaller and less powerful, but the car kept shooting off to the right.

Here is a video of this:

By fixing the nudge, we were able to make the car deviate to the right less and it became less of a problem because even if the car beared to the right, it was able to see the candle at the halfway mark. In the video below, we came across this problem where the car did not stop when it was near the candle. The mechanism turned when the MotorCar was at a certain distance from the candle just like the program said but the car itself did not stop! This was so strange because we didn't have these problems before and we had not changed any part of the program. We were using the same basic program this whole time and it was strange that these problems arose when we had never seen them before.

Here is a video of this occurrence:

By the time of this video, the end of finals were coming and I had to leave for home. I had spent a lot of time working on this final challenge and although we had some successes, it was a bit disappointing to not have it work by the end of that night. Even though we were not able to extinguish the fire that night, we had learned a lot throughout this whole process about designing, programming and just trying to find a consistent and clever solution. Despite the challenges, this final project was a lot of fun and it was really satisfying when things worked exactly the way you wanted them to. I just wish that I had more time to carefully look over our program and to come up with a solution.

Fire Fighting Robot- Part 9 Best Videos

Despite some of the challenges we came across, we had some pretty successful runs. We were actually able to put out the candle, but unfortunately we did not get a video of it. We really regretted not recording this because we were not able to get the same results. This shows how inconsistent our program was. We were able to get the MotorCar to reach and put out the candle fairly quickly, but the more we worked on it, the less and less successful we were. It was extremely frustrating because we had been successful and every time we fixed a problem in our program, another problem arose. It was also very frustrating that the candles changed constantly because we always had to adjust to it and that took us a lot of time.

Below are two videos of our most successful runs. In both of them, the MotorCar just misses the candle. It would have been nice if the shaker shook left to right, instead of back and forth, in these occurences because then the candle would have definitely been extinguished.

Fire Fighting Robot- Part 8 Other Problems

To make our MotorCar perform better we added capacitors on our breadboard. Although we did not have problems with this, we wanted to prevent our LogoChip from frying up. By having the MotorCar spin left and right rapidly, it can cause the LogoChip to fry up and by using capacitors it allowed us to smooth the output of power supplies. Here is a picture of the capacitors (in blue) on our breadboard:
Another problem that we had was with programming. Because we relied a lot on counts and our straight prorportional program, we had to remember to re-set our "count a" and our "count b" back to 0 whenever we told the MotorCar to move forward for a certain amount of counts. In this video below, you can see the effect of not re-setting the counts to zero because instead of the car moving straightforward, it went off a different direction. This was a major problem because our goal was to direct the MotorCar towards the candle and it was frustrating when the car deviated away from it.

Below is a video of our MotorCar missing the target:

As you can see, the MotorCar passes the candle because the sensor values that we set in our program were off. When Esther and I tested out what the sensors read when they were very close to the candle, we recorded the values and set them in our program. However, as time went on and the candle decreased in size, which changed the values that the sensors read at that specific location. So as the MotorCar was spinning around to locate the candle, it was a bit off and it deviated away from it. This was a recurring problem that we had and in order to fix this problem, we had to constantly check our sensor values.

Fire Fighting Robot- Part 7 Problems

We came across several problems during the process of having the car finding the candle. The main problem was that the environment that the car was in constantly changed. As long as the candle was lit, it decreased in size which would change the values that the sensors would read at a certain distance. Because of this, we had to constantly change the values in our program and constantly check that the sensors were reading the same values. In order to avoid this, we tried to have the same sized candle. We had to have a relatively low candle so that it wouldn't come in contact with the shaker or burn the plastic. When it was getting too low, we changed the candle and picked a new one so that the flame would be 11cm of the ground, just to keep things consistent. Here is a picture of the size of the candle that we used:Another problem was the the sensors kept shifting. Obviously, this would alter the readings of the sensors. So in order to avoid that, we taped the sensors at the exact positions that we wanted so that would not move. This actually worked pretty well and we didn't have to worry about re-adjusting the sensors all the time.

Another problem was that baking soda isn't the best thing to work with. A lot of other groups in the class were using baking soda and it left the floor very messy. As you can see in the picture below, baking soda got everywhere and it really affected the way our MotorCar moved. The baking soda made the wheels slip and the shaft encoders don't take into account slippage, which would really affect the counts and our straight proportional program embedded in our larger program. It also affected the way the MotorCar turned. Instead of spinning quickly, it made these large circles which affected the car's position and the values that the sensors would be reading.

Here is a picture of the baking soda on the wheels:
In order to avoid this program, we cleaned the wheels regularly and we swept the floor after every test run. We sometimes had to clean the floor with water because the baking soda accumulated so much.

Another problem was a weight distribution issue. We were concerned that because most of weight was on the right side which would make the car topple over. Well it just did that. Here is a video of it:

In order to fix that we added some batteries on the back and left side of the car as weights to create some more stability. This proved to work very well because the car did not topple over again.

Fire Fighting Robot- Part 6 Picoblocks

Now that we had our mechanism down, we were able to focus on the programming aspect of the final challenge. It took a lot of trial and error to figure out to make the MotorCar find the candle. Our candle-finding algorithm consisted of using shaft encoders to have the MotorCar travel a certain distance and having several checkpoints during its path to make sure that it is directed towards the candle.

We first had the car spin left to locate the candle. Once it did, we had the MotorCar stop and since it didn't always stop precisely in front of the candle, we had it nudge in order to find a more precise position. After the car was centered on the candle, we had the car travel halfway, using the shaft encoders. Once the car reached that halfway mark, we had it spin again to center itself on the candle. Then we had it move bit more forward, so that it was had 75% of the way. We had it check again its positioning and after that point we had it inch up to the candle and check its position regularly. This would ensure that the car would always travel towards the candle. Once the MotorCar was close, we had it travel until the sensors at reached a certain value. We didn't want to MotorCar to run over the candle and since the mechanism extends out, we had the MotorCar stop a safe distance away from it, this time by not using shaft encoders but sensor values.We did this by using "wait until" blocks. So for example in the second to last block, we had the car move forward and once the sensors read a certain value, it stopped. The rest of the program was similar to that procedure and uses a lot of "wait until" blocks. For example with the checkpoints, we had the car spin left until it read a certain value and then it stopped.

This technique required us to check what the sensors read at each of the checkpoints. The problem was that these values constantly changed as the candle decreased in size and if the sensors shifted on the MotorCar. Another problem was that the car did not always move to these exact checkpoints because sometimes the MotorCar did not travel perfectly straight. So in order to account for that, we made our sensor values a bit lower so that if the MotorCar was behind its checkpoint, it would still be able to see the candle. It was just a tedious process because the sensors a very sensitive and it is hard to get accuracy in the MotorCar's movements.

Below are screenshots of our LogoChop programs:

Above are the blocks that are responsible for the basic movements of the blocks, for example like moving forward, stopping, spinning left and right. We copied these blocks from our previous LogoChip challenges in this course.

Below you can see our program, the long list of blocks to the left. It consists of various of small procedures that consist of the MotorCar checking its positioning or moving forward. As you can see, it is a pretty long program that has many parts to it. The last block turns on the motor for the mechanism and tells the shaker to shake for 8 seconds.

When we tested our program, it worked fairly well but it required a lot of patience and double checking. It would have been better if we had made a program that relied less on the shaft encoders and that moved forward according to what the sensors read, instead of having it checking for its positioning every once in a while. What we could have done was to first have the car center on the candle and then to have it keep the candle within its range of sight by using the sensors. There many other ways to solve this challenge, but some are more accurate and easier than others. I'm afraid that we did not pick the easiest solution, but that is part of engineering and it takes a lot trials and errors to figure out the best way to achieve something. By the end of the week, Esther and I didn't really have enough time to re-create a program, but we decided to work with what we had and even though we had a some pretty successful test runs, our program was not consistent in its results.

Fire Fighting Robot- Part 5 Shaker Idea

Esther and I had to think of another way to put out the candle using our mechanism. We realized that our mechanism was not good at pulling things, but it was good at pushing things and at moving back and forth relatively fast. We decided to focus on the strong aspects of our mechanism and we transformed our mechanism into a shaker. We thought about having something shake something over the candle that would put it out. It is relatively easy to put out a candle with baking soda and it is lighter than sand, so we decided to use baking soda.
In order to make a shaker, we made a piece on SolidWorks that would attach to our mechanism. We designed that extra piece according to a box-like plastic piece that we found in the engineering lab. We drilled holes in this plastic piece that small enough so that the baking soda would not just fall out while the car was in motion and large enough so that a decent amount of baking soda would sprinkle out as the shaker was shaking back and forth. In our design, the plastic piece would just fit on the delrin piece and we could remove it whenever we wanted. We attached this new delrin piece to the our mechanism by heat staking them together and this proved to be very effective because our new shaker was very sturdy. Here are some pictures of our new shaker:
As you can see, the shaker requires less support and reinforcements than with the spritzer idea. This was very nice because we could reduce the amount of Lego pieces we used as well as the overall weight of the MotorCar. We could also have a clear view of the breadboard and it made it easier for us to change wires and to connect the motor powering the mechanism to our breadboard. We were able to see very quickly how much easier it was going to work with this shaker idea rather than the spritzer idea and how much time we would save trying to make it work.

Here is a close-up picture of the new delrin piece and the plastic piece:
Here is a picture of the what our robot looked like after we finished attaching the mechanism to the robot:
To connect the NXT motor to our breadboard, we had to go back to one of our LogoChip challenges. Since these motors are designed to use a 9 volt power supply, we needed to supply it with more power and in order to do this we wired a transistor to power our NXT motor. We connected it to pin P3, so in order to turn it on and control its speed with PicoBlocks we used the "setpower3" command. We reduced the power a bit because with full power the shaker was shaking way too fast.

Now we had to figure out if it actually worked! This was the moment of truth and we were pretty nervous because we had been spending a lot of time trying to put out this candle and if it didn't work, we would have to spend more time making new reiterations.

But it worked beautifully and it put out the candle almost instantly. Here is a video of it:

As you can see in the video, the shaker is moving rapidly and that is because we removed the extra gears because now our intent was to create a fast motion and not a strong pull.

Another good thing about this mechanism is that it is very stable and even with this rapid motion, it did not fall apart. The only concern that we had was that most of the weight was on the right side and we didn't want the car to topple over. So I added some more Lego blocks to the left side of the car in order balance the car a little bit.

Fire Fighting Robot- Part 4 Spritzer Idea

As we changed the design of our robot, we continuously tested our mechanism out on the spritzer by powering the NXT motor. To our disappointment, the mechanism never worked because it wasn't powerful enough to pull the handle of the spritzer. As a result, something always broke off at the weakest point of our design. So we decided to get assistance from the professors because we were at the point where we didn't know how to make our mechanism work.

Professor Turbak first told us to focus on the mechanism without having it being attached to the robot. We would worry about attaching it to our robot later. So we designed a "spritzing unit" where the mechanism was attached to the motor, the spritzer and the Lego pieces . Unfortunately I do not have picture of this, but it looked like some kind of "spritzing gun" and we succeeded in making it pretty sturdy. Professor Turbak showed us a trick that would make our design sturdier and it was to add vertical components to our "Lego towers" so that they would not break apart. To increase the power supplied for pulling the handle, Professor Turbak also showed us that we could play around with the gears. We attached other gears of varying sizes to our main gear on the axle to increase the torque. We saw that going from small gears to big gears increased the overall torque and that it decreased speed of rotation. We ended up using a 15:1 gear ratio and we could really see a difference in the pull that the mechanism provided. Unfortunately, even with this gear ration, the mechanism still could not pull that handle.

Again, pictures would have been very helpful to show our "spritzing unit" and our gears, but in the end we ended up not continuing with our spritzing idea. Even with all the changes and reinforcements that we made on our model, the mechanism was simply not powerful enough to pull the handle on the spritzer. Every time we tested it out, something broke off of our model and it became very frustrating. To decrease the amount of force needed to pull the handle, we could have extended the handle but doing so would increase the amount of space and the amount of Lego pieces that we would need, adding weight to the car and making it harder navigate. It would also make our whole design more complex and we were not completely certain that it would successful, so because of the limited amount of time we had to complete the challenge, we thought it would be better if we left our spritzer idea behind and used our delrin mechanism for something a lot simpler.

Fire Fighting Robot- Part 3 Spritzer Idea

Today, we designed our mechanism on SolidWorks. We intended to use a servo motor to power it, but Professor Berg warned us that it would probably provide enough power to pull the handle of the spritzer. So we decided to use a NXT Lego motor along with the Lego gears (we did not want to make gears out of delrin) because they would provide enough torque. Since the NXT motor is designed to connect to Lego pieces, using this motor was a lot easier than using a servo motor because we didn't have to worry about connecting it to our robot with extra delrin pieces. Here is a picture of the motor that we are planning to use:After deciding which motor we were going to use, we were able to make the other pieces. We closely followed our Lego model for measurements, which proved to be very successful because all the pieces fit together. We used rods to connect delrin pieces together and lego pieces to connect delring pieces with lego pieces. All of our holes were designed to be loose fits so that the pieces would rotate smoothly. We then made bushings (tight fits) to secure the pieces on the rods. We made different bushings for the rods, lego rod, and lego black connecting pieces. It took us a couple designs to find the perfect bushing size and in the end they worked very well and made our mechanism stable and function wonderfully. Here is a picture of our mechanism attached to the motor:
In this picture, we placed our mechanism to the right side and our motor to the left side of the robot. We wanted to distribute the weight so that the robot would not topple to one side as it was moving. However, because the motor was separated from the mechanism with a certain distance (as we can see in the picture),when we powered our motor, the mechanism wobbled a lot and most of the energy was lost to the lego rod. The lego rod connecting the NXT motor, the gears and the delrin piece moved a lot so we decided that it was best that we take away that distance between the gear and the motor. We also decided that it would be best if the mechanism was pulling on the spritzer directly behind it, rather than having it pull it from the side. This would concentrate all the power towards pulling the spritzer.

Because of all the changes we wanted to make, we greatly altered the design of our robot. We took this opportunity to minimize the amount of lego pieces we would use in order to make our robot lighter.

Fire Fighting Robot- Part 2

Today, we focused on the programming aspect of this project. Esther and I think that this will be one of the biggest challenges of this final project, because making the MotorCar move exactly where you want is actually pretty hard, especially after finishing the LogoChip challenges. In order to detect the candle, We were given four photo transistors. We attached the photo transistors to legos so that they could move left to right and up and down and then connected them to the front of our MotorCar. Here is a picture of the photo transistors:On the breadboard, they are connected to the outputs and so on PicoBlocks, because they are sensors, we can print out the values that these photo transistors record. In order to get a feel for what kind of values the sensors gave, we attached them to the front of the car and lit a candle fairly close to it.On Picoblocks, we were able to see the values that each sensor recorded and we immediately saw that some of the sensors were weaker than others. There was great disparity in the values. For example, when the candle was up close, sensor 1 printed values below the hundreds, while sensor 4 printed out values above a thousand. This was very important to note because we would have to take in account different ranges of values for each sensor. So we designated the weaker sensors to locate the candle at a short range and the stronger sensors to locate the candle at a long range.

We decided to use 4 photo transistors: 2 for long range and 2 for short range. In doing so, we can locate the candle more accurately because the motion of the MotorCar will be restricted by two sets of limits, instead of one. This will also ensure that the car will move straight towards the candle, instead of having one sensor move straight towards the candle.

To test the long range sensors, we placed the candle 10 feet away from the MotorCar. We positioned the photo transistors (sensor 3 and 4) at our desired angle and we read the values that they gave. Sensor 4 fluctuated from 730 to 760 while Sensor 3 fluctuated from 750 and 770.

For our short range sensors, we placed the candle close to the MotorCar, at the distance at which the robot could put out the fire. Like with the long range sensors, we positioned our photo transistors (sensor 1 and 2) and read the values from PicoBlocks. Both sensor 1 and sensor 2 fluctuated around 5 and 10.

The values that we obtained are very important because we will use them in our program to ensure that the MotorCar is moving straight towards the candle and that it stops at the proper distance from it.

Below is a picture of how we placed the candle in order to test the values from the photo transistors.

Fire Fighting Robot- Part 1

For our final project in this class, the challenge is to make a fire fighting robot. We can use and build upon our existing MotorCar and use a mechanism primarily built from laser cut parts. The goal is to extinguish a candle that will be placed 10 feet away from the MotorCar. The car will not be necessarily placed directly facing the candle. We are also limited to one motor to power our mechanism.

Esther and I first started brainstorming about different ways to put out a fire. We needed to think of a clever, yet simple, idea that would get the job done because we knew that we did not have a lot of time to complete this project. So we had a few ideas:

1. snuffing the candle
2. using vinegar and baking soda
3. "pinching" the flame
4. throwing a heavy fabric on top of the flame
5. using a spritzer

In the end, we decided to go with the spritzer idea because it put out the flame effectively and also because no previous groups, that we know of, had used a spritzer. For example, we really liked the snuffing idea, but a previous group created a really cool robot with a snuffer and we really wanted to be original.

So we looked at the spritzers that were located in the room. We decided to use the green and white spritzer because it had the most powerful spray and because it had a longer handle which would help us get a good grip on it. We knew that the size of the bottle were too big and would probably make the MotorCar topple over, so we had to find a replacement.

Now that we knew with what we were going to extinguish the fire with, we had to figure out a mechanism to actually do it. We decided that it would be best to pull the handle in repeatedly until the candle was out. We thought that we could attach a string to the bottle, which would lie on the handle and be pulled on the other end. The question now was, how to pull the string back a forth?

We looked at previous motion modules. For example, like the one below. We could tie the string to the end and have a motor rotating the circle piece, which would pull the string and in the end pull the handle in. The good thing about this mechanism is that we could just continuously rotate it would just move the string back and forth.
So using that motion module, would be relatively simple but the problem is that we didn't know how strong it could be. It takes a certain amount of power to pull the handle in and we didn't think that this motion module was powerful enough for that. So looked at a different mechanism. This time we looked at a project from last year and we were intrigued with their idea. Below is a picture of it. As you rotate the gear, the Lego blocks contract and extend. This is the kind of motion that we were interested in and it looked a lot sturdier than the other motion module. It is a bit more complex than the other, but we thought that it would be more effective.
Now we had to think of various ways to place all these elements on the MotorCar. This was a bit tricky because had to make sure that the MotorCar and our bottle wouldn't topple over and that our mechanism wouldn't get in the way of the photo transistors and breadboard.

Here are some our sketches describing the motion that we wanted and how we wanted to design our robot.


I went to a convenience store and bought a small bottle to which I attached the spritzer. Here is a picture of it:
We tested it out just to see if it would still work and it did! So now that we reduced the size of the bottle, we were able to start modifying our MotorCar. We decided to place the spritzer in the front of the MotorCar above the breadboard. We attached the photo transistors to the side in the front, so that nothing could interfere with them. Because the spritzer is placed so high, we knew that would have to use a tall candle.
Then, we wanted to incorporate the mechanism into our design. Instead of directly creating the pieces on SolidWorks, we wanted to see how it would fit on the MotorCar so we could make precise measurements. Below is a sketch of our motion module:

Instead of having a gear to make the motion module move, we wanted to directly attach the pieces to the rotating motor. Professor Turbak said that it was possible to press fit a wire on the delrin with the motor, so we would definitely use that technique to attach the two pieces. We made a model in Legos and made a foundations on the MotorCar to support it. We would use the exact same dimensions as the Lego pieces when creating our pieces on SolidWorks. We also have to imagine that a string would be attached to the end of the mechanism and to the bottle. Here is a picture of what our basic design looks like.

Final Challenge-9

For the last part of this challenge, we combined everything that we learned into one program. Our goal was to make the MotorCar move straight for 10 feet up the ramp. In doing so, we used our straight-proportional program and our nudge program. So we combined these programs together and basically looks the same as our previous program from challenge 8. However, this time when we tested our MotorCar on the ramp, it didn't move straight. It was very strange because in our previous programs, it had successfully moved up the ramp without falling off numerous times. So we decided to take a closer look at our straight-proportional program. We saw that there were a few problems in our program. We first created a "protect" block that would ensure that the power settings would remain withing the range of 0 and 10000. Before, we did not have a way to limit the setpowers and if our they were set to numbers that were negative or higher than the full power, it might have caused our proportional program not to work properly. The second thing that we did was to change the equation that determined our proportional control. We did not know that LogoChip did not consider order operations. It reads an equation from left to right. Therefore, LogoChip misinterpreted our equation to be (10000-count-)*800. While this is what we intended our equation to be: 10000-(count-*800). So we altered the order of our equation. This is a picture showing the changes that we made:

This is our program for the protect block:

These are the blocks that determine proportional control:
These are our nudge and straight-proportional blocks:
and we combined them to create a program to make the car go exactly ten feet:

After making those changes, we tested our program and this time the MotorCar wobbled and still beared to the right. To decrease the wobbling we decreased our gain from 800 to 200. But even after changing the gain, the car still beared to the right. So then we decided that the problem was in the wheels. To test that out, we switched the two wheels and tested our program again. The problem did lie in the wheels because the car, this time, beared left. There must have been a slight difference in the diameter of the wheels which would have completely thrown off the counts and made our proportional program ineffective. So we tested out different wheels until we found a pair that would make the MotorCar move the straightest.

This is a video of our MotorCar moving up the ramp. The car moved fairly straight but we had to nudge it a little bit so that it wouldn't fall off. We were disappointed that we had to do this because in previous challenges, our car was able to move along the ramp without falling. However, the car stopped really close to the 10 feet target.

This is a video of our MotorCar moving down the ramp. Like when going up the ramp, we had to slightly nudge our MotorCar. The car did, however, stop fairly close to the 10 feet target.

The last two videos are of the MotorCar on the concrete floor and on the carpet, respectively. On both of these surfaces, the car beared to the right. On the carpet, it beared greatly to the right. These tests were one of the worst out of all our LogoChip challenges. We didn't really understand why this happened because our programs were working fine before. So one of the reasons that our final programs didn't work as well was that the wheels were changed, which would have messed up our counts because the wheels are not exactly the same. Unfortunately, we didn't have much time to invest in fixing this problem because Esther and I had to concentrate on the final project. However, we will certainly use our straight proportional program in our final project because our robot would have to move straight for 10ft to reach the candle.

Final Challenge-8

For this part of the challenge, we created a "nudge" procedure that caused the car to move a very small distance for a brief moment. Because with proportional control, the car can overshoot or undershoot its target, so we used nudging to make the movement of the car more accurate. We used this program to make the MotorCar repeatedly move up or back up towards the target. This procedure would help us make the MotorCar get closer to the target of 10 feet up the ramp. This is a picture of our nudge program:

This is a picture of our nudge program: Our nudge program consists of backing up and moving forward at a lower power. If the count was higher than a certain count then the car would back up and if the count was lower than a certain count then the car would move up. We then added a last part that would make the car coast once the car was at a certain range of the count. After completing the "nudge" procedure, we combined it with our " straight proportional control" procedure.

Our "straight proportional control" was a set to stop the car at a certain count. Our count was 3050 and it made the car move exactly ten feet on the concrete floor. This is a picture of this procedure:

We then combined these programs with an "init" block that would start the count and "forward" blocks that would start moving the MotorCar. This is a picture of our final program:
So we tested it out on the ramp and the car did not reach the 10 feet mark but it came up very close. This is a picture that shows how close the car came to the target:
One of the reasons we think that the car make the 10 feet mark was that it slipped on its way up the ramp. The skidding would create problems with the counts, making it miss the 10 feet mark. So we decided to lower the incline which would reduce the slippage. This is a picture of how far we moved the ramp down:
So we retested our procedure and we found that the car moved a lot closet to the 10 feet mark. This means that the more the ramp was level with the ground, the more the car would reach the target.
We then tested our procedure in different situations. We had the car go downhill and like previous tests, it went past the 10 feet mark. In this situation, the car slipped, making the car overshoot the target. This is how far the car passed the target:
We then tested it out on the carpet. And unlike our previous tests, the car made the 10 feet mark exactly. Here is a picture of the car after the procedure was done:
This is a video of the car moving on the concrete floor and nudging towards the 10 feet mark:

Final Challenge-7

For this challenge, we created a procedure that uses proportional control to make our car go exactly ten feet. Like the previous challenge, we combined two of our older programs "go ten feet" and "proportional control". However, instead of using time to control when the motors were running, we used the counts with the use of shaft encoders. We used our unit of .037 inch/count to figure out how many counts where needed to go a distance of 1o feet. We obtained a total count of 3243 and we tested it out to see it worked, but the car passed the 10 feet mark. So we lowered the count to 2960. So this is the program we came up with:

Like in the previous challenge, we made the car coast instead of braking. Below is a picture of our power settings and how they are a product of a constant gain factor and the average of the shaft-encoder variables.
After making our program, we tested it out on the concrete floor. It worked extremely well (moved very straight) and stopped exactly where it was supposed to.

Here is a video of it:

We then tried it on the carpet. The MotorCar beared right slightly, not as badly as it did when it was running under the "bang bang distance" program. This time, the car stopped short by 2 inches of the 10 feet mark.

Here is a video of it:

We then tested our program with the car going up the ramp. We were impressed because the car moved very straight and it came closer to the mark then when it was running the "Bang Bang" distance. It was about 4 inches short of the 10 feet mark.

Finally, we tested it out with the car going down the ramp. The car beared to the right but it straightened out very well, which made us very happy and convinced us that our proportional control was working. The car did not pass the 10 feet mark as much as it did the "Bang Bang" distance control. Instead of being off by a foot, it was off by around 6 inches. Here is a video of it:

These trials showed us that the proportional control worked much better than the bang bang control for this distance challenge. But we were still unable to make the car stop exactly at the 10 feet mark on the three surfaces (upramp, downramp, carpet).

We then tested out different gains because we wanted to see how it affected the motion of the MotorCar on the concrete floor. Our original gain was 800. We first tried a lower gain of 100. This resulted in the car deviating right. It still went 10 feet, but it did not go straight at all. We then tried a higher gain of 1300. The car still went 10 feet but it also deviated to the right. This showed us that we had the right gain and that changing it would really affect the results and if we had tested it out the ramp, the car would have surely fallen off.

Final Challenge-6

For this part of the challenge, Esther and I wrote a procedure that used bang-bang control to make our car go exactly 10 feet. We also had to stop the motors only by coasting, not by braking. In order to achieve this, we combined our "go ten feet" and "bang bang control" programs into one. We used time to tell when the motor needed to coast. The time we used for our program was lower than the one we used for the "go ten feet" procedure, because we had to take into the account the extra time it took for the motor to stop, since it was coasting.

This is a picture of our program:

We then tested out our procedure on different surfaces. We first tried it on the concrete floor and it worked very well. The car fairly straight and it stopped exactly at the 10feet mark.

Here is a video of this:

We then tested it with the car going up the ramp. The car beared slightly left but it did not fall off. It was short of the 10 feet mark by around 8 inches. Here is a video of this:

We then tested it with the car going down the ramp. The car almost fell off as it beared right, but managed to straighten out very nicely. The car passed the 10 feet mark by almost a foot. Here is a video of this:

Our final surface was the carpet. We measured out ten feet on the carpet. This was the least successful trial because the car beared left very noticeably and it missed the 10 feet mark by 3 inches. Here is a video of this:

Final Challenge-5

For this part of the challenge, we wrote a procedure that would make our car travel approximately 2 feet, then reverse and return to where it started from. For this challenge, we copied the program for the previous challenge. Since we know that the distance per count is about the same for the left and right wheel, we were able to find how many counts was needed to travel 2 feet. We multiplied 2 feet by 12 to get 24 inches and then divided that amount by .037 inches/count to get a value of 648 counts. We first tested that value on the program that we created earlier and the car did in fact travel 2 feet.

In order to create this procedure, we made two programs (one for the forward directionand the other for the reverse direction). This a picture of these two programs, entitled "2ftfor" and "2ftback":
We then combined them under our "bandf" program (back and forth). We remembered to add a wait of .2 seconds in between the two directions. We also remembered to put a "stopstack" block at the end of both our programs so that they would hand over the control.

This is a picture of our final program:

This is a video of our "bandf" program.

We saw that when the car reversed and went towards its original location, it didn't quite make it. It about an inch to go before it attained its original starting position. To fix that, we can alter the count on our"2ftback" program.

We then test our program with the car starting uphill on the ramp. As the car moved up, it didn't make reach the 2 feet mark. As the car reversed, it went passed its original location by a couple of inches.

When we started the car going downhill, the car passed the 2 feet mark and as it tried to reverse, its skidded for a couple of seconds and proceeded to travel back up, but it did not reach its original location.

After that, we created a program that would repeat this process 3 times. This is what our program looked like:

We first tried it on the concrete floor. The car ended ip being much further from the starting line ( by a couple of inches). When we tried it on the ramp, with the car first travelling up, the car went further back from the starting line by a couple of inches.

Final Challenge-4

For this part of the challenge, we developed a procedure that that made our MotorCar go exactly 10 feet. We used a timer to control the amount of time the motor would be on for. . In order to figure out this time we timed how long it took for our car to move 10 feet on the concrete floor. The times that we obtain were not very consistent because the MotorCar did not travel in a perfect straight line. However, we were not worried about the vehicle moving straight at this point. So our average time was around 8.86 seconds and we incorporated it into our program. In PicoBlocks 1 seconds corresponds to 1000, so 8.86 seconds would be 8860. We first tried out our program with the motor stopping after the times exceeded 8.86 seconds and the MotorCar passed the 10 feet mark by an inch. So we decided to lower the time to 8.5 seconds. When tried it on our MotorCar, the car stopped exactly at the line!

Here is our program on PicoBlocks:

And here is a video of our MotorCar travelling 10 feet:

After making sure that our program worked on the concrete floor we tried it in different situations. When we tried it with the car going uphill, it stopped short of the 10 feet mark by a foot. When we tried it with the car going downhill, it passed the 10 feet mark by 3/4 of a foot. The fact that the car is travelling downhill or uphill definitely matters because the car moves slower as it travels up and moves faster as it travels down the ramp.

We then replaced our "stop" block with a "coast" block to see the difference between the distances that the car would travel. In fact, when the car coasted at the end of 8.5 seconds, it passed the 10 feet mark by a couple of inches.

We then, using the shaft encoders, measured how many "counts" it took for the car to travel that distance. We created a program that printed "count a " and "count b" for 8.5 seconds.

"count a" was 3237 and "count b" was 3225. All of these measurements were taken on the flat concrete floor.

This is a picture of the program that allowed us to obtain the counts:

We then figured out how far was one "count". We divided 10 feet with the counts that we obtained and the result was that for both "count a" and "count b", the car moves .037 inches per count.

If the car were to skid, which means that the car would move but the wheels would not spin, the distance per count would increase.

If the car were to slip, which means that the car would not move but the wheels would still spin, the distance per count would decrease.

Final Challenge-3

For this part of the challenge, Esther and I created a program that uses proportional control to make the MotorCar go straighter. In order to do this we changed our previous Bang-Bang control program. Instead of the "set power" blocks to be fixed to a certain value, we made them vary according to the count difference. When the count was positive, we subtracted the difference times a gain (a coefficient) with the total power (10000). When the count negative, we added the count difference times the gain to the full power. This means that if the count difference is small then the set power will be set to a value closer to full power, which would make the vehicle only bear slightly left/right. If the count difference is great then the set power will be set to a value much smaller than full power, which would make the vehicle bear left/right much more. We had to figure out what gain we needed to incorporate in our program. After a couple trial and error runs, we found that the gain value of 800 was the correct one and made the MotorCar move very straight. This is a picture showing our "set power"blocks:This is a picture of our "straight porprotional" program. Except for the "set power" blocks, it looks exactly the same as the Bang-Bang control program.
We first tested our program on the concrete floor along the tape line. The MotorCar stayed within the line, but it beared to the right slighty. This is a video of it:

We then tested our program up on the ramp. The MotorCar successfully managed to reach the top without falling. This is a video of it:

Then we tested our program down the ramp. The MotorCar beared to the left and was very close to falling off. This is a video of it:

Then we tested our program on the carpet. The MotorCar didn't move as straight on this surface compared to the other ones. But it did not deviate too drastically. This is a video of it:

After testing our program on different surfaces, we tested by altering the friction on the wheels. When both wheels had low friction, the MotorCar moved fairly straight and beared slightly to the right. When one wheel (left wheel) had high friction, the MotorCar moved just like when both wheels had low friction. Finally, we set both wheels to have high friction and the MotorCar moved very straight! It followed the tape line perfectly!

Then we tested to see how changing the gain would affect the MotorCar's straightness. When we set the gain to be 50, the MotorCar drastically turned towards the right. When we set the gain to be 500, the vehicle wobbled a bit and beared to the right. Then we set the gain to be 1110 and 1550, the MotorCar beared to the right but not as noticeably as when the gain was set to a much lower number. We finally tried 900 and 700 and the MotoCar moved fairly straight but beared slightly to the right. After testing all these different values, we re-tried our program with the value of 800. The MotorCar moved very straight and it showed us that we were able to constantly reproduce a straight path when our gain was set to that value.

Final Challenge-2

For this challenge, Esther and I used Bang Bang control to make our MotorCar to move straighter. In class, Professor Berg showed us a visual example of Bang Bang control with a sensor, a candle, and a fan. The sensor was placed above the candle. In his program, he wanted the temperature to stay constant so when the sensor sensed that the temperature was a above a certain point, then the fan would start. When the temperature was a below a certain point, the fan would stop. The graph for the program oscillated and that is a characteristic of Bang Bang control.

We used the count difference (count b- count a) to determine whether the Motorcar should bear left or bear right and thereby constantly adjusting itself to move in straight line. We saw that when the count was positive, the Motocar drifted towards the right and we needed to add friction to the left wheel so that it would bear left. When the count was positive, the Motorcar drifted to the left and we needed to add friction to the right wheel so that it would bear right.
So we created a program "s-bb" that used the "if then else" blocks and the "bear left" and "bear right" blocks that we made in the previous challenge.
We added a print statement so that we could see the count difference and we could also see the oscillation because the count would vary from -3 to 3.
This is our program:
We had some difficulties writing this program because some of the blocks that we used, such as the "forward", "bear left", and "bear right" blocks, had forever loops in them. Since the forever loops never give up control, the program that we had written up above never worked. When we ran the program, the Motorcar would just move forward forever. So this was one of our major problems. We had another problem that made things a little bit confusing. We had our left wheel associated with count b and our right wheel associated with count a. We should have had it the other way, so in order to correct this we just switched the wires so that the right wheel would be connected to inputs 1 and 2 and the left wheel would be connected to inputs 3 and 4. By having these mixed up, we were not able to correctly use the count difference and had the wrong notion of what happened when the count difference was negative and positive. However, when we took away the forever loops and connected the wheels to the right inputs, our program worked really well.
We played around with the power settings hidden in the "bear left" and "bear right" blocks. We had previously had the power settings reduced to 9000 and when we ran the program, we could see a minor wobble in the Motorcar, hence the oscillation. So we decided to make the difference slightly smaller by have the the power settings reduced to 9700. When we ran that program, the Motorcar did not wobble and moved straight!

So we tried our program on different surfaces.

We first tried it on up on the ramp. Here is a quick video of it:

Then we tried it down on the ramp. We found that the MotorCar moved a lot straighter while it was going down the ramp and than up the ramp. As it was going up the ramp, it beared right a little bit and wasn't able to make it all the way to the top. However, the MotorCar was able to make it all the way down the ramp without falling off.
Here is a video of it:

When then just tried our program on the concrete floor along a tape line. Here is a video of it:

When we set our MotorCar on the carpet, it did not go as straight as it did on the concrete floor.
Here is a video of it:

We then tested out program under different conditions. We first set both wheels to have low friction. The result was that the MotorCar went fairly straight on the tape line but it beared right slightly in the end. Then we gave one wheel (the right wheel) higher friction and the result was that the MotoCar wobbled a lot more than before and this time it beared slightly to the left. Finally, we set both wheels to have a higher friction. This time the MotorCar moved the straightest along the tape line , even if was a bit wobbly.