Team Seven/Final Paper
From Maslab 2007
The Formation of Team 7, their goals, and their robots for MASLAB
On November 2006, an “I love Robots!” flyer catches the attention of a student walking along the corridor of Building 9. It was then, that such a quest to find ideal teammates to join this robot competition had begun, but what other graduate student would display an interest in joining an architect/electronics hobbyist??? Other architects, of course! Thus, the formation of Si Li, an architect/computer science aficionado; Dimitris Papinikalou, architect and mechanical engineering devotee; and Rachelle Villalon, architect and electronics hobbyist; had arose. They are three graduate students in the Computation Discipline of the Architecture Department with a shared fascination in robotics and Artificial Intelligence. Their goals for an ideal MASLAB robot include:
1. The robot’s chassis must be round so as to avoid any physical impediment along the playing field walls. 2. The robot must implement a simple ball acquiring mechanism whose design would require minimal unknown variables from theory to application. 3. The robot must act “intelligently,” that is, recognize when it has placed itself in an obstacle and decide how to veer from the situation. 4. The robot’s software “intelligence” must be kept simple to avoid confusion.
In the course of one month, the team had fabricated and designed a variety of chassis’ from conception to implementation and produced several lines of code. The following descriptions below detail our robot from strategy to design. We are Team 7, also known as “Archbot.”
SENSORS
Camera: The camera is an important feature for Archbot because it enables the robot to catch sight of red balls, yellow goals, and green barcodes in HSV mode. The robot’s vision features blue line filtering which facilitates in recognizing objects solely within the playing field. The camera is situated at the front end of the chassis and atop its highest platform. Here, the robot’s camera is tilted at a slight angle overseeing the playing field from a tall vantage point. Archbot scans the playing field horizontally and at the first sight of a red pixel (indicating a red ball), aligns itself towards the target and approaches the subject.
Infrared Sensors: Two short-range IR sensors (GP2D120) are positioned at a 45 degree angle at the frontal mid-section of the robot. These sensors proved invaluable when the robot had to avoid a side collision with the wall. Its basic strategy includes: if the distance between the left IR sensor and the wall is greater than 0, then turn the right wheel/motor. The same is true for the opposite side (right IR sensor, turn left motor). Side collisions were effectively avoided as planned. Frontal collisions, however, or any other obscure impact proved the IR sensors could not be solely relied upon.
Quadphase Encoders: To counter Archbot from halting each time a frontal or any obscure collision would occur, quadphase encoders were implemented so that the robot would recognize that its wheels had stopped turning and then take appropriate (i.e. back up and turn 30 degrees) action in getting its wheels to continue rotating (and continue finding balls!). The encoders are placed at a ¼” distance from the wheel and affixed to a custom-made cantilevered wooden bracket. The quadphase encoders proved invaluable alongside the IR sensors when Archbot ran into physical obstacles.
Motors: Two regular DC motors are positioned atop the robot’s lowest platform, which in turn connect to two 4” (dia.) wheels. Throughout the month, the motors had undergone constant handling (along with the rest of the robot) and its 22 AWG wires would detach and require constant soldering. One servo motor is used to control the robot’s gate to rotate 90 degrees and back at 0 (note: it is the only piece of equipment with a female header, look twice before trying to plug it into the orcboard!).
DESIGN & MANUFACTURING
We saw the design as strongly related to the strategy and the entire programming code of the robot’s response in environment. Complex shapes would cause problems to the robot during its turning and navigation maneuvers especially when it would be close to walls. Complex shapes would thus need extra sensors in order to overcome these problems. A symmetrical round shape, on the contrary, with the wheels symmetrically positioned along its diameter, would have the center of rotation coincide with the center of the robot’s shape, so the general outline of the robot’s boundaries would always remain the same. We therefore chose a round shape to simplify problems. The balls’ capturing cavity was convex inside the basic shape so that the robot would collect balls by simply approaching them. A gate opens and closes during the grab behavior to let the balls enter and keep them captured. In order to score, the robot opens the gate, retreats, closes the gate again and uses it to push the balls into the goal. The entire chassis was fabricated by plywood, using a laser cutter machine and the parts were assembled together using a “press-fit” technique based on friction-joints. We took advantage of digital fabrication and rapid prototyping techniques to make the design more simple, precise and robust.
SOFTWARE
Design: The software design was originally intended to allow each group member to program bits and pieces. Input, analysis and output are all Task (a thread based class that performs tasks on our robot) inheritances performed on separate threads individually while they all update and use one command data bank. This way, each of us can take a part to work on without being affected by other team mates. The command data bank is a class that contains all sensor values, motor speeds, captured and processed image, etc. Sensors and cameras constantly updates this data bank every 100 millisecond. The actuator is given a separate thread to keep the motors running from start to end. The speed of the motor is changed by strategic behaviors based on context. By setting up this frame work, every team member can program the behaviors by getting and setting the data bank without going through the APIs For more effective code management, we also used behavior pattern to design the strategic behavior structure which is the most important part of the entire software; each behavior works as an individual class that replaces itself into another behavior class when the task is done.
Strategic behaviors: The behaviors are broke down into fragments of movements. It starts out from the IR wandering behavior. In this behavior, the robot wanders the playing field by reading the sensor value of the two IR sensors that are facing the front at 45 degrees. It simply avoids the wall by turning away from the closer wall. When the two sensors reads obstacles close by, it will choose the further side to make a pivot turn on the center of the robot until one side of the IR sensor is clear. When the robot is moving, the vision processing class from camera sensing thread constantly updates the target location, if a target appears, the behavior swaps itself to “aim ball” or “approach ball” behavior. If no balls are spotted during wandering for a certain amount of time, it will perform a 360 look around behavior to search for balls. The aiming behavior is the behavior that we suffered most problems. Some how our battery can never be charged above 12 volts and it easily drops below 6 volts. For precise aiming, we had to set the motor speed to very low by giving less power to the motor, but many times, when the battery drops low, it doesn’t have enough current to drive the wheels. And we believe that’s what led to our failure in the final competition. The approach behavior adjusts the robot’s orientation to center the ball while moving. We changed the centering formula many times, but the last formula resulted in a tragic over turn on the playing field. When the robot gets close enough to the ball, it opens its gate, moves over the ball and closes the gate to complete a grab ball behavior. After it grabs, it swaps itself into the wander behavior again. Depending on how many balls the robot obtained, if it gets more than three balls, the search target will swap to goal instead of balls and try to shoot. The shooting behavior is modeled after competition videos we saw from past years. It simply opens the gate, retreat to allow to balls to come out of the container, then close the gate and push them into the goal suing gate. Unfortunately we did not have a chance to see this performance during the final competition. Wheel spin – “Quadphase encoder” based Escape checking is accompanied with all movement behaviors. Every time the robot stalls, it tries to move towards the opposite direction and make a slight turn.
Vision processing: We used an HSV converted image instead of an RGB mode, to simplify the color detection. With the HSV mode we only have to specify hue thresholds for each color and then adjust the value intensity to deal with light and shadowed areas.
The vision processing is divided into two parts: image analysis/scanning (input), and image processing/printing (output)
Our vision algorithm works by performing a loop through every line and scans every pixel of each line. According to the encountered pixel it might return:
1. An array of the located balls, with the closest ball as being the last element of the array. 2. The location of a visible goal. 3. The Location and the genome of a visible barcode.
1 Red Ball detection
In order to make the ball detection algorithm more fast and robust, we perform a horizontal scan of each frame starting from bottom left and moving towards the upper right end of the frame. Because of the perspective geometry of the camera, the ball that is closest to the bottom of the screen is the one that is closest to the robot as well. The first red pixel that is encountered in the horizontal loop constitutes (in the vast majority of the cases) the bottom of the circle that defines the closest ball. So, while being in the same horizontal loop the scanning cursor enters the red blob from that bottom entry point and moves up until escaping the red blob. At the exit point we have already defined the diameter of the ball and thus its center. The new ball is instantiated as an object and it is stored in an Arraylist. The algorithm then continues the scan from the entry of the first ball, but ignores all red pixels that are bounded in the first ball’s bounding box. By the bottom-up scanning strategy we do not have to further calculate areas of balls to determine which is closer so the algorithm becomes more simple and robust.
2 Goal detection
If the scanned pixel is yellow, we implement the provided coded for calculating the bounding box, and the centroid of the yellow area. A new Goal object is instantiated that stores information about its centroid’s coordinates on the screen.
3 Barcode detection
If the scanned pixel is black or green then the scanning cursor “enters” the barcode’s area, and when it exits it estimates the middle point of the line defined by the entry and exit point. From there it performs a new scanning upwards until it exits the barcode again, and stores the consecutive barcode colors (green black) that encounters as 0 or 1 digits. At the end of the scanning the algorithm instantiates a new barcode object with a specific genome (the series of 0s and 1s) and specific coordinates on the screen.
Output
After the scanning finishes, the data is printed on the screen with the already provided code. To make it faster we omitted the coloring of the red balls to white. The algorithm returns the number of detected balls in order of proximity, the coordinates of the ball that is closest to the robot, the goal and its coordinates (if found) and the barcode, its coordinates and its genome (if found). The ball that is closest to the robot is marked with crossing hairlines on the screen. Goals and barcodes have different colored bounding boxes.
Overall Performance
During testing, the behaviors are quite pleasing. Each behavior is tested individually and collectively, and they seemed to work well. Except the aiming behavior which always causes the robot to stall. Since the aiming behavior moves the robot very slowly, we unwisely disabled the escape check, eventually we found that when the motors suffered from the voltage problem, the robot seated dead forever, and that was too late for regret.
