Interview Request
 

This summer I have been writing a few tutorials about the more technical aspects of building a robot. For example, one discusses motor/gearbox theory and how to use it to choose the right motor/gearbox for an application. For the tutorials I have written thus far, I relied on the knowledge I gained during the past four years as a team member, or my own research. However, I also wanted to tackle a subject that I know many teams (including my own) struggle with: prototyping. I was wondering if anyone within the community would be willing to help me with this by answering a couple questions in a sort of interview. These questions will not be specific to this year (There is already an excellent discussion on prototyping in 2012 here), but more about your team’s general process/philosophy concerning prototypes.
If you are interested, please contact me in any way you see fit (post, PM, email, etc.), and I will work with you to set something up.
Thanks for your help, and I hope everyone continues to have an excellent summer.

Re: Interview Request
 

I'd be willing to help out. Over the past 6 seasons, our team has gone through just about every extreme in prototyping. Our rookie year, we didn't do any prototyping. Our second year, one of the mentors built a working prototype in his personal woodshop overnight for the team, after which we decided to go with that design. Our third year, we spent about half the build season working with the students to prototype different solutions, really focusing on the process... in the end, though, I don't think the prototypes helped us make any decisions. Our fourth year, we got quicker at it, and were able to base at least one decision on the results of the prototypes. Our fifth year, we basically made up our minds ahead of time, and then built a prototypes to prove the design. This year, we really hit our stride best, and and came up with a bunch of different prototypes over the course of a week, and used those results to determine our design. It applied to every aspect of the robot.

So, lets get to your questions, and then I'll expand on it until you decide to stop listening to me :p

Re: Interview Request
 

You'll want to turn to mentors from teams who are well known for continuous improvement and iteration. Those are the best prototypes.

Suggestions are pretty obvious here: 148, 254, 1114, 2056, 2826, 33, etc..

Ask the teams in this thread as well.http://www.chiefdelphi.com/forums/sh...hreadid=107567

Re: Interview Request
 

Here is the list of questions I put together. I'd be happy to clarify any confusing wording.

• How do you initially choose which approaches to the given challenge your team will prototype? For example, weighted objective tables, voting…
• 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?
• Where else outside of previous FRC competitions do you look for design inspiration?

• Do you build field elements before starting prototyping?
• How many different approaches do you prototype?
• How much of your team’s resources, particularly personnel, do you devote to working on a prototype?

o How might teams with different or fewer resources (especially in terms of personnel) change how they operate?

• Once you begin prototyping, what is your approach?

o Do you try to do a proof of concept before proceeding?
o Do you try to gather quantitative or qualitative data? How refined is the prototype at this stage?
o How do you identify what data you need to gather?

• How can teams decrease their turnaround time on iterative prototyping?
• Does a prototype need to work as well as you expect the final manipulator to before you begin final production?

o Essentially, how much do you refine a prototype before moving on/what differentiates a prototype from the finished product?

• How long is your team willing to prototype before entering final production?
• How do you prevent unfinished prototypes/manipulators in general from delaying the rest of your design/production?

I personally have learned a lot from that thread - it certainly informed some of the questions I asked here. I would love to hear more about these teams' prototyping processes, but didn't want to put them on the spot.

Thanks for your help!

Re: Interview Request
 

This really starts with the strategy discussion. We take all of our strategy talk and translate it into generic robot features. "ability to score a basket from the key" or "ability to lower the bridge" would be some examples. We work our way down the prioritized list, getting more specific. For example, how do we score a basket? We sit as a group and brainstorm ideas. Some are straightforward and "obvious", like a catapult or a pitching machine. Others are less obvious.

