Team Ten/Paper
From Maslab 2006
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15 |
| Team Ten's Journal · Paper |
Contents |
Maslab 2006 Team 10 Final Report
Strategy
The overall strategy we decided to employ for our robot, Cabbage, was to keep it as simple, fast, and robust as possible. Originally, we started with a design that was basically as simple as we could imagine, with the robot just storing all balls in a corral underneath its body. Then, later on into the competition, we decided that we would be able to make the robot much faster if we had it store balls on an elevated platform, and drop them out the left side of the robot as it passed goals while wall following. The final robot design implemented the wall following and scoring strategy. The limited time available for the competition, as well as the relatively small size of our team, led us to the conclusion that implementing mapping was not an effective use of resources, so instead, we elected to use wall following as our main behavior, augmented by repeated scanning away from the wall for balls. The goal of our wall following was to expose our robot to new territory and also enable it to find its way out of enclosed spaces easily. We decided that, in an optimal situation (for our robot), scoring two balls per goal would be the most effective strategy in terms of time spent stopping and starting again. To this end we configured our ball-dropping servo to drop two balls every time the ballDrop procedure was called in our program.
Sensors
The sensors we elected to use were: our camera, two long-range Infrared sensors, and two bump sensors. If time and sensor points had allowed, we probably would have used at least another break-beam sensor to better monitor the current store of balls, and we would have made better use of our optical encoders for odometry data. If the infrared sensors had allowed, we would have liked to pursue a LIDAR based mapping solution, but unfortunately, even the longest ranged IR sensors were insufficient.
Software Design
Cabbage’s software went through many revisions before the final competition, progressively becoming simpler and more advanced at the same time. If there had been more time, we would have liked to implement a more modular software design than the one we finally went with, but there were several debugging issues that we solved by making Cabbage’s software relatively simple. We chose to just use a single threaded design for our robot, although different functions were separated into different classes.
Vision
Our vision system initially began its life as a K-means clustering algorithm. Soon thereafter, though, we realized that this was serious overkill. In particular, thanks to the color-coded Maslab playing field, the clustering was finished. Given this, the approach shifted to placing pixels in the image within different numbered color bins. The placement of the pixels in bins was done from the bottom of the image upwards, allowing the blue line to be found and all pixels above it to be placed in an ignore bin. Once the pixels were placed in their bins, a breadth-first search was run across the image to extract the various objects it contained. When doing the extraction, the center of the objects was found by averaging the positions of the pixels within the object. No further processing was done on the objects, outside of barcode recognition. Our reasoning for this was that the camera serves one very specific role as far as sensors are concerned: finding balls, barcodes, and goals. IR sensors are going to enable wall-following and keeping the robot from collisions much better than image processing can. Speed-wise this approach allowed us to process a 160x120 image in about 90ms-120ms with almost 100% accuracy in finding balls. In our implementation, we knew that only a single image would be processed at any time, so every buffer needed in the image processing was statically allocated and reused to maximize efficiency and keep the garbage collector at bay.
Mechanical Design
All of Cabbage’s design features focus on maximizing ball apprehension, minimizing the necessity of sensory data to achieve tasks, and integrating scoring and wandering behaviors. First, features related to navigation will be described, and then features related to ball manipulation will be covered.
Cabbage’s drive system consists of the standard two-wheeled differentially controlled drive wheels in the back, with a roller-ball caster towards the front. The robot’s battery is set between the back drive wheels, placing the bulk of the robot’s mass directly over the drive wheels. The robot’s drive wheels are the standard Maslab wheels received on day one of the course (also standard 2.007 wheels, as it turns out), coated in a cork-tape to increase friction with the ground. The robot implements a forward facing and side facing IR sensor. Bump sensors on the front corners of the robot sit behind hinged, “L-shaped“ bumpers that allow for front and side collisions to be sensed by the robot. The 160X120 resolution USB camera rests about 7” high, 4” from the front boundary and 6” from the side boundary of the robot. The camera is attached to a servo, allowing for forward and side vision, a feature further explained in the ball manipulation paragraphs.
The robot’s successful manipulation of a ball involves two functionalities: ball apprehension and ball scoring. The robot apprehends a ball by driving through the ball’s location. The robot identifies balls with the camera facing forwards. As the robot runs over the ball, a passive one-way gate opens up due to the elastic collision of the ball and hinged gate. The gate’s effective mouth is roughly 11” wide, designed wide to decrease needed precision in seeking and driving over balls.
Once through the passive front gate, a ball is initially contained in the Ball Corral, where balls continue to rest or roll on the ground but are contained by the robot’s walls. The shape of the Corral moves balls towards the lifting mechanism as the robot drives forward, again making use of elastic collisions as the robot moves and the balls follow suite. The Corral has space to functionally hold 5 to 6 balls.
The lifting mechanism lifts balls up onto a ramp that points down towards the left side of the robot. The ramp holds 4 to 5 balls, independent of the Corral, and is opened and closed with a servo-controlled gate. The lifting mechanism is a 3” long, 1” wide, thin aluminum sheet mounted onto the drive shaft of a Maslab “high torque” motor. The paddle is mounted such that it contacts balls in the ball chorale at the paddle’s lowest point of travel, i.e. the downward position perpendicular to the plane of the ground. As the Lift Motor turns, the paddle pushes a ball up to the top of the ramp, where the ball loses contact with the paddle and begins its fall down towards the scoring gate. The Lift Motor is set to constantly turn at ~50 RPM. The servo gate defaults closed, only opened upon identification of a goal.
The described ball manipulation process apprehends balls at the front of the robot as the robot is in forward motion. Once inside the robot’s environment balls are moved into a queue that faces to the side of the robot. This allows the robot to release balls into goals parallel to the direction of robot travel, integrating scoring capability into a wall following behavior, a feature which significantly reduces the complexity of goal scoring behavior (compared to front scorers). The camera is turned to the side via the servo as the robot is traveling against walls. In this configuration, the robot can “see” goals parallel to its path of travel, as it is wall following via IR sensing.
Suggestions
It would be nice for the teams if a final score could be a composition of two or three rounds’ score instead of just one. This may be slightly impractical because of the need for a reasonable length presentation for the audience, however, due to the variability in many robots, scores between rounds were vastly different.
Although there was hardly enough time as it is, having a lecture about vision recognition, as well as software optimization would have been really nice. If possible it would be interesting to offer documentation for java as well as another language, like C. This would let teams who are more familiar with, or prefer, another language compete easily.
Finally, fostering more communication between teams and even sharing of code might allow teams to spend less time on implementing low level functions like PID controllers and sensor stuff, and spend more time on strategies like mapping. If teams wanted too, they could look at and borrow from other teams code, or they could write their own.
The amount of robots allowed to restart rounds at competition was embarrassing. It is challenging to lecture, teach, or even demand robust design (software and hardware), but more emphasis on robust system creation could very well lead to better robots. Connect this argument with the first suggestion on this list and there might really be something.
