Download CMUCam - Machine Intelligence Lab

Student Name: William Dubel
TA : Uriel Rodriguez
Louis Brandy
Instructor. A. A Arroyo
University of Florida
Department of Electrical and Computer Engineering
EEL 5666
Intelligent Machines Design Laboratory
Special Sensor Report:
CMUcam Vision Board
Table of Contents
Introduction
3
Purpose
3
Benefits
3
Problems
4
Interfacing
4
Usage
5
Conclusions
5
References
6
Introduction:
Gizmo will need to be able to differentiate colors, as well as center its arm on an object.
Both of these tasks can be accomplished with a CMUcam, which is the special sensor on
Gizmo. The CMUcam is a color vision sensor. It is a small CCD type camera mated with
a microcontroller capable of simple image processing. Although limited in its abilities,
the CMUcam should provide Gizmo with the necessary information to track and
differentiate objects of color.
Purpose:
Gizmo’s task is to locate colored cans along its path, and move them to the left or right,
depending on their color. In the real world, this decision process could be used to sort
parts in a warehouse or factory, where the parts would be taken to their next destination
for processing. The purpose of the vision sensor is to detect the color of the can, as well
as to provide positioning information for the robot to center its arm on the can. Since only
one camera will be used it will be difficult to establish the distance from the can (no
depth perception), and the robot will rely on a separate ultrasound sensor for that
information, as well as the presence of a can in the first place.
Benefits:
The CMUcam as an image-processing device makes for an inexpensive color sensor, at
about $109. Not only can it detect the presence of a particular color, but the CMUcam
also reports back the level of confidence it has that the color is present, and the center of
that presence. It is also small enough for a desktop robot, although the attached
processing board could be smaller. I find that the camera’s image processing software has
been programmed well, given the constraints of the processor hardware.
Problems:
While the CMUcam usually does what it’s supposed to, its slow, limited processing is
obvious to the user. Lowering the baud rate slows down all the processing. Since the only
interface is RS232, many devices cannot communicate at the camera’s fastest speed, and
performance suffers. I2C is not available. Poorly designed hardware will frustrate most
users, and components frequently come improperly soldered. Large through-hole
components are crammed together under constant stress. The regulator, which sticks off
of the board, is unsecured, and overheats with the supplied power adapter. It will burn
you. Poor optics and camera CCD module requires much more than normal lighting to
adequately track color. At anything less, all the camera sees is red. The image the CMU
camera processes is off center by about 5 degrees, confusing un-calibrated robots.
Interfacing:
The CMUcam uses a standard serial (RS232) interface. It uses the proper RS232 voltage
levels, so connection with any compliant device is not a problem. By default, the
CMUcam uses ASCII text for communication, although the output from the camera can
be set to send raw byte data. In fact, there are several formats of the data to choose from,
depending on how readable you’d like the output to be. The camera can continuously
report its data, or a polling mode can be used. Polling mode is most convenient in a
microcontroller setting where you can only deal with limited amounts of data anyway.
When polling mode is used, a command is issued to the CMUcam and the response can
be read as needed. Because there is no header or identifier to let the CMUcam that you
are issuing a command, it’s next to impossible to share your precious serial port with
other devices, such as a serial PWM controller - another reason I2C would be preferred. I
had to place a switch on the camera’s connection so that I could share the CMUcam with
my programmer hardware.
Usage:
To remedy the problem the CMUcam has not detecting color under normal lighting,
supplemental lighting for Gizmo will be necessary. I’ve created a special mount for the
vision sensor, which will not only house the CMUcam and its complementary ultrasound
sensor, but also an array of lights to illuminate the object detected by ultrasound. This
should allow the camera to distinguish color under any type of lighting, even total
darkness. To avoid reading stray objects, the camera mount aims the camera towards the
ground, so that the field of view of the robot is limited to the area under the height of the
robot. Using this mount should fix most of the problems with the poor optics. Contending
with the slow performance response is still an issue, and I will have to be careful in my
programming to give the CMUcam ample time to respond. The automatic white balance
and gain takes about 6 seconds to adjust, and I will need to decide if I should do an initial
calibration with no objects (preferably on startup), calibrate on the first object I see, or
calibrate on every object. This time consuming adjustment would really slow down the
operation of Gizmo if required.
Conclusions:
While the CMUcam is not the best choice for complex vision processing, the CMUcam
will work for the simple task of locating and sorting objects of color. It also has some
additional functions that may be useful in other tasks for Gizmo, such as window
tracking. With the additional lighting and time necessary for auto adjustment, the
CMUcam should provide Gizmo the information it needs to differentiate colors, as well
as center its arm on an object.
References:
CMUcam Vision Board User Manual. Anthony Rowe and Carnegie Mellon University.
Version 1.15, 2002 http://www.seattlerobotics.com/cmucam.htm