Mentor/Student Involvement Philosophies

[Jon Stratis]

Originally Posted by Libby K

Another example we're working through right now - we're having a programming problem, and I want it fixed yesterday so our drivers can practice. One of our mentors knows how to fix it, so am I just going to let the students flounder around the issue and waste precious build season time? Of course not - that doesn't help anyone. We fix the issue immediately, and then the mentor who knew the solution spends the time to teach the students how he got around it (after the robot's functional, because ain't nobody got time for that right now).

We've done something similar with our coding this year. In order to get driver practice going as early as possible, we had a compiled "mentor code" jar and an associated script on the roboRIO that would let us swap in code one of the mentors wrote for driver practice, then go back to the student written code while the programming team was working. This way, we could easily drive the robot when needed so the drive team could be successful, while still allowing the programming team to tackle and overcome the challenge of doing the work themselves (with mentor assistance, of course).

In another incident, we were having a horrible time two years ago getting the built in PID controller to control our arm and stop oscillating. After several hours of banging our heads against the wall, I stepped in and wrote a quick controller we could use instead, and that would be much more intuitive for the students to tune. Then when the programming team had to be hands off the robot for a bit, I spent a solid half hour teaching them with a white board how the controller works and how I came up with it. Like you said, sometimes you just need to get things working, as a team, and worry about the education portion of things a little later.