At what point does it become unacceptable for a mentor to design/build the robot
 

I understand FIRST is for inspiration, but if mentors are building and or designing the robot isn't it pointless for us to waste our time there? When the ideas for the robot are basically mentor ideas, and student ideas are either shot down or refined enough so that they're just the mentors ideas.

If FIRST is about inspiration, then maybe mentors should just build their own robot and face off against each other and just let us watch. I'm sure that's inspiring enough to get into a STEM field.

I'm in no way accusing my team of doing this, I'm just wondering. Where is the line drawn between student/mentor involvement.

Disclaimer: I in no way shape or form are discussing Team 1745's opinions, these are my opinions and mine only.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

There are approximately a zillion threads on this, and it always turns into an accusatory and awful discussion. If people want to discuss this, please do so calmly and without internet-rage.

If you're asking for my $0.02, whatever a team needs to do to accomplish goals - as defined by that team and their dynamic (I'm talking mentors and students here)- is what works for them, and what they should do. So long as everyone on the team agrees on their process - that's their process, and that's that. Outsiders don't get to 'judge', because it's not their team.

For example - I was the founder/captain of 1923 in high school, and we worked side by side with mentors, because we knew that they know better than us. The kids did the design, the mentors were there to tell us "Physics says that won't work. Try this instead?" Now that I'm attending (and about to graduate from!) Clarkson University, I work on teams where there's a lot higher mentor-driven design and work- 229 and 4124 - because we work at the University, mentoring is a course for the CU students... and it's just plain not legal for the kids to machine here. None of the teams I've worked with are doing it 'wrong' - because it's what works for each team, and the kids and mentors are all happy with, and agree upon, the process.

Where teams encounter problems is when one "side" tries to "take over" the process and the team as a whole isn't happy. That's what I think you're trying to get at here, and I think that deserves some discussion.

Chief Delphi always gets weird in threads like these. Keep it civil if you're gonna post here.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

It's unacceptable when students aren't inspired anymore. Anything less is a cop-out.

I've seen students inspired by 90% mentor built robots and I've seen students turned away from engineering forever by 90% student built robots. I've seen robots that look "mentor built" that come from excellent programs with students inspired at every level, and I've seen robots that look "student built" that come from terrible programs with almost no actual student involvement.

All of that said, I don't think the standard "whatever works for your team" answer really helps this particular question, since this thread seems to be asking about at what point one's *own* team has crossed a line. That calls for a level of introspection that the other threads lack. I would try to separate any frustration you as a student have from the objective facts of what is going on, and the subjective reality of how inspired these kids are by this program you've got.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

It's this time of year again already?

I'll wait for this thread to either be closed or develop into yet another thrilling debate on a topic that will forever be debated and never really change anything because most believe nothing should be changed.

For now, I'll leave you with this.

This means we must be mere weeks away from the "adults on the drive team" and "x was 'un-GP' to y, allow me to point them out to you and display my Gracious Professionalism" threads. Gosh, those are fun.

In the name of science, let me propose this if-then statement:

If Dean Kamen tells us "it's not about the robot," then why does it matter how the robots get built?

We come to be inspired. We stay because we are. We will become the inspiration. Teams aren't preparing a dynasty of a high school robotics team.

Sorry if I seem frustrated, it's just... tiring.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

I've been reading some similar threads for the past few days (i spend too much time on this site), and a big difference in this thread and the others is that OP is not attacking a team, but is more curious. yes, this is beating a dead horse, but it's nice to see curiosity rather than jealousy.

Know this OP: If you're inspired enough that you want to make those extra steps to win, you'll have to realize that students don't have all of the answers, and it takes years of studying and experience to even understand a fraction of the answers to any year's game. For this reason, it's important to have mentors. Mentors show you the steps to becoming competitive, which is an inspiring process for all. They'll show you how to design, how to go about doing iteration, and how to continue to engineer your dreams. Don't shun them.

It's up to you and your team mates, but also your mentors to decide how to handle relations among each other. You as a student want to design a solution, and the Mentors want to guide you to whichever solution you choose. Talk with them and discuss how your team wants to go about finding and implementing the solution for this year's game. Just remember that different teams have different methods. You'll find that most of the famous teams boast more than a handful of mentors, and this is because the students and mentors want the relationship to be like this, and both parties find this to be inspiring.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

We know we've crossed the line when the students tell us. We crossed the line in 2008, and the students pulled us back halfway through the season. Since then, we've done much better. It's best when the students can be up front with the mentors about what they want. Ours always are.

Personally, I always cringe when our students say "do we want to go with this idea we had, or do we want to go with mentor X's idea?" Unfortunately, that's part of the development process - anyone can have an idea, and a 7 year mentor knows more than the students. We explore every idea equally, and if I present an idea to the students, I don't say "we should do this instead." I say "I had an idea that would get around this specific problem you guys are having with the current favorite idea." I explain the idea, and then walk away - I let them (with the help of other mentors, if needed) evaluate the idea and rank it with he other ideas. I don't stick around to push my idea over theirs.

