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(), andgetObstacle() 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 hella 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 it’s 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 see.
- p. 88 timeRemaining() not defined: but there is an alternative idiom.
- 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 technology 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:
- Call currentTime() and store the resulting starting time in a variable
- Run takePicture()
- Call currentTime() again, subtract the new current time from the starting time, and store the resulting time lag in another variable
- Report the lag using a print() command
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.
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.