Go to Post Simply. Minimize. Reduce. It's a good engineering rule, and an even better management one. - Tom Line [more]
Go Back   Chief Delphi > Technical > Technical Discussion
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

Closed Thread
Thread Tools Rate Thread Display Modes
  #16   Spotlight this post!  
Unread 07-31-2012, 01:53 PM
BBray_T1296's Avatar
BBray_T1296 BBray_T1296 is offline
I am Dave! Yognaut
AKA: Brian Bray
FRC #1296 (Full Metal Jackets)
Team Role: Mentor
Join Date: Jan 2011
Rookie Year: 2010
Location: Rockwall, TX
Posts: 725
BBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond reputeBBray_T1296 has a reputation beyond repute
Re: Design Process: 2012 Shooters

Our team (1296) and our other school district team (3310) got together for the 3rd year in a row to our parallel design meeting. We decided to go with a wheel-ed shooter instead of an air cannon/puncher/catapult alternative, though all 4 methods were brought up in the meeting. We made this decision because we thought it would be the easiest to produce, easiest to control distance, and quick to fire.
After that, we decided we wanted to have our turret pivot 360 degrees so we could shoot from all robot orientations. This was suggested by 3310 as they had already chosen a tank drivetrain and we had selected mechanum again. This infulenced our decision to not have a variable-angle hood due to complexity with wiring and weight. We opted out of the 360 degrees rotation and settled on 120 degrees because of the agility of the mechanum.
We did some prototyping of our shooter ideas with 4X4 and 2X4 wood (excellent for making strong prototypes) and some spare motors we had. We tested 3 models, one with 2 wheels on top and bottom, one with 2 wheels on left and right, and one with one wheel on the bottom with a curved hood. We ultimately decided upon the latter of the three designs. After several configurations and designs we finally had a CAD of our current shooter.
To get the speeds right, we spent several hours on our practice field testing distance-from-goal:speed-of shooter ratios until we formulated an algorithm to calculate the necissary speed automatically.
We originally had 2 Fisher price (the part # eludes me) motors and 2 gearboxless andymark motors working in tandum to power the shooter. (They were mounted on opposite sides of the wheel with different gearings so they each produced the same output speed into the wheel even though they have different Max RPMs) After the Bayou Regional, we did some further testing of the shooter and determined the andymark motors were actually Impeding the fisherprice's speed.

So thats how we got what we got
If molecular reactions are deterministic, are all universes identical?

RIP David Shafer: you will be missed

Last edited by BBray_T1296 : 07-31-2012 at 02:47 PM.
  #17   Spotlight this post!  
Unread 07-31-2012, 02:05 PM
Unsung FIRST Hero Woodie Flowers Award
Chris Fultz Chris Fultz is offline
My Other Car is a 500 HP Turbine
FRC #0234 (Cyber Blue)
Team Role: Engineer
Join Date: Jan 2002
Rookie Year: 1942
Location: Indianapolis, IN
Posts: 2,654
Chris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond reputeChris Fultz has a reputation beyond repute
Re: Design Process: 2012 Shooters

I think #2 and #4 are worth noting.

#2 is to evaluate and agree that you want to score basketballs. Even though this seems really obvious, it is important to review the game and all of the scoring and confirm this is something you want to do.

#4 is to focus on the "what", not the "how". The intent was to get a ball through the hoop. As soon as you begin to say "shoot the balls", then you start eliminating other ways of getting the ball through the hoop and start thinking about shooters.

Step 1. Understand the game and how to win the match and the event.

Step 2. Determine if we want to score basketballs.

Step 3. Evaluate the benefits and challenges and risks of 1, 2 and 3 point scoring.

Step 4. Brainstorm ideas on general “ball scoring” ideas.
(We avoided using the word “shooting” as long as possible, since we determined we wanted to score the balls but shooting was just a way to do that.)

Step 5. Sketches and rough prototypes of scoring options.
• Conveyors – could we make something like a farm conveyor to take the balls up to the goals?
o This is most suited for 1 or 2 point goals, more of a challenge for 3 point goals.
• Launch tubes – could we make a tube to raise up, rolls the balls off into the goal?
o This is most suited for 1 or 2 point goals, more of a challenge for 3 point goals.
• Push Shooter – could we push balls through a tube (pneumatics, springs, etc).
• Wheeled shooter – motor driven wheels to shoot, similar to many from “Aim High”.

Step 6. We determined a wheeled shooting system was the best option for versatility and the ability to score from many places on the field.

Step 7. Research shooters. Reviewed baseball and football machines. Reviewed “Behind the Design” ideas. Evaluated our baseball pitching robot from the summer of 2011. Evaluated one and two axle (ball between the wheels) designs.

Step 8. Based on reviews of other designs and our experiences, we determined that a single wheel shooter was our preference.

Step 9. Prototype. We made a basic design in Inventor, and then made our first assembly from Plywood and Lexan and wheels we had from previous kits and robots.
• Questions to be answered included –
o Speed required to shoot from the fender, the key, the bridge, the sides by the alliance bridge.
o Exit angle to required.
o Could we run a single speed and vary the exit angle and be accurate.
o Could we run a variable speed and have a set exit angle and be accurate.
o What squeeze was required to minimize the ball size and density effects.
o How critical was “the load” process and location on exit speed, motor drain, etc.
o What size wheel was optimal.
o What wheel material worked best with the game pieces.
o What was the best way to “aim” the shooter and what accuracy / tolerance was acceptable.
 Options – Lazy Susan rotation, Simple single point pin with worm drive movement, No rotation and only driver adjustments of robot
• Several iterations of speeds, exit angles and ball squeeze were tested and recorded.
• Based on test results for a surface speed of the wheel and the motor / gearbox capabilities, we determined a wheel size.

Step 10. System integration and implementing prototype results into a design.
• Decisions made
o Variable speed wheel.
o Fixed exit angle.
o Approximately 50 degrees of wheel / ball contact.
o Bottom load, top exit.
o 2 – 3” Squeeze.
• System Integration
o Shooter as low as possible to keep CG low and increase robot stability.
o Shooter high enough that a shot ball would clear a 60” robot that was sitting directly in front of us.
o Simple ball collection and management.
 Balls collected and held in a single row inside the robot.
 Balls loaded / sequenced into bottom of shooter.
 Balls managed to prevent “jamming” in the collector or shooter.

Step 11. Continued development of shooter.
• Improved shooter design created to incorporate mounting provisions, supports for left / right rotation, motor and gearbox mounting and adjustments for ball squeeze.
• Motor decisions
o Initial Prototype used 2 CIMs, 1:1 drive
o CIMs required for drive to provide speed and power required for the field
o Determined 2 FP and 2 AM motors with similar output speeds into CIM-sim gearbox was best option
 Power and durability of FP’s was known. AM’s assumed to be durable.
o Direct Drive mount of CIM-sim to shooter wheel shaft for a durable and simple drive.
 One set each side
 No additional gearing, chain or sprockets required.

Step 12. Shooter, Production Version 1.
• Higher quality shooter built to match new design.
• Continued prototype activity with wide and narrow wheels, wheel tread surfaces, single wheel and “double wheel” (two narrow width wheels with space between) and ball squeeze.
• Shooter mounted on robot frame to begin determining accuracy, speed requirements, optimal exit angle, etc.

Step 13. Integration to Prototype Robot (R1)
• The prototype robot (R1) was built while the shooter system was being tested and modified and optimized.
• The shooter system was mounted to R1. Integration, testing and modifications continued.

Step 14. Shooter, Production Version 2.
• Changes and improvements from continued work on the prototype were incorporated into the design of the shooter, ball collector and loading systems. Weight reductions were made, the design was optimized.
• Production Version 2 was completed and installed on the Prototype Robot (R1) while the competition robot was being constructed.
Chris Fultz
Cyber Blue - Team 234
2014! IRI Planning Committee - Co-Lead (yes, already planning).
2010 - Woodie Flowers Award - Championship
  #18   Spotlight this post!  
Unread 07-31-2012, 02:15 PM
JesseK's Avatar
JesseK JesseK is offline
Expert Flybot Crasher
FRC #1885 (iLITE)
Team Role: Mentor
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 3,037
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.

Last edited by JesseK : 07-31-2012 at 02:21 PM.
  #19   Spotlight this post!  
Unread 07-31-2012, 04:33 PM
roystur44's Avatar
roystur44 roystur44 is offline
AKA: Roy Dumlao
FRC #4543 (Apollo Robotics)
Team Role: Mentor
Join Date: Mar 2010
Rookie Year: 2006
Location: San Jose,California
Posts: 341
roystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond reputeroystur44 has a reputation beyond repute
Send a message via Yahoo to roystur44
Re: Design Process: 2012 Shooters

What iterations did you go through?

I’m afraid to count. In the 6 weeks of time we did a very detailed build resulting in a great shooter/robot.

What features did you tune in during the evolution of your design?
  • Control loop for wheel speed shooting multiple balls
  • proto different motors and gearing to test motor power
  • ball path (How the ball is released to the wheel and how much distance the wheel is in contact with ball)
  • release angle for fender and key shot
  • wheel type (grip slip behavior of different materials vs wheel speed)
  • ball compression
  • camera targeting ( auto vs aimed, photo vs live feed)

Which system variables were most important to performance?
  • Control loop for wheel speed
  • Wheel contact area to impart the wheel rotational force to the ball
  • Type of material the wheel was made from
  • Ball release mechanism
  • Aiming and release angle

What did you prototype? How detailed were your prototypes?
  • CAD design ball path drawing
  • 8020 mock up
  • simple sheet metal proto
  • Final shooter using lightweight tube glued and riveted together
  • Used high speed camera and slow motion analysis

What did you start with? Why -- what inspired this baseline?

We started with a single axle shooter with hood and no turret
We looked at many shooters from previous games took the elements we thought we could expand on.

Take a media trip of our 2012 build. The photos and video show the progress and our build capabilities and how much fun we had.

971 2012 Build Season

Roy's 2012 Photos

Shooter Prototype Testing

Final Assembly and Testing

Practice at the Poof's Lab
Roy Dumlao

2006-2012 971
2013-2015 4543

Last edited by roystur44 : 07-31-2012 at 04:35 PM.
  #20   Spotlight this post!  
Unread 07-31-2012, 07:21 PM
Jacob Paikoff's Avatar
Happy Birthday! Jacob Paikoff Jacob Paikoff is offline
Registered User
FRC #5402 (Iron Kings)
Team Role: Mentor
Join Date: Apr 2007
Rookie Year: 2007
Location: Kokomo, Indiana
Posts: 165
Jacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant futureJacob Paikoff has a brilliant future
Send a message via AIM to Jacob Paikoff
Re: Design Process: 2012 Shooters

Originally Posted by Jared341 View Post

Two things convinced us that the latter group was "right":
1) We found this article: http://news.ncsu.edu/releases/money-...ball-shooters/
That article was written by the dynamics professor I had this spring. Coincidentally or not he actually went over how to shoot a basketball during the first week of class which gave me a good feel for my team's shooter.

