Mentor coded robots

FIRST General Forum
#1

THIS POST IS FOR DISCUSSION AND NOT AN ACCUSATION NOR INTENDED TO BE POINTED TOWARDS ANY INDIVIDUAL OR TEAM

There’s a lot of talk on CD about mentor-built robots. But something I see discussed a lot less in mentor-coded robots. While the two are similar concepts and overlap in some regards, a team could have one without having another.

Mentor-coded robots are presumably harder to see: lots of teams are accused of being mentor-built because the casual observer notices the difference in quality of the design and fabrication of physical parts, but a mentor-coded robot would be much harder to notice. The result of code is often agnostic of it’s actual design and implementation. There’s rarely an obvious indication as to what language a team is using, whether they are using command base or iterative (or their own approach). Perhaps a vision system shows itself via the presence of a coprocessor on the robot, but that does little to show how it is actually coded.

Which of these cases would you consider to be a mentor-coded robot? Some quite obviously are, others are much more questionable and I hope to provoke discussion around them.

  1. A mentor writes, commits, and pushes the code for a subsystem.

  2. A mentor writes an interface in the team’s code, which students write implementations for.

  3. A mentor writes a library which is publically published and documented on GitHub. Students on another team use this library.

  4. A mentor writes a library which is publically published and documented on GitHub. Students on the mentor’s team use this library.

  5. A mentor writes a library which is publically published and documented on GitHub. Students on another team request features for this library over Chief Delphi, which the mentor accepts.

  6. A mentor writes a library which is publically published and documented on GitHub. Students on the mentor’s team request features for this library over Chief Delphi, which the mentor accepts.

  7. A mentor writes a library which is publically published and documented on GitHub. Students on another team request features for this library over Chief Delphi, which the mentor rejects. Students on the mentor’s team request features for this library over Chief Delphi, which the mentor accepts.

  8. A mentor writes a library which is privately given out to a few teams.

  9. A mentor writes a library which is privately given out to a few teams. These teams request features and the mentor honors those requests.

  10. A mentor plays the role of scrum master for a team.

  11. A mentor designs a subsystem or command which a student implements.

  12. A mentor tells a student, line by line, what code to write. The mentor’s hands never touch the keyboard.

  13. A mentor provides a student with code examples from a personal project, which the student independently adapts for the robot code.

It feels weird to be putting this out on CD, I hope it doesn’t spark too much controversy but rather interesting discussion. As a newly graduated student, it’s personally interesting to me and I think others will find it so as well.

EDIT: I’m not looking to set out some specific rules that every team must / ought to follow. I just want to see what everybody thinks about something that is rarely discussed.

#2

The mission of FIRST® is to inspire young people to be science and technology leaders and innovators, by engaging them in exciting mentor-based programs that build science, engineering, and technology skills, that inspire innovation, and that foster well-rounded life capabilities including self-confidence, communication, and leadership.

Mentor shaming is lame.

1 Like
#3

I’m not intending to shame mentors. I’m just wondering if there’s a point where mentor involvement becomes more harmful than helpful.

#4

They all are to one degree or another.

#5

My responses in bold.

What works for one team is not what works for every team.

Heck, on my team - what works for one student does not work for a different student. Sometimes I can let a kid go wild with minimal supervision, sometimes I have to prompt for every keystroke, sometimes the problem is way over the students and I have to step in.

1 Like
#6

Maybe, just maybe, it depends on what is best for the team and that blanket rules limit the effectiveness of mentors in supporting their teans

#7

For consideration: http://www.theconstructsim.com/smoothing-the-robotics-learning-curve/?cs-explain=off

I found a lot of points made in the article very applicable to the FRC season:

  • Teams are trying to program for a robot that doesn’t exist yet, and in many cases isn’t complete until they actually get to competition.
  • Concepts like vision tracking, PID tuning, auto, etc are complex. Just look at how many teams don’t even drive forward in auto each year to get a few easy points to see how complicated this stuff actually is, even if so many other teams make it look easy.
  • Documentation is an interesting thing. I can read the official documentation easily enough and figure it out, but give a rookie that’s never programmed before the same documentation, and they’ll be lost.

So it really comes down to how a team trains their programmers. That process can look very different from one team to another, and it may incorporate some or all of the OP’s points at one time or another without actually being “mentor coded”.

#8

Yes it is. It’s intended to draw an arbitrary line about mentor involvement and then point at people deemed to be on the other side of it and think of them as somehow lesser.

Katie hit the proverbial nail.

#9

The best way to learn programming is to work with someone who already knows how to program. The most valuable experience I had while a student was being able to program next to 2 professional software developers.

