|
OB2 poses for a picture!
Click to enlarge!
Coming soon...
"OB2 The Movie"
OB2 schematic (.BMP format)
If large image is unreadable, click the "magnify" icon in your
browser.
|
Object Bot 2 overview:
To rehash a bit from my main robotics page... OB2 is my second
attempt at an object-grabbing robot. It is built for a contest designed by
Front Range Robotics ( yahoo
group, web site ) club
member Ed Rupp.The object of the contest is find and remove targets from a
MiniSumo arena (dojo), while leaving certain other targets behind. Each target
has a specific size, color, weight, and "taste" (resistance value) - any of
which can be sensed by the robot (click here for
contest rules ).
OB2 hardware:
OB2 uses an OOPic microcontroller,
a servo gripper
, and a Sharp GP2D12
rangefinder salvaged from OB1. I considered using a
Sharp GP2Y0D340K rangefinder for close range navigation, but found its
sensitivity varied too widely with the different colored targets. The OOPic was
upgraded to an OOPic II before installation into OB2.
The robot is built on a modified
Mark III MiniSumo chassis kit . A few of my fellow FRR members noted
that I run the Mark III "backwards" - this was an easy way to add the
gripper without scratch building a new chassis - and the robot does not care
about "direction" anyway!
Locomotion is provided by two standard model airplane servos (GWS
S03N 2BB) modified for continuous rotation. A pair of
QRB1134 reflective sensors are mounted just below the gripper. These
look look for the white painted edge of the arena.
As I write this, there are four successful bots built by FRR
members. These robots use either height or "taste" (electrical resistance) for
determining which target it has. For me, it is often the challenge of
doing something differently that interests me - thus OB2 uses the targets
color!
|
|
Photo of the color sensor PCB.
Example color signatures in a graph.
|
Sensing color:
It was decided early in the project that OB2
would determine which target it has by visual color, so a simple sensor was
built to do this. A bright surface-mount RGB LED is used to illuminate the
target, and a visible-light phototransistor is used to measure the amount of
reflected light. By switching the RGB LED colors (red, green, blue) on
individually, OB2 can read a specific "reflectance signature" for each colored
target (the chart below left shows an example profile of
the target signatures).
Rather than saving the reflectance signatures for all the target colors in
a lookup table, OB2 only needs to know which targets we wish to keep. This
saves a bit on memory and processing. Originally, I tried a simple
comparison of the values seen by the sensor with those in a lookup table
was used. However, there is a bit of noise in the sensor from
external lighting, so a simple lookup table was not good enough. A simple
fuzzy comparison function was written. This worked well for targets that
have a very different reflectance signature (for example blue vs
yellow), but OB2 still had trouble telling the difference between black and
blue targets. For this I use a software trick known as "normalizing" -
essentially I sum all the color values then divide the sum by a
specific color value - this returns a percentage value for the specified color
rather than just its relative brightness.
In the present software, OB2 first uses table lookup to discriminate "easy"
target colors (for example white vs black), but if a target passes that test,
OB2 then normalizes as a check for more difficult colors.
|
|
OB2 high level diagram
Click to enlarge!
OB2 state machine
diagram
Click to enlarge!
OB2 schematic
|
OB2 software:
Since OB2 is OOPic based, the robots software is written in a
language similar to Visual Basic. OB2's operating software is essentially
made up of a bunch of small state machines; implementing what some readers
may recognize as a "subsumption architecture". The basic
concept being that a larger behavior is made up of a series of
small independent behaviors.
OB2 has three "primary" state machines arranged in a loop. One state machine
handles finding targets, one checks the status of the floor sensors, and one
checks the status of the gripper. Each of the primary machines is made up
of a number of smaller state machines which may or may not be "fired" (take
action) on a particular pass through the loop. OB2 also has a couple generic
actions (such as motor control) that may be triggered within any of the primary
machines.
It really is much simpler than it sounds! The main ideas here are that
certain percepts trigger certain actions - and an action often can be broken
up into a series of simpler actions. Any found redundant are
"generic" and often can be made into a generalized independent
action. This saves memory and makes debugging much simpler in the long run.
Explanation of the state diagram:
Looking at the diagram, OB2 starts at the orange bubble in the
upper left corner (either power is turned on or OB2 is reset). Note there
are two primary state loops indicated by bold arrows (the loops with green
bubbles and a pink bubble). A global boolean variable "A1" is used to determine
which state loop OB2 runs. The loop with green bubbles finds and approaches
targets, the loop indicated by the pink bubble is what OB2 does once it has a
target that needs removed from the arena. Yellow bubbles are states that can
change "A1" determining which loop is run. The orange bubble at lower left is
OB2's ending state where OB2 shows off a victory dance. The blue bubbles at the
bottom of the diagram are "generic" behaviors which may be called from any
of the other state machines.
|
