Team Three/Paper

From Maslab 2006

Maslab teams
Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15
Team Three's Journal · Paper

Design, Strategy, and Results of the Hamburglar Robot

Maslab Robotics Competition Final Paper

Team Three: Doris Lin, Jeff Moore, Steve Zhou

January, 2006

Contents 1 Overall Strategy 2 Mechanical Design and Sensors 2.1 Mechanical Design 2.2 Sensors 2.2.1 Camera 2.2.2 Gyroscope 2.2.3 Servo 2.2.4 Infrared Sensors 2.2.5 Bump Sensors 3 Software Strategy 3.1 Overall Software Design 3.2 Finite State Machine 3.3 Vision / Image Processing 3.4 Sensory Motor Control 3.4.1 Visual Feedback Control 3.4.2 Wall Following 4 Results and Conclusions 4.1 Contest Results 4.2 Performance Evaluation 4.3 Conclusions and Suggestions

Overall Strategy

The design of our robot consisted of four states, which we loop through using a finite state machine. These states include wall following, going to red ball, going to yellow goal, and rotate until object. Due to the size of the playing field, we chose wall following as our wandering strategy because we felt that it was a reliable and convenient way to maneuver around the entire playing field.

Once the competition round starts, we first rotate in place looking for red balls. We do this is by entering the rotate until object state and rotating the robot 720 degrees at a decent velocity. The robot will stop rotating once we've spun 720 degrees without seeing a red ball, or if it sees a red ball. However, due to continuous rotation of the robot, by the time it processes an image and realizes a ball is present, it has already overshot the ball. Thus, to get the robot back to facing the red ball, we do discrete turns in the opposite direction until the red ball is in front of the robot. We decided to use 720 degree turns instead of 360 degree turns because it is possible that due to the velocity of our turn, we miss the ball in the first 360 turn, and turning in place again will increase our chance of picking up the ball.

If during the spin, we see that a red ball is present, we simply go and get it. Once that action is completed, we once again rotate in place. However, due to the fact that our IR sensor in the ball gate notices a ball is present, we will also be looking for yellow goals as well. If we find a red ball before a yellow goal, we go and try to get the red ball. If we see a yellow goal before we see a red ball, then we go and try to score the red ball that is currently in our possession. Scoring in a goal contains multiple steps. First, we drive towards the yellow goal, until our front sensor reaches a threshold. Next, we slowly scans the yellow goal using small discrete turns to determine the location of the two yellow posts. Then, we turn the robot so that it's roughly facing the middle of the two posts. Lastly, the robot open its gate, which leaves the balls in place, drives backwards for a little bit, closes the gate, and pushes the balls into the goal. After it scores, we back away from the goal a little bit, and rotates 720 degrees looking for other red balls.

Anytime we fail to see an object of interest after turning 720 degrees, we enter our wall following state. When we enter this state, it checks if the right right sensor is close to the wall. If it is, it will try to follow that wall. If not, it will drive straight until the front sensor is close enough to a wall and then rotate left until the robot is roughly parallel to the wall. The robot will stay in the wall following state for a set amount of time. Once that time is up, it will do the 720 spin again to locate objects of interest. Due to the fact that our wall following strategy uses a single thread, we could not possibly take camera images continuously and process them while being able to wall follow effectively. Thus, instead of taking continuous images, we take and process a image once in a while. If that image happens to present an object of interest, we exit the wall following state, and enter the rotate until object state and does the 720 degree spin to locate the object.

The strategy of looping through the four states above works relatively well. However, it does not guarantee that the robot does not get stuck. To account for that we implemented timeout functions that gets tripped if we stay in a particular state for a long period of time. The timeout function wiggles the robot, in attempts to get free and then goes into the wall following state in order to get away from the unfavorable location.

Mechanical Design and Sensors

Mechanical Design

