For Mentors Only: Inspiring Youth
 

Sometimes, I think a small rubber mallet would be just the thing...

Mentor: Why don't you program 127 speed as a special case -- your driving code takes too long to return to stop when the user just lets go of the joystick.

Student: NO! If I write the code to handle all cases properly, it should handle that, too.

Mentor: The acceleration curves look good, except when the driver wants to stop dead. Why not program 127 as a special case?

Student: NO SPECIAL CASES! That's a hack. I want to do it right.

Mentor: We have to ship the robot in two weeks. Don't you think you should just call this a win and program the aiming algorithm? I think three weeks on the driving code is enough.

Student: NO! I know what's wrong -- just one more change!

Mentor: Just program 127 as a special case, and let's hook up the camera.

Student: NO! I know I can do it!

etc.

Kind of makes me think I should take up bull riding instead.

Any other instructional student/mentor interactions?

Re: For Mentors Only: Inspiring Youth
 

you mean "motivation"? we have one of those. we also have two larger ones called "inspiration" and "respect".

here on 1369, we mentors have been using The George Wallace Method (named after it's creator, George Wallace); simply put, you use frequent, random beatings and verbal abuse to keep students in line.*






*just kidding. we don't beat the students to keep them in line. we just beat them for fun.

Re: For Mentors Only: Inspiring Youth
 

I know this is supposed to be for mentors only, but I have to say this sounds a lot like a typical conversation with myself! :D :rolleyes:

Re: For Mentors Only: Inspiring Youth
 

I am a rookie mentor, but I will say one thing: SPIRIT.

Ain't no way to get this job done - not to mention have ANY fun at all - if people don't pull together. The FIRST manuals on building the robot are exhaustive, but there ought to be a Project Management pack to help inspire and organize the team crews and balance the flow of ego. It's almost as though if you are not actively involved in building the bot, you rate, well, less.

Yes, I know. It's First ROBOTICS, not FIRST, um, T-Shirt. Still, a quick look at Autodesk Streamline shows you how the hierarchy of a project flattens out--the sum is greater than its parts, etc. That's what I think we need to remind ourselves.

Team leaders and mentors have to work to get this message across. I think that you gotta do EVERYTHING to maintain a team atmosphere. Make sure that you start right away with sprit-building stuff like choosing a team name, logo design, getting t-shirts and logo-stickers and slogans onto anything that moves. Make NOISE. Choose a theme song. Be nuts!

Your project manager has to be an absolute MANIAC for teamwork. He has to make EVERYONE feel valued, right down to the kid who letters the safety signs. An "I can do it myself" Type-A personality may get the job done, but he/she will alienate most of the team before the first week is out.

I'd be glad to hear what y'all think.

Re: For Mentors Only: Inspiring Youth
 

I've been all too guilty of that one plenty of times. Heh. It's interesting to see it from a mentor's point of vew... Good idea for a thread.

(I know this thread's for mentors only but eh...)

Re: For Mentors Only: Inspiring Youth
 

I tell them "Sure, I'll take the blame if we don't get it done or it doesn't work. But that doesn't mean I'll do anything about it."

Is that inspiring? :D

But seriously, I tel students I'll help them but I won't do it for them. And anything I do, I make sur they know what is going on. Because I don't want us getting into the mindset that every time they need something I show up and it magically appears. They actualyl need to know that there are parts suppliers and shipping companies between the web page and me, and that there are hours of machining between inventor models and actual parts. If mentors do too much, they start believing all their designs come with an automatic/instantaneous "export to reality" function, which they most certainly do not.

Re: For Mentors Only: Inspiring Youth
 

Rick,
Each case is different but in a situation like this, it might be best to comprimise. i.e. "We need to get going on the shooter program and we are coming down to ship. How about you work on this problem until 7:00 and then just insert the 127 so the drivers can practice. We can come back to it we have time before ship. Then get the shooter done and we'll see how it goes from there."

Re: For Mentors Only: Inspiring Youth
 

Great topic as this does get to be a difficult balancing act.

This 6 week project is all about deadlines and compromises. Try to be firm with the planned deadlines for major tasks and play it by ear for the lesser ones, as the dependencies quickly determine what can and can't be done.

Do the "must haves' first, then focus on the "nice to haves".

Make the point to the students that if they don't all work together AND to the plan, the robot will NOT get completed with enough time to test that it works (really important to do this before it goes in the box).

I purposely didn't refer to the programming issue because I look at programming the same way as I look at making parts - it ALL has the same deadline and MUST be included in the project planning. There are lots of times I would love to keep working on a mechanism until it was perfect - but if it is not an absolute critical piece, we do the best we can and move on. I suppose knowing how to convince a student to "move on" is what the real problem is in your example.

When deciding to make something "perfect, but late" or "sufficient, and on time" - take sufficient and on time, there is time for improvement later.

Re: For Mentors Only: Inspiring Youth
 

There have been some excellent documents floating around (check white papers) and also at least one championship presentation on the topic of project management. In a perfect world all teams would have some sort of decision making / timeline "system".

That being said, this is less than a perfect world and many decisions for every FIRST team will be judgment calls during the brief build season. If there is a priority list with time limits set during brainstorming that could help. Mentors will almost always have to step in and keep everyone focused on the big picture while they also inspire the learning process. I'm a big fan of Al's approach, which validates the student's desire and moves the project along at the same time.

During my six years in FIRST, I've had several opportunities each season to address groups of students and individuals about project management, timelines, and decisions. I always try to be empathetic, but I'm also always as real as I can be about deadlines and the big picture. Mentoring and teaching can take place in all kinds of ways. What one student needs is not what another student needs. Sometimes a very gifted and intelligent student simply needs to learn that it's time for the project to progress and it is not their decision. Other times it may be appropriate for mentors to allow someone to "run with a ball" and go a little past the team deadline.

In all cases though, it's about respect, responsibility, learning, the big picture, and the final product. No one is perfect and I'm the first one to admit as a teacher that I make mistakes with students every day. In the end, the best we can hope for is that we (mentors and students) learn from our mistakes and grow as people through the process.

Namaste...

Re: For Mentors Only: Inspiring Youth
 

Some of my favorite Mentor/Student conversations:

[Student, 1 minute before a match] I want to make a small change to the code, its only one line
[mentor] we cant change the code now, there is no time to test it before the next match
[student] we dont need to test it - its only one line - I KNOW it will work


[student] My code is not running right, there must be something wrong with the robot controller!" (I call this CS101 syndrome: "My ten line program is giving me the wrong answer, there must be something wrong with the VAX / Mainframe / PC / microprocessor.....")

CS101 version 2.0 [Student] the RC in the robot is blown out, the robot is completely dead!
[mentor] what was the last thing done to the robot?
[student] I made some changes to my SW, recompiled and downloaded, and now the RC hardware has failed.
[mentor] did you try downloading your old code again?
[student] what good will that do? the RC is bad!

the core all these situations is ego. Im not picking on students, because ego is a problem for all new engineers. We have to learn to detach our ego from our work (projects) and accept that we must follow the whole engineering design cycle:

define WHY a new system is needed
define WHAT the new system must do
define HOW the new system will do those things
build a prototype
test the system to ensure it does the WHAT
give the system to the customer (user) to make sure its what they want.

The temptation to jump into a project at one point, and fly by the seat of your pants is overwhelming. For most new engineers, once you have done than, and gotten burned by your own ego, then you really understand the whole design cycle, and why each part is absolutely necessary.

Re: For Mentors Only: Inspiring Youth
 

I have a pet motto I keep trying to remind myself which I think is relevant:


I bet a lot of us (mentors and students) got into this line of work first because we wondered how things work, and stayed in it because we thought "I can make that work better". Thus starts a life-long battle between perfection and time. So far, time is ahead.

Re: For Mentors Only: Inspiring Youth
 

The one thing we've been focused on is prioritizing and time management. It's worked for the most part, but there are always kinks that need to be worked out. Speaking of, 1089 found and developed a great project management script for our team. It's called Dot Project, and it allows you to set up projects with timelined deadlines, assign individuals to a project, track the progress of the project etc.

You can find the software here: http://www.dotproject.net/demo/
Here's the tutorial on how to use it, as well: http://psdam.mit.edu/rise/tutorials/...anagement.html

I sympathize with your post, Rick, I'm sure most mentors do. Just remember, even if they do it the long way, at least they're learning! :D

Re: For Mentors Only: Inspiring Youth
 

"Better is the enemy of Good Enough." I must confess, I have never heard that before, but it is something we should have posted where all can see it. Good one!

Sometimes even the most capable students can't live up to their own estimations of their capabilities. I am of course guilty of this, too, but as we get older and experience more failures, our assessment of our own skills becomes more realistic, or at least more humble. I wish I had the blissful self-confidence of some of our students, even if it is a little delusional. It's all part of the process.

Re: For Mentors Only: Inspiring Youth
 

In my office we call that "analysis paralysis". In addition to using the quote above. Sometimes you can get so focused opn a problem you can't see it clearly anymore. At that point a good engineer will ask for assistance from someone whom is outside the situation and can look at it more objectively.

Sometimes our paradigms blind us from seeing the alternate solution because it is outside our understanding. That is why we never saw the solution that now seems so obviously simple.

Re: For Mentors Only: Inspiring Youth
 

I've had the same experience with our team's students: they want to jump in immediately and do everything (and have it work right the first time). Every year it's a long effort teaching them the virtues of incremental development.

Typical conversation:

Student: Why are we testing trig functions on the bench? Why don't we just write the code and run it on the bot?

Mentor: Because if we test the trig functions (and the gyro, and the camera, and ...) here, we'll know the math is right, so when the bot spirals around randomly instead of doing the right thing, we will have a much better idea of what went wrong.

Student: But I want to run the bot now.... I have my completely untested follow-the-camera-with-PID-control-gyro-and-accelerometer-code that I want to try out.

Mentor: You must first learn patience...

Student (impatiently): How long is that going to take?

However, it's working now. All the nuts and bolts of the programming have been tested (gyro code, PID feedback, improved camera tracking, holonomic drive), and now that it's working really well, they are now seeing how the design process is supposed to work.

Re: For Mentors Only: Inspiring Youth
 

Location: In the queue, about a minute before a match....

Mentor: Okay, where's your check list?
Student: We don't need one. It's all under control. (Thumbs up, wink)

Location: Going back to the pit, after the match.....

Mentor: What happened?
Student: Uhhhhhh, we forgot to close the pneumatics valve.
Mentor: Here's a sheet of paper. Make a check list now.

This really happened. Too many times.

Re: For Mentors Only: Inspiring Youth
 

take two: forgot to set the "left/right side of field" switch (makes for an entertaining auton period when the bot goes the wrong way).

take three: forgot to line the robot up (aim) for auton mode

take four: the auton-disable switch was set to disable

Re: For Mentors Only: Inspiring Youth
 

Me: Lets give up on the binary counter chips, interrupts will do the job just fine!

Mentor: Yeah, but those chips are so cool and so is the multiplexing code!

Me: Yes, but interrupts will work, lets just implement it that way and move on...

Mentor: You know what else is cool?

This sword cuts both ways. I don't see it as a mentor/student thing, but rather a personal bias issue. I've seen many professionals succumb to perfectionism many a time, and it's not always a bad thing.

Re: For Mentors Only: Inspiring Youth
 

I would have to agree with the sentiment that you can't allow things to just magically appear for the students, if they don't do it, we CAN'T do it for them.

Once they realize that they are on the hook to deliver and that they will have to explain to the rest of the team why they aren't done their motivation seems to increase dramatically... however, it seems to be a struggle at the beginning of every year.

Re: For Mentors Only: Inspiring Youth
 

Ah the gentle art of mentoring. My advice, let them fail.
You gotta suffer if you wanna sing the Blues. We all learn to walk, talk etc. Learning anything is by a trial and error process. I've seen a very experienced team spend 4 hours trying to 'trouble shoot' a 'software' problem, when the RC had a big red trouble light on the 5v supply circuit. (the problem was a shorted sensor. As a mentor, I simply asked them "Well, what does that light mean?" (everyone assured me the light was on as a result of a software problem.)

Eventually they came around to my point of view, but I pretty much let em thrash for about another hour, before they exhuasted themselves and came to the brilliant conclusion that maybe I was right.

Some people (and I include myself) can repeatedly shoot themselves in the foot, and then reload and shoot some more. The mentor's role is then to say sympathetically,
"If you shoot yourself in both feet, your limp will be less noticeable."

If you (as a mentor) are struggling with a problem, don't hesitate to get help from your fellow mentors. Many the time, a fresh pair of eyes can spot the problem that you can't. I've been on both sides of that situation.

Last piece of advice - adjust the trajectory by slight mid-course corrections, instead of waiting to the last possible minute and using up all your reaction mass.
(Sorry for that last bit, too many years working at NASA.)

Re: For Mentors Only: Inspiring Youth
 

Why not have a student be that second pair of eyes?

Re: For Mentors Only: Inspiring Youth
 

well as some one who was on a robotics team(I was that student who found all the flaws to your designs then solved them, and said that that alternitive would be "easy to do") and who now is mentoring one(im a college student on a team with no engineers and only 1 real coach Im as close to a mentor as you can get) I kinda have an intresting perspective on this

most of the students your working with are smart . . very smart, they have probly been smarter than their teachers for some time now, and have probly never come across a problem that they could not solve. you may call this arrogence but I say its only that if they cant back it up, and most of them can.

most mentors have gone through college, they have a job in industry and are doing pretty good . . they also are probly smarter then their colleges/bosses, and can usuly solve a problem before it becomes one(admit it youve done this).


the problem become is that you have 2 very smart very confidant people, argueing about their own personal abilitys. and thats what both students and mentors need to realise, that when you argue with each other your really arguing with yourself from 10 years in the feature or past. and your both probly right. the solution to this is respect, for the student remember that your mentor does have experiance behind them and that "getting it working" is a great place to start from, you can then add onall your little whisslebobs after that. and the mentors nead to remember that that student your talking to can do what they say they can, and that paper with fancy writeing/ paper with big numbers doesnt neccicarly make you always right.


and thats my take on it

Re: For Mentors Only: Inspiring Youth
 

yes, there it is: ego. One person who keeps tripping over his own ego, or two people whos egos are so big they keep crashing into each other.

Engineering and science is not about being smart. You dont get paid based on your IQ, or how many things you have memorized, or what you can invent on your feet.

You get paid for results. Sometimes the super bright young engineer gets so caught up in recognition and credit for his work, whether or not he will get a bonus or a raise, that they go off the deep end, quit their job in the middle of the project and go where someone will recognize what a 'genuis they are'. The run off to someone who will stroke their ego.

Then who finishes the work that was left behind? Usually its your engineer with an average IQ who comes to work everyday, follows a logical proceedure, and doesnt worry about whos getting all the glory. In other words, the guy without the ego problem. The guy with his eyes on the whole project. The guy who understands than when his task is done there are twenty other people downstream whos tasks are just beginning.

With engineering, the thing is, there is no right answer. There is not even a best answer. There are always many ways to design and build and test a system. In the end it doenst matter whos idea was the most clever or creative. What matters is who got the project done, on time, on budget, with few bugs and errors in the final product.

The end user (the drivers in our case) are not going to know if the code in the RC is brilliantly written, clever and concise, all they will know is "when I push the joystick the robot goes forward...."

and the dead-honest truth is, thats all the end user really cares about.

Re: For Mentors Only: Inspiring Youth
 

Ken is so on target here.

The end user does not care who finished the project. He does not care what problems you had to overcome. He does not care how much work went into designing / testing / building whatever widget you designed / tested / built.

All they care about is that it does what you say it does, in a fashion that is easy to use and reliable. Lets face it, in the real world very few are interested in the design problems that went into your MP3 player....all they care is that it works out-of-the-box and all the time.

Re: For Mentors Only: Inspiring Youth
 

In the process of trying to inspire youth as well as inspiring fellow mentors, I am reminded of one thing:

In corporate life, it's a careful balancing act:
Product Quality
Product Cost
Product Schedule

You can have supurb-quality products that are "late to market" and cost too much and will FAIL

You can also have products that ship to meet the schedule (e.g. the holiday rush) but that have terrible quality and safety issues.

So, I find inspiration in students and mentors when you can look YOURSELF in the mirror and say "I did it all....quality, cost, and on time"

You have noone to impress but yourself........isn't it called "self-engraciating"?

Re: For Mentors Only: Inspiring Youth
 

It is a delicate balancing act - when do we allow the students to try something we know will fail, but the experience will make them better. Especially this close to the end of the build, we as mentors are taking a more aggressive approach to putting forth our ideas. Not because of ego, not because of pride, but because time is an (the) issue and, at this point, our greatest foe.
I am in a unique position in that I am sponsoring a second-year team, but this is my first year with FIRST. I was able to attend the IRI in 2005, so I have a taste of what a FIRST competition is. However, as a teacher new to the school system and new to the programs, my knowledge of robotics is rather limited, so I try to apply common sense as a problem solver as I can. I know that I have learned ten times more from the students as they have from me. But the one thing I do believe I understand is the FIRST philosophy - gracious professionalism, co-opetition, celebrations of group successes and failures ("failures are a great thing, especially when they happen early" - Andy Baker), etc.
Before the school year started, I sat down with the returning team members and asked what they wanted out of this year. Their #1 concern was that the 2005 robot was completely student-designed and student-built, and they'd like that to continue. We as mentors are exactly that - the proverbial "guide to the side" rather than "sage on the stage". We must understand that FIRST is about recognizing innovations in science and technology from the youth. We've had our glory days, now it's our opportunity to pass on the values, virtues, and legacies on to the next generation of problem solvers. I think that some of the ego issues come about when individuals lose sight of the fact that FIRST teams are exactly that - teams. As I peruse CD forums, there are countless references to team 71 in 1999 or 230 in 2002 or 45 in 1776. I have yet to come across anything that said "remember that one blonde kid from 234 in 2000 and how great his design was?"
The purpose of FIRST is not to win awards or championships or become a hall-of-fame team. These are fringe benefits to a strong work ethic, positive attitude, and fun environment. Life's a journey, not a destination.
I want to add that I am cognizant of the fact that I am a newcomer to FIRST, that I undoubtedly do not and cannot see all that FIRST is, was, should be or will become, and in the grand scheme, my opinion is negligible. But I do know that I have the charge of growing a young team into one that is respected, well-liked, and successful (and hopefully has working robots). By sharing my thoughts with the CD community, I hope to gain a greater knowledge of my role, of FIRST as an institution, and feedback and friendships from trusted and renowned authorities on the subjects at hand.

Re: For Mentors Only: Inspiring Youth
 

That is a tough question. Ive seen so many engineering prototypes or concept demonstrations in which the designer shows you a system that is sort of doing what he says it can do

and there is always a reason why its not working exactly right (when we get the real optics the image will not be blurry, the real electronics wont glitch like that, its overheating but we will use a bigger fan....). When you hand them a bunch of money, and they build the 'real' system, guess what? The problems are still there.

An engineer should be able to tell you if something is going to work or not before it is built. Every system has inputs and outputs. If you cannot explain clearly how the outputs are derived from the inputs, then you have not thought things through all the way.

There is a time for tinkering and building mockups and experimenting, but at this point in the project you should have a clear path to a functional robot.

Small failures and setbacks along the way are ok, as long as you have a plan B. Showing up at a regional with a fancy 130 pound statue violates the prime directive for mentors: no matter what, dont let your team fail (show up at a regional with dead robot).

Re: For Mentors Only: Inspiring Youth
 

I know that method all to well, especially because when its George Wallace sometimes it applys to fellow mentors as well. :rolleyes: heh just kidding hope he doesn't hurt me :ahh:

Re: For Mentors Only: Inspiring Youth
 

I agree completely. Some time ago, someone posted a survey asking if the robot should be student-designed and mentor-built, or mentor-designed and student-built -- no other choices, pick one. To me, FIRST isn't an advanced shop class, better have the kids design it.

In general I agree, but there is some room for exceptions. It's extremely important to have the kids see what goes into fabricating a part, including having them fabricate it themselves wherever possible. On occasion, we come across something that simply cannot be fashioned in the limited shop at the school, so it might be taken home or to work where the facilities are better. But, this is rare, and should remain so.

But the main point is this: If there comes a time where you, the mentor, must step in and guide the kids more aggressively, then do so. Let them fail until you hit the pointo of no return, and then prop them up. Like Asimov's 1st law, a [mentor] cannot harm a [team] or through inaction cause a [team] to be harmed.

It is a difficult balancing act - we're engineers because we like to solve problems, and to take a step back and let someone else solve it, with what may be a poorer solution, is darn hard. Letting a kid cut it, then cut it again ("it's still too short!"), when you're running ,ow on materials, is darn hard. BUT, if that's the last (or only) piece, and it's essential and more cannot be had before ship date, then make darn sure it doesn't get ruined, even if you have to do it for them. Hate it, tell them you hate it, but...

Don't let them fail at the end.

My 2 cents.
Don

Re: For Mentors Only: Inspiring Youth
 

Failure is relative. Losing a match, or even a tournament may be a short term faliure, but lead to important lessons that lead to even greater success.

In 1999, the rookie team I mentored finished 192/212 at the Nats. The next year they won the Nats. There would of been no success in 2000, if not for the 'failures' of 99. What is the hardest thing for a mentor to do, is let them learn through 'small' failures, so that they can build upon small successes, and finally 'big' success. Guess what? There are very few big failures in FIRST competiton. A big "failure" is not shipping a robot. Fortunately, this happens very rarely.


In my book, if you as a mentor/coach, have got your team to ship a robot and show up at the competition. You're a big success. As a matter of fact, if you're alive, breathing, and reading this, a million, billion things had to succeed to get you here, starting from the big bang 15 billion years ago. So relax and have fun, and don't sweat the small stuff!