ABOUT MY ROBOT

Its name is Puca. In Irish folklore, a Puca was a mischievous shapeshifting spirit.

Puca has a 20-80 RPM wheel speed, depending on terrain.

Puca can, at the moment, beep and move a tiny bit.

ABOUT ME

I love programming--all else to do with computers confuses me muchly. Which is, of course, why I'm in this class.

This summer I met people and had adventures and worked at Jersey Mikes.

I love fantasy in books, movies, and imaginings. I also took karate but am looking for a new martial art to learn at USC.

LAB 1

part 1

Mathew Schacher, Taylor Solon, and Olivia Hogan

The four of us worked together, but each robot drew its own shape. Puca drew a four-pointed star.

LAB 1

part 2

Puca's Stats

Line Sensors: 0-1

IR Sensors: 0-1

Fluke IR Sensors: 0-6400

Light Sensors:64700-65200

Battery Sensor: 7.29221

TrashBot's Stats (Joseph Boman)

Line Sensors: 0-1

IR Sensors: 0-1

Fluke IR Sensors: 0-6400

Light Sensors:64750-65400

Battery Sensor: 7.29221

Tommy Trobot's Stats (Mike Ciesielka)

Line Sensors: 0-1

IR Sensors: 0-1

Fluke IR Sensors: 0-6400

Light Sensors:65000-65400

Battery Sensor: 7.57818

Camo's Stats (Mathew Schacher)

Line Sensors: 0-1

IR Sensors: 0-1

Fluke IR Sensors: 0-6400

Light Sensors:64500-65000

Battery Sensor: 7.38753

LAB 2

I worked with Mathew Schacher, Taylor Solon, and Olivia Hogan to train our robots to sing the Harry Potter theme song under certain conditions, like when the battery is greater than 6.1 or when the bot runs into an obstacle.

LAB 3

I worked with Mathew Schacher, Taylor Solon, and Olivia Hogan to train our robots to sing the Harry Potter theme song under certain conditions, like when the battery is greater than 6.1 or when the bot runs into an obstacle.

LAB 4

I created a rudimentary program for Puca to demonstrate proficiency with usage of Puca’s sensors, a variety of loops, and variables. Before the main body of the program, Puca would run a check to see if its center light sensor was covered. If it was, a for loop would run causing Puca to spin in a circle four times before continuing the program. The rest of the program began with Puca discovering its battery level and assigning it to two variables--sBattery and eBattery. The program from that point was run in a while loop that terminated when sBattery and eBattery were no longer equivalent. At the end of the loop, the current battery level was reevaluated and assigned to eBattery. When it dropped from the start battery level, the loop would end. Inside this main loop were more while loops. The outer of these loops were lineSensor based, detecting whether or not Puca was on a light or dark surface. When Puca first changed from light to dark, then when it changed from dark to light, the powerUp method would run. This method consists of playing the Mario powerUp sound effect and of increasing Puca’s speed (also a variable) by 0.1. After changing from a light surface to a dark surface to a light again (putting the program in the third second-tiered while loop), another series of loops become available. These dealt with the obstacle and IR sensors, commanding changes in direction when obstacles were encountered. Both if and while loops were used in this section, as well as the powerUp method.

LAB 5

I worked with Mathew Schacher, Taylor Solon, and Olivia Hogan to program our robots to be able to use the fibonacci sequence to draw a spiral.

Talent Show

1) Puca will sing the Mario power up sound effect. The sensor that triggers the algorithm involving the song is the obstacle sensor. When an obstacle is detected during the light-following phase a random number is generated which becomes the upper limit of the subsequent for loop. Each time the loop runs, Puca sings the Mario power up effect and two new random numbers are generated and input as right and left motor speeds, causing Puca to drive forward with alternating speed and turning radius.

2) Puca will draw a four-pointed star each time its IR sensors detect an object during the light-following phase if the line sensors detect that Puca is on a light surface.

3) As previously described, Puca runs an algorithm for randomizing motor speeds in a for loop in response to sensing an object with the obstacle sensors. However, Puca’s primary special ability is light-detection. Puca will drive in circles until it detects light. It will then use a while loop which redirects to a method consisting of if statements to discover if the light is brightest on the center light sensor. If it isn’t, Puca will turn a tiny amount towards the light. This will repeat until the light is centered. Once the light is centered Puca will drive towards it in intervals, continuing to check if the light is still centered. If Puca loses the light, it will turn in circles until detecting it again.

4) Most of the program is contained in a while loop checking that the battery is above 6.5. After that, Puca’s light sensors continually scan for a bright light. Until the scan provides a sufficiently bright result, Puca turns in circles. No other actions are available outside of the light detect phase. Once light is detected, Puca attempts to follow it and is receptive to detection and reaction to objects in front or behind. See above.

(Code)

LAB 6