In the end, it's up to the students and the mentors to figure out the balance that works best for them. If students join the team and decide to leave because of the atmosphere or interaction, there's a problem.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

Sometimes I feel that because mentors have been doing this a long time they don't take into consideration or even test students ideas. The mentality that students can not come up with good solutions, or rather the mentality that the mentors designs are more correct keeps coming into play. Students, if dedicated enough spend as much or more time coming up with solutions, and it isn't all that inspiring to be shot down without any thought or even any testing. I'm saying this from personal experience, sometimes I feel like I have to go on my own to build something to prove it will work and after it does suddenly it is looked at more seriously.

Obviously if students are being inspired then they are going to want to help design and build instead of watching. Watching someone build something leaves something to be desired.

To clarify, I am not attacking any teams in this thread. I am talking about team dynamics.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

Students should be testing their own ideas, not handing them off to mentors.

For some teams, the mentors need to be very involved. For other teams, they almost don't have mentors. Most teams lie between those two extremes, and as long as everyone is OK, it is OK. When someone doesn't like it, they need to change it democratically.

So in our hypothetical team where some students felt their ideas were being ignored, first advise the mentors of those feelings, and try to see how it can be addressed.

Students need to understand that mentors are unlikely to take any cockamamie ideas that students throw at them and make them work - that takes way too much effort. Instead, the student has an idea, they get reasonable resources to develop and test it, with the mentors offering verbal advice when a roadblock is hit.

I had a student approach me with an idea for lifting up frisbees, and I quote "well, the frisbees get in here somehow and are lifted up somehow and pop into some kind of hopper." Great idea, but still needs some more effort, because a 5 year old could've come to that conclusion. The devil is in the details - come back with a working prototype and we can talk.

No J.W., I am not referring to you.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

Having been a student and now a mentor I totally agree. I got started in FRC when I was in 7th grade and about as "useful" as a wet pool noodle. I was very involved for the next six years, and as you can imagine got considerably more useful as I got older. During this time I got to interact with a wide variety of mentors with a wide variety of styles.

I did not mentor a team in college (although I would occasionally drop in on 2791). IMO, this was a critical piece of the puzzle for me. I was never in that awkward phase that is somewhere between student and mentor. I was very clearly a student, and now am a mentor. (Which may scare me, but...)

I do not think there are any adults (or at least exceedingly few) in this program that would intentionally block-out students. It is most likely that they just don't remember when they didn't know how to do something, and are unsure of how to involve students. Or maybe they feel the clock breathing down their backs, and they want to make sure that the team fields a working robot. Or, you get a bunch of technical experts in a room they start going at it without them even realizing that they are excluding everyone else. (eventually you have to fire the engineers and just build the darn thing)

What I consider one my greatest mentoring strengths is I remember when I was a student in varying degrees from "completely useless" to "Mr. Mentor is here for insurance reasons" And I try really hard to hand out tasks that fit where kids are today AND give them an opportunity to grow in the future. And I think the people that stick with this program think along those lines, but sometimes people who are in their first season or two haven't figured that out yet.

For example, freshman and sophomores generally have a really hard time drilling a perpendicular hole with a DeWalt drill. I am not sure what the scientific reason for this is, but I know I was also totally incapable of drilling a perpendicular hole for a long time, so you either have them use a drill press or have someone else sight the drill (and continue moving it back straight when they drift off!) To continue the example you may have to drill a particularly difficult hole during week 1, show someone how to adjust the clutch on a cordless drill in week 3, and just ask someone to mount a reinforcement brace on the robot in the pit.

This thread has some really great insights into Doing / Showing / Asking from people much smarter than I.

::safety::

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

Another issue is training time. If a team forms before build then the mentors are more involved in the robot as this is the only time to teach. We have our students all year in a engineering program and so we can mentor before build. There is no way you can compare the two different styles. You have to do the best with what you have. Both systems produce great students. Also some teams focus on the robot and some on the students. Each system produces good results depending on the mentors and students involved. What works for my team will not work for many other teams.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

I think our coach handles it perfectly. He basically acts like another student when it comes to brainstorming: suggesting anything that pops in his head or helping out here and there with some new ideas. But nothing more than any of the rest of us provide. I (note: not we. This is just my thoughts) feel like our coach does a great job of being part of the team, but not taking over at all.

A great example. Today we were discussing climbing plans and he said "Y'all are welcome to override me, but if I were a dictator or a one man team, what I would do is..." and gave us his opinion. Then went on to say "but y'all decide what you think is best and that's what we're gonna do." Providing ideas but not shoving them down our throats seems to work really well :)

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

