Team Thirteen/Paper
From Maslab 2006
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 15 |
| Team Thirteen's Journal · Paper |
Contents |
Strategy
We lacked a good strategy.
Mechanical Design
Despite the hexagonal prototype we constructed, our finished bot was a circular robot that manipulated balls through a rotating paddle-wheel mounted beneath the robot. It was designed to be as compact as possible, to minimize the possibility that it would get stuck while navigating. As well, the design was heavily weighted in the rear to insure that it was stable on its back castor even when decelerating. This enabled us to incline the robot to get a better angle for the paddle wheel.
Roller
Our original intention was to use high-speed rollers in order to shoot balls into the goal from a distance. At first we tried to implement two rollers mounted vertically, but found it to difficult to position the rollers in such a way that balls would be channeled through them. For simplicity, we instead used a single horizontally oriented roller wide enough to accept balls within some degree of alignment error. However, this too failed due to the tendancy for our robot to shift slightly, misaligning the roller, as well as its inability to produce significant forward momentum in the balls. Therefore, our final design incorporated a paddle wheel (albeit one with extremely small paddles).
Also, we abandoned our plans for a rear “cage” that could store many balls in favor of a chute the width of a single ball. Though the chute could only hold 3 balls without malfunctioning, it was much more reliable in guiding the balls back into the paddle-wheel. As well, it enabled us to place two photodiodes, one on either side of the wheel, that gave us an accurate count of the balls we were storing.
Sensors
We used three long-range IR sensors positioned at 45-degree angles to one another, to give our robot a wide field of vision to aid mapping and navigation and to avoid collisions with walls. We mounted them as far back on the bot as possible to circumvent the fact that data from within 8 inches of the sensors was usually unreliable. Our quadsensor pair was often unreliable, and due to repeated hardware problems, we did not have them functioning enough to work with and test them extensively. However, the worked acceptably for measuring distance traveled in a straight line. Despite initial concerns about its reliability, our gyro functioned extremely well, especially after removing the noise injection, so it was used for feedback.
Software Design
Our software formed a multi-threaded finite state machine. One thread continuously captured and processed images, one thread polled and recorded sensor readings, and one thread combined these two to form a map of the playing field. A fourth thread runs the current state, and a fifth decides whether to change state.
Image Processing
The HSV color space seemed to separate the colors on the playing field more than the RGB color space does, but conversion to HSV took unacceptably long at the resolution we wanted (160x120). Therefore we identified regions of HSV color space with objects by hand, then used this to create a lookup table in RGB color space. The lookup table used the first 6 bits of each byte, for a 64x64x64 size table. This strategy did a good job, but was unable to reliably differentiate floor and wall and often required modification of the thresholds.
Once we had identified each individual pixel, we used floodfill to find all the objects a frame. Simple statistics (including x- and y-positions, center of mass, minimum and maximum x and y values) about the regions were used to compute distance, angle, and other information. To identify the angles of gates, we found the ratio of the heights of the left and right sides of the goal and the angle between the sides of the goal and then used some trigonometry. Wall detection was implemented based on the position of the blue line, specifically the height of the blue line for each column of the image. The algorithm used was to guess a number of wall segments and then find a "least-sum" best fit set of segments using greedy optimization. This was repeated several times and the best answer taken, with extra cost added for using additional wall segments.
One other useful bit of processing was that we computed the difference between the image and the previous image. This was done from differences both in pixel values and in blue line heights. When the robot is in motion, the picture changes a good amount every frame, which does not happen when the robot is stuck. This method of detecting stuckness seemed more reliable than waiting for current spikes in the motor, since a low battery or weak motor power could affect current sensing.
Movement
We found a proportional-derivative control system using the gyro as feedback was very effective at turning and moving straight forward. We needed to use the (rather unreliable) quadsensors for distance measurements. We used the camera as feedback for driving toward a ball, and didn't need the derivative term in that case.
When scoring goals, we used the goal's angle to find the point 0.25 smoots in front of it. We used our control systems to move to this point, face the goal, and ram into it several times with the roller pushing balls out. This would hopefully be enough to propel the stored balls forward into the roller one by one, where they would all be shot into the goal.
Mapping
We used an extended Kalman filter to keep track of the robot's position and the location of barcodes, tickmarks, and goals. We had intended to also map walls, but did not manage to complete that in time. Without walls, a map is not very useful for navigation, so we only used the map as a pretty display on botclient. We might have used it to improve aligning to a goal, but that was unnecessary and would have required more testing of the map to prove reliable.
Robot Strategy
We had states that pick up balls, deposit balls in goals, wall-follow using our IR sensors, and get out of a stuck position. We continually scan for balls, goals, and a not-changing image to decide whether to change state.
Performance
The robot picked up three balls within a minute or two, then ran over a fourth ball. The third ball had jammed the roller, and the fourth became wedged underneath the right motor, raising a wheel above the ground. The robot was unable to move after that, either because the camera wobbled enough it didn't seem stuck or the left wheel alone was unable to dislodge the ball.
Suggestions
Getting a functioning robot that uses lots of heuristics is not very hard. Some ways to improve the heuristics, such as using PIDs, can make a large difference without too much work. Other ways, such as mapping, can be very difficult to get working and provide little benefit with partial implementations. If your goal is to do as well as possible, quickly develop a simple control flow for the robot, and spend most of your time testing your code and making incremental improvements. On the other hand, working on fancier things such as mapping can be enjoyable even if it does not result in a better robot.
Random comments
- Ensure that the robot can handle seeing too many balls.
- Test, test, test.
- Because testing the code and improving the hardware can be mutually exclusive, having team members on different sleep schedules might be beneficial.
- Always charge the battery when you aren't using it.
