From Maslab 2006

Final Report

Introduction

Team Intro

Team 5 Members (alphabetical):

• Fa (Class of 2006)
• Lohith (Class of 2008)
• Shreyes (Class of 2008)
• Vinith (Class of 2008, maybe)

OneSense

Our robot, dubbed OneSense, was a success and a failure in many ways. Even though it did not win the 2006 Mobile Autonomous Laboratory Final Competition on February 3, 2006, it taught its creators many lessons about engineering. It taught us the importance of testing, organizing code, utilizing simplicity, and dealing with broken equipment. OneSense was in many ways an adventurous explorer, daring to go where no mobile robot has dared to go.

Overall Strategy

Team I See Dead Robots chose to use the camera and only the camera for sensory input, using no other sensors. Hence, we adopted the name OneSense for the robot. The vision-only approach taken by I See Dead Robots had repercussions throughout OneSense's design. First of all, the strategy used would have to rely purely on image processing. Originally, plans had been made for very long distance vision combined with topographical mapping, but implementation details in control ended this pipedream. Instead, seperate "wandering," "looking," "scoring," and "catching" modes were settled on. All would be dumb.

Wandering was clearly a priority. It was thought that this could be done efficiently by looking around for discontinuities in the blue line, and driving around those edges. While the image processing machinery for this task worked smoothly, a last minute decision to tilt the camera down rendered it useless. A quasi-successful attempt was made to replace the blue line searching with finding the bottom of walls.

The ball collection strategy employed the use of a wooden cage underneath the robot, with a gate in front that could open and close depending on the state of the robot. The robot will begin by looking around for a ball, and only search for a goal and score upon finding and capturing two balls. Between capturing a ball and searching for the next one, the robot wanders, as described above.

Mechanical design and sensors

Mechanical Design

We decided to use wood in constructing our robot because it is easy to cut and drill. To avoid getting stuck, we made a circular robot with the size as small as possible (diameter of about 12 inches) and we made it tall so that we have enough space put an Eden and OrcPad. The picture from the top of the robot is shown in Figure 1.

Figure 1. The top view of our circular robot.

In terms of capturing mechanism, at the beginning we wanted to use a simple gate mechanism with one rod closing over a trunk underneath the robot. However, the rod is not strong enough to endure the crash with the wall. As a result, we used two pieces of wood rotated by two servos to open and close the trunk. The picture of the two gates and the trunk is shown in Figure 2. When the robot finds a ball, it centers on the ball, opens the gates, drives over the ball, and closes the gates. When the robot finds a goal, it aligns with the goal and engages on the scoring motion. This involves driving towards (and often into) the goal, backing up, opening the gate, driving forward and stopping suddenly, allowing the momentum of the balls to continue forward out of the trunk and into the goal. While this scoring method seems a little complex, it proved to be the most reliable after testing simpler options such as just driving towards the goal with the gates open.

Figure 2. The front view of our robot showing two gates.

The robot has two wheels which are placed along a diameter of the circle, mainly to enable it to spin in place. Since this is not very stable, we added a caster on the back of the robot. To avoid having the robot fall over its front side, we put the battery (the heaviest item) on the back of the robot, on top of the back caster. The batter is secured in a wooden box as shown in Figure 3. Unfortunately, the battery that we began the competition with was replaced with a smaller, more reliable one, which explains why the wodden casing is too big for the battery.

Figure 3. The back view of our robot showing the battery holder.

Sensors

We decided to use only the camera to help navigating so that we do not have to worry about sensor failures (and because we thought it would be an awesome idea/challenge). Our robot heavily uses image processing to navigate around the playing field and avoid getting stuck with the wall. The only sensor points which were used on the robot was used for the two servos which control the gate mechanism.

Software Design

The overall software design for the robot was relatively simple, as it followed a finite state machine model. The core of the design was focused on enabling the robot to continue action in a state, and easily make the transition to the next one based on a specific response. To accomplish this, we create a standard function called OneIter in each class that was performing an action, which would return false if it needed to be repeated, and true if its job was complete. This enabled us to use simple while loops on the higher order classes, calling the lower level OneIter functions as the conditional of a while look, so that it would only break to the next operation when the first operation was complete.

A second fundamental aspect of the code was the feedback provided by the images to the controls. The actual image processing is described below, but the implementation in the driving classes allowed us to use the information from the images to adjust the current given to the motors. For example, as the robot drives forwards towards a ball, if the x value of the ball moves a little to the right on the next image, then we are able to correct the motion by providing less current to the right motor, turning the robot very slightly to right and centering the ball.

Our software had to ignore balls already placed in a goal.

State Machine Drive

On the higher level, the code was divided into specific actions the robot would take. There were two higher level states of the robot, which we called Ball Search and Goal Search. Each of these states was represented by a class, and each had smaller sub-states which corresponded to smaller actions performed by the robot during one of the larger states.

The first state was BallSearch. The robot would perform smaller states of turning to locate the ball, adjusting to center itself on the ball, driving forward to capture the ball, and closing its gates and stopping after the ball had gone into the cage. If a ball was not seen in the initial turn, the robot would go into another sub-state of BallSearch, FindEdge, which locates and edge on the map and drives slightly offset from it. The robot then tries to search for a ball again.

