Team Seven/Final Paper
| Line 6: | Line 6: | ||
== Ball Collection == | == 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 === | === 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 === | === 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 === | === 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 == | == Drive System == | ||
| Line 21: | Line 32: | ||
= Software Design = | = Software Design = | ||
== Communications == | == Communications == | ||
| + | |||
== Vision == | == Vision == | ||
| + | We used OpenCV's thresholding functions extensively for our vision system. | ||
| + | |||
== State Machine == | == State Machine == | ||
== Movement == | == Movement == | ||
Revision as of 17:50, 3 February 2013
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
Software Design
Communications
Vision
We used OpenCV's thresholding functions extensively for our vision system.
