Plans for the future

[thenomnivore]

For next year's robotics season, the team decided to change almost everything entirely about the team. Our showmanship, that way we dress, etc. One of the most important and most talked about issues we face is the design process. For the last couple years, what we have done this process was we would have 2 teams making 2 robots, choose which one is the best, go from their but by the end of the season, it seems like a waste of time because of the amount of time we spent of each robot and not one. I'm asking any team for advice or how their team does their design process and how well does it work. Also, we are trying to get our mentors to have less say in the final robot because usually, the most important task almost 100% becomes a project of the mentors.
Any input and ideas are helpful. Thanks

[Michael Blake]

Originally Posted by thenomnivore

For next year's robotics season, the team decided to change almost everything entirely about the team. Our showmanship, that way we dress, etc. One of the most important and most talked about issues we face is the design process. For the last couple years, what we have done this process was we would have 2 teams making 2 robots, choose which one is the best, go from their but by the end of the season, it seems like a waste of time because of the amount of time we spent of each robot and not one. I'm asking any team for advice or how their team does their design process and how well does it work. Also, we are trying to get our mentors to have less say in the final robot because usually, the most important task almost 100% becomes a project of the mentors.
Any input and ideas are helpful. Thanks

You may want to start with John V-Neun's (148 Robowranglers) white-paper on the Design Process...

http://people.clarkson.edu/~jcarroll...R.20091204.pdf

We're a 2nd year FRC team who won the Engineering Inspiration award and seeded in the Top 8 at our two regionals. Plus, we seeded 5th/Captain on Archimedes and made it to the Semi-Finals... 15 months ago, we didn't know a "Digital Sidecar from a Railway Car!"

Our entire approach/process is based on this document...

EXPERIENCE, HARD WORK, recruitment, combined with this _invaluable_ knowledge that JVN has shared is what has enabled our team to progress rapidly...

Hope this is helpful to you and your team...

[Garrett.d.w]

We do something that we call the 7 ways. It works great for us because it gives everyone, even the mentors (though they generally opt out) an equal opportunity to present and comment ideas.

I like to break this down into a few simple steps.

1). Individual brainstorm.
Each person goes off and draws or describes a solution to a problem.

2). Presentation
Each person gets a brief slot of time to present their ideas and then a slot of time to answer questions.

3). Listing of pro's and cons
The team brainstorms the pro's and cons of all of the solutions, normally we have already axed 3/4 of the ideas at this point, so we are not overworking ourselves.

4). Vote!
The team votes for their favorite solutions. From here we take two or three solutions and mock them up in plywood, just as a proof of concept.

This process can take our team about a full day to complete. We generally only have to do it once per season to figure out our general build strategy.

[LeelandS]

Hi! First off, I congratulate you on taking this step. A lot of teams I've talked with are not willing to do a total overhaul of their process and team in general. It can be a great way to get a team to reinvent themselves and start down a different path if they're not liking their current one.

First off, I wouldn't advocate the "two teams, two robots" deal. It's in interesting thing to consider if you have a very large team and an insane amount of resources, but otherwise, you're going to have two robots that are half as good as one could be. So I'd recommend having your entire team come together and work on one robot.

Here are a few notes I remember when considering how I'd run a team and designing a robot:
- Break into groups. Put students and mentors into assigned sub-groups that focus on a single aspect of the robot (drive system, game piece manipulator, end game device, etc.). It's easier to facilitate design and production on a smaller group, so long as they're not TOO small. Make sure all students on the team are able to suggest designs.
- K.I.S.S. "Keep it simple, stupid." Don't over complicate things. The process I follow most is start with your design. Then iterate it, making it more robust and effective each time, without adding too much complexity.
- Built within your resources. In addition to K.I.S.S., don't build a design your team can't support. Unless you have the manpower, time, experience and resources to design, build, manufacture and maintain a system, don't do it. I've seen a lot of teams try and build something beyond their resources, and the result is not terribly pretty. This includes both physical systems and anything related to programming. Don't overburden your programmers.
- Play for the game. Consider everything you want to do in this game. From drive system to game piece manipulator, make sure your system plays the game. If you're designing for this game, you may want a drive system with high traction for bridge traversal. Things like that are what you want to consider.

