Team Nine/Paper
From Maslab 2006
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15 |
| Team Nine's Journal · Paper |
Contents |
Introduction
Team Nine, Bad-Ass Mother 4000 (regardless of what the Wiki and programs say), competed in the Maslab competition during IAP of 2006. Our robot, svn_destructo, came together nicely towards the end of the month but, as is the case with many Maslab robots, was hung up in the final competition by a small mechanical error.
Our decisions were driven by a single central philosophy and three simple rules:
Design Philosophy: Robust mechanical design simplifies software design.
Rules:
- Keep it simple.
- Don't break anything.
- Don't let Muth touch the code.
The sections below detail the way that these rules played out over the course of the month.
Mechanical Design
The centerpiece of our mechanical system was the ball collection system. The front of the robot was a V shaped indentation which funneled balls towards the storage tower in the center. A motor attached to the Phillips Head Death Driver (a pair of wood screws... of Damnation! stuck in a dowel... from the Armoire of Despair!) swept the balls from the collection channel into the storage tower. A set of phototransistors in the tower were used to detect the presence of the balls for the purpose of determining strategy. Balls could be released by reversing the collection motor.
In an earlier revision, A holdover from an earlier system which involved a solenoid was actually responsible for the mechanical failure at the competition. Foam was necessary to slow the descent of the balls when the solenoid was triggered and was responsible for binding the ball during the competition.
The second salient mechanical detail was found in the camera placement. The camera was mounted high on the robot in order to simplify the blue line filter as will be illustrated later in the paper.
IR sensors were placed on the robot in three key locations: one over each wheel and one in the front and center of the robot. These were set into the body of the robot to prevent false distance readings at the end of the IR sensors voltage curve. The side sensors were angled forward in order to provide feed-forward information for the purpose of wall following (which limits the refresh rate needed by the code). In addition, the side sensors being mounted over the wheels allowed the robot to make accurate turns around obstacles without accounting for its size in code. The third sensor, on the front of the robot, was necessary for collision avoidance.
Other valuable mechanical features included rounded edges on the robot to prevent it from being stuck on walls and high torque motors for better field destroying, enemy robot smashing, corner escaping action.
Image Processing
After an image is captured by the robot's camera, it is passed off to the image processing code. All of the image processing is done in the HSV color space, so the first step performed by the image processing code is converting the image from RGB to HSV. The actual image processing sequence then consists of two steps: blue line occlusion and object recognition.
Due to the height of the camera, we initially believed that we could perform blue line occlusion by simply ignoring pixels above a certain point in the image. However, due to the downward angle of the camera, this was not possible. The height of the camera did make it possible to use a simple blue line recognition scheme since only a small portion (if any) of any captured image would be above the blue line. The method chosen was to use least-squares line fitting of all the blue pixels in an image, and then filling above the fitted line with blue pixels. The method worked well on all test cases.
The second step in the image processing sequence is object recognition. Object recognition works by scanning the image pixel by pixel and looking for significant colors. Only three colors are significant for finding objects: red (balls), green (barcodes and power ball), and yellow (mouseholes). When a pixel of one of these colors is found initially, a bounding box is extended about the pixel to encompass the relevant object in the image. For balls and goals, this is sufficient to locate items in the image, but for green/black objects, an additional aspect ratio check is used to determine if the object is a barcode or a power ball. The objects are placed in different vectors for each type of object, and the information attached to each object includes its bounding box, its area in pixels (to help determine proximity), and its center of mass.
Routines are also included in the image processing code to help determine information about objects in the image. A simple barcode reading routine is used to read the value of a barcode. Another routine determines whether or not a red ball is within a mousehole. Finally, another routine is invoked to determine whether a mousehole can be associated with any barcode present in the image.
Control Code
The robot was controlled by a finite state machine which followed walls (using the forward facing IR sensors) until the camera caught sight of anything red. At which point it would switch to a target acquisition state and finally, if the target was confirmed, to an approach state where the robot moved to the acquired target.
A few additional states covered the transitions between the dominant states, such as the time between losing sight of a ball and acquiring it in the collection mechanism or depositing balls after approaching a goal.
Data was carried between states by a messenger class which was returned by the method executing each state. This was used to keep track, for example, of the number of red balls posessed by the robot to prevent motor jams.
Our controller was massively threaded in the sense that we had a single massive thread -- the simplicity of programming made up for the minor loss in performance.
Strategy
The robot would collect only two balls using its phototransistors to detect when they have been gathered. After its capactiy had been reached it would follow walls seeking a goal and then approach said goal and deposit the balls.
In the absence of any interesting objects in its field of vision the robot would attempt to find a wall and follow it, in hopes of going someplace more interesting.
By hauling only two balls at a time the robot maximized the points gathered on each trip to a goal. In addition, the strategy minimized the chance of being stuck in live-lock on an island because it will be drawn to any red balls it spots.
Advice to Future Teams
- Be absolutely, 100%, certain that everyone on your team wants to do the competition. This includes being sure that everyone has the same level of interest; everyone may want to do the competition but not everyone may want to work 80 (or even 20) hour weeks. Be sure to know this sort of thing before hand.
- On a related note, be certain that Maslab is your only obligation during IAP. It may not seem too time-consuming at the start, but these robots can easily consume all of the time you can give it and still want more.
- Start Early! Be Regular! (as in, work regularly, though the other meaning is valuable too. Team Nine wholly supports eating lots of fiber to get things going.)
- Do a lot of testing too.
- USE svn or cvs or some other sort of version control - you will write a load of code for this project.
- Start making the actual robot (in both hardware and software) at the beginning. Its tempting to throw together hacks to pass the various checkpoints, but its a very bad idea. Laying some groundwork in the first week makes the rest of the month much more pleasant.
- Don't let crappy, difficult to implement systems (especially mechanical ones) eat your testing time.
- This is, at heart, a software competition. It helps to have more programmers than hardware people (the hardware team is necessary, it just doesn't need to be big), and it is helpful to have at least one dedicated algorithm/optimization hacker who is familiar with Java.
- The occasional jihad can be a good way to blow off steam and blow up infidels.
- Take advantage of the Wiki as a way to have fun when you're stressed - for ideas, consider our logbook.
- Have fun with it! The only thing worse than losing at the final competition (statistically, you will) is looking back and thinking that you wasted all of your january working on the robot rather than having fun making the robot.
Advice to Future Staff
Plug a bunch of things into the orcboard, run this program:
/**
* Tests:
* - QPE
* - Ball Sensors
* - IR Sensors
* - Camera Calibration
**/
import org.orcboard.camera.*;
import org.orcboard.orc.*;
import maslab.telemetry.channel.*;
public class TestSuite {
public static void main(String[] args) {
Orc orc = Orc.makeOrc();
Camera cam = null; cam = cam.makeCamera();
BufferedImage img;
DigitalInput lowBallSense = new DigitalInput(orc,9);
DigitalInput highBallSense = new DigitalInput(orc,10);
IRRangeSensor irL = null; irL = irL.makeGP2D12(orc, 5);
IRRangeSensor irR = null; irR = irR.makeGP2D12(orc, 6);
IRRangeSensor irF = null; irF = irF.makeGP2D12(orc, 7);
Gyro gyro = new Gyro(orc, 4);
Motor motorL = new Motor(orc, 1, true);
Motor motorR = new Motor(orc, 3, false);
Motor ballMotor = new Motor(orc, 0, true);
DigitalOutput ballSolenoid = new DigitalOutput(orc, 8);;
QuadPhase qpeL = new QuadPhase(orc, 3, false);
QuadPhase qpeR = new QuadPhase(orc, 2, true);
ImageChannel ichannel = new ImageChannel("Test Images");
TextChannel tchannel = new TextChannel("Test Text");
gyro.calibrate(5);
ballMotor.set(1);
motorR.set(1);
motorL.set(-1);
ballMotor.set(1);
ballSolenoid.set(true);
try {Thread.sleep(500);} catch (InterruptedException e) {}
motorR.set(-1);
motorL.set(1);
ballMotor.set(-1)
try {Thread.sleep(500);} catch (InterruptedException e) {}
motorR.idle();
motorL.idle();
ballMotor.idle();
ballSolenoid.set(false);
int qper0 = qpeR.readCount();
int qpel0 = qpeL.readCount();
tchannel.publish("----------Start---------");
int i = 0;
while (true) {
tchannel.publish("IR -- L: " + irL.getRange() + " R: " + irR.getRange() + " F: " + irF.getRange() + "\n");
tchannel.publish("QPE -- L: " + Integer.toString(qpeL.readCount()-qpel0) + " R: " + Integer.toString(qpeR.readCount()-qper0) + "\n");
tchannel.publish("Gyro -- " + gyro.read() + "\n");
tchannel.publish("Balls -- Low: " + lowBallSense.read() + " High: " + highBallSense.read() + "\n");
tchannel.publish("\n");
if (i%100 ==0) {img = cam.capture(); ichannel.publish(img);}
try {Thread.sleep(200);} catch (InterruptedException e) {System.out.println("Exception, Motherfucker!");}
i++;
}
}
}
And check the output.
It really helps if all of the electrical systems are in place at the beginning. For example, the absence of the gyro at the beginning of the month inhibited our strategy and the absence of the digital output at the end cost valuable testing time.
It would also be helpful if the checkpoints encouraged the construction of the robot rather than hacks to get by them. This is tricky to accomplish, especially because the checkpoint tasks already feel like necessary parts of the robot. A checkpoint for robot design or expiciit instructions to pass chekpoints with the final design of the robot in mind would be appreciated.
In order to minimize the effects of everyone trying to get everything done two or so days before the deadline the staff could resort to the rather dastardly trick of announcing a false deadline then pushing it back at the last minute. There are no guarantees on the effectiveness of the strategy but some teams will only really get work done with the hammer of a deadline hanging overhead.
Don't go overboard on the lectures, especially the ones on less specialized topics. An introduction to mechanical and software design is nice, but not nearly as interesting as mapping and control strategies.
Conclusion
I'm not a hero, I'm not a stranger, forget what you know. I'm just a man whose, circumstnaces, are beyond his control, and I need control. I need control. Beyond my control, they're beyond my control.
Domo Arigato, Mister Roboto. Word.
