Sensei-Sensors & Bang-Bang Control

More work with the Sci-borgs!

Partner: Rachel Hwang

1. Use the various sensors (touch, ultrasonic, brightness, and encoder) to fine-tune how exact your Sciborg (Stew) can get to the 10 foot line.

Task 1: Tweaking the Motor Encoder
The motor encoder basically can read the position that the motor is at, represented by a number (but is calculated cumulatively if the wheel keeps turning forward over many rotations). When we first ran the sketch, it ran the motor backwards and forwards for one second each. However, we noticed that the position didn't go back to zero. The first reason being that the motor after turning forwards and backwards for one second doesn't return to the exact same spot, the second reason being that because of the interval in which the motor checks itself. In this case, we had the motor check every 1 second, thus over multiple cycles of forward and backward, the lag/difference would be compounded.

Code notes:
- The code in the first image includes all of the packages and libraries required to control the motor and read the position. In addition, it sets up a variable to keep the time elapsed and a variable rpms that is the speed of the motors.
- The code in the second image sets up the Arduino to print the serial print statements in the 11520 baud setting. and tells the motors to begin.
- The code in the third image creates two variables motor1 and motor2 that will eventually store the  position reading of each motor. Both motors are set to drive at the speed of rpms for 1 second, and then to go the same speed but in the opposite direction for one second.

Next, using measurements for the radius of the wheel and the length of the track (10 ft), we calculated the number of revolutions the wheels would have to go in order to go 10 feet (about 18 revolutions). We looked at the serial window, and saw a rough estimate of what the motor encoder would read after that number of revolutions (12643) and created a while loop for the motors to run while the motor encoder read value was less than 12643.

C'mon Stew! I know you can do it! (from this angle, Stew kind of looks like a bug)

Conclusion: Pretty close, but not quite there. Probably because he doesn't move in a perfectly straight line. What are some other sensors that we can use to get him to the line?

Task 2: Tweaking the Touch Switch

We connected the touch switch to the Arduino (not an easy feat), and got the program to change the printout in the Serial window to the status of the button (pressed or unpressed). The key to getting the circuitry is using an LED in the circuit to visualize the state of the button (if electricity if flowing or not). Only one LED was sacrificed(burned out) in the testing of this process.

After we were able to get the Serial window to accurately print the status of the button, we altered the code so that the motors would stop once the button was pressed. Just to push ourselves a little bit further, we coded Stew to, once the button was pressed, stop, back up, turn around, and head the opposite direction. Cool, huh? Go, Stew, go!

Wiring:
   

Stew: Stop when button is pressed.

Stew: Stop when button is pressed, then turn and go the other direction.

Code for final behavior:




Task 3: Tweaking the Light Sensor

In this exercise, we we attached the light sensor to the Sciborg and looked at the Serial window to see the different readings from the sensor. We also looked at how accurate the readings where with the additional LED light on and off and concluded that the LED light off was better. In order to get Stew to stop at when the light sensor was at the white line, we set the dark value for the light reading to set the motors to full power (Scaled light value < 70) on and the white tape light reading to be motors off (Scaled light value >= 70). The values ranged from 10 to 90ish. The distance to the surface was optimized after we attached the light sensor to Stew, about 2 cm.