These are the basic points I consider. I'll post more later when my laptop battery isn't on the verge of death.

[thenomnivore]

This has been a lot of help THANKS!!

I'd like to start this post by saying thank you for making this thread. I've been meaning to redo how our team does design for a while, and this gave me the initiative to start it. So, thank you.

Anywho, this is what I came up with:

Saturday (kickoff day):
-Discuss game
-Objectives
-Ways of scoring
-Possible Strategies
-Get the general game strategy locked in
-Make a strategy for both offense and defense
-Have people decide which subgroup they want to work in during the design period

Sunday:
-No team meeting
-Have team members brainstorm different designs for their subsystem

Monday (may go on to Tuesday):
-Whole team meets
-Break up into system subgroups, and start making a list of designs and details for each subsystem part
-Subgroups draw out and list the details of each mechanism, and pick their top 3
-Each subgroup presents their top 3 ideas to the entire team
-The whole team goes over the pros/cons of each design presented
-After a detailed pro/con of each part, the team does one of two things:
-1: Choose the best design out of 3 for each subgroup
-2: Eliminate one of each subgroup design and vote again on the remaining two
-By the end of Monday/Tuesday, there is 1 remaining design for each subsystem of the robot. The team then finalizes those designs with the more intricate details (how, what), and the design is semi-locked.

Semi-locked means that for the most part, you won't change anything, but you can if you need to.

[Walter Deitzler]

Also, check out Kartik's presentation, once it is posted online. Definitely a thing to see, and a great help.

[thenomnivore]

again, i thank thee!

[Alex.q]

I know almost nothing about your team, so I can't give comments directly to your situation, but I will describe ours this past year. We are one of if not the largwest FRC team in Minnesota with about 50 kids that show up on a regular basis. Every year it seems we have re-structured our build plan and leadership. This past year, we considered the same idea with two different robots, and decided it would be a lot of wasted effort because much of the work would be redundant and it would not create any opportunity to iterate. The idea then became 1 chassis with two competing manipulator teams to see who could design the best manipulator. (While we did not use this approach, I think it would have worked well for a subsystem like the shooter, but I'm not sure if it would have meant a catapult and a wheeled shooter or two different but similar designs.) Anyway, we decided that it could be hard to decide which one was better (at what point do you decide, and at the deadline point the truly better manipulator is still waiting to get its essential part in the mail) and could also create hard feelings within the team. We also considered employing large number of students to build more prototypes. I'm not exactly sure of the approach we chose, because as soon as we started the build season, the approach changed to create our traditional build subteams (chassis, manipulator 1, manipulator 2). (As a sidenote here, I remembering vehemently opposing this, having experienced in lunacy compartmentalized subteams who failed to properly integrate their subsystems. Beware of this.)

In short, instead of 2 robots, build 1 chassis 2 different yet similar subsystems that will employ the same game strategy. (It would be hard to compare good ball collector to a mediocre shooter). OR Build 2 robots and iterate upon the first version to improve it. This is probably the more popular method.

I have been thinking about how to once again restructure the build process, and this is what I am currently considering. Everyone as a team decides what strategy they want to employ. Then groups break out into subgroups (chassis and manipulator) to brainstorm possible ideas for the sub-assembly on which they will specialize. Ideas are presented to the whole team, some shot down; a select few will be prototyped. A smaller group of students will work as the design team to do the detailed design work. As they do this, they will assign build tasks to the builders (prototype what amount compression will be needed on the ball). Once an iteration of the robot is designed, everyone works to build it. Its tested, evaluated to see waht could be improved. Re-design flawed systems, continue to test v1.0 while designing and building 2.0.

*Keep in mind I am accustomed to a large team, with a smaller team, I am sure you would adapt this structure.

[Michael Blake]

Originally Posted by LedLover96

Also, check out Kartik's presentation, once it is posted online. Definitely a thing to see, and a great help.

