• How do you initially choose which approaches to the given challenge your team will prototype? For example, weighted objective tables, voting…
We try to follow the V-model of prototype development. The idea is to start wide and work your way inward. Make sure you have a good understanding of rules/requirements. Then talk about all the different ways you can score and/or descore. Then talk about the attributes required to do those tasks, and begint o assemble the list of priorities. On 33, we have a lot of history, and pretty good resources towards getting things done. This allows us to often take on more than most teams which makes the descision process easier (note, we often bite off more than we can chew which is a bad thing). If you have limited resources (mentors, machining, fab skills), this is the part of the process where you really need to decide what your team is going to focus on. Once you have decided on some functional concepts, it is time to start deciding what needs prototypes. We often prototype not to see if it will work, but to try to understand important parameters. In 2012, we made a wood mock-up of a single wheel shooter to do a study on pinch, repeatability, and whether to go for the bank shot or the swish shot. Ironically, our prototype was great for swish shots (41/42 in one series of tests). We also prototyped the ball lift to understand compression and how many lift points we needed. In 2011, we prototyped the tube gripper to understand pinch, and how large the lower roller could be before pushing the tubes. We also prototyped about 10 different minibots with no fewer than 3 different styles used in competition. We also prototyped several different minibot delivery systems. In 2010, we protyped the kicker, the pole latch, and the ball collector (the prototype ultimately lead us down a dead end due to pushing balls into the collector rather than driving into the balls).
• What is the best way for teams that weren’t around for “the last game that was like this one (ex. 2011 was similar to 2007, 2012 was similar to 2006)” to catch up on what was learned in that year?
Read Chief Delphi. Collectively there are hundreds if not thousands of years of experience on CD. Someone on there will make the comparisons. If you look up what won on a previous similar game, you will find a solution that will do well in a modern game (maybe not a winner, but definitely a good idea). Get copies and read both of the Behind the Design books. These are a wealth of great information.
Also, brainstorm old games in the off season. Read the rules, and discuss what you think will do well.
• Where else outside of previous FRC competitions do you look for design inspiration?
Everywhere. Look at specialty construction machinery. Farm machinery. Factory machinery. Modern Marvels (I love that show). Latching mechanisms, sorting mechanisms, conveyor systems.
• Do you build field elements before starting prototyping?
Sort of, I would say almost concurrent. We have a good parent support group that comes in and works on building field elements while we discuss strategy with the students. This is new as of the last couple of years, and a huge help. While parents may not want or be able to spend every waking hour doing robots, asking them to come in an held build some field elements is a well defined way to engage them.
• How many different approaches do you prototype?
The real answer is, as many as are necessary to get something we think will work well. In 2005, we prototyped a ton of different Tetra manipulators, and ended up with a super complicated articulated… It was a mess. 67 and 66 at GLR that year just had some pitchforks. We raced home during the fix-it window and made a pitch fork for our next competition, and then during the next fix-it window made it have an articulated “middle tine”. It was very difficult and time sensitive those days with the fix-it windows.
The most important thing about a prototype is understanding what you want to get out of it. Basic function? An important parameter link pinch of a ball? Efficiency estimates of a thrower?
• How much of your team’s resources, particularly personnel, do you devote to working on a prototype?
Roughly 2/3s of the team works on prototypes while the other 1/3 work on design of non-prototype systems.o How might teams with different or fewer resources (especially in terms of personnel) change how they operate?
KISS. Simplify your objectives. Do 3 things really well (drive around well, acquire game piece, deliver game piece or drive around well, push hard for defense, and do end game bonus). Trying to do 5, 6, or more will likely lead to failures of many systems.
Also, use proven chassis solutions rather than re-inventing your own. Kit bot on steroids is awesome. Just follow that recipe, and then you will have way more time to do a game piece manipulator. Trying to do a custom chassis with relatively low resources, will just take time and skill away from the scoring elements of your robot.
• Once you begin prototyping, what is your approach?
Keep working on it until you understand your goal that you wanted to get out of it.
• Do you try to gather quantitative or qualitative data? How refined is the prototype at this stage?
Depends on the prototype and the game. We often measure how fast the unit will be able to conduct its action.
• How do you identify what data you need to gather?[/indent]
Use your goals to understand what you want to know. Then measure those elements.
• How can teams decrease their turnaround time on iterative prototyping?
Practice. The off season is a great time to practice prototyping. Brainstorming is nearly free.
• Does a prototype need to work as well as you expect the final manipulator to before you begin final production?
No, but you need to know that you can make it better. This takes some subjective assessment and some experience or intuition. There is a fine line between knowing you can make it work better, and fooling yourself into thinking it can work better.o Essentially, how much do you refine a prototype before moving on/what differentiates a prototype from the finished product?
Sometimes very little, sometimes a lot. Again it depends on the goals of the prototype.
• How long is your team willing to prototype before entering final production?
Protoypes really need to be done in the first week or two. Your goal should be system integration in week 4. This give the programmers time to do software, and the mechanical teams time to fix all the little problems they didn’t see beforehand.
• How do you prevent unfinished prototypes/manipulators in general from delaying the rest of your design/production?
Have a schedule. Talk to good teams with similar resources about what their schedules look like. If you do not have access to CNCs don’t try to use a schedule from a team that relies heavily on CNC parts. Instead, look at all of the robots that do well, and look at ones that you think you could build (from a FAB skill standpoint), and then understand their schedule. Once you have a schedule, stick to it. When you fall behind note it. Ask the folks falling behind if they need help, or need a parallel team to try to get results. Note, the parallel team often hurts the feeling of the original team, so it is important to have a results oriented culture to follow this path.
************************************************** ********************************************
I hit on this a few times, but a really important element towards iterative approach, and continuous improvement is having the drive to do it. Not all FRC33 members have the drive (often myself included) to continue developing and re-developing until excellence is achieved. Jim, Tim, Eric, the Steves and several of the students (about 25% of the team) work really hard at improving the robot throughout the season. For most of FRC, there is the 6 week build season, and then there is their regional competition, and they might do some work on a system within the witholding allowance between. continuous improvement is only possible if you can keep it going.
You need the opportunity to test your system, and you need access to the system in order to improve it. FiM and now MAR give every team 2 opportunities to compete. This gives them the chance to compete, and then to try to fix what didn't work. Unfortunately most of FRC does not have this.If you are a team that only does 1 regional, then I would recommend finding an off season to fix your issues for. Fixing problems helps you not make the same mistakes. Continuous improvment is not just a single season or single robot effort, but a continuous effort. That doesn't mean you have to dedicate your entire year to FIRST, but it does mean that you need to not only improve the robot, but improve the team, and improve the processes.
Starting a thread like this shows you have a desire to improve you team and processes. Now you need to discuss the improvements, and implement some of those actions. This fall, make a Tetra and a Tetra goal from 2005, and practice your prototyping. With $100 of material from Home Depot, you will find a treasure trove of experience.