Failed attempt (so you know we aren't always perfect):

Success:

Task 4: Tweaking the Ultrasonic Sensor

(Since I forgot to put in comments, here are the general notes on the code.) Basically we imported all of the relevant and required libraries, and set the Serial window input to be at 9600 baud. Depending on the value read from the ultrasonic sensor (the distance Stew was from something directly in front of him), change the behavior. If Stew's ultrasonic sensor read anything lower than 16, then stop (because he quickly approaching an object.)

                                                    

Task 5: Use bang-bang control to get the Sciborg to go in a straight line. Bang bang control is basically on-off sensing. For example, if the air in your house gets too cold, then the heater turns on for a certain amount of time and then turns off, there is no in between. In this case, if one motor was lagging behind the other, then adjust the speeds of one motor so the other could catch up.

Task 6: More bang bang control - get your Sciborg to follow the white path!
(yellow brick road aka white tape road)
The key to success in taking apart this problem was by placing the light sensor on the edge of the tape. Take note of the light reading off the tape, on the edge, and completely over the tape. Thus, we were able to tell Stew to adjust a specific way (right or left) based on the light reading. Greater accuracy with following the path was achieved through decreasing the delay between measurements and decreasing how harsh the turn was to readjust the direction. Look at Stew wiggling is way down the white tape road! Off to Oz he goes!

(pretty jerky and misses the final turn) wait wait, reiterate!

(better, adjusted by the size of the delay and speed of the turn to adjust)

Task 7: Conga line! 

Adjust the ultrasonic sensor code so that when it is far away from the object in front, go full speed ahead (with adjustments so it goes in a straight line); when it is medium distance from front object, go slow, when very close to front object, stop. 

(Stew is following the board, Katrina, Vivian, and Jiaming's Sciborg is following)

Stew also led he following line with Magnolia and Amy's Sciborg.

Overall, working on these exercises, the coding got easier over time, however, it was often hard to find new ways to work at the problem. Of all things, I would tell the students next year to never forget about the delay function, it is your friend!! Start by working on little steps, like going straight forward, and then working your way up. If anything goes horribly wrong or too complicated, the simply start over! Sometimes it helps to think of new solutions by starting with a clean slate! In addition, try taking apart the problem and working out how to approach it in a broad sense before you start coding!

Skills:

• bang bang control
• sci-borg coding in c
• sensing, input and output
• light sensors
• ultrasonic sensors
• touch sensors
• motor encoders

Cyborg or Sci-borg?

We hit 300 blog views today!

Today we are working on a combination of the Arduino and a Lego racer (with a much better motor):

Partner: Rachel Hwang

a) making functions -- an effective way to reuse code rather than copy and pasting. In this exercise, we had a dot() function and a dash() function that were called in order to execute a SOS message with an LED and Arduino.

b) set up the sciborg

1. attach the battery pack & Arduino
2. instal Bricktonics Lego NXT
3. use NXT cables to connect the motor and motor port
4. plug the Arduino into the computer and download the necessary libraries

Behold! The dreaded SCIIIIBORGGGGG!!! (doesn't this thing remind you of that gross baby-head spider creature from toy story?) Coincidence? I. Think. NOT.

 

*scream in the background*

c) work with your SciBorg (just getting the single motor file to run on my computer was, in itself, a challenge with a buttload of error messages, still unresolved to this day)

1. Single Motor -- In this exercise, we downloaded code from Amy Banzaert (our professor) and ran it. Basically, the code tells the Arduino we are dealing with only one motor and that we want to turn it at a speed of 75 (forward slow), then 255 (forward fast), -75 (backwards slow), -255 (backwards fast). Note: In the serial console, the behavior of the wheel will be printed out as it is occurring (see code).

2. Both Motors -- (all together now, ladies) In this exercise, we edited the single motor code so that we were controlling both motors. Then we copy and pasted the code for motor one and changed it to be controlling motor two. 

Serial Console Output (the 2 denotes the printout of the second motor)

3. Minimum Speed -- through experimentation (trial and error), we found the minimum speed that would move the Sciborg (100 (sorry, speed units currently unavailable)). This was not too difficult, but we did hit a couple of road blocks when one of our wheels (the left one) wouldn't always turn...

4. Hard Turn -- Set one motor to full power forward and one to full power in reverse. This had the effect of a very sharp, minimal turning radius, turn.

5. Soft Turn -- Make the sciborg take a gentler turn. (This was unclear whether we were supposed to just lower the speed but still have the two motors/wheels turning in opposite directions to achieve a turn or to increase the turning radius as it was executed)

Same turning radius as Task 4, just lower speed and longer time period to execute the turn.