The Hamburglar earned its name from its double-decker circular design. We chose to make it multi-layered in order to get more area to work with and to reduce the clutter of battery, Orcboard, Orcpad, and computer. Between the first and second circular disks, the battery sits on the back of the robot, above the robot's rear castor while the camera resides in the front center of the first layer. Up above, sitting on the second disk are the computer, Orcboard, and Orcpad. Residing on this upper layer, they are easy to access, which makes our lives simpler as we constantly need to access these parts. As for the circular design of the robot, we chose a circular design to minimize the chances of getting stuck against walls, corners, and other obstacles. Although there are the occasional exceptions, this circular design works well in keeping our robot free to wander. The two circular disks are supported by two wheels, the ones originally given to us in our bin, that are each hooked up to their respective motors. As mentioned before, there a rear castor supports the robot as well, being placed in the back center of the bot. To address the concern of robots being unstable with just two wheels and one back castor, we placed most of the robot's weight, such as the battery, on the back part of the Hamburglar. Hence, the robot refrains from doing “push-ups” and falling forward when it suddenly stops or changes direction. The first layer is held up high enough above the ground by the wheels and castor to allow enough room for balls beneath the robot. Our robot thus uses the front space beneath it to store balls. The balls are held in a ball cage by a gate that is controlled by a servo. The gate's servo is attached to a lego gear from which extends a lego bar reinforced by a small wooden dowel. This gate remains down most of the time in order to keep balls within the ball cage but is lifted at specific moments. When the Hamburglar sees a red ball, the servo lifts the gate as the bot drives to the ball, and when it is attempting to score, the gate is lifted to let the balls out and then dropped again to push the balls into the goal. The gate can only hold at maximum three balls, which also helps us score only a few balls in each goal and spread out the balls to different goals. The overall mechanical structure of the Hamburglar is rather simple but effective in accomplishing what it needs to.

Sensors

Camera

Like all other robots, the camera is the most important sensor on our robot. It is situated in the front center of our robot on the first layer so to be closer to the ground. It is also angled slightly downward. By angling it as we did and keeping it low, we see only the playing field and completely avoid having to do blue-line filtering. However, we only angled it so much to just avoid seeing above the walls so that the robot can still see balls and goals at a distant enough location.

Gyroscope

Unlike many teams, we adore the gyroscope. The gyro sensor is the key to our ability to drive straight and to rotate accurately. It is mounted on the top of our robot by our Orcboard so that it is mounted securely flat. Although we attempted to calibrate our motors so our robot would drive approximately straight, the bot continued to veer enough so that it was noticeable even in short distances. Our calibrations were not sufficient in certain situations when we needed to drive very precisely straight. One of these instances occurs during scoring goals. When we tried to push in balls without the gyro, the robot would veer enough so that the balls would then just slightly miss the goal. However, once the gyro was implemented so that we could drive very straight, the robot's reliability in scoring goals increased incredibly. In addition, the robot relies on the gyroscope when rotating. The most common use of the gyro by our bot is turning 360 degrees, which it does every so often to scan the area for balls or goals. Another use of the gyro while rotating occurs when the Hamburglar aligns itself to the goal. The gyroscope allows the robot to turn to a specific angle to line up with the goal and increase the chance of scoring. The gyro sensor is also used to thrash about and free itself when time-outs are activated.

Servo

As mentioned while describing the overall structure of the robot, we use one servo to control the behavior of the ball gate. The servo is attached to one end of the ball gate while the other end of the gate is mounted through a hole so it can freely turn with the servo end. The servo begins in a down position of 1.1 radians and lifts to an up position of 1.7 radians.

Infrared Sensors

Three near-distance IR sensors are employed by our bot. Two are mounted on the top of the robot—one in the front center, the other on the right center. The other is mounted on the bottom right of our robot, on the side of the ball cage. The front top IR is used to help the Hamburglar avoid obstacles that are straight ahead. When obstacles are too close, the bot turns left until the obstacle is no longer in the way. The right IR is used to help the robot wall follow on the right side. A feedback control loop is used to help keep the robot at a certain distance from the wall. We chose only to use an IR sensor on one side so we will always follow walls with the walls to the right of the bot. By doing so, it simplifies our feedback loop in the software and also allows us to follow the wall in one direction so we less likely to go in circles or explore the same areas over and over again. These two sensors up top are used together to allow our robot to successfully follow the playing field's walls. The IR sensor below the robot along the ball cage is used to detect if a ball has actually been captured. Every so often while testing, we would miss a ball but continue searching for a yellow goal and attempt to score. This wasted our precious time, so placing an IR sensor facing into the ball cage allows to know if we actually obtained the ball. If the IR sensor senses a close object, such as the ball, the robot will try to score the ball. If not, then yellow goals are ignored and time is not wasted.

