Computer Science 101: Lab #5
So, of course, this lab wil be from Chapter 5 of the textbook.
We will also do some exercises (Questions below)
not in the textbook, to help us understand our robot better. I've
also noticed some errors and discrepancies in the text. As you read,
check back in this list to keep from getting frustrated:
- p. 83 and elsewhere: senses() acts totally flaky for me.
Substitute individual sensor commands
like getIR(), getBattery(), and
getObstacle() in a while True: loop as needed – and don't be afraid to
report weird results!
- p. 83 takePicture()
is a bit fussy: you have to wait until you see Ok before
you can display the picture, and the first time around it can take a
long time, up to a minute. So be patient.
- p. 84: typo fot instead of for
- p. 84: the savePicture() function
may give you an error if you use it as the author suggests, because
trying to save the picture in the same folder as the Calico application (to
which you do not have
write permission). The
solution is to provide a full
pathname; for example:
- p. 85: RGB color vs. grayscale color discussion is correct, but
doesn't match what I'm seeing when I do the exercises (see Question 5.2 below).
And the image size reported by the author is much smaller than what you will
- p. 88 timeRemaining() not defined: but there is an
- p. 88: Don't be afraid to shine the flashlight directly into the light sensors on the
back of the robot, and maybe fiddle with the motor power values to
get more peppy behavior.
- p. 90: As in Lab #1, substitute the joystick() command
for use of the physical gamepad.
- pp. 95-97: Skip the gamepad section entirely.
- pp. 104-end: Exercises are pretty boring. So you have any time left over
after getting through the chapter and my Questions below, create a workaround
for the broken senses() function by writing your own version:
call it sensors(), and have it call print()
one or more times to output the values of the sensors in a
while True: loop.
Question 5.1: Did you notice a significant
difference in the time it took to run takePicture() the first time, versus
subsequent time? If so, can you suggest are reason for this difference?
Question 5.2: Let's try and figure out why it takes
such a hella long time to take a picture, even after the first try. After all, you can take photos pretty
much instantly on your cellphone, which uses the same camera
as the Fluke, so why the delay?
First, we'll collect some precise time
values by using the currentTime() function from last week's
lab. If we type this command in by hand after we run takePicture()
we're going to create even more delay, because of our own (human) response time. So
let's write a little timePicture.py script to do the work for us.
This script should do the following:
Once you've got your timePicture script working, run it a few more
times to make sure you're getting consisent values (say, no more than one
second difference). As you can see, the picture is hella big.
- Call currentTime() and store the resulting starting time in a
- Run takePicture()
- Call currentTime() again, subtract the new current time from
the starting time, and store the resulting time lag in
- Report the lag using a print() command
Now try this:
double-click on the image that you saved to the Desktop. This will pop up a
full-size version of the image in the Mac's Preview program. In the Tools
menu, click on the Show Inspector item. Clicking on the first tab in the
resulting information window will show you the file size in bytes, and also the
image width and height in pixels. Clicking on
the second tab will show you the depth of the image (number of bits per pixel).
Based on this this information (width, height, bits per pixel), and the fact that eight bits
make one byte, what is the expected image size in bytes? How does this compare with the actual
image size you saw in the info window? What accounts for this difference? (If you're not sure,
google on JPEG to find out.)
To conclude this exercise, let's figure out why it takes so hella long to grab a picture from the
Fluke. How is your Mac getting back the images from the Fluke board (and communicating with the
board in general)? (Scan quickly over Lab #1
if you're not sure). What is the expected data transfer rate you get with this system (again, GIYF).
How do these rates compare with the bits per second you get when you divide the JPEG image size (in bits!)
by the number of seconds reported in your script? How do the rates compare with the bits per second you get
if you use the expected image size instead of the JPEG image size?
Question 5.3: Did your light-detecting “insect” program (p. 88) seem a little sluggish?
Mine did. If yours is behaving to your satisfaction, great! If so, can you modify the author's code to pep it up a little?
As usual, have one team member submit all your Python scripts as attachments,
and each member send me their own answers separately in a PDF.