Thinking Process

[Skehtb]

I know it's a bit soon, but i'm thinking about that for the last few days. I'm not realy happy with the thinking process (about the robot) that my team did this season. As a student, who will be one of the team leaders next year, I want to know how most of the teams do their process: how do you decide what your robot will do? how do you decide what mechanisms will be on the robot? what do you do first-build the robot or plan strategy? These are only 3 out of many things that i want to know... Thanks for helping! And sorry if i have some mistakes in English.

[DominickC]

Our team began by reviewing all of the rules and the game. We then moved on to asking "what do we want this bot to do?". From there, we came up with a few designs, tested a few prototypes, and ended up with our final designs.

[SenorZ]

As a team leader you need to just that: Lead.
Make a list of what you didn't like about the process this year and have your team come up with some alternatives. If they can't decide, you need to do it for them.
As a mentor of a small team, with limited resources, and limited student time availability, I had to make many decisions that a more organized team would have done on their own. Ideally, after reading the manual there should be some goals written down. Do you go for a "team" robot that is able to support others but is lacking features, or a "lone wolf" that can do everything? Make some rough designs, think about costs, and go from there.

[Skehtb]

This year, the process was managed by one of our mentors. Even though most of the team members did participate, most of the the dicisions were made by this mentor together with the team manager and captains. About 70% of the kids don't feel that the robot is "thiers", the feel that it's the mentor's robot. Another reason for that feeling is that the robot was manufactured in one of our sponsor's workshop, and the kids didn't really build it.
I'm pretty sure next year won't be that way, but in my two years experience i've seen two kinds of robots - A robot that was 90% of the kids (by bulding and design) and didn't played well at all, and a robot that was 20% of the kids (like this year) that played pretty well, except for some software problems..