I worked with Mathew Schacher, Taylor Solon, and Olivia Hogan. We worked together to create a series of functions simulating simplistic animal behaviors in response to stimuli, then we each did one on our own. I made the program "Paranoia" in which Puca will move forward until detecting a shadow, at which point it will turn until its light sensors are no longer in shadow before continuing forward, imitating rudimentary animal behavior.

(Code)

Robot Games

Puca and I are members of the Olympic robot team, the Usain Ro-Bolts along with Mathew Schacher, Joseph Boman, Mike Ciesielka and their robots

1) Opening Ceremonies: a while loop checks for user input. The user directs the robot’s movement through the wasd keys, stops it with the f key, and discontinues user control with the x key. The robot then begins to sing the fight song.

2) Line Following: inside of a while loop, the robot uses the line sensor to detect if it’s on a line, in which case it drives backward. If one of the line sensors loses the line the robot rotates in that direction until it’s back on the line. This section of code is terminated when the center light sensor detects a very bright light.

3) Maze Solving: inside of a while loop, the user inputs the obstacle sensor power and the time it takes for their specific robot to make a 90 degree turn. After that the robot moves forward until the obstacle sensors detect an obstacle. The robot turns 90 degrees to the left and moves forward again unless it detects another obstacle, at which point it turns 180 degrees to the left again and moves forward again. This section of code is also terminated when the center light sensor detects a very bright light.

4) Fastest Drawer: the robot’s IR sensors first scan for nearby obstacles. If none are detected, the robot begins drawing. The robot begins by drawing the outside triangle, then progresses to drawing the inner triangles in three segments—one side of the medium triangle with one full small triangle. No lines are drawn more than once.

5) Main: the robot’s battery sensor first detects the robot’s battery level and only executes the main code if the level is above 7. Inside of a for loop limiting the number of times the program can run, the user is presented with a menu to choose from. The user’s input determines which case the switch statement runs. The cases correspond to the different skills the robot is prepared to display in the robot games.

(Code)

LAB 7

I worked with Mathew Schacher, Olivia Hogan, and Kristen McNeal. We exchanged the code we'd written for our individual robots' drawings and songs, then worked seperately to use arrays to create user definable playlists for both types, which the robots could then perform.

Urban Search and Rescue

Puca and I joined forces with Josh DiGiovanni, Brian Chen, and Matt Pohlmann as Silly Landmine Studio, the Urban Search and Rescue team.

1) Assuming all robots start at the same point, each of our robots will face in a different direction and start by taking a picture with the camera before driving in those different directions in search of the lost robots.

2) Puca will move based on my keyboard input and will report back the sensor read-out from the front and back obstacle sensors. From this data and regular pictures I will be able to guide puca through the maze.

3) Puca will drive around the maze taking pictures, and I will look at the pictures to figure out if there is a robot in the picture.

4) Once the robots are done searching the area, our team will compare the pictures they took and the paths they made through the maze to ascertain how many individual robots we found and what their comparative locations were.

MARS Rover

1) My algorithm for finding aliens in pictures for MARS has three phases, each delegated to a separate function. The first phase (searchPic) scans the picture while searching for the alien color. If it finds that color, it will mark that column as being “true” for having an alien in it. In this way it can know how many aliens there are, but little more specific detail. If it detects no aliens, it prints that there were no aliens in the picture and stops there. Otherwise, on to phase two (identifyAlien). In this phase an array of pointers alien objects is made from the found number of aliens from phase one. It scans the picture again, focusing on the columns marked as having aliens in them. It finds the number and coordinates of consecutive columns to contain an alien, as well as searching the columns again for the highest and lowest points of alien color. Once the scanner finishes with that alien it passes in all of these details to phase three (characterizeAlien), which assigns dimensions, coordinates, and the identifying number of counting off from left to right to the next alien being pointed to by the array based on everything found in phase two about this particular alien. Afterwards it returns to phase two where the variables are reset and the counter for which alien is being worked on is increased by one in preparation to repeat the process with the next alien until the entire picture has been rescanned.

2) Class alien is a very simple class made only to store values describing found aliens. It has int ID, setID(int id), getID() to store and return the alien’s identification number in accordance to the order in which it was found; int r, int g, and int b along with functions getR(), getG(), and getB() to store and return its color; int height, setHeight(int h), and getHeight() to store and return its height; int width, setWidth(int w), and getWidth() to store and return its width; int leftX, setX(int x), and getX() to store and return the farthest left x coordinate the alien exists at; and int bottom, setY(int y), and getY() to store and return the lowest y coordinate the alien exists at.

