SciBorg Part 2 (Drive Straight, Follow the Line, Follow Another SciBorg)

Drive Straight

Our next task was to implement bang-bang control to make the SciBorg drive straighter. We wrote a program that only gave the SciBorg three options: drive with both motors at the same fixed speed, make a gentle left turn, or make a gentle right turn. We decided to use the motor encoder for this task to determine which direction the SciBorg was straying. If the position of motor 2 (the left motor) is greater than that of motor 1, that means motor 2 is travelling faster, so the SciBorg is turning right. This must be corrected with a gentle left turn. We defined a gentle left turn as motor 1 speed 5 faster than motor 2 speed. If the position of motor 1 (the right motor) is greater than that of motor 2, that means motor 1 is travelling faster, so the SciBorg is turning left. This must be corrected with a gentle right turn. We defined a gentle left turn as motor 2 speed 5 faster than motor 1 speed. If both motors are at the same position, the SciBorg is driving straight, so nothing should be done (that is, both motors should continue at the same speed).  Here is a picture of our code and videos of the SciBorg travelling on different surfaces. 

On the Lab Floor

The SciBorg goes straighter, but it's obviously not perfect. Towards the end, you can see that it's veering to the left. 

On the Carpet 

There's more friction on the carpet, so you can see the SciBorg shaking a bit. It also appears to veer right in the beginning and left towards the end. 

Going Up the Ramp

As you can see, the SciBorg veers to the right and falls off the ramp pretty quickly.

Going Down the Ramp

The SciBorg veers to the left and falls off the same side of the ramp as when it was going up. This made us think that the ramp was crooked or provided different friction forces to the two wheels. The SciBorg appeared to make it farther down the ramp before falling off than it did up the ramp.

Conclusion

It's very difficult to get the SciBorg to drive straight. Its path depends greatly on the surface it's driving on, but it seemed to do best on the lab floor. The various surfaces certainly all provide different frictional forces, which probably affects its path. I wonder what the coefficients of friction are for each of the surfaces and what the optimal coefficient is. I also wonder what the coefficient of friction between rubber car tires and asphalt is. It also may not be entirely the surface's fault that we could never get our car to drive straight. Perhaps we had a fault in our logic. I'm not sure if the assumption that equal motor positions means the car is going straight is true. The differences in speed between the two motors can be inconsistent, and the way we defined our gentle turns was pretty arbitrary. I'm thinking that perhaps if the SciBorg veers to the left (with a natural speed difference between the motors that is greater than or less than 5)  and we try to correct it with a gentle right turn (with a programmed speed difference of 5), maybe when the motor positions become equal again, it won't necessarily be pointing straight. I don't think using the motor encoder with this strategy was the best way to make the SciBorg drive straight. We had a couple other ideas: First, put a straight line of white tape down and, using the light sensor, program the SciBorg to follow the line. Second, put a narrow delrin board 2 feet behind wherever you want the SciBorg to stop (as documented in my last blog post). Put another delrin to the left and 1 foot behind the first delrin board. Put a third delrin board to the right and 2 ft behind the first board. This way, the three boards are staggered, and the ultrasonic sensor would have different readings depending on which one it was pointing at. Then, you could program the SciBorg to make a gentle right turn if the ultrasonic sensor reading was consistent with facing the left delrin board, or make a gentle left turn if it was facing the right board. However, both of these methods are pretty complicated and involve augmenting the lab floor course, which I'm not sure if we were allowed to do. I feel like there must be a better way that we haven't thought of yet. 

Bang-Bang Line Following

Our next challenge was to use our brightness sensor to make our Sciborg follow a zigzagging line. We tried for a very long time with no success to get this to work. Finally, we came to the realization that using while loops to make the SciBorg follow the edge of the white line would be our best bet. We found that the edge of the white line had a brightness reading in the 80s (depending on how much white vs. brown was under the sensor), so we decided to use a value of 80. We coded the SciBorg so that while it saw a brightness of less than 80 (meaning it's over wood), it should make a hard left. Once it sees a brightness of greater than 80 (meaning it's over the white tape), it should make a hard right, and then repeat the loop. (Note: In the code below, we accidentally named the right turn left and the left turn right!) The trickiest part was fine-tuning the speeds of each motor in the turn definitions. The turns had to be hard enough that the SciBorg could handle the sharp turns on the course. Here is a picture of our code and a video of our SciBorg following the line. 

Follow Things

Our final challenge was to make our SciBorgs follow each other in a line. We wrote a program using the ultrasonic sensor that told the SciBorg to drive if the object in front of it was more than 2 feet away, and stop otherwise. We used an ultrasonic reading value of 37 to correspond to an object 2 feet away (details in my last blog post). Here is a picture of our code and videos of our SciBorg following me and another SciBorg. 

