And despite the best efforts of my teams students, I still can’t floss and I don’t know any of the lyrics to Hamilton. Maybe I’m not involved enough?
and we’re over here allowing our students run our Haas Mill with nothing more then a mentor doing general shop supervision. I guess it really comes down to experience and how much you trust the students.
Of course it is not “us and them”. Without mentors there are very few teams that could function (mine included). Mentors are certainly a part of the team. But should the mentors design a robot? I am still going to stand by my opinion that mentors should be teaching students how to design a robot, not designing one.
Mentor: an experienced and trusted adviser
That’s the dictionary definition of a mentor. An advisor. Not someone who does something for you.
FIRST website: Volunteer professional mentors lend their time and talents to guide each team.
They are guiding the team, not doing a bunch of things for the team.
And none of this excludes a mentor from being a part of the team. They still very much are a large part of the team if they follow this philosophy. They pour in tons of time and make sure everyone is safe and has a good time. They also put in a ton of hours teaching students about lots of stuff. This makes them a part of the team.
I think the argument would be, what is the best way to inspire (or whatever FIRST’s goal is) students? (which differs for each team, as someone previously said: what works for one team might not work for another)
In my view, mentors act as an enabler for the students. If a student wants to program but has no mechanism, then a mentor made mechanism is fine. If a student wants to learn programming by watching mentors and studying their code, then that’s not completely wrong. However, would it be right to skew competition for your own learning experience? If we all collectively skew competition, it might not matter as much, but then FRC wouldn’t be a highschool aged competition, but an anyone 13+ competition. I think even the ones arguing for how mentor-built is fine also agree that if possible, a high percentage of student made components would be amazing. In general, non-student contribution is “as much as necessary”.
If it comes to a point where you have a 3 point defence bot even with mentor coaching throughout offseason and during the build season, why not join FTC and try to start smaller, and still have the mechanical concepts in mind? Maybe by the time the FTC freshmen are seniors, their new FRC bot can go to worlds. On the other hand, if mentors bring a good bot to an even better bot, then that sounds beneficial for everyone. It doesn’t have to be FRC or nothing. You can even make a bot in the off season with students for practice and show it to your robotics students. Imagine a non student touched Lego League bot. The students can still learn from understanding how the bot works, which aligns with FIRST’s mission. It might not be wrong, but there can be a better way to inspire children.
When I took over the coaching of team 2357 several years ago, I had a very utopian dream of a 100% student run team. In the last 5 years, I’ve learned this is a “shoot for the moon, and maybe you’ll achieve orbit” type of goal (popular saying revised for accuracy)
I want this team to be as student-run as possible, but I also recognize the importance of achievement as it relates to learning and inspiration. This year, when the new mentors asked about how much involvement they should shoot for, I said “I’d like to optimize for maximum learning, inspiration, and achievement, in that order.” That means we are pretty hands-off on the areas we have students who are well trained, and we’re much more hands-on in the areas where the students aren’t quite up to speed. But we always make sure the students are involved in every area, to the extent that they can contribute.
Edit: Thanks to @Karthik for his statement in his video where he says (paraphrasing) “FRC is not a science fair. Mentors shouldn’t be hands off.”
We totally allow our students to run the tormach, the manual mills and lathes, and our CNC router, often times with very little supervision. In my opinion the table saw is a significantly more dangerous machine than any of them.
“We totally allow our students to run the tormach, the manual mills and lathes, and our CNC router, often times with very little supervision. In my opinion the table saw is a significantly more dangerous machine than any of them.”
Also to Karthik’s aside about FRC being different from other high school activities as to the level of adult involvement. I actually have grown to see the similarity between FRC mentors doing things like, say, creating a set of strategic goals, or programming the robot, or CADing a part, and the job a coach does with a basketball or football team. In fact I go by the moniker “head coach” rather than “lead mentor” for this reason. Providing the team with the tools and culture they need to succeed is what I do; how that plays out from year to year is changeable and unimportant.
This is going to offend some people, but if this we’re actually the case we’d see every robot every year actually be competitive. Instead we see countless robots not move in matches and fail to complete any part of the game task. This comes from “mentor built” teams the whole way to “white glove” teams. Building robots is hard.
Unfortunately, you are actually more the exception to the rule when it comes to students. As you’ve stated, you put in the effort in and out of season to learn as much as you can. This is not the case for many many students out there.
FIRST is about learning. Learning doesn’t happen without teaching. We may not have any, but on a moral standpoint I don’t see anything wrong with a mentor taking a more hands-on approach if the student is learning more. At the end of the day, that is what matters.
As for mechanical design, our systems are entirely designed and modeled by students. Before anything is turned into a physical object, we have a design review meeting where our 3 main FRC mentors ask questions about the design while the students talk about it and move about the CAD model. Once they point out potential problems, it is back on the students to take what they learned from the review to solve the problems and bring them up in the next design review. This process is repeated until all glaring problems are resolved.
As for software, our robots are programmed 100% by students with zero review, and this is mostly due to the fact that our only software mentor is unable to come in on a regular basis but he is always willing to discuss anything we have questions about. Luckily, through an incredibly driven student body of bright programmers, we are able to sustain a strong knowledge base and continue to not only put out high-quality software, but also release libraries and tools that are used by other teams such as RoyalVision and the RoyalIterative programming framework.
This is a very narrow-minded view of the roles that mentors can or should play on a team. From the mouth of the founders we known that FIRST is not intended to be a ‘white glove’ type of experience. Why are you relying on a dictionary definition to try to argue otherwise?
I would still like you to articulate why a totally ‘white glove’ approach would be more inspirational to every type of student, and how this would work with teams of all sizes and situations where there might not be any students interested in a particular topic.
As a mentor, I try to emulate the people who were the best mentors to me, within and outside of robotics. One of those is an extremely talented engineer I work with professionally-- I’ve learned more about software development pairing with him than I have with almost anyone else, and that’s an experience I want work with my students to create on our team. For my role on the team, that means a lot of pair CAD and a lot of pair design work. Helping someone grow in technical and soft skills, in my opinion, is often best done with a combination of being “on the dancefloor” and “on the balcony.” It seems to be working alright for the students I’m working with now, but I’ve accepted that my role will probably change over time, depending on what the students and team need from me.
The founders of FIRST, Dean and Woody, have clearly laid out what they think FIRST should be. One of the beauties of FIRST is that you don’t need to follow their vision.
However, as a mentor I can unequivocally state that if a program requires me to donate my expertise, time away from my family, and vacation time from work there better be something in it for me. I love teaching - but I also love doing. I suspect many other mentors feel the same.
Keep that in mind before you decide the right direction is to cut mentors out of the design, engineering, and programming process. FIRST is designed as a partnership. There are no hard lines drawn in the sand. Your opinion is fine, but it doesn’t (and shouldn’t) hold true for all other teams in FIRST.
If some dynamic on your team has caused you to feel this way, I suggest you talk with your mentors about how you feel. Perhaps they can improve the environment for you.
Thanks you for sharing your opinion. The way you want to run your team is good one. The way I run my team is a good one as well. Please, continue to do what you do and I will do the same. Don’t let your opinion color the work I and my mentors do, or what my kids do. Best of luck to you.
Last year, my team showed up to our first event with nothing but a drivetrain. We left with a mid/low tier switch arm on top of it. A combination of poor team organization and lack of CAD experience meant we couldn’t field the best robot we could, and certainly not the one we wanted. The season ended with pretty much the entire team discouraged and frustrated.
Everything I do as a mentor on this team this year stems from the unwillingness to allow that to happen again. So, yes, except for the single student who took the opportunity to learn more about CAD when I presented it in the preseason, we do have mentors who do CAD for the team. We don’t do ALL of it, and we make sure that whatever we do is explained and communicated to the students so they can learn more.
On the other hand, the programming students have been operating on little, if any, mentor intervention. They know enough about what they’re doing to not need much help. I think it’s important to dispel the idea of “black or white” thinking in terms of mentor involvement. At the end of the day, how involved I am depends on the specific student and the situation. There are times where my doing something for you is the most effective way to both teach you and get done what needs to get done. Other times, the student is perfectly fine without my help. Other times still, it’s somewhere in the middle.
Our lead mentor’s philosophy is basically to leave us alone unless something is dangerous or we need his help. This has, in my opinion, been fantastic for the growth of our team. All of us know how the robot works and how it behaves. We also don’t believe in mentor drive coaches. I’m a junior and I’m going into my second year as our drive coach. Without our mentor, we wouldn’t have a team. But, we students handle 90% of everything that goes into the robot. That, I think, has been the key to our success.
That’s awesome for your team, but all teams aren’t the same. Don’t put a value judgement on how other teams operate.
And the guarding on said mill. Our students run our machines (both CNC and manual) too, under supervision (as in, we watch long enough to make sure they don’t screw up too badly, once we have some confidence in their abilities).
First of all, did we really have to bring this up again?
I am on one of those teams that is always called mentor built, and I am always disappointed when I see a thread like this one. People come up to my team all of the time in the pits, and call us mentor built, and I find that insulting. Just because we consistently make good robots does not mean that the mentors build are robot (which would not be a problem if they did, but they don’t). Last year I probably put in way over 50 hours into CAD, as did many other people on my team, and the mentors barely did any CAD work.
To answer the question of this thread, I would say that my teams mentors help with strategy analysis, and ideas for our robot, along with providing guidance while we design our robot. No decision is made without a discussion between students and mentors. Our mentors will sometimes help out in CAD when we are in a time crunch, but the students do the vast majority of the work. Our programing mentors will help when there is something that needs debugging that our programers can’t figure out.
I think we should start a thread of COTs verses No COTS robots. We could include software libraries in the discussion.