created by Tom and Cathy Saxton
Orion, the Egg-Hunter, was created for an Easter egg collecting contest proposed by SRS member Kinsey and run for the first time at the April 2007 SRS meeting.
All participating robots are released at once, to round up as many eggs as possible from an area bounded by walls and containing obstacles. Eggs are safest when returned to the robot's "home" area, but eggs in the robot count at the end of the contest. Complete rules are on the SRS site.
Orion's chassis and bump sensors are standard VEX Robotics parts. The electronics and battery are mounted at the back of the robot, behind the egg "basket."
There are two "pickup rollers" that pull eggs into the robot. Both use a long VEX axle. The larger diameter upper roller has a 1" thick piece of foam around it. Both rollers have "Wonderliner Plus" shelf liner. This combination of materials makes the rollers nicely "squishy" and "grippy," so they work great for picking up eggs.
The front wheels are (currently) standard VEX wheels covered in 3M painter's masking tape to reduce friction for better turning. We didn't have any VEX omni-wheels handy, and they're the wrong size for our design. We're planning to experiment with omni-wheels and adjust the roller mounting to compensate for their smaller size.
Orion's bumper uses VEX lever switches. There is a switch on each side, so he knows on which side an obstacle has been detected.
Orion uses an AVRcam to track eggs. It is similar to the CMUcam (same camera sensor), but has the ability to track up to eight distinct objects of up to eight user-defined colors. Another cool feature is that the code for its ATmega8 microcontroller is open-source. (And, you've gotta love JRobot's slogan, "Building robots instead of sleeping...")
Early testing showed that we were getting erroneous tracking data when we got near a wall. The problem was that the camera was seeing the black wall and dark brown carpet and setting exposure to get images in a gray range. This resulted in having the wall show up as a medium-dark gray and the carpet as a fairly bright yellow. This caused intermittent tracking data for the yellow and sometimes pink/red colors. We were already blocking some of the upper portion of the frame with a white "roof," so were able to easily solve this problem by just shining a light on that white surface, giving the camera a nice neutral area to help with setting the correct exposure (and white balance). This may turn out to be the best solution, but we're also planning to experiment with manually setting the exposure.
We're using an Atmel AVR ATmega128. It's kind of overkill for this task, but we chose it for two reasons: we had a new board we wanted to use/test, and the ATmega128 provides three separate PWM outputs from a single 16-bit counter, which works great for controlling the three motors (two for driving, one for the pick-up rollers).
There's a bank of four DIP switches for setting options (e.g. ignore the camera, or skip searching for the cone to head home), and two LEDs to help with debugging. I do miss having an LCD; two LEDs don't provice a lot of distinct feedback!
The VEX motors are controlled by sending a standard servo pulse (1-2 ms width about every 20 ms). They are connected to battery voltage and signaled using outputs from a 16-bit counter.
The board with the LEDs is a typical perf board. It has a 40-pin 0.6" DIP socket into which the ATmega128 carrier board is mounted. The perf board is where all the components and connections are mounted.
We're using C++ code compiled with avr-gcc. (WinAVR on Windows.)
The basic strategy is that Orion wanders around, using the camera to find eggs and the bumpers to avoid obstacles. Periodically, he will also look for an orange traffic cone that marks our home area.
Here are details on the algorithm:
After setup, the main loop does two basic things: checking the camera, and checking for "bumps." The camera code checks to see if anything needs to be sent to the camera (e.g. the next stage of the setup commands), then processes any data received from the camera. When a full tracking packet has been received, it is analyzed. If it's been "long enough" since we started the run, Orion will look for an object the color, size, and shape of an orange traffic cone as well as the standard search for eggs; if a cone is found, Orion will head for it. If there is no cone, or it hasn't been long enough since starting, the list of eggs is processed to determine where Orion should head. This is done using a center-of-mass calculation that gives heavier weights to closer objects. Motor speeds on each side are adjusted proportionally to the target distance from center. When eggs are no longer visible, Orion will make a large turn to look for more eggs, and then just wander if no eggs are found during the turn.
The bump code handles checking the bumpers and will cause Orion to back up and then turn away from a detected obstacle. If three bumps are registered "close" together, he will make a larger turn in order to get away from a constrained area (e.g. a corner of the arena).
In all cases (tracking eggs, handling bump, etc.), current state is kept, and time is checked to see whether to advance to another state, e.g. from back up to turn when avoiding an obstacle.
The code (ZIP, 155k) is provided here under the GNU General Public License. Please note that this is not intended to be a tutorial for programming. It is provided for the curious, with no support and minimal explanation.
When we were practicing before the competition, at one point I tossed an egg in front of Orion. His reaction caught me completely by surprise -- he immediately turned and started following the egg, including re-centering it as it bounced and wobbled around -- it struck me as being very much like what a puppy would do, really giving him a great "personality!" There are a couple examples of this in the above video, although the eggs around the perimeter of the arena provided a bit of a distraction.
During the competition, we discovered several issues with the bumper design. We fixed these and ran a successful demonstration round after that.
We also realized that we filled the robot's egg capacity very quickly, so we'll be working on increasing that, and also adding a shield so that Orion doesn't spit eggs back out when he get full! (There are several funny examples of this in the video.)
Interestingly, the other two robots in the April SRS meeting competition didn't have any code to find home, but ended up wandering back to their home areas occasionally anyway.
In the post-competition explanation of robots, when we explained about the tracking functionality of the camera, one of the SRS members suggested turning our camera upside down so that foreground/close objects are the ones tracked first. This is a great idea and one we'll be implementing very soon!
|©2000-2020 Idle Loop Software Design, LLC. You may not copy or reproduce any content from this site without our consent.|