Quote:
Originally Posted by GaryVoshol
I totally understand Michelle's point. "If you give a man a fish, he eats for a day. If you teach a man to fish, he eats for a lifetime." We shouldn't be giving things to any team. We should be helping them to develop something on their own. However, if you look in the excerpt I quoted from the original challenge, you will see that was what was proposed. Even more important than working at a regional with a team is working before ship with them.
|
I think there is a compromise that must be struck between "teaching a rookie everything there is to know about MPLAB and autonomous programming from scratch" vs. "here's a complete MPLAB project - it'll work - download it and go". This is the build season, not the summer and fall where longer term classes and educational sessions can be held. It's crunch time, ladies and gentlemen. If veterans are to assist rookies and the inexperienced NOW, during the build and at the competitions, ANNNNND we hope to preserve our sanity because, ya know, we still have to design and build our robots too, then we're going to have to meet in the middle on this.
The autonomous program structure I posted earlier in this thread does not exist as a standalone package - it is merely a foundation upon which additional autonomous understanding can be constructed. The recipients must still take that code and discover where to insert and "hook" it into their project. They must understand what pwm outputs are and learn how the variables in the code link to the physical outputs on the RC. They must learn what the different speed and timing parameters are and how changing those values affects the real-life operation of the robot. If they wish to add additional steps to the program, they must seek to understand the function of the if statements and how the pathtracker variable works. It is merely a modular building block. It isn't a complete drop-in solution, nor is it too watered down to prevent relatively rapid comprehension of its functionality. It encourages further experimentation and learning while saving veterans the added stress of meticulously explaining what the heck an unsigned int or char is or why all those #define statements are in there.
Let me just say this from my personal experience - I'd like to think that I don't totally inhale audibly at programming. I possess nowhere near the skills that many others on these forums do, nor do I have any formal training in C, but I can do enough to get the job done. Now everything I first learned about programming in my rookie year of 2001, I learned by looking at the previous programmer's code from 2000. He left for a fellowship at Stanford - no one else on the team knew PBASIC. I joined the team in May of 2000, but I didn't have the opportunity to sit down and try to understand the code until late December, just prior to the 2001 kickoff. If I didn't have that existing framework in place from which I could borrow and construct my own 2001 code, I'd have been totally lost. And even with all the "pre-established" programming presented to me at the start of my initial programming journey, I'm quite certain I was very proud of what I was able to create by the end of that first season.