Bump Sensors

Despite all our circular design and IR sensors, the Hamburglar still has some “blind spots” in which it cannot see obstacles and may get stuck. To avoid these situations, bump sensors were placed on the right side of the robot's second layer. Since we only wall follow on the right side of our robot, the robot would get stuck along that side so these sensors were only necessary for that side. Aluminum strips were attached across the bump sensors to allow for more surface area that would activate the sensors when hit. When these sensors are hit, the Hamburglar reacts appropriately by veering to the left and freeing itself from the obstacle.

Software Strategy

Our software strategy is relatively straightforward, complementing the simple overall strategy. We focused on writing simple, minimal code at first. We then tuned, tweaked, and modified our software based on thorough testing with the robot placed in a variety of circumstances. This method of software development allowed us to focus on getting our robot behaviors to be very reliable. Simplicity, testing, and reliability were more important to us than complexity.

Overall Software Design

Although the focus was on “tweaking” rather than developing a full-scale software architecture, we basically kept to a design plan which we decided on near the beginning of Maslab. We have three major classes of functions and behaviors which the robot can execute: (1) main class/finite state machine (2) image processing (3) sensory-motor control. Basically, the finite state machine calls functions from the sensory-motor control class, which has access to the sensors and actuators, and reads/controls them as needed. Thus, motor functions interact directly with the sensors. The one exception is with visual data from the camera. Raw camera data is first processed in the image processing class, which returns a summary of the important features in each image.

Finite State Machine

We run the robot through the main class, which initializes the sensors and actuators, and keeps track of which state the robot is in. As described in the “Overall Strategy” section, the robot has 4 states: (1) wall follow, (2) rotate (3) go to a red ball (4) go to a yellow goal. The main class calls various motor control functions based on which state it is in, and the various motor control functions return a message to the main class, specifying which state the robot should go to next. The state which the robot is “told” to go to next, is dependent on whether or not the motor function is executed successfully. For example, if the robot is in the rotate state and a red ball is detected, the control fuction that causes the robot to rotate while looking for objects returns a message to the finite state machine telling the robot to go to a red ball. The state machine then calls another control function which drives to a red ball using visual feedback. If the robot rotates in a complete circle and no ball is detected, the rotate control function returns the wall follow message.

Vision / Image Processing

The vision system of the Hamburglar is also very simple. We simply take images, filter them for various colors, and return summary information of where the objects of interest are in the image. The only colors we need to look for according to our overall strategy are red and yellow. When an image is taken (in RGB coordinates), we first convert to HSV coordinates, and then check each pixel to see whether it satisfies the H,S, and V thresholds for each color. This allows us to convert HSV image data into binary image data. We write two “binary array images” (one for each color). If the pixel values are in the valid range, we specify a “1” for that position in the image, otherwise we assign “0” to that location in the image. From the binary images we can extract the relavent summary information which the motor control class can use. This summary information is handled by the “blob” class, which has fields (1) x-centroid (2) y-centroid (3) size (in total number of pixels defining the blob) (4) minimum x position (5) maximum x position (6)minimum y position (7) maximum y position. Basically, the image processing class passes a “blob” back to the motor control class when asked for one. Our vision system cannot differentiate between multiple objects in an image, but it does not need to, since we rely on vision for only very rough approximations of where obects are. Basically, if there are two red balls, the robot will first start driving between them until one of them can no longer be seen, and then corrects for this change and drives to the other one. For goal alignment, we use vision to “get close” to the goal and use the fact that our IR sensors (which are mounted above the height of the goal) can stop us in time to actually align with the goal. When aligning with the goal we only care about what angle (using the gyroscope) we are oriented at when we see each goal post (as a blob). The basic idea is that instead of having an advanced/complicated/slow vision system we use combined information from multiple sensory systems. Through this “multimodal” sensory interaction we are able to get by with a very primitive vision system.

