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.