Mentor coded robots

FIRST General Forum
#21

Yes. Please stop inspiring roboteers to achieve higher levels of programming with your libraries, better build systems, etc.

:rolleyes:

Software engineering today is driven by reuse of common libraries and code. If you look at why programming languages become “popular” very little of it is the syntax of the language but it’s around the Library that is used.

Like “Hey, lets use Ruby, we can build a webserver in three lines!” Why yes, after including in 5,000 lines of libraries, all it takes is three lines of code.

Hampering teams by not being able to leverage libraries, mentors or code gurus like Jaci is just $@#$@#$@#$@#

#22

Talk to your team, see what everyone is comfortable with. Figure out what the teams’ overall goals are and try to set up a situation that most closely aligns with it, or at least builds up to it over a few years. Then do trial and error. Run things one way, and afterwards review it. If it went well, keep it up. Iterate on the details that can be improved upon and keep moving forwards. If it didn’t go well, re-evaluate and try something in the other direction.

Figuring out what’s best for your team isn’t something anyone else can tell you, but it’s not that hard to figure out. Try things over and over again until you find your sweet spot. The offseason is great for this!

#23

As Marshall talked about: do not look for some threshold of effort where ‘good’ switches to ‘bad.’ This does not exist.

This is not a question of degree, but a question of approach. There are numerous situations where it is appropriate for a mentor to write some or all of the final code for a robot. On the other hand there is no situation in which an adult should take work away from a student that the student is willing and able to complete.

Example:
Team A has no current students interested in programming, so a mentor writes all robot code so the team’s other students can have a fulfilling season. Team B has five capable students who have programmed before and attend most meetings, but an adult muscles the students out and writes the code with no input from the students because ‘the students will make mistakes.’

In both examples an adult programmed the robot completely. No reasonable person would find fault with Team A, while Team B operated contrary to the core principles of FIRST. Team B has an dysfunctional adult team member, not a mentor. Mentors writing code (or designing parts, or building, or fundraising, or doing outreach, or… pick anything a team could do) is just great as long as each and every student is involved in the area(s) of their interest and to the degree of their growing abilities enables.

#24

But be aware that the sweet spot may not stay in the same place from year to year. Students come in green, develop, then graduate. Each class and each student within each class has distinct abilities and interests and drive.

Some students start out with little promise then suddenly start to click, where others start strong then drop out, and others are a nice steady increase year over year*. During build and competition season, sometimes a week is too long between adjustments.

  • On a team with only 20 students, we had several instances of each this year.
#25

Every team is using an FPGA that was written by engineers, therefore every team is using a mentor coded robot.

Those white gloves have a dirty liner!

#26

How dare you ruin FIRST by helping hundreds of teams across the world‽

Unrelated, suppose a team has 40 kids who only want to play with metal and build a robot, with no ability or desire to program. Do they have a better experience struggling to program a robot that won’t function at their event(s), or having a mentor program the robot for them?

Unrelated(?), suppose a team has 40 kids who only want to play with computers and program a robot, with no ability or desire to build a robot. Do they have a better experience struggling to build a robot that won’t function at their event(s), or having a mentor build the robot for them?

(Hint: in both cases the answer probably depends on those 40 kids)

#27

Some years ago, back when we still used the IFI system and serial ports, a particular mentor (NASA mentor, to be exact at the time) coded a serial interface to work with various things.
My understanding is that even other software mentors got tripped up by trying to understand that one on occasion… but if you just used it and implemented it properly, it worked, even if you were a student.

All of the examples given are just fine, with the caveat that the kids need to be inspired, EXCEPT #7. And #7 would be fine if it was stated up front that outside feature requests would not be accepted (because the code is for this particular team, and published to comply with the rules).

#28

Agreed!

But the reality is that there is and always will be a mentor involvement line and a perception that someone will take issue with…like I’ve learned, stop wasting your energy. The real question for each team is who is drawing the line. Woodie has perhaps the best description when he calls classes “training” and what you do with it outside of school the “education”. If a mentor draws the line out of need it’s “training”…if students draw the line out of inspiration and confidence it becomes “education”. I think most teams do a very effect job of drawing and re-drawing that meandering mentor involvement line through all activities and seasons. Rookie and re-developing teams need far more training and mentor involvement. I also believe the strongest and most sustainable teams have lines mostly drawn by the students, with the ability and confidence to seek and deploy technology and designs generated by their mentors, other team mentors, other team students, robotics suppliers and industry.

I’ve observed mentor and minion teams perform well sporadically, but are rarely sustainable, so the perceived problem for many is mostly self correcting.

We know where our line is, and the students can articulate where it is and why it is there. Results speak for themselves.

#29

