Team Seven/Final Paper
Contents |
Overall Strategy
Team 7's strategy went through three primary phases that depended fairly heavily on our mechanical capabilities. For most of MASLab, we intended to play a low-ball-count high-ball-value game where we would not bother going after the ball release button and put as many balls as possible into the top tower. After a while, we realized that this would not be optimal if we were collecting balls thrown over from the other side, so we designed a two-hopper system that could differentiate ball colors so that we could put only our balls in the tower and throw the rest back over the scoring wall. Unfortunately, this strategy had to be simplified a great deal when the competition arrived, because we didn't have the time to implement the required systems. As such, we found that we could maximize our points by scoring over the wall, in which case which color balls we collected wouldn't matter, because gaining 20 points and causing the opponent to lose 20 points had the same net result. In the end, our strategy boiled down to getting any ball we could for the first 150 seconds, and then spending the last 30 seconds looking for the yellow scoring wall and attempting to score with all the collected balls.
Mechanical Design
Our final mechanical design used a two-level system with a ball collector on the bottom and a hopper/dispenser on the top, each powered by a rubber band roller. An Archimedes screw was used to transfer the balls from the collection area to the hopper, and all of this was mounted on a two-wheeled drive system with a ball transfer unit in the back to provide balance.
Ball Collection
Janky Woebot's ball collection system drew heavy inspiration from the winner of last year's MASLab competition. It comprises of rubber band rollers to grip and take in balls, an Archimedes screw to lift the balls up to a higher level, and another rubber band roller to hold on to or release balls from the top hopper as necessary.
Storage Areas
Two storage areas were present in our design. The bottom storage area comprised of a curved piece of sheet metal designed to allow the intake roller to draw in balls and then bring them over a slight bump, which prevented balls from being lost through the front and also allowed space for the drive motors to be mounted under the sheet. The sides of this storage area were simply the acrylic sides of robot itself, to which the sheet metal was mounted. The back of the sheet was bent and cut to allow balls to naturally roll towards the Archimedes screw.
The top storage area was also made of sheet metal and mounted on aluminum support columns. It left space in the back for the Archimedes screw to deposit balls, and had acrylic support sections in the front to allow the roller motor to be mounted.
Archimedes Screw
The Archimedes screw mechanism employed one high-speed motor, a bent welding rod for the helix portion, and two aluminum guide rods to trap the balls being moved. The helix and the guide rods provided the requisite three points of contact for stability as the balls moved up through the screw, and a piece that jutted out from one of the guide rods near the top of the mechanism knocked the balls onto the top hopper once they passed the required height.
Originally, the motor suffered from a problem where it could not provide enough torque to move the balls up the rails unless it was run at a very high speed. However, when run at a high speed, balls could not get trapped in its bottom portion easily after rolling there from the bottom storage section. This issue was solved by having the laptop send commands to alternate the speed of the motor from a faster (higher-torque) speed to a slower one and back ever 5 seconds. Thus, the helix would be slow enough to grab balls from the bottom storage section and still provide enough torque to move balls through the mechanism into the top hopper.
Rollers
Rubber band rollers were made by cutting acrylic "wheels" and mounting them onto aluminum axles that were coupled to high-speed motors. Rubber bands were stretched across the "wheels", thus providing a large area by which balls could be drawn in when the system was turned on. This method was proven to be a very effective and reliable way by which balls could be captured, since the large area required less accuracy by the robot's movement, and the rubber bands were able to grip the balls well and draw them into the bottom storage section.
Drive System
For much of IAP, the robot had a drive system comprising of two small, fast motors with thin, water-jetted aluminum wheels. These wheels were made to have sharp spikes to provide traction on the carpet, and had 20 openings along them to allow for the use of optical encoders. The drive system was mounted onto the frame using aluminum L-brackets, and was placed just underneath the aluminum bottom of the robot's collection level. However, when the type of floor used for the competition changed from carpet to gym tiles, we had to drastically change the way we approached the drive system. The metal wheels dug into the mats and the motors we had didn't have enough power to move the robot effectively on this surface.
During this period, we also experienced issues relating to an imbalance in the speeds of the motors. We found that one side drove much faster than the other, and had to do a significant amount of compensation- giving the faster side speed commands that were 20% slower and the slower side commands that were 30% faster than the actual baseline input value in order for the robot to approximately drive straight. In the process of testing this drive system, we had at least two motors destroy their internal gearboxes, wearing the gears down until the device was essentially useless. We also had a few incidents where the amount of current that the drive system was drawing overwhelmed our motor control board, causing it to fry. At least one incident involved a very visible fire on the side of the robot.
These problems were actually resolved when we had to switch to rubber wheels and slower, more powerful motors in order to properly drive on the gym tiles. During the switch, we noticed that while our original motors looked the same, they were actually different models, thus explaining the speed disparity. The switch allowed us to drive much more effectively, and gave us a much smoother drive system than we had before, though we had to give up the ability to use encoders in the way that we planned, since these wheels did not have the required holes (though we found that we didn't really have the time to incorporate encoder information well anyway by this point). These motors didn't have to draw quite as much current, so we were able to get away with not using a separate motor control board and still managed to drive without burning any of our electronics out.
Electronics
Hans/Victor
Software Design
Our software was written in Python and AVR code, and run on the provided Acer netbook and Arduino Mega.
Communications
Hans
Vision
We used OpenCV's thresholding and downsampling functions extensively for our vision system. The webcam that we were provided was very high-quality and gave far more information than was necessary for the relatively simple processing that we needed to do. As such, we downsampled each image we obtained into a 120x160 thumbnail in order to lower processing costs significantly while retaining our ability to identify and process color information.
To avoid some issues associated with lighting and coloration, we then changed each image from RGB format to HSV. Then, we used two pairs of maximum and minimum HSV coordinates to filter out the color(s) that we wanted to find. Traditionally, only one maximum and one minimum HSV coordinate would be required, but we used two pairs along with the CV.OR function on them in order to make our color identification system more robust.
A color calibration program was written in Python to adjust the HSV thresholds for optimal color identification. It was found that the saturation and value parameters did not really affect color identification much, so sliders were only put in place for the hue maximums and minimums. These parameters were adjusted while the program took in either a picture or the webcam image, and the resulting color masking was checked. Originally, calibration was intended to be done in both the 38-5xx and 26-100 playing fields, but it was found that there was very little difference between the two, and the values used in 38-5xx were sufficient for use in 26-100.
State Machine
The robot’s default state for most of the game was a wall following state. It could transition into a getBall state if it found a ball in its field of view and was in the first 150 seconds of the game, or into a findWall/scoreWall state if it found a wall and was within the last 30 seconds of the game. Since our strategy did not require the robot to go after a particular color of ball, it treated both colors the same way. Additionally, we did not require the robot to press the ball release button, so even though our vision system could reliably identify the cyan button, this information was never used. Older versions of the state machine that were not used in the final competition did, however, have states where the robot would keep track of the button’s delay time and press it after that had elapsed.
A timeout was implemented as a form of both exploration and stuck detection. If the robot was in the same state for more than 10 seconds, it would execute a lookAround movement (detailed below). This prevented the robot from being stuck without the sensors realizing this, and also helped it see balls that were not necessarily near walls and would be harder to see while wall following.
Movement
Janky Woebot essentially had four different movement patterns: wallFollow, moveToX, backUpFromHit, and lookAround.
Wall following was done in a right-handed manner, where the robot would follow a wall on its right side and correct if it was too far or too close to the wall. IR values of sideClear, tooFar, and tooClose were used as thresholds to decide when the robot would move forward or turn to be further/closer to the wall. If the IR value was higher than the tooClose threshold, proportional control was used to turn the robot back away from the wall. Similarly, if the IR value was lower than tooFar but higher than sideClear, proportional control was used to steer the robot towards the wall.
In the moveToX movement pattern, an x value was given to the movement command, and the robot attempted to move forward and turn towards the given direction. The x value was obtained from the vision code, where it corresponded to the difference between the center of the image and the center of mass of whatever color the robot was going after during a particular state.
BackUpFromHit was a movement pattern consisting of a brief backwards movement followed by a turn to the left. This was entered if the robot detected a collision via its front IR or bump sensors. The turn to the left complemented the robot’s right-handed wall-following, since more often than not, this kind of movement allowed it to immediately enter a stable wall following state.
LookAround consisted of a short backwards movement and then a slow leftward rotation. Although the actual movement is similar to backUpFromHit, the intention of lookAround is to be used after a state timeout occurs. This rotation would occur for a maximum of five seconds, during which the robot could be distracted by its present target (any color ball during the first 150 seconds, or a scoring wall during the last 30 seconds). If after 5 seconds, no target was found, a wallFollow movement would be executed.
Overall Performance
Janky Woebot proved to be a fairly reliable robot in terms of movement and ball collection. After the last-minute change in drive system and a bit of rewiring and adjustments to movement parameters, it was able to execute movements smoothly, though a bit of turning oscillation was observed when it was tracking a ball. The “ball digestion” system of rollers and helix performed well despite the fact that our motor had relatively low torque due to the workaround we found with pulsing its speed. Notably, our helix spun much faster than any other team’s, and the lift system could have probably been made even better by using a slower but more powerful motor.
The lack of a mapping mechanism or really any kind of odometry or “memory” of locations made it so that the scoring ability of the robot was rather chancy. Whether or not it found the wall really depended on the field and where it was as it entered the end game phase of the last 30 seconds. Clearly, this was area that could have been worked on.
Conclusion
It’s hard to program a robot that hasn’t been built yet. That being said, integration of the software and hardware was surprisingly quick once the mechanical side had been completed. We found that while roboticists might say that 90% of robotics is software, that doesn’t really apply to MASLab. We do not have the advantage of being able to order all of our components and have them manufactured precisely. Given the short time scale (~ three weeks) given for MASLab, we found that the mechanical side of the project was almost always what was slowing us down. Perhaps our initial design was too ambitious. We had a design that really required the full attention of five people to really work, and while our schedule had us completing the mechanical portion of the project within the first week and a half, we were actually still changing the drive system up to two days before the final competition, and had to cut an entire hopper and its associated ball separation systems in the last week of the competition. Due to circumstances outside of our control, our team really only had the full attention of five people maybe one or two days of IAP, making it impossible to achieve our original design within the allotted time.
We also found that because of these circumstances and a relatively low level of top-down management, we were not always able to delegate tasks very effectively at the beginning. The difference between what teams wanted to achieve and what they ended up getting in general seems to show quite a gap in MASLab, and it ended up being a very good thing that we had a backup plan that allowed us to cut several systems and still have an effective robot. As such, it would be recommended for future teams to have contingency plans built into their schedule that could be shifted to if certain goals were not met by particular dates.
MASLab staff was found sometimes change their decisions well into IAP, this time notably on the issues of flooring type and how seeding was to be conducted. The type of flooring really affected how we designed our drive system, and we wasted quite a bit of time changing that to make it possible for our robot to drive at all on the new floor. Different design decisions would have definitely been made if the flooring decision had come in at the beginning of IAP. How seeding was conducted (competition-style against another team or against a stationary robot) ended up not really affecting any team since none of us had advanced far enough mechanically, though it could have theoretically affected our seeding strategy. Because of this, we would recommend that MASLab staff test out these things a bit more extensively before the beginning of IAP in order to provide “final” competition parameters to competitors as early as possible.