I find that one of the most overlooked aspects of this whole discussion is the very extreme time window compression of the FRC build season.

Clearly, there is not a whole lot of time that can be wasted trying out some of the student ideas that a mentor may clearly instantly see is frankly unworkable. It often seems heavy handed when ongoing arguments over opposing design concepts finally get decided by a unilateral mentor decision, and without any student-expected "fair test."

I sometimes feel like the compressed time window prevents a lot of learning experiences from happening, just as much as it may create some too.

There is a lot of pressure on mentors to have a build season end with some sense of accomplishment. When mentors see that the focus of team efforts is going in a bad direction that is destined to fail, they feel obligated to right the ship. Often this leads to them taking too much control and doing too many things that students could still handle, if they were more skillfully redirected toward the more potentially successful direction.

Students can then start feeling left out of the process. It is a real balancing act to have students being responsible for things that they have had zero prior experience doing, and at the same time knowing that there is really not enough time to deliver to them the background knowledge and training that may be required to complete many tasks.

So as the time crunch pulls a team ever closer to the event horizon of bag day, mentors may often seem like they start drifting away from doing as much mentoring, in the manner that students expect them to, and seem to start taking on too much of the job, to the point of excluding students from too much of the process.

However, understand that it is the mentor's strong commitment toward realizing the extended team's goals - students, parents, administrators - that is the primary factors that triggers this kind of mentor-doing-too-much behavior.
This still doesn't mean it is a good thing, but it does make it easier to understand how and why it happens.

I personally feel the the very short time window of the build season of FRC seriously undermines the level of good mentoring that I can accomplish with my team, and forces me to be doing way to many things that I would rather have them be doing, but time simply does not allow that.

-Dick Ledford

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

The best way to avoid these discussions on CD is by teams learning their own team dynamic and discussing it with students, teachers, and mentors together.

The better the students understand the mentors' motives and actions, the better they react. Usually this means more rational reactions and less irrational threads on CD (Not that Kusha is an example of this). When mentors understand students' concerns, they learn how to better react to farfetched ideas in a method that is more conducive to the student being inspired/learning from the mentor.

It really boils down to team communication that happens before build season. Open discussion and everyone understanding how the team runs/how they want it to run is what makes or breaks a student's reactions to these types of scenarios.

+.02 based on experience from the past season and offseason. Kusha, feel free to PM me or chat on facebook about my team's experience with these issues.

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

I agree completely. It seems we're in the same boat. Student acquisition of skills takes a LOT of time. We started pre-season prep in the summer, and it still isn't enough. In the build season, the competitive teams that will win this are not doing hardly anything new. They are already experts, and are simply repeating things they have done in the past. They innovate in the offseason, and apply minor tweaks during build season. If you're trying much of anything new starting in January, you have already lost the game.

This build season has been particularly tough. Already, I have over 230 hours into it personally. As a team, we have over 3000 people-hours into it total so far.

There are plenty of things I wish I could take the time to show students how to do for the first time, but the harsh reality is that if I did, it would be February 19th and we wouldn't have anything close to resembling a robot sitting here (we still may not anyhow!). Sometimes one has to consider the greater good. Whch is better: students involved in every step an the robot is a terrible failure, or a reasonable dose of mentor involvement and the kids have something adequately field-able? While it's not about the robots, a terrible robot can ruin any team's morale. I refuse to allow it to happen here. Failure is not an option.

In my opinion, a team needs to best utilize ALL of its people. If an adult has knowledge or skills or abilities that can benefit the team as a whole, it's doing the team a disservice to hold that back.

While currently I may do too much work for my students, they are all aware of my goal to be sitting back in a La-Z Boy recliner with my feet up on my desk and a cool beverage in my hand within the next 5 years, and several students are making progress toward helping me achieve that goal. :D (This is a fictional goal by the way. I don't think I'll ever be a hands-off mentor. It's just not my style).

Re: At what point does it become unacceptable for a mentor to design/build the robot
 

Almost all of the time it depends on the student. I have a great pair of seniors who can build most anything. They presented me with a frame plan and a CAD drawing and I made some minor suggestions, and then they made it... alone.

The shooter group, on the other hand, has me do most hands on work, even when I insist they do it.

The other groups are a mixed bag, sometimes you need to stop an action in progress, like the first year member using one of my classroom desks to pound a gear onto a shaft... don't ask...

Other times, there just isn't time. Last year a support strut broke in between matches, as I watched the confusion and repair attempts, I KNEW I had to step in and take over, or all was lost. I felt bad afterwards, but the team congratulated me. To quote the outgoing leader, "sometimes experience trumps enthusiasm."

Ask yourself this, should I have let them fail to repair the strut and forfeit several matches? What purpose would that serve?