I'm not to delve into 2059's design process cause that would require me to think and I don't feel like doing that right now. But you can find specs of our robot as well as some design thoughts on my blog: http://nop-jepblog.blogspot.com/2012...ing-benjy.html
Team 79 2007-2010 Student
Team 2059 2011-2014 College Mentor
Team 5402 2015 Mentor
  #21   Spotlight this post!  
Unread 08-01-2012, 02:07 AM
IanW's Avatar
IanW IanW is offline
Rookie Mentor
AKA: Ian
FRC #0997 (Spartans)
Team Role: College Student
Join Date: Feb 2010
Rookie Year: 2009
Location: Corvallis OR
Posts: 73
IanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond reputeIanW has a reputation beyond repute
Re: Design Process: 2012 Shooters

Unfortunately, my team (FRC 2374) did not find as much success as some of the more experienced teams in designing a shooter. However, the process we used in developing our shooter resembled a proper design process much more closely than we have ever done before.

We essentially started out by brainstorming different methods of getting the ball in the hoop (First mistake: not deciding on a clear strategy and generating design requirements from it). We quickly narrowed down our ideas to a wheeled shooter, and two different types of catapults. Based on our review of previous games/the "Behind the Design" books, we already had an idea that the wheeled shooter would probably have the best chance of success. Still, we began prototyping all three shooters. We soon abandoned the catapult based prototypes and began focusing on the pitching wheel idea.

