Team Three/Final Paper

From Maslab 2012
Revision as of 21:11, 6 February 2012 by Team3 (Talk | contribs)
Jump to: navigation, search

Team 3 Final Paper: The Tools and Albi Story

AlbiAndTeam.jpg

Overall Strategy

Our focus was on taking advantage of the rule that allowed the launching of balls to develop a strategy to collect and launch one ball at a time. Thus, our strategy would be relatively simple: find a ball, find yellow, launch ball. Unfortunately, we ran into several problems in the implementation that we weren’t able to solve by the competition. We were never able to reliably detect when we had “loaded” a ball into the catapult- our strategy hinged on using an LED-photosensor combination, but we couldn’t get our hands on a photosensor. Secondly, we ended up going with one camera due to sensor points. However, we collected balls and fired in opposite directions- meaning we had to precisely calibrate our robot to turn 180 degrees before firing off a ball. Thirdly- the best camera placement to collect balls is low, so that blue line filtering isn’t as needed. But the best place for a yellow-wall finding camera is high, so that the direction of the yellow ball is detected no matter where the robot is. We were forced to go with a compromise between the two, which didn’t do as good a job at either task. Finally, and most cripplingly, the range of our catapult was never quite enough to be a serious delivery method. We achieved a 4-5 feet range (wall clearance) in theoretical testing, but when we used a motor controller instead of a simple switch, the range dropped to ~3 feet, which isn’t really enough to gain efficiency. Using relays would have solved the problem, but by then it was too late to switch over. Ultimately, our strategy held promise, but we failed to overcome several technical challenges.

Contents


Team Members

Vamsi Aribindi: Course 16 Junior - head coder/consultant

Katherine Hobbs: Course 16 Sophomore - head vision coder/entertainment

Rebecca Navarro: Course 16 Sophomore - head builder/scribe

Anthony Venegas: Course 16 Sophomore - head designer/CAD Expert

Mechanical Design

Design Process

Albi underwent a few iterations. The initial version of Albi was constructed out of acrylic and replaced our peg-bot for the first mock competition. The initial design was large and simple, essentially a box with wheels. The issues with it were due to it's weight. The robot in this state was clunky and slow, and the weight was too much for the motors to move it properly.

Albi1 0.jpg

Albi 1.0

Albi1 0CAD.jpg

Initial CAD drawing

This first design also depended on the use of a solenoid as the firing mechanism. We ordered a solenoid and tested it, but found it's force output highly lacking, and our dreams of a solenoid powered ball cannon floated away. Seeing the lack of success of this initial design in the first mock competition, we headed back to the computer to draw up a new design. A couple redesigns brought Albi's concept to its final version.

Final Design

Albi2 0.jpg

Albi 2.0!

There are a few key aspects behind this final design. First, we wanted to place the wheels in a centered location, allowing the robot to turn in place for more agile movement through the track. We also decided to use a circular base, which was made of sheet aluminum. Having a round-based robot would prevent the robot from getting stuck on walls or corners while turning in place. Albi's final iteration opted for a compact, lightweight frame. Since one of the tie-breaking criteria was weight (and we are all aerospace engineers who love making things lightweight), the design attempted to utilize the most efficient use of space and as little acrylic as possible. This included using thinner acrylic and making the robot's base have a diameter of 11 inches.

Albi2 0CAD.jpg

CAD model of the final design

One design we maintained through all the iterations of Albi was the collection mechanism, a typical rubber-band roller powered by a small motor. The roller would pull the ball up a ramp and knock it into the launching mechanism. The final and most major design characteristic was our launching mechanism. Really wanting to make balls fly through the air, we used a catapult mechanism to launch balls. It involved a motor attached to a lever arm with a cup at the end. By torquing the motor and stopping it at about vertical, we were able to send balls flying quite a long distance.

CatapultCAD.jpg

Launching Mechanism'

The robot was constructed mainly using a CNC laser cutter to manufacture the acrylic, and a CNC water-jet to cut the aluminum. It was held together by angle brackets and bolts, even glue in some cases, and plenty of tape. In order to stop the catapult bar and keep Albi from destroying himself, we placed an aluminum rod between shaped pieces of acrylic that stopped the catapult at 90 degrees without putting too much strain on the motor.

Sensors

Bump sensors were are main detection system, placed all around the robot. They acted as a simple on/off switch to tell the Arduino when Albi hit something (to wire them, we simply connected one lead to ground and the other to a digital input slot). We connected many of them with aluminum bars, so the whole bar acted as a bump sensor, giving us better bump detection without needing more sensors or wiring. We also used a couple of infrared sensors in the design to attempt to follow the walls in search of target balls. Unfortunately, their low position made them difficult to use, as the bump sensors themselves got in the way and the IR sensors ended up detecting EVERYTHING. The code also did not handle them well, so we really had no need of them.

Ideally, we wanted to use some form of break sensor to detect when we had captured a ball, but could find nothing suitable. Therefore, Albi always assumed he had a ball if he tried to go for it.

Other uses for sensor points

The final design required 4 motors total, two drive motors to power movement, one small motor powering our collector, and the catapult motor, therefore we used two motor controllers in our design to control all four. One unforseen consequence was that the motor controller limited the current output to the motors, drastically shortening the range of the catapult. This could have been fixed with a bridge, but time was not on our side.

Gears were also used to run the rubber band collector.

Software Design

The software matched the simplicity of our hardware design, and used a state machine. There were five states: FindBall, SeekBall, GetBall, FindYellow, SeekYellow, and Shoot.

The FindBall technique rotated the robot a circle, in six steps, looking for a ball at each angle. If a ball was found, the machine transitioned to the GetBall state. Otherwise, the machine transitioned to SeekBall.

GetBall used a PID controller to drive the robot towards the closest ball detected. It then transitioned to the FindYellow State. Unfortunately, we did not manage to acquire a photosensor, which (with an LED) would have told us whether or not we had captured a ball. Thus, our only option was to assume we had captured a ball, and transition to FindYellow.

Seekball randomly wandered around the field. We attempted to implement wall-following, but were not able to get it working. In its place, we just used six bump sensors with aluminum bars between them, covering the entire front 180 degrees of the robot, which was fairly effective in preventing jams.

FindYellow copied FindBall, except it looked for a wall instead. It transitioned to Shoot if it found yellow, or to SeekYellow if it did not.

SeekYellow wandered the field randomly, for a set period of 20 seconds, looking for yellow. If it didn’t find one, it transitioned to shoot in a random direction. This was, of course, suboptimal, but we didn’t want to get stuck with a ball.

Shoot found the yellow wall, turned 180 degrees from it so that the catapult would fire in its direction, and then activated the catapult.

Overall Performance

Conclusions/suggestions for other teams

A rather unfortunate mistake was that we attempted to rewrite the software interface in java. We are all aero-astro majors, and java is the language most of us are most comfortable with. Unfortunately, we were forced to abandon the idea and use python, as java did not play nice with opencv (the video library) on ubuntu. We lost two weeks to that fiasco.

Also, be sure to get some sleep outside of the lab!! :P SleepingVamsi.jpg

Personal tools