We'll create a list of prototypes to make based on a few items:
- Votes (if an item is really popular, it gets built. If no one likes it, it generally doesn't)
- examples on past robots (by watching video from previous seasons with similar game pieces, if applicable)
- Personal enthusiasm (If a student is really enthusiastic about an idea, we aren't going to tell them they can't prototype it)
- Time required (If a prototype would require a week to build, it's too complicated. One that can be completed by two students in a single meeting is awesome!)

We try to break the task down as much as possible. For this year, for example, the shooter and collection/transport system were completely separate. Last year, the collector that held the tubes was completely separate from the mechanism that lifted it to the top row. We can adequately prototype these different mechanisms separately, and only have to worry about the point where they join together. Sometimes in thinking about this, you can develop a "natural order", where you have to make a decision on one mechanism before you can make one on another (lifting the balls to your shooter really depends on what your shooter is and how it's designed to have balls loaded into it, for example).
Watch videos. Look up the winning alliances from those years and see if they have any details or photos available.
Anywhere and everywhere. While it's not about robots, this commercial really highlights where inspiration can come from. Pitching machines and batting cages are an easy example from this year. Last year, I brought in a desk lamp I've had for 10+ years that uses a 4-bar mechanism to provide adjustable lighting in order to demonstrate how such mechanisms work. We talk about real-life solutions such as forklifts.
Not really. we have our parents build the field elements for us, so waiting for that to happen is a big waste of time. We'll throw something together to give us an idea (for example, this year we stapled cardboard boxes to some plywood, and screwed the whole thing onto our tower from Breakaway to simulate a basket as a prototyping target), but the real field elements come later when we're trying to perfect everything. Even a simple cardboard mock-up can help you eliminate ideas that don't come close to working well.
We prototype until we find something that works AND that the team is excited about. This year, that meant 3 different methods of shooting the ball, 4-6 (my memory is fuzzy) methods of ball collection, and 2 methods of tipping the bridge.

All of this is during the initial prototyping phase. Once we finish that and know the direction we take, our chosen path may contain a more, smaller prototypes. For example, if we're building a pitching machine, we might look at how different wheels perform, or the affect of different spacing, or the affect of different angles, or the affect of differing amounts of spin. All of that might be considered prototyping, but it's something that happens as part of the build phase once we've settled on a design.
We use whatever spare parts are in the shop. Last year, one of the students built a prototype ball collector out of wire hangers, string, and shop rags.

As for personnel, everyone on the team is involved. We try to limit the prototyping phase to the first week, and to do so we break into 3-4 groups. Each group is responsible for a single prototype each evening (sometimes prototypes take multiple evenings, but we try to get each one done in a single meeting if possible). As a result, we could have one meeting where we build 3-4 prototypes, all for addressing the same goal (like shooting, collecting, or bridge tipping). That gives us the ability to run the prototypes all at the same time, right next to each other in order to provide a good comparison.
We have 20 students. While not the smallest out there, it's also a far cry from the largest. While it may not always apply, building something on a smaller scale might be easier, quicker, or less costly than building it on a full scale. Instead of trying to shoot a basketball, shoot a tennis ball at first.

The resources available, especially in personnel or hours available, may also dictate how far you can go on the robot in a season. If you don't have the time or the people to build a robot that can reliably do task X, it might make sense to focus on task Y. That gets back to your strategy discussions and creating a reliable plan of attack that works for your team.

YES! We always do a proof of concept. Generally speaking, we look around the shop and say "What can we build this out of?" Duct Tape is often used to help hold things together (in fact, our first shooter prototype had the wheels taped to the axles to help save time). Drills are great to use to provide power to something, since you can easily and quickly clamp them onto the end of an axle. In building a catapult prototype, the team used the stand from our miter saw as a base. In a sort of "hitting" prototype, the team re-purposed our Breakaway robot.

Quote:

o Do you try to gather quantitative or qualitative data? How refined is the prototype at this stage?

Not very refined, and we don't gather too much data (but maybe we should...). It really starts with qualitative data - for example, how close to the basket can we get? If a prototype shows no ability to really meet the goals, we don't go beyond that. However, we then get into more quantitative data by asking how repeatable the prototype is. While some tasks are 1-shot items (like deploying the minibot in Logomotion), most tasks are repeated multiple times throughout a match (like scoring baskets this year).

Quote:

o How do you identify what data you need to gather?

This is largely game dependent, but generally speaking there are 4 points of interest for every task:
- speed
- accuracy
- repeatability
- durability
It's a job for the team to decide what how to weigh each of these items in any particular game, or for any particular task in a game. Our team has learned a lesson on each one of these in different years through slow mechanisms, inaccurate scoring, jamming balls, or burned out motors.
I think the biggest thing here is to remember that the prototype doesn't have to be perfect. It only has to be good enough to give you the data you need to build the real thing. That was our biggest problem with Lunacy - we spent a ton of time prototyping because none of the prototypes were perfect. As a result, we didn't have time to work on all of the kinks that arose on the actual robot.

Every prototype you build should be built to help you answer a specific design question. That question could be as broad as "pitching machine or catapult?", or as specific as "what grip material should be have on the wheels of our pitching machine?" The nature of the question will help you determine how accurate the prototype needs to be.
No! Build it well enough to make a decision, then get started on the real thing. Often, you can use the real thing as part of your prototype later, by swapping components or gear ratios as needed.

Building a quick prototype from 2x4's will give you a good idea of what to build, but until you start working with your actual materials (axles, bearings, etc), you won't know what your real challenges will be.
We have the first week dedicated to prototyping, and try to come out of that week with a good idea on our overall design. There will still be "unknowns", but we'll know enough to start building and work out those unknowns as we get to them.
This is a great question. A lot of it has to come down to a team's ability to decide what's important and stick to a schedule. (There's a word here that's completely eluding me that describes what I mean perfectly...)

If you can break the robot into sections you can greatly increase your ability to keep working even if you don't know exactly what something will look like. You have to clearly define the interface between two systems and any space constraints, but that doesn't mean you need to know the specifics of the end effector to know what the arm will look like.

Re: Interview Request
 

Thank you for your response!
I would like to refine my questions in a couple ways, and would appreciate hearing from more perspectives.

How do you know when a prototype can feasibly work with proper refinement vs. when it needs to be abandoned? For example, was there some general criteria in your mind this year such as "if this mechanism can shoot the proper distance, it is viable"?
Any tips for avoiding false positives, or even false negatives?

How do you ultimately choose which prototype your team will refine as the final product, especially when their capabilities are rough and not necessarily representative of what a refined mechanism will be capable of? How do you compare solutions whose true capabilities are unknown?

I am interested in hearing about teams' approach after they have chosen a single design to refine.
Some of the original questions are better suited for this stage in the design process, specifically:
• How can teams decrease their turnaround time on iterative design refinement?
• How do you compare the mechanism's capabilities from iteration to iteration when the differences may be minute without time consuming experimentation?
• Does a prototype need to work as well as you expect the final manipulator to before you begin final production? What differentiates a prototype from the finished product?
• How long is your team willing to prototype before entering final production?

Re: Interview Request
 

• 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.

Re: Interview Request
 

We brainstorm for days following kickoff. It may take us a week to get to a design concept. If there are some issues like ball control that come up during these discussions, we may prototype a shooter, kicker, etc. during the first week. When we come down to the final design, most everyone has had some input.
Every team has a potential to be an inspiration for us. Our students and mentors watch CD and gather info from any source, even people on other teams.

Our playing field team starts to build the afternoon of kickoff and if there is a particular field element we must have, they will build that first and bring it to brainstorming sessions. We often break into small groups and then rejoin at intervals during the first few days. Strategy teams work on playing the game, mechanical and electrical work on manipulator functions and we all decide on driving style base. We don't do crab every year! Only those games that the team thinks could best benefit from that design. Not everyone can work on prototypes or be present to brainstorm everyday. We show up when we can.

We build a proto base so drivers can start to get a feel for driving and software can have a testbed. Then we add elements as we get them built to test effectiveness. We have tossed elements that didn't work as expected in the past or redesigned as needed.
The data needed is mostly set by design goals or strategy. In Aim High for instance, strategy called for shooting ten balls at least during auto mode. Accounting for positioning the robot, that was a very fast shoot rate. Once we achieved the rate, then we refined it to make it accurate. The results was 10 for 10 in ten seconds in most cases. Overloaded the scoring every time.
In most cases, the proto is made of 80/20 slapped together with actual manipulators mounted as they become available. This year, since we lost our welding facility, many parts were bolted together. that theoretically made the proto and the finished robot interchangeable. However, we did find several things lacking in the proto that we fixed in the real robot. Flexing of the under chassis frame was the most pronounced this year when going over the bump.
We are lucky to have a lot of people on the team, both mentors and students. As the build team meets, we discuss priorities and goals. If we have to wait on one item, we move on to something else. If say a turret wasn't complete, we mount the shooter temporarily and let drivers practice driving and software work on vision processing. If everything that can be done is complete and wired, then electrical and mechanical get to go home early while drivers and software continue.