Once the robot finds two balls, it enters the second large state, GoalSearch. GoalSearch has a few sub-states, each describing a smaller section of the process. First the robot finds the goal in the picture by turning, then it turns in smaller increments to center itself on the goal. Then it drives forward, using the feedback from the images to make slight corrections, and continues until it no longer sees yellow, meaning the camera actually goes into the goal. The robot then performs the Score sub-state, backing up, lifting its gates, moving forward, and releasing the balls into the goal. It then returns to the BallSearch state.

Image Processing

The robot ran its image processing in a separate thread from the main controls and decision making thread, enabling more efficient processing of the images and quicker feedback to the controls. Each image taken by the camera (about 20 frames per second), was processed in three separate ways. First, it would search the image for red balls, going horizontally every other pixel until it found a group of red, and the decreasing the y value to locate the bottom position of the ball. Next it would search the image for goals, looking for yellow in a similar way that it found the red balls. Finally, the image was searched for edges. We defined an “edge” to be a location in the image where there was a discontinuity in the wall, either because the wall turned backwards or out of the sight of the camera. The process of finding an edge was originally done by utilizing the blue line at the top of the wall. We first formed a vector of positions that represented the top blue pixels along the wall, and then calculated the slope between every fourth pixel. With a little robustness built in for possible gaps along the wall, the image processing was able to detect when there was a clear break in the blue line, and thus an edge.

Discerning Edges is harder than it looks!

The modularity of the image processing was evident in the last few days, as a mechanical change to the camera’s position on the robot affected the images that were taken. The camera was tilted downward, making it hard for the camera to see the blue line at a close distance. Thus, the same algorithm to determine edges with the blue line was transformed and renewed, this time with a vector of positions of the top pixels of the carpet. Because we only had to make a change to the class looking for the edge, all of the higher level actions which relied on moving towards an edge did not have to be changed.

Our software had to be careful when recognizing multiple objects, like goals.

Another large part of the image processing was determining when the robot was stuck. Since the robot did not use any other sensors besides the camera, it had to be able to know when the robot was not moving. While teams in the past had developed a nice algorithm to determine how similar two images were to each other, we chose a simpler approach which again utilized elements that were already in place. We took the vector of top positions of the carpet, and compared them over the course of several images. If the y values appeared to be within a certain threshold of each other, then there is a god possibility that the robot is not moving. This enabled the robot to get “unstuck” after hitting an edge or wall.

Overall Performance

Team I See Dead Robots had a fun time building OneSense, even though it scored 0 points during the final competition. The team considered the robot both a success and a failure. OneSense was unique in its ability to catch balls, wander intelligently (no getting stuck!), and score with only a camera. A pity it never got to show off the third.

The double gate system was the product of rushed mechanical development. During Maslab we were under the impression that many teams were spending far too much time on mechanical efforts. In retrospect, it is more likely that we simply spent too little. Because of a hackish design (and questionable ball-letting-through-while-closed construction) our ball cage was incapable of possessing balls for more than 10-15 seconds after capture. However, unlike our previous ball gate, the double gates did not break off when we rammed walls!

In addition, our height allowed the EDEN computer to be easily placed on the surface of the tall wooden platform, allowing our robot to be smaller in length and width. As discussed in the mechanical design section of our report, this helped OneSense become more mobile in hard to reach areas. Unfortunately, OneSense never detected any yellow goal posts in its environment while it was in the GoalSearch state, which was unfortunate because at times it did see a goal with possession of a ball. It was just in another state at the time (BallSearch).

OneSense could not see this goal when it had possession of a ball during the competition.

Conclusions and Suggestions for future students

The team learned some very important lessons through the course of Maslab. One of the greatest changes we made to our robot, which was a bit too late, was to angle the camera down. Throughout IAP, Team I See Dead Robots knew that the camera had a large blind spot but we felt uneasy about moving it cause the camera would then be loose and error-prone.

Plus, the camera was held simply by a screw that held the robot at one angle relative to the ground. We made the decision and changed the camera angle three days before competition day, after which we realized the awesome advantage and unfortunate disadvantages.

The key advantage was that the robot could more easily see balls right in front of it and use feedback mechanisms to go after it. The key disadvantage was that this made most of our Image processing code and algorithms for discerning edges invalid since now the camera would only see white walls and the carpet boundaries. If we had made the change earlier, the robot would be more intelligent (versus simply crashing into a wall) and also more likely to catch the balls that it saw.

Another observation we made was that for most of IAP (~1.5 weeks) we worked mostly on ImageProcessor code which in the end, not only was invalidated by our camera angle change, but was also very buggy and untrustworthy.

The importance of finishing code and the mechanics of the robot was clearly evident after Team 3's victory. It allows teams to cleanly debug their existing code and use it to create a crisp final piece. The only problem with this is that the teams would have to decide upon and finalize their strategies and design plans early during the course of IAP. Although during the initial weeks, a lot of time is spent trying to get acquainted with the process of building a robot, the team has to work together at a parallel level to try to finalize on their design plans and algorithms. Our robot was working great on the morning of the day before the competition. If only we had more time or finished earlier, we could have debugged OneSense and prevented ourselves from adding code at the last minute. This, in fact, hurts us cause at the end of the day on Thursday, our robot was immobile.

Nevertheless, the team had a lot of fun making the robot and the course was a memorable experience. We learned a lot (from our mistakes) and we made good use of our IAP time.