UNIVERSITY OF ROCHESTER

DEPARTMENT OF COMPUTER SCIENCE

CSC 190C - Explorations in Robotics

Resources

Revised:  2009-10-25

 

Here are some resources you may find useful when taking the CSC Explorations in Robotics course:


Course Email

All course email communication is done via the Google group urcs-robots-0910f. You do not need a Google account in order to be a member of the group - simply send a subscription request to be added to the group providing your full name and email address and I'll take care of it. Once you are a member, you will receive all messages sent to the group, and you can send messages yourself by addressing them to urcs-robots-0910f AT googlegroups.com.

There is a benefit to having a Google account: it lets you log in to the web site associated with the group, which is http://groups.google.com/group/urcs-robots-0910f. One good reason to go there is to view the message archive, i.e. all messages that have been sent to the group since it was created.

back to top


Your robot's hardware

Base
The base of the robot you obtained from the Department is a
Scribbler from Parallax Inc. This is a programmable unit, and it's worth exploring the website and checking out the demos to see what it can do. But the programming is a little bit too primitive for our purposes, and so is the base.

Fluke
However, this base together with the Fluke module from Georgia Robotics makes for an amazingly affordable but versatile and capable mobile robot platform. This plug-in module provides a camera, several proximity sensors, and wireless communication capability.

Batteries
Your robot runs on battery power - 6 AA cells, to be precise. You'll find that batteries don't last all that long, especially when you drive the robot (as opposed to just doing sensing in place). I will maintain a supply of alkaline batteries, which you can purchase from me at $5 per dozen. You're likely going to go through at least 3 or 4 dozen in the course of the semester.

If you prefer to go green with rechargable batteries, you will want to use NiMH (nickel metal hydride) batteries, rather than NiCd (nickel cadmium) batteries, as they hold a much longer lasting charge (get batteries with a rating of at least 2000 mAH) and don't have a memory effect. You will also want a charger that can charge all six batteries at once, and independently (i.e., not in pairs), to avoid the serious reverse charging problem with unequally charged batteries. (Using the more common 4-cell charger you run the risk of putting 4 fully charged and 2 low charge batteries in your robot together, which will destroy the two low charge batteries.)

Here's a battery and a charger that look to be appropriate for the robot. Note that I provide these links only as illustrations - I don't have first-hand experience with these, and I do not endorse these particular brands nor this particular vendor. Get these or similar items whereever you choose.

Bluetooth Wireless
Your robot will communicate with your computer via a wireless Bluetooth link. Most recent laptops have Bluetooth built-in. If yours doesn't, or if you are going to use your own or one of the department's desktop computers, you'll need a USB Bluetooth adapter. (Same caveat regarding brands and vendors as in the previous paragraph.)

Game Controller
You'll notice several references in the textbook to steering the robot with a game controller. The kit you acquired at the beginning of the course does not include such a controller, but you're welcome to experiment with a controller of your own. Here's a short note on several types of game controllers that work with Myro (the software that controls the robot - see below). (Same caveat regarding brands and vendors as in the previous paragraphs.)

back to top


Your robot's software

The software we will be using to control this mobile robot platform was developed by the Institute for Personal Robots in Education (IPRE), which maintains an awesome wiki site at http://wiki.roboteducation.org/ with a ton of useful information about your robot, and about programming it.

The entire software package consists of three pieces, only one of which (the last one in the list) you will ordinarily be using directly.

If you are so inclined, all this software is available for your perusal, and even modification! Yes, if you want, you can get right into the nitty gritty details of accessing the hardware. Just check out the Hacking the Fluke page on IPRE's wiki.

The Graphics library within Myro is taken from, and documented more exensively in Chapter 5, Objects and Graphics, of John Zelle's text "Python Programming: An Introduction to Computer Science".

back to top


Improving your robot's software