Following Me

Following Another SciBorg

This was pretty neat! It was easier to make the SciBorg follow me because I could sense when it was veering and adjust my position so that it would continue following me. Even though the SciBorgs didn't drive completely straight, they still stayed in line for quite some time.

SciBorg Part 2 (Sensors and Stopping After 5 Feet)

Our first challenge was to explore different sensors (an ultrasonic sensor, a light sensor, a motor encoder, and a switch) to understand how they work, and then use each sensor to make our SciBorg travel a predefined distance and then stop. We then analyzed the advantages and disadvantages of each sensor and came to a conclusion about which was most effective.

Motor Encoder

The first sensor we tried out was the motor encoder, which reports the position of the motor at a specific time. We ran a program which made motor 1 repeatedly spin forwards at speed 225 for 1 second, then spin backwards at speed 225 for 1 second. The program printed out the position of the motor at the end of each loop (once per second). One would expect the motor to spin forward x amount, so that the first position recorded is x, and then spin a distance of -x, so that the 2nd position recorded is 0 (x-x=0). However, as you can see in the picture of the printouts below, this was not the case. The motor is inconsistent, so it doesn't always spin the same distance in the same amount of time. That is, the speed you assign to the motor in the code isn't always the speed it actually goes. In addition to inconsistencies on the motor's part, perhaps the voltage from the USB port fluctuates slightly, which results in slightly different speeds. 

You can see how inconsistent one motor is, imagine trying to get two of them to work together! Next, we ran a program that printed out the positions of both motors after each second. We noticed that motor 1 was much slower than motor 2. We thought it would be interesting to plot the relationship. Below, you can see that the difference in motor position vs. time fits a quadratic relationship. We thought that perhaps we could use the equation generated to determine how much to adjust the speeds of the two motors in order to make the SciBorg drive a straight line. That's definitely not bang-bang control, though, so we'll save it for another time.

Next. we programmed our SciBorg to move forward at speed 225 and timed how long it took to travel 5 ft, which was 8 seconds. We then plugged it into the computer and read the positions of the two motors after 8 seconds. We did this several times. The average position of the slowest motor (motor 1) after 8 seconds was 6123. We then wrote a program that told the SciBorg to move forward at speed 225, and stop when the position of motor 1 was equal to or greater than 6123. Here is our code.

Here is a video of our SciBorg running the code. 

Our SciBorg stopped about 3-4 inches short of the 5 foot mark, which I think is pretty good. It stopped shorter than 5 feet because of the value we used for the stopping position, 6123. This value was an average, so depending on the trial, the motors may travel farther or less in 8 seconds. In the case shown in the video, the SciBorg was a little on the faster side, which is why it reached position 6123 sooner and stopped shorter than we hoped.

Touch Switch

The next sensor we experimented with was the tactile switch. I think this sensor was the easiest to use. When the button is unpressed, electricity can flow to the specified pin, so a reading of that pin would be high. When it is pressed, electricity flow is reduced to the specified pin, so a reading of that pin would be low. We used the values read from the pins to determine whether our car should stop or go. We placed a large piece of delrin at the 5 foot mark, supported by a trash can. The SciBorg should travel until it runs into the delrin, pushing the button and causing a pin reading of low, which tells the SciBorg to stop moving.  Below is a picture of our code and a video of our result. 

This method was extremely accurate for making the SciBorg stop after 5 ft. However, it is pretty inconvenient, because you'd probably want to be able to stop a vehicle without having to place a large obstacle in front of it. Also, depending on how fast a hypothetical vehicle is travelling, running into something in order to stop could cause damage.

Light Sensor

Next, we experimented with the light sensor. We ran a program which printed the values detected by the light sensor in order to understand which surfaces had high, moderate, and low values of light reflection. Here is a video (without the LED light turned on) in which you can see the values detected for different surfaces. 

When we turned on the LED, the sensor picked up values in the 90s for pretty much every surface we put under it. We couldn't really figure out what the LED is good for, besides showing you exactly where on the surface the sensor is reading from. Below is a video with the LED light turned on in which you can see the values detected for different surfaces. 

We noticed that the readings are more accurate when the sensor is closer to the surface (but not pushed up against it, as this blocks out light and can make a bright surface appear dark), so we attached the sensor on the car so that it would be very close to the ground.

Since the lab floor is gray, it has a relatively low value of light reflection. White paper had values in the high 90s. We put a white paper on the 5 ft mark on the lab floor. Then, we wrote a program that told the SciBorg to drive if the light reflection value was less than 90, and stop otherwise. Here is our code and a video of our result. 