We only worked on single axle shooters mainly because they are simpler mechanically, there is one less variable to control, and because we had read that backspin would be helpful. Our first prototype barely worked, as we tried to make it too much like how we envisioned our end product instead of using it to determine what worked best. We then created a much more basic prototype that worked much better, but from which we gathered no real data (Second mistake: making prototypes and not really learning anything from them. In this case, it was failing to gather data about how changing each variable involved with building a shooter affected its ability to shoot).

At this point, we had a better idea of what capabilities we wanted our shooter to have - turret, adjustable launch angle, and capable of shooting from at least the key (We didn't really have good reasons for wanting these features, they were just what we wanted; see "First mistake"). From this, we made one more prototype that was essentially just a proof of concept to show that our packaging would work. Again, we didn't really learn anything from this prototype. Based on this prototype, I designed our final shooter with CAD, and then proceeded to build it.

From when our shooter was mounted to our first regional, we pretty much only iterated on it by changing how we mounted sensors. Before we bagged, we removed the shooter so that we could use it with our practice chassis for further development. After our first regional, we realized that our launch angle control was superfluous and therefore removed angle adjustment for our second one. Though I believe our shooting percentage increased, this probably had as much to do with our completely-rookie driveteam becoming more comfortable as it did with our shooter being more accurate. One of our main limitations was actually ball collection - our intake was not very effective, resulting in us being unable to even try very many shots.

I hope this explanation is of interest to someone. Unfortunately, I am not knowledgeable about our software development process, so I cannot share about those iterations. Hopefully I use these lessons learned if I mentor a team in college.
  #22   Spotlight this post!  
Unread 08-01-2012, 05:44 PM
Taylor Nicholson's Avatar
Taylor Nicholson Taylor Nicholson is offline
Queen's FIRST Robotics Club (QFRC)
FRC #3710 (Cyber Falcons)
Team Role: Mentor
Join Date: Jan 2010
Rookie Year: 2009
Location: Southern Ontario
Posts: 10
Taylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond reputeTaylor Nicholson has a reputation beyond repute
Re: Design Process: 2012 Shooters

Build Season
After our initial strategy and brainstorming sessions, we placed shooting as our number 2 priority below drive, thus most of our prototyping/testing went towards the shooter. We chose to use a wheeled shooter design based on our own experiences with them, as well as their proven success in FRC as a whole. From the beginning we knew a lot of backspin would be important, and initially used HOT’s 2006 robot as an inspiration.

Based on this inspiration, we built our first prototype with a long hood. We wanted to minimize the amount of rotational velocity our wheel lost with each shot. To do this we needed a large wheel, with most of its weight distributed at the edge. For packaging, 8” was as large as we were comfortable with. The 8” KoP wheel met these requirements and we had a lot of them in our shop, so we started prototyping with them. Our initial testing proved we were heading in the right direction, so we continued to refine that design.

Basically, all of our prototypes looked like this in some form.

Even after minimal testing we found the tread on the KoP wheels would slip which caused less consistent and less powerful shots. We then tried a slew of options available in our shop, from high voltage electrical tape to the common conveyor treads used on wheels. Eventually we settled on using the paint on urethane we used in 2011 on our rollers. This gave a smooth, consistent surface, with considerable more traction, and remained attached at high speeds (if applied correctly).

As we moved towards our final prototype, we observed that the ball was not using the full length of the hood. As a result, we shorted it down so it was just longer than the exit. This ended up being the length we used on the final design. In the early stages of prototyping, our designs were not well built, or easy to adjust which lead to inconsistent results. In addition, we wanted to be able to shoot from both the fender and the key, and testing proved simply adjusting the shoot speed did not give us enough range to be able to accomplish this task; we needed to adjust our hood angle. With each iteration, we added more adjustment (in both hood angle and compression) and used more precision in fabrication and assembly. Our final design incorporated pneumatic cylinders, providing two hood angles, one for key shots and one for fender shots. While our final design also had adjustable compression, we found about 2” of ball compression was ideal, and had it set there for most of the season.
Final Prototype

We never really questioned the need for a turret, as we assumed it to be essential for targeting quickly. As well, a turreted shooter allowed us to have a forward facing shooter for driver control and a rear facing shooter for autonomous so we could retrieve balls from the bridge without turning the robot around.

The other aspect, along with backspin, that we thought was key to consistency was feeding the balls into the shooter itself. For this, not much prototyping was done, but we decided to load the shooter with a pneumatic cylinder directly below the ball. The advantage here is that the air pressure is regulated so the force would be consistent (compared to the variability of a motor) and applied to in the same location on the ball relative to the shooter wheel regardless of where the turret was facing.

Due to space constraints and the amount of stroke we required, a telescoping pneumatic cylinder was needed. After completing minimal research, we abandoned the telescoping cylinder approach and attached two standard cylinders together with the rods extending from opposite ends of the assembly. We used a cup (“the flower” as we called it) on the end of the cylinder rod to push the balls into the shooter. We surrounded the ball with pink polystyrene insulation, with a surface of thin polycarbonate (~.01”) and Teflon.
Pokey Pokey (the shooter loader)

The shooter was initially designed to use 2 BaneBots RS-550 motors as they are the most powerful motors available other than the 775’s (which we no longer use after many issues with them) and the CIM's. Prototyping proved we needed a maximum wheel velocity of about 5000 rpm to achieve the range of shots we desired. With the 550 has a free speed of 19300, we chose to reduce the speed by a ratio of about 4:1 using gears from the Fisher-Price transmission.

Approaching ship day, we were overweight. The second motor on the shooter was an easy couple of pounds between the motor, the Victor, and wiring. After removing the second motor, we found that the shooter still performed well, but lengthened our spin-up time by about 1 s.

Simbot Jordan's Shooter

Greater Toronto East Regional
We were unimpressed with our shooting at this event. We were shooting 50% in drive control, far from the 90+% we desired. No design changes were made to the shooter at this event, as we gave any and all free time to our programmers to continuously improve our software (mainly tune our PID constants).

Waterloo Regional
In an attempt to save weight at this event (we were preparing to add a dingus for balancing for our next event), we tried switching our 1/8” polycarbonate hood for 1/16”. In theory, we thought this would not only reduce our weight, but it could possibly improve our shooting as well. The theory was that the polycarb would flex differently for different ball densities, allowing variable compression and more consistent shots. On the field during a practice match, we found that the new hood completely failed, as balls flexed the hood too much, and basically dribbled out of the shooter. The hood was promptly

switched back for the rest of our practice matches. With the PID constants more tuned, and an extra two weeks of driver practice, our shooting percentage increased to 76%.

Greater Toronto West Regional
Before this event we finally went through with attempting to linearize the Victor output. This gave a huge improvement to the stability of our shooter speed.

Now preparing to add the dingus to our robot, there was still some weight we needed to remove. We removed the adjustability from our hood angle, by replacing the pneumatic cylinders with plastic rod. This choice was obvious for us as our fender shooting was significantly worse than our key shooting so we rarely used the fender. We noticed a slight improvement in consistency, which we attribute to the pneumatic cylinders giving a little when a ball is shot, further confirming that flexibility in the hood results in poor consistency. Our shooting percentage continued to increase at this event, with an accuracy of 83%.
Removed pneumatic cylinders for hood adjustment

To improve targeting accuracy, we had decided to add a laser to point at the top basket. The operator was now able to confirm the turret was aligned after camera tracking, or manual aim if the low basket was out of sight of the camera (i.e., blocked by another robot).
Laser Mounted (it can be seen mounted on the side in pick foam).

During our qualification matches we were having electrical issues, and pulled the laser during troubleshooting, as it may have been part of the issues.

Our shooting percentage did not improve much at this event, with an accuracy of 84%.

For IRI we decided to reattach our second shooter motor with the extra weight allotment given. This was to improve the shooters spin-up time. This probably had negligible effect on shooting accuracy.

Note: It’s been a crazy season, so some details may not be exact.

Last edited by Taylor Nicholson : 08-01-2012 at 11:34 PM. Reason: Grammar and clearer language. Also, added detail.
  #23   Spotlight this post!  
Unread 08-01-2012, 10:15 PM
kramarczyk's Avatar
kramarczyk kramarczyk is offline
is getting his kicks.
AKA: Mark Kramarczyk
FRC #3096 (Highlanders)
Team Role: Mentor
Join Date: Mar 2006
Rookie Year: 2006
Location: Sterling Heights, MI
Posts: 602
kramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond reputekramarczyk has a reputation beyond repute
Re: Design Process: 2012 Shooters

I know several very good teams have already responded to this thread, but I wanted to put this up just for contrast.

After we read the rules we discussed our team's goals for robot performance this season. They had previously been discussed, but it was good time to remind, reiterate and verify them. For us it was to qualify for the Michigan State Championship.

From the rules we came up with 18 discrete actions that we could combine into strategies.

In order to meet our goal, we determined that our game strategy would need be
Score our base load up high in Hybrid = 2 balls *3 pts/ball = 12 pts
Score 2 balls / 15 sec in Teleop (3 cycles) = 14 balls * 3 pts/ball = 42 pts (We knew this was optimistic when we picked it, but we used it to drive mechanism speeds.)
Lower bridge and balance in end game = 10 pts
Total score = 10 + 12 + 42 = 64 pts

Being a team with limited resources, we prioritized the discrete actions using a pairwise comparison to prioritize or efforts.
This list was a great asset in ending a conversation about a chassis that could cross the bump. Crossing the bump was #17 on the priority list.

Additionally, since our resources have a habit of changing dynamically throughout the season without notice, we look for simple solutions that can be accomplished in an agile manner. For the shooter this meant a mechanical system with a minimum of moving parts and controls that could start very simple, evolving as resources became available.

We started brainstorming while looking at the 2006 behind the design book for inspiration. We were able to do this on the MEZ field with the field assembly from kickoff. This allowed us to toss the balls around and discuss field position, ball action, and act out ideas. This was very useful for communicating the scale and dynamics to new team members. From this dicussion several ideas were selected for protoyping.

In our intial prototyping we only invest 3 man hr into an idea before we expect resuts. We looked at both single and double axle shooters, sling shots, pneumatic plunger cannons & a vex conveyor on an arm. We probably prototype too many ideas, but it soundly settles question of any idea's feasiblity and allows the team to move forward with a minimum of hurt feelings. We only got the single and double axle shooters to produce serviceable results. At this point we created a weighted objectives table to select a concept to scale up. Based upon the amount of work we estimated it would take to get a consistent shot, we elected to have a fixed elevation to the shooter to simplify the mechanicals. For software simplicity we decided to define a set of fixed settings for shooting from the key and a second set for whatever ended up being our highest percentage shot. We would add additional settings, software, camera tracking as time and need dictated.

To refine our selected double axle concept we played with the intial prototype to determine what are the dominant factors that affect it's shooting accuracy. The critical factors we discovered were ball compression, spacing between the wheels on the axle and ball feed speed. Based upon this info we built a improved prototype that would allow us to adjust these factors and run a designed experiment. This prototype would consist of as many competition intent features as possible (motors, gearboxes, axle configuration) while allowing us to vary the critical factors. This was also the point at which we decided to put the shooter on the opposite side of the robot as the intake. We knew through intution that shooting from closer would be more accurate and confirmed this in playing on the field. This meant that most balls on the field would be behind our shooting position.

Motor selection was pretty simple, there were several motors in the kit that had adequate power, so we used what we had available. In this case it was the FP's as we already had numerous comperable while not identical pieces. Next we looked at gearing. We wanted to use as much of our speed capacity for the various ranges as possible because this would improve the control resolution of the shooter and allow the shooter motors to run closer to max speed for thier best cooling. We know that many folks on CD discusses shooting from midfield and beyond, but we thought this was more than what was reasonable for us and confined our range to the top of the key. One question that was on our mind was how much slip did our balls experience with the shooter wheels. We suspected that the balls would exit at something less than the surface speed of the shooter. We used a optical tachometer to measure the axle RPM of our initial prototype and then measured the ball trajectory to determine the efficiency of this interface. It was ~ 50% efficient with old 8" KoP wheels. We knew we wanted smaller wheels on the final one and opted to get a more aggressive tread in the hope of increasing the efficiency. We used a spreadsheet to look at the parabolic motion of a ball in flight and determined that our best bet for a single positon shooter was 65 degrees from vertical. Shooting from the key this required a ~27 fps exit velocity. Based on this we planned on a free wheel speed of 50 fps. Based upon the FP free speed we started with a target gearbox ratio of 5.5 to go with 4" wheels. Fortunately this year's FP gearbox came with 13T pinions and a 72T fist stage gear. Since this was the right ratio (5.538), probably the lightest option (vs a commercial gearbox), and free(!) we went ahead with used them to drive each of our shafts.

Second Gen Double Axle Shooter - pic 1 - pic 2 - pic 3

The design of experiment method we used was based on the Taguchi model so that we didn't have to reun every combination. As a part of this we picked three values for each factor, one on each extreme and one in the middle. We isolated 5 balls in different states of wear for the test and ran each ball through the system twice for each trial. This gave us 10 shots for each setting. We had not run this process before, but we trusted the theory to guide us to a consistent shot. We set the shooter assembly up for an approximately horizontal shot with the goal of just getting consistent shots. Once we had that it would be simple to adust for. For each trail we measured the X, Y position of the shot and averaged all of the shots to get the 'center' of the group. Each shot's distance from the center was calculated to find the shots' devaiation and finally the average deveation for the settings were determined. Many shots later into the night we made some plots with our results then shot the engineer and built based on the best data we had.

Because we alway run short on time during the build season we planned to withold out shooter assembly for controls tuning. We modified our plywood conveyor prototype to accept the shooter assembly and got a functional equivalent of a testing robot. In the course of one shop session we were able to iterate on shooter values for the shots we required and a few more. While we had encoders on the shooter we found that a hard coded PWM value was consistent enough for our shooting needs, so we stopped development there and went to our next weakest spot. We added lines to the dashboard as a targeting guidance for the drivers. The Labview interface allowed the driver to drag them around to where they wanted them. (In the off season we added code that made this more elegant by adding and subtracting the lines as the shots were selected.)

While we were not good at our initial event (this was unrelated to the shooter) the district system gave us a second event. The urgency that was lacking in the team at the first event was generated for the second which made a huge difference. The product can be seen on the blue alliance starting on the far side of the field. http://www.youtube.com/watch?v=y0ye6z49SqU&sns=em It is not an incredible machine, but not a liability for our partners. Unfortunately we did not make our goal of qualifying to MSC. Still digging on the root cause.

Brick walls are for other people. - Randy Pausch
  #24   Spotlight this post!  
Unread 08-03-2012, 03:41 PM
Wetzel's Avatar
Wetzel Wetzel is offline
DC Robotics
FRC #2914 (Tiger Pride)
Team Role: Mentor
Join Date: Sep 2001
Rookie Year: 1999
Location: DC
Posts: 3,464
Wetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond reputeWetzel has a reputation beyond repute
Send a message via AIM to Wetzel
Re: Design Process: 2012 Shooters

I joined 2914 just after kickoff this year. While this was their fourth year as a team, only one student had done FIRST before and many had a very low level of knowledge about hand tools. We had a strategic discussion about the game to figure out how we wanted to play and ended up with a design to get picked rather than rank high. We settled on a priority list of SIMPLE, bridge, defense, feed balls forward, shoot baskets. For us, the shooter was an intentional afterthought.

We initially pursued a pneumatic kicker, and took two weeks to determine (and learn how to use the pneumatics) we couldn’t make it work well and keep it simple. Then we rapidly prototyped a single wheel shooter to chuck the balls to the other half of the field. We built a wood chute and then powered various wheels by various motors, mostly held in place by hand or clamped in place. We did these rough prototypes to get a rough estimate of how the ball responded to different wheels, motors and speeds, then following our SIMPLE mantra chose a COTS gearbox from the available options at AndyMark and BaneBots. We ended up deciding on two RS550 motors into the CIM-U-LATOR based on how far we wanted to be able to chuck the ball, our quick and dirty empirical testing, and the options available. It ended up being a simple lift system to the wheel, and then the ball went under it and above a steel plate. It chucked balls to the other end of the field admirably, fulfilling its primary mission.

From there, we have constantly tweaked the system to improve shooting at all our events, with the target of better than 75% accuracy in autonomous. We went from the ball passing under the wheel to going over it to reverse the spin and 3 major revisions to the shape of the exhaust, with the major changes mostly done to reduce flex and uncontrolled motion. We had a video camera with the ability to capture super slow motion HD video, and that was incredibly helpful to identify what was going on with the shooting and to identify issues. We went from making one shot in autonomous in total at our first event to somewhere around 80% in autonomous at St Louis.

One of the things we realized pretty early on was that the battery made a significant impact on the accuracy of the shot. We first attempted to use a shaft encoder on the shooter axle and to tune a PID loop but were unable to get satisfactory results with that. We got an improvement, but a small one. At St Louis we set up the CAN and drove the shooter motors by voltage rather than PWM and I think that gave us the biggest improvement in having a repeatable shot amoung all the changes we made.

We wouldn’t settle for it is what it is, but remained cognizant of the fact that sometimes better can break good enough.

Design is iterative. Life is iterative. Strive to improve.

Viva Olancho!
  #25   Spotlight this post!  
Unread 08-03-2012, 04:37 PM
Jon Stratis Jon Stratis is offline
Electrical/Programming Mentor
FRC #2177 (The Robettes)
Team Role: Mentor
Join Date: Feb 2007
Rookie Year: 2006
Location: Minnesota
Posts: 2,737
Jon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond reputeJon Stratis has a reputation beyond repute
Re: Design Process: 2012 Shooters

I'm not sure if I can remember our entire design process, but here goes...

We spent 1 night the first week prototyping ways to shoot the ball (a wheeled shooter, a catapult, etc). I got to work with the group that was focusing on a wheeled shooter, and we talked about a couple of things:
- How do aerodynamics affect a ball in flight? (think knuckle ball versus curve ball, versus slider, etc)
- How does spin affect a ball contacting a stationary surface? (think about how a pool player can change the angle of reflection on a bank or kick shot)
- What was our goal and backup plan for the robot?

The team came up with these answers:
- A ball with no spin tends not to travel in a straight line as well as one with vertical spin. Side spin can cause a ball to curve from one side to the other.
- A ball with back spin can cause it to reflect downwards off the backboard. Top spin will cause it to reflect straight off the backboard and miss the basket.
- Our main goal was to score from the key. Our backup plan was to have enough power to act as an effective feeder robot playing defense.

From this, we built a quick prototype with some spare 2x4's and old wheels. We wanted to be able to test differing amounts of backspin on the ball (while maintaining enough speed to hit the wall in a "realistic" fashion), so we put wheels on top and bottom.

The initial build had 1 wheel on top and 1 on bottom (each powered by a drill). We quickly noticed that the ball tended to "squirt" out one side or the other if it wasn't perfectly placed, and thus not shoot straight. We fixed this by going 2 wheels on top and 2 on bottom, which helped to center the ball and make the shot consistent side to side. We could alter the strength of the two drills to vary the backspin on the balls.

It turned out that this prototype worked really well. The shots were more consistent than anything else we built. So, we went with that as our basic design.

In building the "final product", we decided to get smaller wheels with better grip, and to add some heavy flywheels to help reduce variation in the shots (since they would decrease the amount each shot slowed the wheels, we could shoot more rapidly). We also added some encoders onto it to allow us to more easily monitor the speed and set a more precise speed for each shot.

In order to figure out how fast we wanted the shooter to go, we turned to empirical evidence. We knew our prototype was about 80% of what we wanted to shoot from the key. So, one of the mentors brought in a strobe light with a variable speed setting. We taped a dark line on the wheel, and brought it up to speed. By adjusting the speed of the strobe, we could make it appear like the line stopped moving, thus giving us the rotational frequency of the wheel. A little math, and we could figure out how fast we wanted our real wheels to spin, and work backwards from there to figure out the desired gear ratio.

After that, it was really just a whole lot of testing with the actual robot to figure out what the best values were for the code.

The end result was a very consistent shooter. If we placed the robot in a single location and set the speed to be constant, we could feed the same ball in over and over again, making a basket each time.

The only thing we didn't take into account very well was the variable density of the balls, and how "soft" and "hard" balls would shoot differently. We'll get that next time there's a shooting game!
2007 - Present: Programming/Electrical Mentor, 2177 The Robettes
2012-2015: North Star LRI
2013-2014: Lake Superior LRI
2013-2015: MN State Tournament LRI
  #26   Spotlight this post!  
Unread 08-04-2012, 08:11 PM
Gigakaiser's Avatar
Gigakaiser Gigakaiser is offline
Registered User
AKA: Brandon Hjelstrom
FRC #0987 (High Rollers)
Team Role: Programmer
Join Date: Jan 2012
Rookie Year: 2012
Location: Las Vegas
Posts: 65
Gigakaiser has a spectacular aura aboutGigakaiser has a spectacular aura about
Re: Design Process: 2012 Shooters

I posted a white paper outlining 987's shooter design process:

FRC Team 987 - It's not enough
  #27   Spotlight this post!  
Unread 08-06-2012, 11:33 PM
Ziv Ziv is offline
Has code to be writing...
FRC #0125 (Nutrons)
Team Role: Alumni
Join Date: Mar 2010
Rookie Year: 2009
Location: Boston
Posts: 39
Ziv is a glorious beacon of lightZiv is a glorious beacon of lightZiv is a glorious beacon of lightZiv is a glorious beacon of lightZiv is a glorious beacon of light
Re: Design Process: 2012 Shooters

Brandon outlined earlier our iteration on the shooter itself. Controlling it was another interesting journey.

As he mentioned, I initially thought that controlling hood angle would be easier than controlling wheel speed. While this is certainly the case for a lead-screw hood, it is not necessarily the case that controlling shot distance with that angle is easy. Furthermore, we'd still be at the mercy of the precision of wheel control. At the scrimmage, I found as operator that I could adjust shooting distance enough with the wheel speed that a fully controllable hood was not necessary, making a pneumatic hood the correct choice.

Controlling that wheel speed was still an issue. We ended the build season and went through our regionals with a typical integrated PD loop (that is, a PID controlling the change in shooter speed with kI = 0). It gave us a short spin-up time from rest to both our fender and key speeds, with little-to-no overshoot while doing so. However, we had significant overshoot after firing each basketball that took 1-3 seconds to settle. We were having lots of other problems that were more important, and I was getting the hang of firing the next shot at the right time, so the issue was put on the back burner.

Enter championships. Anticipating more fender defense than encountered at our two regionals, we decided to focus on key shooting, and the more sensitive situation meant we needed a tighter control algorithm. Playing around with gains showed us that it was the kD term that was causing most of the overshoot. Programming the controller to recognize when we were taking shots and setting kD to 0 while the shooter speed quickly plummeted and restoring it during the following spin-up eliminated the overshoot but retained the quick shot turnaround we had previously.

At some point—I think between the Boston Regional and champs—we tried a bang-bang controller. It worked really well control-wise, but the pinions in our gearbox couldn't take it. Perhaps a faster update rate could have solved the problem.

Another interesting observation we made was that using Victors caused our speed to oscillate. Even with small gains, this didn't go away. We wonder if this might be something to do with either back-EMF or the resolution of the speed controller, but someone with a more solid control theory background would know better. Our team usually prefers Vics to Jags, but we made an exception for this.

Tom (from 254) had suggested a state-space controller to us earlier in the season, but I never had the time to go over the prerequisite math in enough detail to implement and tune one myself.
Closed Thread

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

All times are GMT -5. The time now is 02:18 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi