Team Five/Final Paper

From Maslab 2007

Overall Strategy

One of the first things our team sat down and discussed was our overall strategy. We decided to start with simple strategy goals and agreed to improve upon those if things were going well later in the month. Our begining strategy was to collect as many balls as we could and park on the porch to double our score. If we mastered that with plenty of time to spare, we would attempt to score goals to obtain points. As it turned out, we did not have everything together in the end to score goals so our strategy going into tournament day was simply to collect balls and park on the porch.

More specifically, our ball collection strategy was to wander until we found balls, move towards them, collect them, search for more balls, and after 4.5 minutes had elapsed search for and park at the nearest goal.

Mechanical Design

Robot Layout

The final mechanical design for our robot was kept rather simple. However, there were some careful design decisions that went into this simple layout.

We chose a round shape to prevent the robot from getting stuck on corners or walls. The baseplate was a 14" circle cut from a piece of 1/4" acrylic plastic. The circle was truncated by a few inches on each side to allow the wheels to extend above the baseplate. This allowed us to use the stock motor mounts without using shims to get the wheels below the surface of the acrylic. The overall round shape prevented us from getting stuck in many situations, but the gap between the wheels and where the circular baseplate began again turned out to be a trouble spot. This was solved by creating fenders from some aluminum tubing to fill in the gaps and make the shape more circular.

The drive wheels were placed in the center from front to back and as far to the sides as possible. This allowed us to make on-the-spot turns with ease without translating. To provide stability, we placed two ball casters in the front left and front right of the robot.

We chose to go with a single-layer design for simplicity and ease of access to all components. As such, most of the 14" circle was covered with the major components. To save space, we mounted our OrcBoard at a 90 degree angle with a custom sheet metal mount to reduce its footprint.

Weight distribution was an important factor in the layout of our components on the baseplate. By far the heaviest component was the lead acid battery. We positioned this as far foward as possible, keeping the majority of the weight over the casters so as to prevent the robot from rocking back and forth or getting stuck with the drive wheels off of the ground. The computer was mostly centered over the axis of the wheels. The lightweight mount for the camera was attached at the rear. This left us with a very stable, front-heavy robot that took a great amount of force to tip backwards.

We mounted our camera on an adjustable mount made from two pieces of 5" x 1" x .25" acrylic allowed to pivot against eachother. This allowed us to adjust the height and angle of our camera so we could experiment to find what worked best. We determined this to be 14", the height of the blue lines on the walls, and pointing slightly downward so the blue line was at the top of the frame. By placing the camera at the height of the blue line, the line always appeared horizontal and filtering out objects about it was greatly simplified. This camera mount was about the only interesting-looking thing on an otherwise boring robot.

During the course of this project, we decided to attempt to score goals via a linear actuator-powered ball shooter. This consisted of a DC motor with a long bolt attached to its shaft. When the shaft rotated, a plunger attached to a nut moved along the bolt's threads to push balls from the ball chamber into a goal. Unfortunately the DC motor we chose for this task drew more current than the OrcBoard could handle and we abandoned this idea.

The final ball storage system consisted of sheet metal panels affixed to the underside of the baseplate. In the front of the robot was a servo-operated gate. Since we were attempting to collect as many balls as we could without a need to release them, the shape of the ball chamber was not important and the balls were allowed to roll around freely anywhere under the robot. We were also able to create a large gate and mouth to the chamber so inaccuracies in ball-gathering code could be made up by having lots of wiggle room.

The final composition of the robot was approximately 10% acrylic, 8.5% aluminum sheet metal, 76% hot glue, and 5.5% sheer irony.

Sensors

Throughout our design process, we experimented with many different kinds and arrangements of sensors. To facilitate this, the first iteration of the robot was outfitted with a wire railing onto which sensors could be temporarily affixed and easily moved. This was flimsy and would not have worked for a final robot, but it gave us a better method of temporarily holding things down than simply using tape.

Originally, we planned to use an array of bump sensors arranged around the perimeter of the robot to detect collisions with walls. The whisker switches proved to be delicate and broke easily after repeated wall abuse. We had more success with the Nintendo buttons, but they were more difficult to trigger. Eventually, our other sensing systems were advanced enough that we did not need bump sensors and left them out to avoid unnecessary complexity.

The most helpful and heavily used sensors on our robot were the IR sensors. By placing two sets of two back-to-back IR's perpendicular to eachother and pointing at 45 degrees to the direction of travel, we were able to get full coverage of distance data all around the robot. Additionally, since the IR beams all originated at approximately the same point, we were able to model the robot as a single point in space. The IR sensors were mounted above the height of the goals so they would not get confused when passing by the goal gap. Since they were so important, they sat high and mighty atop a pillar of infrared holiness.

We also used a gyro to gyrate and tell us how far we had turned. Apparently, it drifted a lot.

Oh and who could forget the camera? It told us what things where which colors and gave the robot a slightly cooler look.

Software Design

Our robot split the perception and decision sides of the robot brain. This was done both to simplify these tasks and to enable both coders to work simultaneously. Out of all the decision we made, this was probably the best, since it meant that nobody was waiting on anybody else until we started debugging the final design.

The perception side of the robot created a simple model of the world. It contained one wall, one ball, one goal, and a virtual beacon. The ball and the goal were simply the closest ball last seen by the camera. The camera utilized a fovea of sorts - we only deleted a fake ball from the world if we saw it in the center of the camera's vision, due to noise on the edges. The walls were calculated by checking the 4 IR sensors and assuming a wall between each pair. The model reported the wall that minimized the area of the triangle formed by the IR sensors and the center of the robot. This was a remarkably robust mechanism, and resulted in us generally choosing the closest real wall, as opposed to an imaginary wall that was closer to the robot. The model relied on odometry from optical encoders and the gyro to translate and rotate all the objects in the world. Most of the distances were calculated using various degrees of trig, but some key measures (like the distances of the ball) were calculated using line-fitting. This was done mostly because trig is hard, as well as somewhat unreliable given imprecise measurements (e.g., how high is the camera actually mounted?).

The decision side was a simple emergent behavior machine. Given the model of the world, it was simple to focus on effective wander mechanisms and tuning PID constants. It had a few basic PID-controlled behaviors (go forward, turn, wall-follow), and everything else was based on combinations of these behaviors. For the first 4:30 of the competition, it simply wall-followed until it found a ball, and then charged it. After that, it tried to find the nearest goal and park in front of it. Our panic behavior relied to dropping virtual beacons in the world, and when we stayed in the vicinity of any particular beacon for too long, we turned in a random direction and drove for 3 seconds. This simple behavior gave us both the control we needed to debug, while the random walk behavior got us out of almost any situation, given 3 or 4 tries (~20 seconds).

One of the most striking features of this paradigm was the persistence of objects in the world. If we saw a ball but failed to make the necessary decision in time, we could correct for it and come back to that ball when we needed to. Similarly, if we saw a goal, we kept it in mind until the end of the match, at which point the robot could turn and drive directly towards the last goal it saw. Overall, we highly recommend this division of labor, both for effectiveness and overall fun.

Overall Performance

Going into competition, we had tested the robot a number of times and were fairly confident it would either score around 6-12 points or completely fail and get zero.

It turns out that we got zero. This was caused by the connector on the main power lead to the battery becoming disconnected after an impact with a wall. It was a silly little thing that was easy to overlook but ended up blowing our chance at incredible job offers, truckloads of swooning women, and infinite glory as MASLAB champions. A shame, really.

However, if we judged our overall performance of the past month's work solely on a single freak occurance, that would be unfortunate. It would kind of be like the scene in the movie /Garden State/ where Large tells of how his whole twisted lithium-sedated life went down the drain when he pushed his mom and she tripped over the dishwasher door which was open because the little plastic handle was broken so she wound up paralyzed and he felt guilty until he stopped taking his medication and came home to New Jersey for her funeral and met up with some old friends who took him to a party where he took some ecstasy and woke to the clanging sounds of his friend's mom's rennaisance fair knight boyfriend. In reality, we managed to accomplish a lot, and the test runs the night before impounding and the run we made in the exhibition round reflected this. We made it to a point where we gained great understanding of the major systems involved in creating an autonomous robot and built a robot that reflected this. With a little more time to polish things up, we may have done even better, but overall we are satisfied with what we made.

Conclusions

MASLAB is a lot of work to do in a month. You probably shouldn't try to do it and take 18.02A at the same time. It will make life hard for you and your teammates.

MASLAB also packs a lot of learning and cool stuff into a month. If you're looking to dedicate yourself to this competition, you can get a lot out of it.