The light sensor method was very effective. As you can see in the video, the SciBorg stopped almost immediately after it reached the white paper at the 5 ft mark.

Ultrasonic Sensor 

The last sensor we worked with was the ultrasonic sensor. This sensor emits sound waves which hit the nearest surface in front of the SciBorg and reflect back. The sensor measures how long it takes to receive the reflected wave back, which is used to calculate the distance to the obstacle. As the handout states, "because of acoustic phase effects in the near field, objects between 6-inches and 20-

inches may experience acoustic phase cancellation of the returning waveform resulting in inaccuracies of up to 2-inches. These effects become less prevalent as the target distance increases, and has not been observed past 20-inches. '' We decided to escape this issue by writing a program that makes the SciBorg stop when it's 2 ft away from an object. When the delrin was 2 ft from the SciBorg, the sensor read a value of about 37. We used a distance less than this value (if distance < 37) as the stopping point for our program and placed a delrin sheet 2 ft from the 5ft marker on the floor. A picture of our code and a video of our result appear below.

The ultrasonic sensor ended up being about 1.5 inches from the 5 ft mark. Pretty good, but once again, using this sensor was a little more complicated than it was worth. 

Conclusion

The tactile switch and the light sensor had the highest accuracies for stopping at the 5 ft mark. The tactile switch was the easiest to use/program for, and the light sensor was a close second. The motor encoder and the ultrasonic sensor were both inaccurate and difficult to use. 

Real-world Feedback and Control Systems

What are four examples of feedback/control systems you encounter in your everyday environment?

1. Swipe access doors
Sensor- A sensor reads the magnetic strip on a OneCard.
Control mechanism- If the sensor determines that the code written on the magnetic strip has access, a signal is sent to the actuator to unlock the door. Otherwise, no signal is sent.
Actuator- The mechanism that provides the energy to unlock the door. (A motor?)
What works well: The door only opens if it reads a card with access, so other people can't get in. The door doesn't stay unlocked for very long. This way, people without access can't sneak in after you.
What Doesn't Work Well: Sometimes the reader doesn't read the card and you have to swipe more slowly or swipe twice.

2. Handicap doors 
Sensor- The button on the wall near the door is the sensor.
Control mechanism- When the button is pushed, a signal is sent to unlock the door.
Actuator- The mechanism that provides the energy to unlock the door. (A motor?)
What works well: Very effective. I've never seen a door fail to open when the button is pushed.
What Doesn't Work Well: People use it just because they're lazy and therefore waste energy. The door stays open for a long time, so people who don't have access can get inside.

3. Ionization smoke detectors
The battery in the smoke detector sends voltage to plates, making one positive and one negative. A radioactive isotope in the detector decays at a constant rate and emits alpha particles.  They ionize with the air flowing through the chamber in order to create a constant current between the two plates. When the air flowing through the chamber has particles or water vapor in it, it can interrupt the current.
Sensor-The sensor measures the current flowing in the chamber.
Control mechanism- If the sensor measures a current lower than expected, it signals the actuator.
Actuator- The battery sends an electric pulse to the electromagnet in the speaker, which then vibrates and creates sound.
What works well: It's very effective, beeps to warn residents that the battery is low
What doesn't work well: It can be triggered by steam from boiling water or a shower.

4. Stove/Oven Timer
In the dorm kitchens we have timers connected to the oven and stove that we must turn in order to use the stove or oven.
Sensor- Something senses whether the timer is at 0. I think it might be a tactile switch. After you twist the timer on, it slowly ticks back to 0 until a part taps the switch.
Control Mechanism- When the switch is triggered, a signal is sent to turn off the flow of electricity to the oven and stove.
Actuator- Wherever the electricity for the oven and stove comes from. When it's turned off, turning the oven to bake or the stove to high doesn't do anything. You must turn the timer to allow the electricity to flow again.
What works well: The timer prevents people from accidentally leaving the stove or oven on for long amounts of time and therefore increases the fire safety of the building.
What doesn't work well: The timer is really short so if you're trying to bake a cake or something, the oven will turn off in the middle and you'll have to restart it. This is especially bad if you don't realize it turned off and then find a pan of batter when you expect to find a cake. You should be able to set the timer for as long as you need.

Sciborgs Day 1

Our first task was to write a sketch that makes an LED flash the Morse code for SOS using functions to reduce repetition.  Here is our commented code.

Next, we had to set up the Sciborg. Our first Sciborg task was to download the code "single motor" from the class website and run it to see what it does. Our commented code and a video of the Sciborg after uploaded the program appears below. One problem we had was that gibberish was appearing in the printing window. We had to make sure to change the data rate in the printing window.