One of my friends told me that - "I'd rather build the entire robot by myself and lose, than not build the robot at all and still lose!" (even though this year a sponsor helped us to build our robot, we are not the regional winners (and I'll add that information - most of the teams that compete in our regional are teams withour factory and engineers that help them and build their robots).

At the bottom line, I'll be glad to hear you advices about how can we, as a team, create a balance between those two situation that I wrote about: We want the kids to be more involved at the building and designing of the robot, but still build a great robot that could win!

[nitneylion452]

I'm guessing this is your second year as a team?

If so, design is a process that will change every year until your team finds the one that is best for you. Sometimes you will be at one extreme and lock in to a poor design too early and then not have time for a redesign, and sometimes you will be at the other and prototype for too long and have the robot finished on bag day (and not let your drivers have any practice). My team has done both of these and neither is good. You need to find the middle ground between both.

As for mentors designing the robot and having the parts manufactured by a sponsor, that's actually a great resource to have (save the mentor-only design process). Being able to have parts custom made is a great thing because it will save you some weight and will add functionality to your robot as the machines they use are extremely precise.

Good luck with the rest of your season and the remainder of your FIRST career!

[Skehtb]

Originally Posted by nitneylion452

I'm guessing this is your second year as a team?

If so, design is a process that will change every year until your team finds the one that is best for you. Sometimes you will be at one extreme and lock in to a poor design too early and then not have time for a redesign, and sometimes you will be at the other and prototype for too long and have the robot finished on bag day (and not let your drivers have any practice). My team has done both of these and neither is good. You need to find the middle ground between both.

As for mentors designing the robot and having the parts manufactured by a sponsor, that's actually a great resource to have (save the mentor-only design process). Being able to have parts custom made is a great thing because it will save you some weight and will add functionality to your robot as the machines they use are extremely precise.

Good luck with the rest of your season and the remainder of your FIRST career!

Thanks!

Actually, our team is 4 or 5 years old, and the design process keeps changing...

I know the whole mentor and sponsor thing can be good, be as I wrote before - this season the kids didn't feel they had a part in the robot designing and building process, and we didn't win (so there is nothing to cover their feeling).
Some of the kids even didn't enjoy from the process because of their feeling, they just felt bad and I think this is something that shouldn't happen!

[couvillion]

The thinking process is also called "System Engineering" as an engineering field of study. Beach City Robotics team 294 has a excellent presentation on it for FRC robotics http://www.bcrobotics.org/wp-content...ering%2025.pdf I stole from it for presenting a design process for my team.

As for making the robot yours instead of the mentor's, the easiest way to do that is to get ahead of the mentors. Prepare the kids ahead of time for how to do the decision making, make plans for the kick-off and be ready. Keep the adults in the loop, you don't want to freeze them out, but let them worry about other things (money, permission slips, etc). There is always more work that could be done than the team can get done. Your team is striving to find a process for building a robot, you can help that along by getting involved in it.

That said new mentors and sponsor are prone to over control the robot build, they want good results, and there is a tendency to view the robot as the result of the team. That is not true, good students are the desired results of the team, the robot is a means to get them. By leading you leading the students in the process of building a robot, learning a little bit of all the fields of engineering involved in making a robot. You are showing them the results that the team wants to accomplish.

[Brian Ha]

Our team does a mix of both. Students come up wit goals of wat we want to accomplish. Then u come up wit robots that accomplish those tasks. We do a ranking system thingy that selects the best ribot. The mentors then go into action mode and figure out the best way to design it. Then our parts are all manufactured by one of our mentors wit a waterjet. Then the parts ate brought in and finished cause a waterjet has some faults in it. The kids build the robot, the kids fix the robot. We just get the parts. Thats how it should be done. Not built by the mentors.

While I said all of that wat really matters is whether the kids learned anything. It doesnt matter if its mentor built. Its about expanding ur knowledge.

[Katie_UPS]

I would learn from the greats. Simbotics has a bunch of workshops that I suggest checking out. Robot Design and Strategy would answer your questions. I know many [successful] teams follow similar guidelines/ideas/schedules as posted by 1114.

[DonRotolo]

All of those^^ are good suggestions. As a leader, you first need to find a process that works, and then (the hardest part) convince the rest of the team to use it.

Our team first takes a long day to decide how exactly to win the game. This is our Strategy. (often more than one). We all know some strategies to win at Baseball, but with the new FRC game we need to figure it out each year.

Then we take 1-2 days to create a list of Capabilities. NOT how to do something, but WHAT to do. Example: Throw balls into a basket. We assign priorities to each Capability, because some are more important that others. Try to not leave anything off this list (like "drive across the field")

Next we take 2-4 days to design (not in detail, just the ideas) for Mechanisms that might give our robot the Capabilities we need.

Our sub-teams then go make Prototypes of the Mechanisms, so we can test which is the best. Another 2-3 days, then we decide which ones are best.

We then start building these best mechanisms, hoping to complete them for testing by the end of Week 3. These are assembled into a robot during week 4, then the robot is programmed.

At the end of week 4, we finalize the design and build the "final" robot.

Many of these stages overlap in time. We have the "Final" drive train being built in week 3 for example, and driving code is done in week 2. But for the manipulators - like our shooter this year - we did not finalize the design until week 4.

Once a decision is made, we stick to it unless there is a serious problem that cannot be solved, even with mentor advice. That is, we Freeze the Design in week 2 or 3, and then it is not possible to change the design. (This prevents "scope creep", a term you can Google to learn more)

[Aur0r4]

Our design process is very similar to Don's where we brainstorm a game play strategy, then develop a list of what we want the robot to do, prioritize them, and then begin designing and prototyping several mechanisms in parallel. We set goals on how long we want to prototype before selecting the most promising mechanism.

We found it is very helpful to emphasize constantly that the game play strategy and capabilities list should not include discussions of mechanisms. This sidetracks and often narrows people's vision of the machine. We also find it helpful to remind the students that EVERY strategy they even think of will be thought of by others, and most of the ones we eliminate will still be done very well by someone else and may beat what we select. We try to remind them that most of what determines success is the quality of what is implemented, and not necessarily on whether the "right" strategy is selected.

Come up with a "good" strategy, narrow your focus, and get to work prototyping! We got through game play strategy and capability selection during the first meeting on kickoff day. We were prototyping shooters the next day! It can be tempting to spend too much time selecting a strategy, but some of the magic of engineering is seeing how most ideas can be designed well enough to work, and most can work very well. Yes, some are easier to make work in our timeframe, but I've rarely seen strategy selection trump design and build quality as the Number 1 component of success.

We try to keep multiple mentors involved in brainstorming to prevent one authority figure from dominating the discussion. The team benefits from watching us disagree too! It keeps a "balance of power" and shows the team that engineers rarely agree on the "right solution". We also strictly allow them to chose the final design strategy. We will add our opinions to the discussion, but once the team decides, all of the mentors work to make the chosen idea work. Often things you disagreed with work better than you expected!