That being said, if a team only has one student interested in programming and is just learning, it would behoove the mentors to step in and program the robot as to allow for them to compete.

1 Like
#10

The intent is admirable! Still, the title/examples in the post inherently lead to line-drawing, in a space where it has been well established that the line must vary team-to-team. This area tends to cause some pretty aggressive emotions to come out, so it’s best to tread with caution.

The way I would have gotten the same info is to pose a question along the lines of “How do top-performing teams engage software students in developing high-quality software?” This could help extract best practices without creating division.

#11

My team of about 10 students had 4 kids “interested” in programming in 2018, and this past year had 2 kids who were actually able to program parts of the robot. With our team size we had most of the robot coded by our only programming mentor.

Going into 2019 we will have 3-4 programming mentors and hopefully 5 students who can code our robot.

Different circumstances warrant different actions, but the founding principles of FIRST were to have industry professionals working with students. We take our mentorship roles very seriously, even when we have to do much of the heavy lifting.

#12

Quite a few times, I have seen mentors from one team working with a different team on the Practice Day at a Regional to build their robot or write some or all of their code. Since the goal of this program is to inspire the students, allowing enough flexibility for things like this to happen is crucial.

#13

3946’s philosophy with coding is the same as with the strategy, design, mechanical, controls, marketing, and scouting aspects of the team - we give the students as much control as they’re ready for, and the mentors back fill the rest, with at least an attempt at transferring knowledge to one or more students.

I don’t think we’ve ever had mentors writing huge swaths of code, but the coding mentor has been responsible for organization and management more often than not. This coming year, our programming mentor Eric is planning to do the lesson planning, but have our lead student programmer Chris teach the coding class and do much of the design and tasking for programming during build season. This should free Eric up to spend some time on project management of the whole team and work with the strategy group as well.

Our focus is on inspiring and developing our team members (and the team as a whole), not adherence to an org chart or position descriptions.

#14

This is the lame Mentor-Built™ variant of “I’m not ___ but (blatantly ___ statement)”

If you don’t intend to do a thing, don’t do the thing.

#15

They’re no harder to see than mentor-built robots.

If you’re making presumptions that the way something looks or the way it performs correlates with the type of people who produced it, you’re doing yourself and your peers a tremendous disservice.

#16

This year at CNY, there was a heavy snowstorm, and some teams couldn’t bring their students out. During practice day, there were teams who had no students, only a few mentors due to school policies. Now what do you expect the mentors to do, wait and not adjust auto code based on the real field measurements, resulting in broken autos for their comp, or successfully adjust autos and be set for competition day, but be labeled a mentor-coded robot?

Flexibility is key.

#17

Students didn’t build the RoboRio, the Talon SRXs or the Xbox controllers used to drive the robot. We give these tools to the students to empower them so they can accomplish their goals, learn new things and have new experiences. Sure giving the students a Talon SRX may not teach them what they could from designing a custom H-Bridge motor controller but that’s not the goal of the program and more than likely would end up causing a whole lot of frustration. Frustration and limitations are not a good way to inspire students.

As mentors we too are tools to empower students. If that means that a mentor needs to write your robot’s code then so be it.

#18

Well $@#$@#$@#$@# me I guess

#19

Sorry you aren’t getting a lot of useful replies.
The statement that each teams needs to do what is right for them is a good start, what does that mean? How do you figure out what’s right?

I think there is a point where certain levels of mentor involvement can hurt the team and the development of students. If a team has student programmers fully capable and willing to code the robot but a mentor does the work anyway then I think that is more harmful than helpful. If a team had students willing to do the work but they did not have the knowledge and a capable mentor did not assist them, then I think that level of mentor involvement is also harmful. It comes down to a balance of who has the knowledge/time to complete the tasks and can they teach while doing so.

For a long time my team did not have an active dedicated programming mentor and it was up to the more experienced students to teach everything to the newer students. At the same time we had one mentor capable of designing the robot but we did not have the means to teach students CAD and allow them to be more hands on in the design. We have since evolved to have more mentors and students involved with both programming and design of the robot. The more variety and depth a team can offer it’s students the better.

#20

The line between student and mentor programmed should be drawn where the student starts to get less out of FIRST.

Different kids need different amounts out of robotics. Some need to be shown how cool coding can be, which would be more mentor programmed. Other students might need to be taught a language. Some need to be taught different algorithms (PID, filters, sensor sampling). Each year is different, and each student is different.

This past year, I never touched the robot code. I helped with configuring the Jetson, but honestly the student programmer did 90% of it. Other years I wrote nearly everything. At the end of the day I want the students to take something away from robotics, while still enjoying it.