I believe it is uncommon to hear rumours of other teams being supposedly too mentor-dictated or involved. What are the norms in your team or past teams you’ve been in?
For example, if a program is buggy, would a mentor debug? Would your mentors be brainstorming mechanisms, or mostly comment and raise suggestions on student designs? How much would your mentors be touching the CAD or program? What extent do you think is fine for mentors to contribute?
Uncommon, or common? (Rumors with a basis tend to be uncommon; without a basis are all too common.)
Anyways, on to the actual question: As much as necessary. So we’ll brainstorm with the students, question their designs, and otherwise make sure there’s a design that can work. We’ll build with them as necessary (one or two tools are mentor-only due to safety issues), CAD with them, and otherwise help them out.
However, one thing we try to make sure is that the students are the ones driving the design, strategy, build, and other things. We tend to function more as enablers than as do-ers.
I live by the philosophy that students should make and build the entire robot.
My view on mentor involvement in design is fairly simple, students should be able to use our larger knowledge base (with respect to designing robots) but at their discretion. Our team is fairly student run (as in lead mentors will only step in if there is a major issue that needs adult attention), so it follows that our design process should also be student lead. I think that teams with more student leaders and experience with design should have the mentors take a bit more of a step back, allowing the student leaders to do their work, while on less experienced teams (especially new teams, or those with large turnover) it becomes a lot more important for students to take into account mentor input seeing as they won’t have much.
While FIRST is all about students learning, that doesn’t mean they can’t have help. If FIRST was solely about students doing 100% of the work then why does FIRST have the Woodie Flowers award or encourage mentors at all? It is because they recognize that for teams to function and students to have a good experience there has to be mentors.
Now, specifically to CAD and the programs. IMO mentors should not be making any portion of the CAD or programs. Their role should be reviewing the code/CAD and giving suggestions to improve it along the way. There are cases where students do not know how to do something, and in that case I see it as fitting for a mentor to either direct them to an online resource they know of, or create an example. By example, I mean that it should not be something they can copy & paste, but more of an overview of how something is done.
A good example of this is where I went out and dug through the WPILib code to figure out if it was possible to have multiple USB camera inputs and have a single stream to the dashboard that was switched, and then gave the students breadcrumbs to lead them to a method to do it.
You let students touch the robot?! How does it get finished on time?!
In an ideal world, I don’t have to touch CAD aside from reviewing and approving, however, we step in as much as needed. All teams and all situations are different. My goal is to teach a kid enough that I don’t have to step in.
For example, last season I had to do 100% of CAD. In the off season we tried getting kids interested, and now I have a least two students who helped me with the intake and other robot geometry.
Additionally, our robot design was chosen using a process I taught the kids. I taught them enough that I felt comfortable stepping back from the decision making process, and it led to what I believe is a smart design and strategy for our team’s capabilities, almost 100% decided upon by the students.
Today I did the important task of taking screws out of old wheels, leaving the students to do menial stuff like all the CAD, all the CNC, practice robot assembly, vision programming, drive practice and coaching, and other such boring jobs.
While the above is true, my real answer is that our team culture is such that mentors and coaches like myself are the support structure, and we mostly advise, supervise, and purchase materials. I haven’t touched the CAD this year, though I would if I need to,and I’m glad that option exists, unlike other organizations like BEST, where all I can do is smile and nod at bad ideas.
The thing about CAD and programming is, they aren’t something you can just learn in a day.
Last year we had two students that did a lot of CAD. One of them graduated and the other one isn’t there as much as last year. This year, we have around 4 students learning how to CAD. Most of what they make is practice and I don’t think anything they’ve CADed has been a huge part of the robot.
We also don’t have many people programming the robot. In fact, it’s just me and a mentor. Before I was on the team, we had a student programmer that was actively messing with the robot code but usually there isn’t more than one. This year, I’ve been the only one to touch the robot code while the mentor messes with vision on a coprocessor.
Most of our student work goes to machining parts and assembling the robot and parts of the field but when students take interest in CAD or programming and show up often enough, they can get into it pretty quick.
As a mentor, I try to identify problems the students will encounter and warn them about them, because often especially newer students lack the ability to evaluate the downsides of their opinions/choices. I also try to point out when the students designs don’t meet the priorities they set. However, I strongly believe the students should make all the final design, priority, and programming decisions. I think the students get the most out of the program when the robot is solely theirs.
However, I’ve heard other teams have different systems that work well for them. So do whatever seems right for your team. The crucial point in my opinion is that you optimize for student learning and student experience not for how good the robot is.
Completely agreed, some team dynamics mean that student learning and experience has mentors stepping in more than it would on another team.
@EricH I’d be interested to know what tools are considered “mentor only” on your team and who makes that decision (team as a whole, mentors, insurance, school, students, parents)?
Mentors are embedded in every aspect of the team. We are a student led team that values the mentors and the knowledge/skill sets that they bring to the team. I believe it would be a colossal mistake to leave mentors out of the processes and decision making on the team.
But, I guess I could have them stand on the sidelines and make certain that tools are safely operated 
. Oh wait, my students work with the mentors on the safety team as well. I guess they can all go home.
How does it tend to be in your team?
103 has a similar policy with the table saw in our shop. It’s something that, if not used properly, could cause serious injuries. I’ve seen more injuries and destruction from table saw usage, both in our shop and other places, that I’m fine with being in the firing line while a student receives on the less dangerous back end of the machine.
This decision was made years ago, before I was even on the team, and it’s stuck around for what I think is good reason. There is a door behind the saw that leads into the hallway that has more dents and divets in it than any other in the entire district, all from that table saw. I’m pretty sure the glass window on the door has been replaced multiple times as well.
This all could be said for a lot of the equipment in the shop, but the table saw is just less predictable and kick prone than other equipment. With the correct usage it shouldn’t cause problem, but our students, despite all the training we do, don’t always do things by the books.
Sorry, you can’t tell people the “right way” to run their teams. There’s nothing wrong with a mentor designed anything.
The students still haven’t taught me how to CAD, so they have to do it all. They do let me tell them about robots we built in years past, some of which worked well, while others did not. This leads to some fun discussions about what might be better ways to build the new robot. They also let me make a few parts at home, on my mill. But the students make most of the parts, and they have to figure out how to make it all fit together. We have a pretty good “team” thing going, we don’t seem to worry about who is doing what.
Most of the time I was with 3946, mentors were significantly involved in the engineering side of design (Hobson and Larry, then later me), and in the architecture of the programming (Jeff and later Eric). Students would drive the requirements and brainstorming and strategy and do most of the building and (as far as I am aware) all of the programming. Except for STRONGHOLD, I think at least one subsystem on each robot was designed and its build coordinated by a student. How much mentor input was there in any given year? What @EricH said: as much as necessary. We would always encourage students to fill every role, with mentors there to fill the gaps when needed and provide a voice of experience when the students rose to the challenge.
I can see how that’s true, as there is no direct correlation between “mentor designed” and FIRST’s mission itself. Maybe more students can even be inspired by strong designs to reach out more on their own and take initiative if they do not already.
I miss the dead horse thing. Still, I’m glad no one has yet said that mentors should wear white gloves
The thread’s only 4 hours old; give it some time.