3) In developing my alien recognition algorithm I started with scanning the picture for a small range of bright green colored pixels. Whenever I found one I would change it to black. At the end I displayed the picture and saw the effectiveness of my range, which I then tweaked until I was satisfied that it was detecting the whole alien—excluding the eyes which are completely inside the green and so don’t affect my ability to find location or dimensions of an alien. After that it was all a matter of storing which values and making them unique to specific aliens. One problem was that there was no way of knowing beforehand how many values I would need to store, since the number of aliens, their dimensions, and their locations were all variable. In order to store any alien-specific data, I would need and alien array (or array of pointers to alien objects), and to make that array I would need to know the number of aliens in the picture. How to determine that, if I'm locating them one pixel at a time? So instead of comparing neighboring pixels together, I decided to compare columns. Since none of the aliens in the first four pictures overlap with each other’s x coordinates, there would always be at least a column with no alien in it at all between one alien and the next. I used this separation to count the number of aliens, which I then used to make the alien pointer array. Now that I had this array I could start storing alien specific data. I used the columns of consecutive alien to determine width and x location, searched them for highest and lowest green pixels to determine height and y location, then passed these into the alien in the array that they belonged to once the program had finished scanning it in its entirety. Then I reset everything to do repeat the process for the next alien.

4) I started testing my algorithm with MARS1 first so that I could test all of my alien recognition processes across the whole picture without having to worry about differentiating between multiple aliens from the get-go.

5) I used selection sort to compare the widths of all the aliens in the array, setting the first to be the max width, then comparing the rest of the array to find any bigger at which point I would take the biggest and swap it to the front. Otherwise the front alien was already the biggest and I would leave it where it was. I would then move to the next spot and repeat this process until I got to the end of the array.

6) I used selection sort to compare the bottom y coordinates (their feet—the lower their feet are the closer to the rover they are) of all the aliens in the array, setting the first to be the max y, then comparing the rest of the array to find any lower at which point I would take the lowest and swap it to the front. Otherwise the front alien was already the closest and I would leave it where it was. I would then move to the next spot and repeat this process until I got to the end of the array.

7) The Big O of selection sort is n2.

(Code)

Final Project: Games

I worked with Basil Sunier, Adrian Mendoza, and Jerry Webb

1) Our group made a series of text-based games for our demos that the middle schoolers can play while we explain that fundamental facets of computer science like algorithms and programming can be used to create more than just functional, boring software. Video games are a side of computer science that give learning computer science and gaining the skills an end goal of creativity and entertainment. Many children might find the idea of sitting behind a desk and programming for a living tedious and unappealing. But the idea of sitting at that same desk playing or creating video games suddenly makes them wake up and pay attention. Everything we’ve learning in class this year—algorithms, loops, arrays, classes—all of that general computer science knowledge suddenly gains a new life in the context of fun and gaming. Approaching computer science through games is a way to enjoy every side of the field.

2) My program, the dice game craps, will engage the user with the lure of winning (made tangible through increasing amounts of candy as prizes). Gambling is addictive for a reason—everyone loves the thrill of not knowing if they’ll win and the large payout for the times that they do. The user will bet by realistic craps rules and will “roll” the dice and can earn or lose points depending on the roll in comparison to the bet. They can make strategic decisions about how many bets to place, which numbers to bet on, and how much to bet each time.

3) I did a lot of research online since I have never played craps before. I followed the rules and the set order of events laid out for me. I give the user instructions for the types of bets they can place and what the odds for each are, and they can then enter their choices and bet amounts. I then allow the user to “roll” the dice rather than doing it automatically so that they can feel like they’re actually playing. Since I’m not making my own rules, just following those that already exist, I didn’t have to develop much on my own. However, I did have to include failsafes against users trying to enter unusable data into the program, like betting more money than they have. These failsafes warn them of their mistake and repeat the segment until a usable value is input.

4) I will evaluate the human-computer interface by keeping track of the number of times my failsafes are activated. If they are activated frequently, that means the users are having trouble with my interface and I ought to improve it. Otherwise they must be able to use it easily, and I therefore did a decent job.

5) I will evaluate the user’s interaction by how many rounds they play, how many bets they make, and how much money they have when they stop playing. If they have a lot of money, they either understood the game well, or got lucky (the latter is more likely if they weren’t playing long). Vise versa if they don’t have much money. If they make a lot of bets, they like gambling. If they play a lot of rounds, they’re getting really into the game, but if they don’t then they didn’t like the game much.

6) I will have counters throughout the code keeping track of how many rounds, bets, and errors are made per person. When that person is finished playing—either from losing all their money or from deciding to quit—my code uses File IO to record these variables and the money the player is left with into an outside file. It will then reset all these values and begin the process anew with the next player, the statistics for which will in due time be recorded in the output file after the previous player’s.

7) I have a function called evaluate which is called once the program is finished running and no other players want to play. This function does the evaluations described in 4) and 5) by reading the previously output file back as an input file and using all of the recorded data to calculate averages and bets/errors per round.

(Code)

Valid XHTML 1.0 Transitional!Valid CSS!

The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees
The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees