I know I shouldn’t be looking ahead to next year already, but as a first year mentor this year this season, I’d like to figure out how to improve my mentoring. I have taken on the role of programming mentor and did the RobotC training, C2SN training, and helped our teams get Jpearman’s TBH algorithm up and running on a flywheel. What I am curious is how to consolidate and build on this for next year. My question is for student and adult mentors: how do you systematically go about training different levels of student programmers? Do you set up libraries of subroutines for students to use? How do you teach advanced topics like tasks, speed control loops and gyro sensor use? So far, these more advanced programming concepts have been tough for me as a mentor; some of the teams have made the leap, while some need more instruction. We have basically been using the cut and try method for anything advanced beyond the RobotC training videos. If there are some good tutorials on these advanced topics, I would love to see them. If you have any systematic outline of how you train new programmers, I’d love to know what that is. Any help would be greatly appreciated!
I learn how to program new things as I need to. For example this year, multi tasking was something new our entire team learned. We learned basically through forum threads, and our own experimentations. Generally example code is good, as it shows how these concepts are used.
This is a great question that I will be following. I am also the programming coach for our teams. I stayed away from advanced programming features (especially for the middle school team) this year and assumed as the kids continue with robotics over the years, they will self discover some of these more advanced features as they need them. I have also found that when kids have a specific problem to solve, they are much more interested in learning the concept. One programmer on my team was only lukewarm about programming - but get her to a competition and have her know that a programming change needs to be made in order to win a match - all of the sudden she’s a master programmer!
However, sometimes I will introduce a feature after the kids have flailed around and implemented something “the hard way.” I’ll tell them, “I discovered XYZ command, we can use that in place of the code you have.” Some of the features in programming require advanced logic and the ability to do that comes with time.
We run two classes each year after the regular season ends. This gets kids more into the learning and we get a 40% participation rate in here. We run it as an extra cost too for parts and such. ($100 for 8, 2-hour classes)
One class we offer is geared towards kids who have had one year of robotics and want to get better and learn the design process, robots, and programming. How to have a winning design notebook, center of gravity/tipping, momentum carrying your robot further than you want, etc. Get them from first year middle schoolers to great middle school teams.
The other class is a more advanced class and varies in subject from year to year. We try and guess something that would be useful in the next game. We did a line following challenge class one year, virtual worlds, visualization, and learning PID was last year’s, and this year is scaling back to an intermediate class covering proper programming techniques - functions, tasks, control loops, slew rate control, sensor use, etc. This is a mix of middle school and high school students. So by eighth grade, some teams are doing the advanced stuff. This is generally a lower participation rate than the first class.
We cover the new game after it is announced as a week in each class. We guess what to teach wrongly ahead of that every year! Line followers have not been a key must use component in years. PID for arm control fell off the earth this year’s game (as with most autonomous programming for that matter. How many programming skills left the starting position? Not the top in the worlds, the average team.) We are not good prognosticators.
Additionally, for this year, we are going to do a firefighting contest this spring and both classes will be building towards that. We are running it locally and not ambitious enough to get it an area wide event. The more advanced class will be concentrating on the autonomous aspects with some control loops and sensor usage to find the candle. The beginning class is about robot construction, using gears and sensors. For many of them this year, this will be the first autonomous programming for movement. We tend to use clawbot bases for these bots and then anything goes for detection and extinguishing them. Firefighting is 1005 autonomous and 12’ cubed
Team GIraffe: I really thought line following would be the savior this year and spent a lot of time perfecting that with our programmers. Didn’t use it at all. We went brute force all the way!
I laughed when I read this line: PID for arm control fell off the earth this year’s game (as with most autonomous programming for that matter. How many programming skills left the starting position? Not the top in the worlds, the average team.)
This year, for my team, the programming skills challenge did not challenge our programming skills at all. Our middle school team has the highest programming score in Virginia. The program we got this score with was basically one line! The program simply ran striker arm motor for the duration of the skills challenge.
I hope the challenge next year incorporates more opportunities to truly program.
@TechRobotics1 I wish I had ready answers for those questions myself.
I wanted to write almost the same thing as @Team80_Giraffes and @Gear Geeks have posted, but they beat me to that - I guess it might be a common setup and similar experiences. 
Our club offers classes every season, typically it is 6 to 8 two-hour sessions once a week. For new members there are basic VEX building and RobotC programming techniques and for returning members there are advanced programming topics like PID and introduction to Debugging Stream and Tasks.
Since it is not a school setting, when you would meet daily and have tests at the end, you don’t expect students to remember everything. It many cases it is parents (new to VEX) who end up benefiting most from those classes. However, students are expected to be aware of all those topics and, hopefully, seek adult help when they run into a problem that needs, for example, a DebugStream.
It is somewhat ironic, that many students who have important qualities to do well in robotics, like “confidence that they will figure out best way of doing something independently”, will keep stubbornly reinventing bang-bang controllers when they clearly need PID as if they never learned about it just a few months ago.
The good thing is that the difficulty of the game itself serves as a vehicle to introduce them to advanced topics which play important role each season.
Here, my experiences are very similar to what @Mystical Pie and @Gear Geeks are describing. You just wait for the students to realize that they need something and be there with the best answer you could get, because it is perfect time for them to learn it.
But if you are looking for something more systemic, then you could never go wrong with best C language practices, debugging techniques, data logging, introduction to VEX sensors,
Coming from my experience as a high schooler who is the main programmer for the team, I would say that teaching only the basics is most useful. I was taught the basic of robotC (set motor powers, read sensor values, etc.) and had to figure out the rest. I feel this was best for me to learn how to write the code because I know well what every part does and understand everything in it much better than when I have tried copying code from others. Most of what I have learned has come from reading the help documents in robotC very closely. It is important to note that I came into it having experience in a C based language (I am a Swift programmer), so I was able to get the syntax down easily.
Yes basics help, but there is a ceiling we found and why we offer the advanced techniques.
Getting beyond binary on off is one thing. Visualization techniques and control loops is the merger of programming and real engineering. Getting kids to think in those terms makes TBH being thrown in this year a snap once you get the new concept. Tell me how far off I am, let me tune it using this new algorithm. Yeah! Success!
I know that my biggest help in learning robotC was a side goal that interested me and forced me to learn. I would suggest a few fairly challenging programs to anyone who wants to learn and try to interest them into making it then answer any questions they have and encourage them. My side goal was a teleop autonomous where the driver would drive on the practice field and then in autonomous the robot would copy what the driver did. It forced me to learn multi tasking, arrays, simple/concise code, and all the basic stuff. It has taken me 3 years and I still haven’t perfected it although to be fair, it’s never going to be perfect and it does work awesomely.
I am mostly self-taught in RobotC, as is my partner-in-crime. He was already fluent in C and C++ before we switched to RobotC from WasyC, so he knew the syntax and most of the commands coming in. I learned from scratch, partly through just reading his code and discussing programming with him, and partly through reading the C and RobotC documentation. It seems as though the difficult functions to use, such as sprintf, are directly from C for the most part, so I look at C documentation when I’m stuck.
Personally, I think learning to code has 3 stages: thinking (how am I going to make the robot do this, what information do I need, how can I get it, etc.), syntax (every command & function ends with a semicolon, for loops use semicolons, etc.), and command/function memorization (this is the function I want, and it takes these parameters). I’m currently in that third stage, though I am much farther along than I was a few months ago, and reading documentation is how we find nifty little things in C and RobotC we can do. Did you know that Vex joysticks have accelerometers in them? I learned that a while ago, and it’s somewhat useful for our code (we ran out of buttons, long story).
A note about those stages: those stages are learning how to program. The first stage is very important throughout all levels of programming. Any time you need to solve a problem, think about how to do it. That’s what pseudocode is for, so you figure out how to do what you want without worrying about syntax or functions.
Honestly, a graphical language is a great way to get the hang of that first stage before worrying about the other 2. RobotC even includes a graphical compiler, although I have not used it. I started with EasyC, and when we switched to RobotC, I was able to pick up most of it pretty easily.
We try and torture our kids and get them right into the real RobotC coding as once you get the hurdles there, most any language seems easier. @foster started us down this path long ago and I agree with him on it. Sixth grade is a great time to learn what a semicolon is.
Sense, plan, act is the mantra but it can lead to sloppy code. What we want to start teaching the kids after they get their robot working, is how to manage the code and write better code. We have a hard time getting kids from “good enough code to run the robot” to comp sci guy grade code. That is why we are doing that in our intermediate class this year.
Function files and tasks is about as far as we get. Structs, pointers, and properly using functions with variables by reference are not generally where we get to. Limitations in memory and debug performance have hampered any mapping of the field attempts. And that pesky gyro drift…
“PID for arm control fell off the earth this year’s game” That may be true, but if you amend it to PD control you can deal with speed control of flywheels. The “I” refers to integration which give you position control. The “D” however is the derivative, which is all about velocity (in RPM, if you choose).
I’ve been trying Plan - Sense - Act.
- What would you like the robot to do? Keep RPM at 2100 RPM
- What do you need to sense? RPM of motor
- Act - Increase motor speed until RPM > 100 RPM
That will lead to discussion on what happens at faster / slower speeds
- Plan – 2000 < Flywheel < 2200
- Sense – Motor RPM and past RPMs to do PID
- Act – PID function
That seems to a little better in the programmers mind.
I have a mixed mind over structs, pointers etc. I can see some complex data structures for some advanced sensor programming (like vision). Not really needed for a PID function.
Reading post from our younger members, I think you are doing great. All I could remember from my own time of leaning how to program is a sense of total confusion looking at the reference page for sscanf() - C is not the easiest language to learn.
I agree with other mentors that advanced topics such as structures, pointers, or tasks could wait - sloppy code is a problem. First, we need to concentrate on the basic programming techniques and quality of code as much as we worry about the build quality on the hardware side.
Sometimes I see one team copying code from another team, thinking that if they use multiple tasks, somehow their code is more advanced and automagically works better. There are very few things for which you truly need tasks and very few robots that do stuff at that level.
For the last week or so my team was doing a lot of programming for multiple autonomous runs. I try to avoid looking at their code as much as possible. I afraid of what I might see there and don’t want to get into the heated argument over the code quality just few days before the states.
They think they are pros, but are practicing code duplication on an industrial scale. It is going to be a long learning process.
@technik3k, I have kids with autonomous titles in their NBN code that say “Red Pins” and “Blue Cubes”.
You asked a good question. There are plenty of youtube videos . There is also the robotc wiki and api. There are also plenty of tutorials on vex forum.
But you should have your mentees look at these links that teach about “advanced” topics.
Robotc Wiki
Tutorial by Cody explaining pointers
Programming Sensors part 1
Programming Sensors part 2
Other helpful videos from the same channel
RobotC api… feel free to look outside vex cortex as there are other helpful programming tutorials on other platforms.
RobotC tips and tricks
I hope this helps, but if your students are truly interested, they will learn a lot of this on their own.
David
Actually, I think this year is the most programming we’ve ever done - and the most complex by far. While running a puncher might be just a motor command, we had to create a custom PID controller for running our flywheel in order to make accurate shots. So even if for our past programming skills runs we’ve just sat in one spot and shot all the preloads, I don’t think that’s devaluing the programming skills challenge because the code behind the flywheel is by no means simple.* But it is definitely different from previous games where the focus of programming skills is moving around the field.
*From the start I haven’t added joystick controls for manually adjusting flywheel power, because it felt like the lazy way out. I would rather improve the code to make it work better for more of the time.
By the way, the way I learned to program was through the CS2N course on programming in RobotC. But I’ve also learn JavaScript on the side. The syntax in C is so similar that I can learn the minor points that vary pretty easily. The same goes for more complicated things like structs - they’re somewhat similar (sort of) to objects in JavaScript, and so learning them wasn’t all that difficult.