I think it starts with understanding what it will take to FIRST-style “Inspire” the students currently on the team that year. What tools will they most need for success?

Yes, sometimes that toolset is a fully-written piece of software. Yes, sometimes that toolset is a vaccuum for students to fill. Moreoften, that toolset is something in between.

Executing on and delivering the toolset is the job of a software engineer. Determining the toolset required is the job of a leader.

I propose this is more of a topic of general leadership technique, and not of software mentorship.

Unfortunately, my knowledge of successful leadership is far smaller than successful software writing.

#30

I don’t have much of an opinion on this, but IMO, this is kind of a cop-out. The fact is, tons of teams don’t work and don’t self-manage very well, especially if a mentor is overbearing. Shy kids have trouble standing up for themselves.
Different things work for different teams, but that doesn’t mean that every team works.

#31

Your response sounds more like a cop-out, but to each their own

#32

I had an edit lined up but didn’t send… sorry.
My ultimate point was that whenever people say “different things work for different teams”, it’s really just glossing over the fact that lots of teams don’t work well. Giving mentors too much power can often result in overbearing, controlling adults. Kids are generally too spooked to do anything in these situations.
I like the things that mentor-student cooperation enables in terms of competitiveness and gameplay, but I wouldn’t implement mentor-built stuff on a team I am a part of. For every successful case of mentor involvement, there’s another two teams that are held back by the same.
My favorite mentor, and the one I feel has had the most impact on my life, was Ted Shinta on 115, who always takes a hands-off approach and leaves everything up to the students. He welcomes any and all questions, but makes no move to ever force a solution on students, and flat-out refuses to do more than help construct the field. That may not be the “ideal mentor” to some folks, but for me it was a blessing in a team that was often troubled by interpersonal conflicts.

#33

I mean sure, valid. But without knowing the nitty-gritty of a team’s situation, its hard to call it as an outsider which is why my answer is “whatever works for your team.”

The problem with the “mentor built” argument is that you rarely know the whole story. I err on the bright side and like to assume that teams are trying to do what they think is best for the students.

#34

Or the problem is way over the mentors and the students have to step in. These two can happen on the same team depending on the problem of the day. Or if this doesn’t happen, at least it could be a possible team goal to get to into that situation some day. Or maybe not. What works for one team is not what works for every team.

#35

Yes. This program was never meant to be a strict “union shop”.

#36

There are also totally student run teams that do work well and student run teams that don’t work well.

Early in my FRC career, I was involved with two student run teams where the student leadership became overbearing and it was not an inspiring experience for the other students. Unfortunately, the people running the teams wanted to allow the students to be able to do whatever they wanted, no matter the consequences. They have both since collapsed.

#37

[sarcasm]
Well I assume no team uses COTS parts that contain software written by current mentors or professionals.

Like say the RoboRio, PDP, ESC, any embedded vision systems, NavX…

[/sarcasm]

There is a team in MAR that had code for their cRIO that could run even if there was major packet loss but not quite enough to get disabled. I know how that code got there and I did not write it. They were better off for it and if more people figured that out a bunch of robots with cameras set a little over the recommended settings would have performed better.

As CSA I try not to write code for teams. I can but if they have no code it is time for them to get help from other students.

As mentor I wrote most of the robot code in 1997. In fairness no one had a PC except me despite our best effort. My laptop 20 years ago was $4,000.

I have written maybe 10 lines since 2000 that are in Team 11’s robot code. I do write code for my own FRC chassis that never compete and that code rarely is shown to any FRC team.

I also write code for FLL stuff: but I judge FLL not coach or mentor it.

There are 2 COTS products in FRC that have code contributions from me.

When I do challenge students, say with another robot mentor built, they often react as though it is me trying to prove them wrong. If students think these other teams won’t do that on their own - reality is coming. If, as a mentor I can’t touch your code and you don’t listen to my feedback, what better tool then to show you proof of what can be done before you are paying money to find out on a field?

Part of life is learning you need to up your game. Discussions like these loose their value when so many people see robots in 3 days then those designs reappear.

#38

As the student who effectively transitioned my own team from mentor coded (literally my first year one of the mentors did the entire code) to an entirely student coded robot this post caught my eye. Warning this post is largely a ramble so stop reading now unless you just feel like it. First I agree that mentor shaming is bad and therefor I do not want my response here to be construed as such. Second, I learned how to program from a professional software developer and that knowledge helped me a great deal in my college career so far and I am sure I will continue to tap from it. (Note I am a mechanical engineering student). So for my real response: Personally, as the mentor who became “in charge” of the programming team somehow (despite the fact that 2 other mentors are professionals in the software world), having a student who I knew was capable of troubleshooting mostly by himself was a huge relief to me because it meant that I could go help other teams, go scout, go to the bathroom, take my time eating lunch, ect and I was not concerned about “what if they need me in the pit” they probably didn’t.

