UNIVERSITY OF ROCHESTER
DEPARTMENT OF COMPUTER SCIENCE
Assignments
Revised: 2009-12-7
Unless otherwise indicated,
-
All references to numbered exercises from the book are according to the
online PDF of the June 2009 version of the textbook.
-
Each assignment must be done individually. See the syllabus regarding plagiarism.
-
Each assignment solution must be submitted via email to the TA, and don't forget to CC the instructor.
-
All late assignments incur a 20% penalty per day (24 hours) late.
Assignment #13 -- Social Robots -- Due Thu. 12/17 9:00 AM
This final assignment consists of two components, each to be implemented by one of two teams. I'll leave it to you to form the two teams.
Just let Kate and me know who's on what team, and which team does which component.
During the project demo on Thu 12/17, each team will share their code with the other team, so that all robots will execute the code, i.e.,
both components will be demonstrated by all robots.
- Design and build a behavior-based program that implements flocking behavior. This idea is based on the way geese fly in formation by
following simple rules such as "when you see a bunch of flying geese, join them" and "when you're flying right behind another goose, move over a bit".
Here are the simple rules that enable your robots to move in flocks (where "moving in flocks" for our robots means moving single file, following a leader):
When you're not in a flock, rotate in place with your LED off, looking for a flock (a robot with its LED on).
If you don't find one in X seconds, (where X is randomly picked between 5 and 10),
become a leader by turning your LED on and starting to roam.
If you do find a leader, start following it, and turn your LED on (so that other robots can follow you).
If you've been a leader for Y seconds (randomly picked between 15 and 25 seconds), you become tired: turn off your LED,
meander around for a short while, then start looking for a flock to join (leader to follow), as described above.
These are suggested rules. You will have to experiment and refine to build a working system. Feel free to change the timing numbers also,
to make the system as a whole behave better.
- Design and build a behavior-based program that implements the game of tag. The program should be written so that
one robot can be started as a tagger, and all other robots can be started as a taggee.
The tagger's job is to tag each of the other robots, i.e., to bump them. The taggee's job is to avoid getting tagged.
Tagged robots will be removed from the arena by their owners.
You will need to design a good way for the tagger to locate the taggees (so they can be chased),
and for the taggees to locate the tagger (so they can run away from it). For instance, the tagger might be looking for blue robots,
whereas the taggees might be looking for a hot pink cone on top of the tagger.
Feel free to adjust the rules so as to make for an entertaining system.
Also, in the real game of tag, when a player is tagged they become the tagger in turn. Could you program that?
In both programs, the robots should indicate somehow (e.g., beeps of different pitch, or a spoken comment) when they change state,
such as when a lonely robot finds a flock to join.
Submit your report containing a complete description of your design, rules, etc. as well as your well-documented code in a file called
hwk13-flock.zip or hwk13-tag.zip, and email it to Kate and CC me by the deadline.
The report should also describe the contributions of each team member.
A note about programmatically configuring the blob parameters.
The textbook describes how you can use the mouse on a picture to indicate to the system what color(s) you want the blob software to track.
It is also possible for your program to configure the blob parameters. This makes it much easier to run the same program at different times.
It also makes it easy for a single program to track multiple colors! (Of course, only one at the time.)
What you need is already in the myro system, namely the functions
configureBlob() and rgb2yuv(). Here's how you'd use them, and why:
The configureBlob() function takes its color parameters in YUV coordinates rather than RGB coordinates.
So you want to take a picture of the object(s) you want to track, and use the mouse to determine the RGB values you're interested in.
Then in your program, you define those RGB values as constants (so you can change them easily later, if you need to).
Your program then converts the R, G and B values to the equivalent Y, U and V values using the rgb2yuv() function,
and calls the configureBlob() with the U and V values you got, plus or minus 1 or 2, and a wide range of Y values.
The rgb2yuv function is not in the main myro file, but in a subsidiary
file (scribbler.py). Therefore, you need to either call it by its full
name, as in
>>> myro.robots.scribbler.rgb2yuv(255,255,255)
[255, 128, 128]
or first import it explicitly
>>> from myro.robots.scribbler import rgb2yuv
after which you can use the short name, like this
>>> rgb2yuv(255,255,255)
[255, 128, 128]
Note that there is good reason for doing color blob detection in YUV
space rather than in RGB space. In RGB space, the coordinates (R, G
and B values) change not only when the colors are different, but also
when the color is the same but the light intensities (brightness) are different.
Take for instance the RGB color [100,125,75]. Adding 50 to each of the R, G and
B components preserves the color but increases the brightness. Adding
100 to get [200,225,175] does the same thing. Blob detection is
generally done by matching within a range. To capture the various intensities of this color in
RGB space, you'd have to specify a range that includes [100,125,75] as
well as [200,225,175]. But this is way too broad - it includes various
intensities of the color we want (such as [150,175,125]), but also lots of other colors
(such as [200,125,125]).
On the other hand, YUV space is perfectly suited for color blob
detection, because it separates brightness (Y) from color information
(U and V). Take the above RGB colors and convert them to YUV, and
you'll see the difference:
>>> rgb2yuv(100,125,75)
[111, 109, 117]
>>> rgb2yuv(150,175,125)
[161, 109, 117]
>>>rgb2yuv(200,225,175)
[211, 109, 117]
As you can see, in each of the three cases, the U and V values are the
same (109 and 117, respectively); the only thing that changes is the Y
component, reflecting the different brightness levels.
When blob tracking, you want the system to find a particular color irrespective
of the brightness. The same color in different intensities occurs
naturally in a picture. Take for instance a picture of a blue bottle.
The side of the bottle that is towards the light source will have a
much brighter blue than the other side.
To programmatically configure the blob tracking, you generally want to
specify a broad range of Y's, and very specific U's and V's. In the
above example, I might specify something like
>>> configureBlob(u_low = 107, u_high = 111, v_low = 115, v_high = 119)
and leave the y_low and y_high parameters set to their default values of 0 and 255, respectively.
Here's the whole program segment:
from myro.robots.scribbler import rgb2yuv
...
BLOB_RGB = (150,175,125) # The target color, in RGB space
...
R, G, B = BLOB_RGB
Y, U, V = rgb2yuv(R, G, B)
configureBlob(u_low = U-2, u_high = U+2, v_low = V-2, v_high = V+2)
...
blobsize, avg_x, avg_y = getBlob()
Specifying the U and V ± 3 or 4 instead of 2 makes it more likely that pixels with the color of interest are captured in the blob,
but the resulting blob is also more likely to contain colors you're not interested in.
As usual, it's another case of balancing false negatives (missing pixels you want) against false positives (getting pixels you don't want)...
PS. For the morbidly curious, check out
Wikipedia's page on YUV.
It has a nice graphic illustrating the U-V space!
Assignment #12 -- Conversations with your robot -- Due Mon. 12/7 11:59 PM
- Design a language of one-word English commands for the Scribbler.
Write a program to input one command at a time, interpret it, and then execute the command on the Scribbler.
The program should print an acknowledgement if the command is understood, or an apology if it isn't.
Try to make it "natural like".
Continue to process these commands until a special termination command is received (such as "quit", or "bye").
- Extend the language from the previous part to include queries (e.g. wall?) and then modify your program to incorporate such queries.
Make the responses English-like, i.e., don't just print a number or a 'Y' or 'N'.
-
20% bonus:
Extend the command language to take optional quantifiers, e.g. allow inputs like "forward 3 seconds",
or maybe "forward 3 feet" or "turn 45 degrees"...
-
Similar bonuses can be earned by extending the capabilities of your conversational program in non-trivial ways.
You'll have to justify why it's worthy of extra credit. (And remember that mere effort does not justify extra credit.)
Submit your report containing a complete definition of your language as well as your well-documented code in a file called
hwk12-lastname.zip, and email it to Kate and CC me by the deadline.
Assignment #11 -- In Pursuit of Color -- Due Mon. 11/23 11:59 PM
- To complete by the end of the 11/18 Lab:
Using the hot pink styrofoam ball,
implement the showBall algorithm at the top of page 234. You'll have to experiment to see what the best R, G and B values are to filter on.
- Finding the Ball
Build the rest of the program for your robot to find the hot pink styrofoam ball. See pages 235-236.
Except that, your robot doesn't move, it just turns in place;
instead of calling forward() when the ball is directly in front, just sit still.
Hint: to make your robot behave better than a yoyo, you may want to make the turn speed proportional to how far the ball is from center.
Note: if you can't come to the lab to do this, and don't happen to have a hot-pink styrofoam ball at home,
feel free to substitute another suitable object. Document it!
- Chasing the Ball 1
Implement a behavior-based program that chases the hot pink ball (while avoiding stalls and obstacles).
Note: you can start with the simple, non-behavior-based program on page 235, but that's not the final solution!
- Chasing the Ball 2
Make a copy of the previous program and modify it so that it uses myro's blob functions to locate the ball.
Discuss in your report the difference in performance between this and the first version of the ball chaser.
If you have a way to make a video, show your ball chaser in action on YouTube!
(Include the link in your report.)
- Brighten up!
Define a brightenPicture(pic, delta) function that increases the pixel values of the given picture by delta.
The delta value may be negative, which should result in a dimming of the picture. (Beware of boundary values 0 and 255!)
Submit your report and well-documented code in a file called
hwk11-lastname.zip, and email it to Kate and CC me by the deadline.
Assignment #10 -- Scaling Up -- Due Mon. 11/16 11:59 PM
There are two pieces to this assignment, but you only need to do one of them. U Pick!!!
Both pieces consist of an easier part and a harder part. You will get a 10% bonus if you complete the easier part
by the end of Wednesday's lab. You are also allowed to do both pieces for 50% extra credit,
but the extra credit will not be given unless both parts of both pieces have been completed sucessfully.
- One Scale
-
Write a function drawRobot(win, x, y)that draws a robot, as depicted in Exercise 8.2, on window win.
The x and y refer to the top left point of the imaginary box around the picture of the robot.
Write a main program that creates a graphics window and draws this robot in three different places on this window.
-
Extend your robot-drawing function by giving it an optional fourth parameter, scale, whose default
value is 1. Change the function so that it draws the same robot figure but scaled by a factor indicated
by the scale parameter. Hence, drawRobot(win,x,y) draws the same thing as
drawRobot(win,x,y,1.0) but drawRobot(win,x,y,1.5) draws the same figure
but 50% larger than the standard figure.
Modify your main program so that it draws the robot in three different places and at three different sizes.
- Another Scale
To play a standard scale on a keyboard involves 7 rather than 12 notes.
On a keyboard, the white keys correspond to the notes A, B, C, D, E, F and G,
whereas the black keys correspond to the notes A#, C#, D#, F# and G# (also known as
Bb, Db, Eb, Gb and Ab). To play the scale of C, you simply play all the white notes, starting at one C
and ending at the next: C4, D4, E4, F4, G4, A4, B4, C5.
In other words, of the thirteen notes between (and including) the two C notes
you play the first, third, fifth, sixth, eighth, tenth, twelfth and thirteenth notes.
To play a different scale, i.e. a scale that starts with a different note, you'd follow
this same sequence of played and skipped notes. For instance, to play the scale of E you would
play E4, F#4, G#4, A4, B4, C#5, D#5, E5.
-
Define a function playScale(note) where note is an arbitrary
frequency. The function plays the standard scale starting at the given note and ending
up at double the frequency.
Write a main program that plays three scales, starting at 200, 300 and 400 Hz, respectively.
-
Extend your scale-playing function to take an optional second parameter, minor, whose
default value is False. If this parameter is False the function
plays the standard (major) scale. If it is True the function plays
the minor scale, which is also eight notes, but instead of the standard
1,3,5,6,8,10,12,13 it is 1,3,4,6,8,9,12,13.
Also extend your function by allowing the note parameter
to be either a numeric frequency or a named note (a string such as "c4" or "a#2").
If it's a number, the function behaves as before. If it's a string, it plays
the scale starting with the given note. In other words,
playScale("a") will have the same effect as playScale(440).
You'll need the built-in Python function
type
to decide whether the parameter is a string or not.
Extend the main program to also play the scales of C, E and G in both major and minor mode.
Note: it's real easy to make the harder part of your piece uglier than a witch.
Instead, think about it carefully and design it so that it's clean and elegant.
Style points will be a significant component of your grade!
Submit you well-documented code in a file called
hwk10-lastname.py, and email it to Kate and CC me by the deadline.
Assignment #9 -- Wall-to-wall Robots -- Due Fri. 11/6 11:59 PM
- behavior-based control
Demonstrate by the BEGINNING of the Wed. 11/4 lab the behavior-based control program as described on pages 161-163.
Note: copy from the PDF, then paste and modify... (don't forget comments identifying you, date and code origin)
BIG NOTE: Email the file to Kate and me NO LATER THAN WEDNESDAY 4:45 PM.
Otherwise, NO CREDIT FOR THIS ASSIGNMENT.
- Variation - Stall
Define a stall behavior (typically: back up a bit and turn slightly), and add it to the list of behaviors.
Should it be at the beginning or the end of the list? I.e., is it a low or high priority behavior?
Try it both ways and describe the observed behavior in your report.
- Variation - light seeking priority
Move the light seeking behavior further down the list.
Observe the resulting behavior and describe your findings in your report.
- Variation - wall following
Replace the Avoid module in the behavior-based control program with a module called: follow.
Note: you do not need to remove the avoid function definition; just replace it in the behaviors list.
The follow behavior tries to detect a wall to the robot's right (or left) and then tries to follow it at all times.
Set up a 2' x 2' walled square on the pad and let the robot make its way around the outside perimeter.
Observe the resulting behavior and describe your findings in your report.
- Experiment - reaction time, one more time
Execute the previous four programs using the Memoizing Scribbler robot software
instead of the standard Scribbler robot software.
(See the resources page.)
Describe in your report the differences in how this program behaves compared to the ones in the previous two parts.
Discuss the implications of reaction time on robot software.
Submit the report of your experiments and your findings, as well as your Python code, zipped together in a file called
hwk9-lastname.zip, and email it to Kate and CC me by the deadline.
Assignment #8 -- Touch 'n Go -- Due Fri. 10/30 11:59 PM
- Simple reactive programs
Demonstrate by the BEGINNING of the Wed. 10/28 lab the light orienting, light following and obstacle avoidance programs
on pages 144, 147 and 149, respectively.
Note: copy from the PDF, then paste and modify... (don't forget comments identifying you, date and code origin)
BIG NOTE: Email the three files to Kate and me NO LATER THAN WEDNESDAY 4:45 PM.
Otherwise, NO CREDIT FOR THIS ASSIGNMENT.
- Experiment - Maze Solver (p.151)
Set up a simple maze using the blocks in the lab, and see how well your obstacle avoidance program works.
Describe the observed behavior in your report. (Be sure to look at left- vs. right-handed mazes.)
- Experiment - reaction time I
Create a new version of your IR-based obstacle avoidance program that keeps track of how often the robot gets to
check for obstacles. Initialize a count variable to 0, change the loop condition from True to timeRemaining(20),
increment the count variable in the loop body, and report the reaction speed after the loop finishes
in terms of the number of loop repetitions per second.
- Experiment - reaction time II
Create another version of the program you created in the previous part that uses the Fluke's obstacle sensors
instead of the IR sensors. Don't forget to turn the robot around: setForwardness("fluke-forward").
Describe in your report the differences in how this program behaves compared to the one in the previous part.
- Experiment - reaction time III
Create another version of the program you created in part c that uses the Memoizing Scribbler robot software
instead of the standard Scribbler robot software.
(See the resources page.)
Describe in your report the differences in how this program behaves compared to the ones in the previous two parts.
Discuss the implications of reaction time on robot software.
Submit the report of your experiments and your findings, as well as your Python code, zipped together in a file called
hwk8-lastname.zip, and email it to Kate and CC me by the deadline.
Assignment #7 -- Look at them Critters! -- Due Mon. 10/19 11:59 PM
- Braitenberg - preliminary
Demonstrate by the end of the Wed. 10/14 lab the "Aggressive" and "Love" Braitenberg vehicles.
- Braitenberg - Gaussians
Create a new version of the Braitenberg insect of your choice using Gaussian normalization.
Experiment and describe the observed behavior of this new unit.
- Braitenberg - non-monotonic
Create another version using one other type of non-monotonic normalization.
Experiment and describe the observed behavior of this new unit.
- Braitenberg - multiple sensors
Do the "Do This" task at the bottom of page 140.
Submit a description of your experiments and your findings, as well as your Python code, zipped together in a file called
hwk7-lastname.zip, and email it to Kate and CC me.
Assignment #6 -- Basic Sense -- Due Wed. 10/7 6:05 PM
- Battery levels over time
Hand in a plot of the battery level over time, as your robot does the following:
- it notes the starting time
- It sits for 2 seconds
- Then it attempts to move forward for four seconds
- But before the four seconds are up it hits a barrier
- When the four seconds are up, it stops trying to move
- While it is doing all this, it is continually printing the time elapsed so far (i.e., the current time minus the starting time),
and the results of the getStall and getBattery functions
You'll have to figure out how far from the barrier to start the robot
to get about two seconds worth of driving followed by about two
seconds worth of stall.
You should be able to see a difference in battery levels when
"thinking" (running a program but not moving), moving, and stalling.
Hint: if you separate the three values with tab characters ('\t') instead of
spaces, you can copy and paste the whole thing into a spreadsheet...
Submit the spreadsheet with your data and plot, as well as your Python code, zipped together in a file called
hwk6-lastname.zip, and email it to Kate and CC me.
Assignment #5 -- Polihere today, Poligon tomorrow -- Due Wed. 9/30 4:50 PM
- Polygon drawing
Using your turnBy(degrees) and traverse(distance) functions you already have, create a program that prompts
the user for a number of sides and the length of the sides, and then invokes a new function drawPolygon(nsides,sidelength)
that you will create as part of your program. Your program layout must adhere to the specifications in Chapter 3.
Examples: drawPolygon(4,1) draws a square with 1 foot sides; drawPolygon(5,0.75) draws a pentagon with 9 inch sides.
NOTE: If your robot is not moving in a fairly straight line when you execute forward(),
you may need to calibrate it.
Be prepared to demonstrate your poligon drawing program at the beginning of the lab!
Assignment #4 -- Dancing the Night Away -- Due Mon. 9/28 4:50 PM
- Exercise 7 from Chapter 2
Duration requirement: at least 10 seconds total, not counting the time the robot is standing still.
Submit your complete program, as described in Chapter 3, via email.
If possible, post a video of your robot's performance on YouTube, and include a link in your email to me AND the TA.
Note: you do NOT need to worry about avoiding walls, obstacles, etc. Just dance!
Note 2: the behavior of your robot must clearly be rythmic.
Note 3: you are allowed but not required to make your robot dance in sync with music.
Note 4: be prepared to demonstrate your robot dancing during the lab on Wed 9/30.
Here are some sample videos of dancing robots. These are not meant to be imitated but to inspire you!
- Scribbler Dance
- Another Scribbler Dance
- SONY Robots dancing
- Another humanoid robot dance
- SONY Rolly Dance
- Dancing Penguin robots
- A Penguin robot (sort of dancing)
- Sync. Dance: Sarcoman Robot
- Keepon Dance
- A kid dancing with a robot
- A Robot Ballet (Nutcracker)
- Dancing Vacuum Cleaner Robots
- Robot Artist (3:21)
Assignment #3 -- Spinning Madly -- Due Wed. 9/23 5:55 PM
-
Create a function turnBy(degrees) that turns right the given number of degrees.
This will require you to experimentally determine how much time it takes to turn a given number of degrees.
You may turn either by rotating around the center-point of the robot, or by moving one wheel while the other wheel remains motionless.
Moving just one wheel may make it easier to get an accurate angle, but you will end up with rounded corners; that's acceptable.
[Rev.9/25/09]
-
Create a function that uses a FOR loop in combination with your turnBy and traverse functions to get your robot to draw a rectangle on the whiteboard in the lab. The function should take the width and height of the rectangle as parameters. The function can assume that it starts out drawing the width of the rectangle (in whatever direction it happens to be facing), followed by a right turn to do the rest of the rectangle.
-
Define a function that repeatedly draws a given number of rectangles.
These tasks must be completed and demonstrated to the TA (i.e., Kate) no later than 5:55.
How much of the task you do beforehand versus during the lab is up to you.
Assignment #2 -- How Far Did You Say? -- Due Mon. 9/21 4:50 PM
-- Sample Solution
Measure the distance your robot travels in 2 seconds, i.e., when you execute forward(1,2).
Define a variable naming this distance.
Define a function traverse(distance) that causes your robot to go forward the given distance.
NOTE: your function may not contain any specific numbers other than 0, 1 or 2.
(This will be true for almost all functions you will be writing this semester.)
Put these definitions in a file called "hwk-0921-yourlastname.py"
Make sure you put comments in your file, including your name and date
Email your file to Kate (TA) no later than 4:45 pm on Mon 9/21. No late submissions accepted.
Assignment #1 -- How Straight Are You Anyway? -- Due Wed. 9/16 4:50 PM
- Do Exercise 2 from Chapter 2
(Write your observations on the paper on which your robot drew the lines.)
-
The command
forward(speed)
is already part of the Myro library. If it wasn't, you could define it yourself, as follows:
def forward(speed) :
motors(speed, speed)
The motors command is a "primitive", whereas commands like forward, backward, etc are convenient shortcuts that are defined in terms of the motors command.
Use your robot to determine the difference between the commands
forward(0.5)
and
forward(0.5, 1)
Then provide your own definition of
forward(speed, time)
Please hand in your solutions to Kate at the beginning of class.