Sensory Motor Control

Within the Sensory Motor Control class there are two types of functions. There are basic low-level motor functions which allow the robot to move. These functions involve no feedback from the sensory sytems. Examples of these are functions that make the robot go forwards, backwards, turn left, turn right, stop. There are also higher-level functions which adjust the motor speeds based on sensory information. The most basic of these functions allow the robot to drive straight forward and straight backward by reading the gyroscope and adjusting the motors proportionally to the gyroscope reading. Other functions (like those which control the 360 scanning for objects and the goal alignment) take pictures, check for blobs of a certain size, and check the gyroscope to see how far the robot has turned. There are also functions which use visual and infrared feedback to drive in a certain direction.

Visual Feedback Control

Driving to red balls and getting close to yellow goals are controlled by Proportional + Derivative controllers based on the position of a blob in successive images. These functions simply continually take images and adjust motor speeds to keep the center of the object in the center of the visual field (in the horizontal direction). Motor speeds are updated proportionally to the difference between the x-center of the object and the x-center of the image (in pixels), and also proportionally to the difference in this difference between successive images (derivative control). The additional derivitave control allows us to lower the proportional “gain” in adjusting to the object, which eliminates wild and dangerous oscillations which may cause the robot to lose sight of the object.

Wall Following

We use data from two IR sensors to follow walls on the right side (one IR sensor points ahead, and one points to the right). This algorithm is quite simple as well. We first drive straight until we sense a wall (with the front IR sensor). If there is a wall in front of the robot we keep turning left until the nearest wall is far enough away. Otherwise if there is no wall in front we adjust the motors proportionally to the difference between the right IR reading and our ideal distance from the wall.

Results and Conclusions

Contest Results

(Journal Entry for 2/3/2006)

The contest went pretty well. We scored 1 goal and got 2 possession points. We got stuck on the course a lot more than we thought we would, but the bump sensors that we added a few days ago helped a lot in these situations. Also we realized that our timeout function was key (basically if a motor function does not complete successfully in a certain amount of time it gives up and the robot tries to "break free"). The goal alignment was slow but reliable (as advertised). Unfortunately, if we had had a few more seconds we could have scored 2 more balls in a new goal, but time ran out just as the robot was approaching the second goal. We were lucky that balls were visible from the central island, or we could have gotten stuck going around in circles (as pointed out yesterday by the staff).

Performance Evaluation

This performance was not quite what we had hoped for (especially running out of time 10 seconds before scoring in a new goal), but we ended up winning the scoring round at the final competition. Despite scoring only one goal, we were very impressed with our robot’s ability to remove itself from adverse situations, and we feel that this was due to our rigorous testing throughout the building process.

Conclusions and Suggestions

There were several principles that we made sure to keep to from the beginning of the Maslab process, which seemed to work well for us and ensured that we had fun in the process:

1. Keep it simple. Even though the hardware you get with the Maslab kit is incredible and you can do tons of cool stuff, the contest only lasts a month. Don’t try to do everything; pick a few cool things to do and do them well.
2. Test early. Test often. Test as much as you can. You can never forsee all the situations where the robot might get stuck unless you experience them. Besides, watching your robot run around is much more fun than writing code.
3. Keep to a regular schedule and avoid doing everything at the last minute. If you write significant chunks of code near the end of the contest it is nearly impossible to fully understand the effects on the robot’s behavior because there simply just isn’t enough time testing time. Keeping a regular, consistent lab schedule helps avoid this and helps you be more efficient in lab. It is very good if this schedule coincides with the lab-staffing hours, because you can’t really do much if you get stuck and no one is there to help you.
4. Never get upset with your teammates. The task is hard and everybody is doing the best they can.