[Jon Stratis]

Originally Posted by IanW

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…

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

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

Watch videos. Look up the winning alliances from those years and see if they have any details or photos available.

• Where else outside of previous FRC competitions do you look for design inspiration?

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.

• Do you build field elements before starting prototyping?

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.

• How many different approaches do you prototype?

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.

• How much of your team’s resources, particularly personnel, do you devote to working on a prototype?

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.

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

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.

• Once you begin prototyping, what is your approach?

o Do you try to do a proof of concept before proceeding?

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.

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

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.

• How can teams decrease their turnaround time on iterative prototyping?

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.

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

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.

• How long is your team willing to prototype before entering final production?

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.

• How do you prevent unfinished prototypes/manipulators in general from delaying the rest of your design/production?

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.