Jerky, wider radius turn. (Further iteration is required to achieve a wider radius smooth turn.) Possible problems: the inside wheel is turning at a faster rate than the outside wheel is (because the outside wheel has to cover more distance, creating a jerking motion)

6. Traveling 10 feet

Step 1:

Set the speed of both motors to high (255) and time how long it takes to travel 10 feet. (See code from Task 2 for how to set the speed to 255)

Result: about 11 seconds 

Proof:

Step 2:

Write a sketch to get the Sciborg to travel for that amount of time (11 seconds) and then stop.

Result: The Sciborg didn't make it to the line because it didn't travel perfectly straight or on an identical path as it did in step 1. (See further notes below)

In this trial our sciborg did not travel in a perfectly straight line (uneven floor?), but stopped about 2 inches from the line. The Sciborg did not stop exactly at the line because it is going on a timed run, rather than based on sensing from the environment whether it has reached a line or not.

In this trial, we attempted to keep the sciborg's path a straight line. We did not alter any of the code, and the course was the exact same as before. Oddly enough, the sciborg dramatically veer off to the left. Reason: unknown.

(its alive)

Bloopies (I hope you enjoy these as much as I do):

As you can see, we often struggled with getting the bot to start. (he's pretty stubborn, I think I'll name him Stew. Stubborn Stew.)

Skills:

• #moar coding
• functions
• morse code #SOS
• working with motors
• set run times with motors
• using millis() and loop()

(hehe, sorry, I couldn't resist)

ArduiNo? More like ArduiYes.

Activities: Learn basic use of the Arduino microcontroller through partner programming.

Partner: Katrina Montales

1. Blink with a delay of 10 - the delay is in milliseconds, so the LED is turning and off so fast that it looks like a continuous stream of light (similar to the fluorescent lights in most of our buildings). If we were to take a high speed video, we would be able to see the the LED flashing on and off.



2. Pattern with (at least) 3 LEDs of different colors using the delay() function

With each new LED, we set the delay to be of different intervals. This was simple, yet gratifying at the same exact time. Getting this little step to work felt extremely rewarding. Something about building something with your own hands feels very empowering, like "I made that!!!" 

3. The potentiometer takes in the input based on where the knob is pointing (the resistance) and sets that to be the value to be the delay between the LED flashing on and off. This was cool to see how we could directly change the input through the potentiometer through hardware changes rather than software changes.

4. Pattern with (at least) 3 LEDs of different colors that does not use the delay() function. This program tells the LEDs to turn on or off based on the time that has elapsed since the beginning of the loop (the millis() function). This was frustrating because we originally only had one variable for the timekeeper (lastTime), but that was changing the behavior of all three LEDs, so creating a time keeper for each LED simplified our code a lot better. (Overall, however, this took a long time to understand.)

5. Using a photocell, we set the LED light to go on when the photocell reads that the light input is at "Dim." After some googling, I found out that a photocell is basically a resister that changes its resistive value depending on how much light is shining on the sensor (squiggly part facing upward near the top of the breadboard). Adjusting the code that was already given to us was not too difficult, but super cool to see how this could be applied as simple light sensors (like for streetlights) around the world.

6. Using the tiny-tactile switch, turn the LED on and off. This task was different than the others because the button was an input. The button basically functions as a pull-up resistor -- meaning that when you push the button, it completes the circuit and allows the electricity (+5V) to flow through. I can definitely see how this could be used with morse code...

(candid of the documentation process, at its best, ps: katrina don't murder me)


7. Use Sweep and Knob (rotate between 60 and 120 degrees) to control the servo. An arduino board basically creates a platform for us to control the RC servo motors. The three wires attached to the servo are power (red), ground (black), and signal (yellow). These programs were basically written for us and were fairly straightforward, so not too difficult to understand. Any confusion was easily solved through looking at the Arduino documentation.

Configuration:



Sweep:

Knob:

Skills:

• coding in a language similar to C
• arduino circuits/resisters/breadboard usage
• input from the environment (using the potentiometer)
• using millis() function within the loop()