Team Eight/Final Paper
Crank: The Tank
Contents |
Introduction
Crank: The Tank was exiled from the land of Bob the Builder... he could not fix it, he preferred eating spherical objects instead. One time he ate the wrecking ball off of Lofty, which is why she only has a hook now. Crank eats balls using his front facing rubber band paddle wheel. He also has a designated ramp area for chowing down balls from the chute. Once he digests the balls, he uses his conveyer belt to spew them out on the pyramid. Crank has a huge appetite for balls and one day hopes to eat the moon.
Overall Strategy
Crank’s strategy is to first find the button while collecting any balls he sees in the way. After pressing the button, he collects balls in the upper level hopper. He then searches for the pyramid and aligns to the top level. The conveyor belt then scoops up the balls in the upper level and places them in the top. Since Crank’s appetite is insatiable, he keeps searching for balls on the field until time is up.
Unfortunately, Crank was unable to line up with the button very well, so for the final competition he decided to just try and eat as many balls as possible. He was hoping to eat all of the balls to clear the field, but ultimately was short by a few balls.
Mechanical design and sensors
Crank is mainly made of laser-cut acrylic pieces designed in Solidworks. He uses two motors to provide rear wheel drive along with two caster wheels in the front. Another motor runs the rubber band wheel, and yet another runs the conveyer belt. The goal for Crank was to be able to collect balls both on the ground and also from the chute, and use a conveyer belt to transport them to the top of the pyramid. The conveyer belt uses a high-torque servo to go from vertical to the angled position shown below.
His uniquely designed collector wheels take a new spin on the traditional MASLAB rubber band wheels. Rubber bands are instead placed as paddles to swipe the balls into his belly.
The conveyer belt was intended to scoop up balls from both the bottom and top levels and place them in the pyramid. This proved to be more difficult than we originally thought, and in the end it could only scoop up balls from the top level.
Crank has a five IR sensor array going around the front of the robot. The IRs effectively covered the entire front and sides of Crank, allowing him to sense obstacles. Crank also has a bump sensor on the front in order to try to help him line up correctly with the cyan button for the chute. Their locations are shown below.
The Webcam was centered right under the laptop stand in the front in order to see as much of the field as possible. This location allowed the balls to remain visible by the webcam until it was just about to be eaten by the rubber band rollers.
Software Design
Crank made decisions using state machine software architecture. He was designed to spend the first 2 minutes searching for the cyan button while eating any balls he found on the way. After finding the cyan button, pushes it and collects the balls from the chute into the top level. He then searches for the purple on the pyramid, and attempts to line up to the base. Once in position he lowers the conveyor belt and transfers the balls from his top level to the top of the pyramid. After all the balls are transferred he raises the conveyor belt and continues looking for balls on the ground. If the cyan button isn’t found within the first 2 minutes, he gives up and only collects balls of both colors.
Open CV was the software of choice to interface with the vision system. Open CV was used to recognize colors and objects as well as to calibrate the camera to different lighting conditions. The vision system consisted of three main features: blue tape detection and two different color detection. Open CV recognized colors by converting the RGB images from the webcam into HSV images and filtering out the desired color ranges. The vision system ran on one thread while the state machine was on the other. Crank was able to ignore objects above the walls by detecting the blue lines on the tops of walls. That was he was robust enough to not be distracted by audience members wearing detectable colors.
Python was used to control the robot motions. Proportional control was used for driving towards the ball as well as to slow down when walls were approached. This proportional control enabled Crank to be both faster and more accurate when driving towards his targets. Since proportional control sufficed, it was not necessary to add PID control.
Overall Performance
The transition from Pegboard to acrylic proved too much for Crank to be ready for Mock 1, so he received a score of zero for this round. Crank discovered some drive motor issues in Mock 2 as he was too heavy for his drive motors to move on the bumpy carpet. So he received a score of zero yet again. During Mock 3, Crank successfully ate 2 balls munching his way to second place. In the seeding round, Crank yet again seeded in second, but navigated his way somewhat successfully and was able to collect many red and green balls. In the final competition, Crank was defeated in his first match by a mere 5 points. He got stuck on the wall in the first round, causing a low score of 5 for the round. In the next round he almost made an epic comeback, eating 5 balls and moving a few more, but he ate one too few balls to win the match.
Conclusions
As the developers of Crank, we learned a lot in his making, especially since we were a team of all mechanical engineers. After a crash course in programming from the lectures in the first week, we were off programming on our own. We stuck with simple but effective code, and definitely learned a lot.
On the mechanical side, we chose to make Crank with a rear wheel drive. This was advantageous for wall avoidance, but gave us much trouble for alignment against both the button and the pyramid. We also learned to build early. Many things took longer than anticipated, and each iteration was a learning opportunity. For example, we redid our base after the first iteration showed that a slightly different design was much more effective.
Suggestions
A list of extra parts available to us in lab (nuts/bolts, tape, castor wheels, sensors, etc) would be helpful for us to prepare what supplies we’d need to buy ourselves. It would be nice to organize the hardware that you do have, and find a way to prevent teams from hoarding all of one supply. Having more resources to build the robot would also be helpful. The Edgerton center was often crowded and members had limited access. Also, many teams struggled with gaining access to a laser cutter, but laser-cut pieces were essential to all teams. If Maslab could ensure access to a laser cutter and train a representative from each team to use it, it would lower much frustration. It would also be helpful to assign time slots to do runs during a mock completion, then have open time for teams to do re-runs if desired. That would fix the problem of mock competitions running over, and teams not showing up to do runs until the end.
But overall we had a lot of fun and learned much about both the mechanical and software side of robotics. Thanks for a great IAP!!!
