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.

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.

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.

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.

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.

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.

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.

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.

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 intoDoing / Showing / Asking from people much smarter than I.

::safety::

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.

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 :slight_smile:

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

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.

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. :smiley: (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).

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?

This is a struggle - one that many old farts still have.
This is my eighth season in FRC, and it made me cringe when on the first Monday the students were saying, “I like Taylor’s idea. Let’s go with Taylor’s idea.”
The thing was, the way we chose to approach this game was decided by the team. The strategies we’ll employ were decided by the team. And when I say ‘team’ I mean students - I only acted as a scribe on the chalkboard. “Taylor’s idea” was simply a way to realize that strategy.
Since then, it has been refined and massaged and manipulated, mostly by students, into a workable solution.
I suppose my tl;dr is this: Ideas are ideas. They’re not property. Once they’re out, they’re not owned by anybody. So if you feel your mentors are hijacking your team, make a concerted effort to stick your nose in, work shoulder-to-shoulder, make yourself a part of the process. If they deny you that, demand an explanation.

I think what you did was completely acceptable.
In my opinion alumni and mentors are a resource to be used in furthering the students learning and inspiration. this means to me that students should be free to ask any questions on the plausibility of their ideas. on the other hand I think the students benefit the most from being led to the solution rather than just being told.

in 2009 the students in my team chose an idea the mentor was opposed to. this was also the first year the robot was mostly designed before being constructed.
After a lot of argument our mentor he eventually came over to the student’s side and ended up giving them vital assistance.
I guess I’m just agreeing with the majority that balance is what is most important. Just that mentors and alumni have more responsibility for how the team looks in the long term.

There is not necessarily an universal answer that answers for every team how much of the robot should be mentor built and how much of it should be student built.

That being said i will explain our mentor/student philosophy and i will state that i am a very large advocate for student built robots halfway because this is how our team does it and halfway because I believe if it is a student built robot the students will learn a lot more than just watching the mentors. Additionally the reason i want to become a mechanical engineer and a roboticist is that i was able to build a robot and actually see the entire design process and participate in it starting from stating my strategy all the way to making the bumpers at the end of the season and mounting the electronics.

Team 1649’s policy is that mentors are only there to guide and teach the students and answer questions. They are also there to make sure someone doesn’t cut there hand off or something else that doesn’t grow back. So basically mentors are there to make sure we don’t kill each other or ourselves and teach us how to build the robot. This being said the mentors are not in a glass box and all they do is answer questions and then sit back down. Normally the mentors are there and will answer any question you have but they also move around to the different projects we are working on and they will advocate safety or ask questions and suggest ways to do something better. Also the mentors will voice their opinions and tell us when where not doing something right or suggest a way to do it better but the students are still the ones building the actual robot. This is our team philosophy and our main mentor follows this team philosophy very closely with the only exceptions to this being a alumni mentor teaching us how to do CAD while cadding components for this year’s robot.

The last thing i want to say is that this is our team philosophy and i just wanted to share it and it may work very well on our team but it may not work for other teams. Such as teams where the machining tools can only be used by mentors or chaperones.

On our FRC team I can say with confidence that every idea that has ever made it onto one of our robots has been modified, tweaked, corrected, and/or simplified before going into production. This is normal and happens in real life every day. In my day job I work for a local power utility, we install equipment in the field that will likely be in place for the next 30-50 years. That means the engineer who designed the system is not likely to be around when it is removed. Our control systems and mechanical designs must be able to withstand time (decay) and design brain loss (engineer retirement). Since I support systems designed before I was born and the same will be true for someone else in twenty years, it is imperative to refine ideas until they are in the most simple form possible.

I am not sure exactly what is going on with your team but I would encourage you to think about the advice your mentors are offering you. I simplify systems everyday which gives me experience in taking complicated designs and making them work even better. My guess is your mentors can do the same.

Remember build season is six weeks, it will never be possible to test or refine every idea people present. Sometimes the mentors can see that even after refining, your idea will never get to the starting point of another idea. This experience is invaluable. As a mentor myself the thing I value most is student initiative. Go build a prototype and test it, then try and make it simpler right away, finally make a final case for the design. In the end, I believe in evaluating ideas by removing who designed/created it and then comparing each system side by side, the one that integrates into the entire system (complete robot) the best should be used.

We had some great ideas this year for sorting Frisbees, but I could see right away that they would not fit in our robot design due to orientation and frame size. Students got upset when I wanted to move on because of the same mentor/student idea origination. We are now building a different design that everyone is happy with and to be honest, I am really not sure if any one person came up with the current idea. It has been through so many revisions that it must have 20 sets of fingerprints on it by now. I use this as an example to show how systems evolve; your idea might not be used verbatim now but later a small piece of it may find its way into a much bigger and better design.

Just my $0.02.

Does anybody truly believe there are teams out there where the students “just watch the mentors”?
That just seems like a huge false dichotomy that’s been used as the crux of a lot of arguments.