Challenge 1: Create a new sketch, based on the previous sketch, to run both motors simultaneously at the same speed. A picture of our code and a video of the result appears below. 

Challenge 2: What is the minimum speed that allows your Sciborg to move? For this task, we basically had to guess and check by entering different speeds and then running our program to zoom in on the minimum speed. We defined the minimum speed as a speed at which the Sciborg will move without eventually stopping (unless the program says to). We found the min speed to be about 85. A picture of our code and a video of the Sciborg appears below.

Challenge 3: Make a sketch that gets the Sciborg to make a hard turn. We accidentally overlooked the comment that said to accomplish this by making one motor full power forward, the other full power reverse. We instead accomplished this task by making both motors go the same direction, but one at a faster speed than the other. A picture of our code and a video of the Sciborg appears below.

Challenge 4: Make a sketch for making a gentler turn. We accomplished this by making a less dramatic speed difference between the two motors. A picture of our code and a video of the Sciborg appears below.

Challenge 5: Time how long it takes for the Sciborg to travel 10 feet. Write a sketch that makes the Sciborg travel for this much time and then stop. This was the most challenging task. Since there was too much friction with the floor for our Sciborg, we used 9 ft of the table for this task, Our Sciborg had something wrong that caused it to veer left when it was supposed to drive straight, We tried to counteract this by increasing the speed of the left motor, but the behavior was very erratic, and we could never get it to drive straight, Thus, it took a different amount of time each trial to reach the 9 ft mark. Once we decided on the best time value we could get and programmed it into the Sciborg, it would always stop right before the line or right after, depending on how much it deviated from a straight path. A picture of our code and a video of the Sciborg appears below.

Arduino Practice Day 2

Challenge: Use the photocell to change something about the LED behavior based on room brightness.

Our Program

(I'm sorry, but I can't get these photos to line up properly.)

Our Hardware

Our Results

Challenge: Use the tiny tactile switch to turn the LED on and off.

Our Program

Our Hardware

Our Results

Challenge: Use Knob to control your servo.

Our Program

Our Hardware

Our Results

Challenge: Use Sweep to control your servo

Our Program

This program allows the servo to rotate independently from 0 to 180 degrees.

Our Hardware

See picture for Knob hardware

Our Results

Challenge: Change Knob so the servo only rotates between 60 and 120 degrees.

Our Program

Our Hardware

See picture for Knob Hardware

Our Results

Reflection:

My favorite challenge was the photo cell. First, we established values for different brightness levels by changing the environment of the photocell. For example,  we went in the bathroom and turned the light off to determine a value for dark of less than 100. For very bright, Amy shined her flashlight on the photocell in order to obtain a value of greater than 800. After deciding on all of our values, we programmed the code so that different LEDs would light up depending on the brightness level. I thought that was very neat. 

One frustrating aspect arose when I was trying to run Button in order to take a video. I couldn't get it to work, and I thought that I had put some of the wires in the wrong places. I kept taking the circuit apart and putting it back together, to no avail, I finally realized that the reason it wasn't working was that I was running the Button program from the examples, rather than the code from the handout. 

While I didn't think Servo and Knob were as remarkable as the photocell challenge, I can see how they would be very useful. I was also surprised at how hard it was to stall the servo motor -- neither of us could do it! It must be a very high torque motor. 

Arduino Practice

Challenge 1: Blink with Delay of 10

Our program

Our Hardware/The Result

The LED flashes every 10 seconds but appears as a continuous light because the human eye cannot perceive flashes that happen that quickly. 

Challenge 2: Pattern with 3 LEDs Using Delay() Function

Our Program 

Our Hardware 

The Result (Turning from 0 V to 5 V)

Challenge 3: Use Potentiometer to Change LED Behavior

Our Program 

(You might need to zoom in for this one, this was the largest size possible)

Our Hardware

Our Results (Turning from 0 V to 5 V)

Challenge 4: Pattern with 3 LEDs That Does Not Use Delay() Function

Our Program 

Our Hardware

Our Results

Conclusion:

Working with the Arduinos was a lot of fun. I've taken Python before, and I thought the Arduino programming language was pretty easy to catch onto. I've always been confused by how breadboards work, though, so I was happy to get some more practice with them. I think figuring out where the connections should go and why is the most challenging part. I was also confused at first by what the the potentiometer does, but I found out online that turning it controls the voltage going to the pin. I enjoyed changing the programs and observing the effect in order to understand what each line of code does. I also liked creating the lighting patterns for the LEDs.