View Single Post
  #4   Spotlight this post!  
Unread 31-07-2012, 14:15
JesseK's Avatar
JesseK JesseK is online now
Expert Flybot Crasher
FRC #1885 (ILITE)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 3,658
JesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond repute
Re: Design Process: 2012 Shooters

Our process wasn't a formal process so much as a cobbling together of visions that had to be simplified into the greatest common denominator in order to come in under weight and on schedule. At the beginning we toyed with the idea of being a great box on wheels, yet we knew that we would be selling ourselves short if we didn't attempt to design to the edge of our known capabilities. So we knew that some sort of shooter would work. No one on the team had a vision for a feasible catapult-like mechanism, so we went solely for spinning-wheel shooters. Research for anecdotes showed that more teams historically had greater success (so they felt) with vertical single-wheel shooters than any other type -- so that was our starting point on Day 2. I'll also say that our Day-0 primary goal was to be GREAT at autonomous -- we felt that 12 points in autonomous, combined with balancing, would win us the majority of worst-case matches (matches with no partners).

1.) We did a feasibility exercise on shooting from anywhere on the court, including determining the exit velocities, aiming accuracy (2 dimensions, in degrees). This was finished after 4 days. Results: given our past results we didn't feel that we could meet the consistent precision needed to shoot from the bump, bridge, or anywhere that was beyond the Key.

2.) We made an Excel spreadsheet showing all of the velocities and margins for error. This gave us a rough estimate of the power requirements for the motors, so we checked our motor/gearbox inventory and ordered parts as necessary.

3.) We then determined a range for the starting ball height as it left the shooter, given our preferred exit velocity and angle.

4.) A group built a 30-lb flywheel prototype from a cart wheel and some plywood, powered by a plugged-in 15,000 RPM Dewalt drill. It hit some very consistent 30-ft shots in the high goal. We had it at the end of Week 1 (we had a relatively light build schedule due to restrictions on being at the school).

5.) A week of "discussion" ensued about the simplicity of that design (and oversimplification of the environment) and why we couldn't just use what we built. Why can't we put a 15-lb wheel at 45" off the ground? We'll be fine, right? At this point we were toying with the idea of an adjustable angle so we could also shoot from the fender. Eventually that got knocked out as too time consuming for our build capabilities.

6.) I CAD'ed up a compromise that used an IFI wheel with water-jet cut removable plates to act as adjustable flywheel weights. I posed a design challenge to the team to come up with simpler designs using lower-cost materials. We slapped all of the weights on and never got around to adjusting it because the re-calibration would take too long.

7.) We built the thing and moved on. This was the end of Week 3.

8.) The rest of the bot was built, losing 2 meetings in a row due to various things -- so essentially Week 4 turned into Week 5 without anyone noticing. The bot was completed by the end of Week 6 though, so the final weekend was all testing and tweaking with no over-nighter's (woo!).

9.) At competition we calibrated the distance of the shot with the wheel speed. I came to find out at champs that the programmers never integrated the encoder that was mounted and wired; they instead were setting it to a constant output power %, and used a stepper scale to ramp the power up (instead of a PID). After much discussion and "requesting", they got all of that in and we went 17 for 18 shots in autonomous after the first match (our primary goal on Day 0).

Karthik's talk about a team 'reinventing itself to stand out' hit home -- I had an epiphany about the precise location for a stationary shooting robot in autonomous, which combined with a sighting mechanism to lead us to the one thing that made us stand out (adjustable-timing highly accurate autonomous). We were then going to feed for the most part, yet that never really came to fruition since we had to be the primary scorer in most of the qual matches and the captain of our champs alliance was primarily a feeder bot.

10.) Along the way we integrated the camera onto the driver's display, and the drivers used tape to calibrate a set distance for the shots. How many shots we made was all dependent upon how 'in the zone' the driver was. Should we have made a turret to alleviate his stress? Considering a couple of students and I had a feasible detailed design in CAD for one ready in Week 2, we probably could have -- yet considering we had to use all available weight on our overlooked bridge lowering device, it would have been a bad idea.

Thoughts for next year: for the last 3 years we seem to have overlooked a critical element of the game -- the students and mentors get distracted by the glitz and glamour of the primary goal (ours is always "get on an alliance by scoring consistently in autonomous"). The focusing solely on the endgame led to great success (relative for us) in 2007, so I think we'll come up with a design approach in 2013 that focuses on autonomous and endgame, leaving teleop open for the 'powerhouse' teams. This year's element was the bridge lowering device.
__________________

Drive Coach, 1885 (2007-present)
CAD Library Updated 5/1/16 - 2016 Curie/Carver Industrial Design Winner
GitHub

Last edited by JesseK : 31-07-2012 at 14:21.