Your robot's software is running on your computer, and robot commands are communicated to the Fluke/Scribbler combination via wireless Bluetooth. It turns out that the Bluetooth communications overhead dominates the time required to get sensor readings. This hurts especially with the Scribbler sensors when you get their values individually. The function getAll() is available to get all the Scribbler sensor values at once. Calling this function takes the same amount of time (+/- a few milliseconds) as calling a function to obtain a single sensor value, e.g. getLight("left"). In other words, almost all the time goes not into on-board computations required to determine sensor values but into the Bluetooth roundtrip.

I've created a specialization of the Scribbler software which takes care to

  1. Only go to the Scribbler for sensor readings if the current ones are too old, where "old" is determined by a sensor-specific timeout value
  2. Grab as many sensor readings as possible if a trip to the Scribbler is required
There's another fortuitous benefit: the Scribbler returns the current sensor readings in response to any SET command, such as setting motor speeds, which the Scribbler class actually stores but otherwise ignores. (They're available through the myro.getLastSensors() function.) The MemoScribbler class uses the information instead to update its memory. This means that in the typical sense-decide-act loop, you not only avoid a trip to the Scribbler to get each individual sensor reading; if your loop is fast enough you don't need a trip for any sensor reading at all: they come for free with the motors() command! For instance, the loop in Braitenberg Vehicle "Coward" (#2A)
while True:
          L = getLight("left")
          R = getLight("right")
          motors(normalize(L), normalize(R))
requires only one Bluetooth trip to the Scribbler per iteration: the sensor readings obtained in response to the motors() command are memoized, and used by the two getLight functions in the next iteration. The difference? About 10 iterations per second, vs. about 3.

Download memoscribbler.py

To use, save the file in the directory where you normally start IDLE from, and do something like

from myro import *
from memoscribbler import *

# Either
memoinit()

# or
robot = MemoScribbler()

# All the original Scribbler methods, such as motors(), turnLeft(), etc.
# are also available in MemoScribbler.

# In addition, MemoScribbler also provides the following methods:

robot.memoGetAutoTimeout(sensor = "all")
#      Returns the current auto-timeout setting for the given sensor,
#      or a map of current auto-timeout settings for all sensors
#      If any sensor's auto-timeout setting is True, the actual timeout value
#      will be set automatically to the time required to acquire that sensor value
#      The default setting is True for all sensors

robot.memoSetAutoTimeout(onoff, sensor = "all")
#      Changes the current auto-timeout setting for the given sensor,
#      or all sensors, to the given boolean value onoff

robot.memoGetTimeout(sensor = "all")
#      Returns the current timeout value for the given sensor,
#      or a map of current timeout values for all sensors

robot.memoSetTimeout(seconds, sensor = "all")
#      Changes the current timeout value for the given sensor,
#      or all sensors, to the given number of seconds
#      Manually setting a timeout value for any or all sensors
#      implies turning auto-timeout off for those sensors
#      Setting the timeout to 0 effectively disables the memoization

robot.memoGetStats(reset = False)
#      Returns a map of two values, 'get' and 'refresh', where
#      'get' is the number of times a sensor value was requested
#      since the robot object was created or the stats were reset, and
#      'refresh' is the number of times a requested sensor value had timed out
#      and a new value had to be retrieved from the Scribbler

back to top


Cool robots

Throughout the semester I will profile interesting robots now and then. Here's a list of them. Send me a link if you know of a robot that should be on this list!

back to top


Image Processing

The textbook discusses a few image processing techniques that can help in controling the robot using its camera. You can find a lot more interesting and useful information on the RoboRealm (Vision for Machines) website. In particular, the site provides some very informative tutorials.

A somewhat dated but quite comprehensive resource on standard image processing techniques is the Hypermedia Image Processing Reference (HIPR2) developed at the Department of Artificial Intelligence in the University of Edinburgh.

back to top


Feedback Control

A crash course on Feedback Control (open vs. closed loop)

back to top


Other useful Robotics links