GP5 FTW

This page will have information on the robot itself. :)

Flow Chart of the Robot's Functions

Group 5 Design Proposal

The idea that we are going to work on is essentially a modified pinball plunger that is robotically actuated. The pucks will start in a hopper which will then drop them into the first one into a prep gate and then from the prep gate into the chute. Once in the chute a motor will move the chute left or right depending on where the device is trying to shoot to. Then a motor will compress the spring of the pinball plunger the designated distance and a servo will release the plunger pushing the puck forward out of the chute and toward the target.
The robot will take in visual data from a web cam or other camera that can be connected to a laptop and from that data it will decide where best to push the puck. We are also going to try to program it to make defensive shots and shots to knock the opponents’ pucks out of the scoring area, time permitting.


The primary goal will be to put pucks on the table, and make sure they score points. The first goal will be to consistently push the puck down the table to the right zone. After that is achieved we will then focus on accuracy and then strategy will be the last goal.
The initial straw-man implementation could be made primarily out of balsa wood and some springs. Initially there will be minimal electronic components in this design just to keep it simple and make it faster to build.

Rationale:
We decided to go with a plunger system because having a device “push” the puck seemed like a much more controllable action than “hitting” the puck to cause it to move forward.


A printer motor seemed like the best method for translational motion. Seeing as printer motors are designed to have one way translational motion it appears as the most logical choice. The biggest difficulty with this will be in the procuring of the motor. If we cannot obtain a printer motor a stepper motor will be the next likely choice due to the simplicity of them and how easily they can be controlled.

 

Launcher Example 4

Above is a top view of the basic concept. Using a plunger similar to pinball, the plunger will be held in place by a solenoid lock and then the spring will be compressed from the back so that the puck remains stationary while the spring is being loaded.

Launcher Example

Above is a side view, showing the wedge that the solenoid lock will be attached to at the end of the plunger, as well as a loose sketch of where the ratcheting device might be placed.

Launcher Example 2

Above is a front view visualization of what the printer motor motion would do. On either side are the clamps, or rests to secure the robot to the table.

Launcher Example 3

Above is a concept of how the hopper would work and where it might be placed, loading a single puck at a time. This could be controlled by a simple logic circuit with some sensors.

 

Team Responsibilities:

  1. Mechanical Design: Bryan and Charley
  2. Manufacturing: Bryan and Charley
  3. Electronics and Software: Tim
  4. Website Maintenance: All, but mostly Charley
    Other responsibilities will be added as they arise.


TIMELINE week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 week 9 week 10 week 11
Design x x                  
Manufacturing   x x x x            
Robot Complete         x            
Troubleshooting         x x x x x x  
Final Completion                   x x

Comparison of initial design to final design

The initial design consisted of a complex hopper system, as well as a wormgear driven plunger loader. The hopper was scrapped because we were able to find a design that eliminated electronics, weight, and manufacturing time. This was, sadly, after we had already manufactured the plunger, but we hand't made it operational.

The second design change was using the worm gear for loading the plunger. This design concept was scrapped for a rack and pinion type system made out of legos which ultimately proved to be innefective. The lego setup was not strong enough to overcome the force of the spring, and thus we could not load the plunger to fire.

From there we tried to possibly move the plunger forward with the rack and pinion fast enough so that it would launch the puck, but this too proved to be too daunting a task for the lego setup. Ultimately, the Motherpucker was unable to fire because of this setback.

Final Partitioning of Team Responsibilities:

- Tim McKee: Electronics and Programming

- Bryan Hudspeth: Manufacturing with some Design

- Charley McGowan: Deisgn with some Manufacturing

ACTUAL TIMELINE

ACTUAL TIMELINE week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 week 9 week 10 week 11
Design x x x x x            
Manufacturing   x x x x x x x x x x
Robot Complete                   ? ?
Troubleshooting                 x x x
Final Completion                     x

Initial vs Actual timeline discussion:

We ended up designing and manufacturing much longer than we thought. The major setbacks were due to us planning on the machine shop being open on the weekends, only to find out that it was closed all weekend. Had they been open on the weekends we would have been able to build much more on the robot and more accurately follow our initial timeline.

Lessons Learned:

Basically we can sum this up in one very powerful engineering principle: KISS, Keep it SIMPLE STUPID!

The complexity of our design led to the setbacks in manufacturing that could have otherwise been avoided had we just build a simpler design such as a ramp. We also learned how to work on an interdisciplinary team and how to accurately communicate the needs between manufacturing and electronics and vice versa. Also, if one can find a way to build things out of parts that are already manufactured, do it! It saves time manufacturing and money.