#39

Alright, time for some shameless self-plugging.

My first FRC season is STEAMworks. Our team by about week three or four had two students dedicated to working on the code. One of those students also happened to be the human player and had never programmed an FRC robot before. The other student was me. I ended I put spending more hours than I care to count trying to figure out what in the world I was doing.

Fast forward to Power Up. I am now the programming (and scouting) lead, programming a good majority of the robot, creating a number of varying autonomous routines, debugging, adapting, creating on the fly. How did this happen?

It didn’t happen from sitting there, staring at hundreds and hundreds of lines of code for hours on end, reading documentation after documentation with zero clue what to look for. It happened because I had two wonderful mentors who are professional software engineers step in.

Did these mentors end up writing some code? Yes.
Does that mean our robots have been “mentor-coded” (in the colloquial sense)? No.

Had those mentors not stepped in, both helping me figure out what I’m doing and fixing the more complicated areas of FRC robot programming, neither myself nor my team would be where we are today.

I know your intent here isn’t to shame mentors, but unfortunately this is Chief Delphi. People are going to assume you’re shaming mentors. Intent does not necessarily correlate with the response to the execution.

Some may argue that mentors should be completely hands-off. If that were the case, I would not be as good of a programmer as I am today.

FIRST is intended to be mentors and students working side-by-side so that the students can learn real-world skills, how to be engineers, and gain everything they can from the program. Students struggling with a hunk of metal expected to “figure it out” with no outside help isn’t anything like the real world (Google and coworkers are a thing, after all)*.

TL;DR Mentors are necessary to provide the best experience for students, even if that means the mentors must step in to assist or write/fix more complicated sections of the code.

*Take this statement with a grain of salt. I’m still a college student, I’m just relaying what I have gathered from the experience of others. :slight_smile:

#40

Personally, this thread is a dumpster fire but I feel compelled to try to extinguish the flames.

Is this mentor shaming? Yep.

The connotation here is that this is a student program, therefore the students must do all the work.

Let me ask you, the first time you sat in math class and learned about quadratic equations and the quadratic formula… Likely one of (if not the) most complicated math formulas to date. Did a teacher explain it to you? Help you know when to use it? Give you an example? Many examples? Did you learn how to use it?

Yes so far…

Do you need a teacher to walk you through it still? Can you do it perfectly, free of errors, every time, 100% of the time?

Probably no here. (Honestly, you never forgot the ±, not even once?)

Now take that same example, and lets talk about programming in FRC, not taught by a teacher, but lead by a mentor.

— Same Thing —

Our rookie year, before I was a mentor I was just a parent of a team member. We didn’t have separate groups, but we did have one kid who was going to program it (not mine). Supposedly he was going to get help from a local college student. (College student got buried in classwork and disappeared.)

Eventually he was handed a book halfway through build season: Learn C++ in 24 hours.

:eek: :eek: :eek:

As a programmer I offered to help – we both learned how to program the robot that year (for good or for bad), and yes, he wrote some code, and I wrote a lot of code. But he learned a lot from his experience. (As did I…)

The next year, we had a programming team, and the student from last year helping teach the incoming students. 2nd year team, did I write some code? Yep. I rewrote CameraServer because it broke in horrible ways with more than one camera. As I recall, “git blame” had me down for about 15% of the code besides that.

Third year, our original programmer is off to college - to study Computer Science (in part b/c of his FIRST experience). Programming team learns code/WPILib in Sept-Nov, a refined set of lessons from the year before, more structured now. Did I write code this year? Yes, I wrote the code to make sure the Tegra board always keeps the CV code running. (A few lines in rc.local, and a small shell script). I also tweaked some constants at competition, and fixed some math functions. (Order of operations in code != in math.) Total git blame this year - a few dozen lines.

This coming year, our programming team might be smaller. Will I write code? If I have to. Would I rather teach the students and help them write the code, you betcha.

My point? We all have to learn. We didn’t get dropped into FRC already knowing how to code, how to build, how to drive a bot. As a mentor I’m here to help my students navigate the challenge FIRST puts before us, to help them learn, and to grow, and to be excited and challenged. I’m also here to catch them when they stumble, or take a wrong path. Putting a broken robot on the field is not inspiring, be it mechanically, or progmatically. If my students ask, and the situation requires it, I will jump into the IDE and code. Every. Time. And I will teach them as I do it.

We can learn from failure, but letting students fail, and not helping pick up the pieces because “mentor coded” is “bad”, isn’t inspiring, it’s cruel.

#StopMentorShaming

1 Like