Without even seeing this yet, I would agree...

We were deep in fixing our bot Wednesday and didn't get the opportunity to go to Karthik's presentation...

Anxious to see the presentation soon to see how we can fuse/merge it with JVN's Design Process approach:

http://people.clarkson.edu/~jcarroll...R.20091204.pdf

[nlknauss]

There are a wide number of engineering design processes you can follow to design and build your solution. Pick one that will work within your system and the resources you have available to your team. Also remember that you have to run that design process. Look ahead and schedule where you should be on exact days of your timeline and make those goals happen. I've seen many people pick a process to follow and not use the process to see the design out because the end of build sneaks up on them.

[Anupam Goli]

Originally Posted by SuperNerd256

I'd like to start this post by saying thank you for making this thread. I've been meaning to redo how our team does design for a while, and this gave me the initiative to start it. So, thank you.

Anywho, this is what I came up with:

Saturday (kickoff day):
-Discuss game
-Objectives
-Ways of scoring
-Possible Strategies
-Get the general game strategy locked in
-Make a strategy for both offense and defense
-Have people decide which subgroup they want to work in during the design period

Sunday:
-No team meeting
-Have team members brainstorm different designs for their subsystem

Monday (may go on to Tuesday):
-Whole team meets
-Break up into system subgroups, and start making a list of designs and details for each subsystem part
-Subgroups draw out and list the details of each mechanism, and pick their top 3
-Each subgroup presents their top 3 ideas to the entire team
-The whole team goes over the pros/cons of each design presented
-After a detailed pro/con of each part, the team does one of two things:
-1: Choose the best design out of 3 for each subgroup
-2: Eliminate one of each subgroup design and vote again on the remaining two
-By the end of Monday/Tuesday, there is 1 remaining design for each subsystem of the robot. The team then finalizes those designs with the more intricate details (how, what), and the design is semi-locked.

Semi-locked means that for the most part, you won't change anything, but you can if you need to.

Your schedule is nice, but seems a tad bit rushed. An alternative to yours would be something like this;

On Saturday, concentrate on kickoff, and READ THE RULES. Do not discuss anything until reading the rules. Know your limitations. Know the game. Once that is done, start coming up with strategies. Make a priority list of what game elements you want to manipulate. There is a good example of this in HOT's technical documents; http://frcteam67.dyndns.org/hot_Engi...Tech_Notes.pdf

On Sunday or Monday, make sure everyone is agreeing with the strategy. Vote is only a four letter word. You have to make sure everyone is unanimous with the decision on strategy. Voting is a last resort to come to a decision, never the first. Once that is done, you can divide people into subgroups and have them come up with concepts for each of the subsystems. The Drive Train should be decided first, as this is usually the easiest to decide and biggest hurdle.

Each concept should have a proof of concept or prototype, though with drivetrains, there are enough resources where a proof of concept isn't needed, and active prototyping would only be fore frame structure. The other subsystems should go through rapid prototyping in order to test the concept and to find an optimal efficiency of manipulating the game element. I like to refer to 118's 2006 week 3 video as an example of what I'm talking about: http://www.youtube.com/watch?v=UV_d1ChpyLg

[Al Skierkiewicz]

I suggest you read "Behind the Design". I question your decision to change the team marketing and look. We did that one year and no one could find us. We are tie dye forever now. We start brainstorming after we take a break when the kickoff ends. We don't stop for the next several days. We play the game, work on strategy, play the game some more, finalize strategy and then make a lost of what it will take to win the game. Then and only then do we start to design the robot. We take input from everyone during this phase, students mentors and parents. No idea is turned down. Each year we do this part a little different depending on who is leading. We often break into small groups and then report back when all the groups get together. Then we build a prototype and start testing. We modify the design throughout the build and sometime right up to Champs.

[Chris Fultz]

http://www.chiefdelphi.com/media/papers/2485

[aja747]

thanks for all the advise ill send this stuff to the head honcho. def alot of teams should be thinking this way because personnaly i think team 148 has alot of fun during build season