My team is relatively small (<20 students, 2 mentors) but looking to grow in the near future, as we only have 2 seniors this year and have had large freshman recruiting classes over the last few years. However, one of these seniors has been our sole programmer for 2 years. There have been 3 other students that have (sometimes half-heartedly) tried to learn from him, but one of these quit and of the other 2, one has mimimal experience and training and the other isn’t particularly interested in programming. One thing I’ve figured out, even as a member of the build team, is that programming (and therefore, good programmers) is rather important:). With this in mind, I’m looking for ways to get a head start on “replacing” him.
Neither of our mentors is a programming mentor and our team does not have extensive offseason programs in which to learn/teach more. Our school does have a newly formed “Coding Club” that we might look to for new members, but I don’t foresee this being highly effective.
Could people please recommend some training resources and/or ideas for recruiting new programmers?
Thanks!
What I would suggest is trying to find a programming mentor if you can, and if not you may have to find a member who is highly interested to learn coding over the summer.
You are right it is important to have programming! You just need interested students and you can get it done 
There are tutorials online as well, so I do not think that is a bad way to start either.
Make your lead programmer a drive team member. That gives incentive to a large and sometimes thankless role. It’s also incredibly helpful at the field.
Look to the coding club, see what languages students already know. Our school does not teach programming, but students already interested in programming, already have a key ingredient, the ability to be self taught.
Look for parents that have of students that have IT background, to help mentor.
Keep, or build a running bot, so programmers can have 100% access to it in the off season.
I am probably one of the worst programmers on our team, and I am the mentor. I am a controls engineer by trade, look to see if parents in school have a controls background. They will bring a key element to know how a machine thinks, and sequences. We have a keen eye for recognizing the difference between something working, and something being controlled correctly. Look for a controls engineering company around, to support team, and mentor.
Look to the FTC program, as incoming freshmen will now have java experience from FTC. We are a labview team, but as our FTC feeder team moved to Java, (as all of FTC I think) it maybe time to move to Java?
Use a language that students and mentors are most comfortable with.
If you have a robot to program, and you have 1 mentor, and 3 students willing to do 16 hours a month, over the next 6 months, you will probably have one strong programming team ready for next years challenge.
Thanks for the suggestions!
This is interesting, I didn’t really know where to look for people with programming experience before, so I’ll have to check on these options.
I would have your new people interested in programming look at all of the old robot code from your past years. And also, build an off season bot, or even just take an existing robot, and have them program that. It’ll give them some experience with programming an actual robot, and with all of the old robot code to reference they should be able to figure it out.
Also, do you have any other teams in your area? If so, talk to them. Find a team with a solid programming mentor, and ask if they’re willing to help out your students this off season. One of the most amazing things in FRC are the team’s willingness to share their knowledge and resources.
Sorry, forgot to mention. . .
Don’t discount your existing programmers. Programming an FRC robot is a tricky thing, and it is really tough to be able to have multiple programmers working on code for different subsystems, all to coordinate and merge code into a whole project, without conflicts.
So your observation of “half-hearted” programmers, may just be that there wasn’t much for them to do at that time. We have 3 strong programmers, and it can be a significant task to manage 3 people working on same program. We have found it typically not worth the added effort, and end up with only one person making code and changes at a time. For us this means we have one experienced programmer with a freshman looking over his/her shoulder, and 4 people not doing anything productive.
We worked this way for a couple of weeks, but with all the downtime, I tore the freshmen away and gave them a bot, and gave them programming challanges. I told them they could not ask a question unless they spent an hour being stuck, and researching the problem. The freshmen were happier, the experienced programmers were happier, and the freshmen will be ready to take on more advanced concepts next year.
It seems that a likely scenario for next season is that your team will have a small number of inexperienced programmers with little mentorship support in that area.
Given that scenario, one way you can increase your chances of a successful season next year is through smart strategic design. If you check out Karthik’s strategic design presentation, it basically walks you through how to go about building the best robot your team possibly can. Golden Rule #1 is to build within your team’s resources.
Recognizing that your programming experience is a limited resource for the coming build season, simplicity in code may be weighted heavily in strategic or mechanical choices on how you build your robot. If it is not feasible for your programming squad to integrate fancy sensors and sophisticated control algorithms, then your particular resources may dictate selection of a simple single-trajectory pneumatic catapult for launching boulders instead of a Cheesy Poofs style adjustable-hood/turret/speed-controlled/automated-targeting fly wheel shooter. Maybe you also choose a shooting position locked in against the tower so you don’t have to worry about targeting code, or use a flash-light to indicate where the robot is aimed instead of a camera?
A great example is 5811’s robot this year. It was consciously designed to only require very simple code. It is quite literally a drive train (uses WPILib code), a single pneumatic cylinder (just true-false, doesn’t get any easier), and one additional CIM motor (again…just on-off with the touch of a button). The design does not rely on sensors to perform its function. This made the job much more achievable for our Rookie FRC programmers, and there were still plenty of areas for our programming team to attempt some more challenging code: ded reckoning auto routines for crossing obstacles, using the PDP current sensing to automatically cut off the intake when a ball is collected, etc. Based on the experience the programming team gained this year, we will feel more comfortable in future seasons relying on sensors and controls to achieve advantageous functionality.
I’ve seen many teams this year that went with motor-driven arm solutions with limit switches, rotary position sensors, etc. to control the arm position that would have been better off with a single pneumatic cylinder raising and lowering the arm. No need to integrate sensors, fewer points of failure, and can come very close to achieving similar functionality. I’m not saying that the same solution is the best for all teams, but being honest and reasonable in assessing your own ability to execute different tasks or mechanisms will give you a better chance at success on the field.
Also don’t discount the resources of your other local area teams! I know your about 2 hours away from my team, but if you use java I’m sure we could work on some remote assistance to help you get people trained and help with debugging issues.
Also, make sure your programmers attend SPLASH in December - the programming sessions there are rather good.
Hello,
My team has gone through the same thing just about every year so the biggest thing we do to minimize the frustration is that the graduating seniors will teach the underclassmen everything they know.
This is best done during the season but you could have meetings a couple times a week until school ends or during the summer. Try coding an old robot or maybe try tweaking the existing robot’s software (add sensors, new features, etc). Alternatively you could try to build something for fun as a design exercise.
In the fall of 2014, we built a mecanum chassis (yes we did this voluntarily!!!). This was helpful for the build and design teams as it was something brand new for them. We ultimately used mecanum for Recycle Rush
Definitely try to find a programming mentor. Use connections of existing students and mentors (our programming mentor last year had a son on the team and our mentor this year has a student in our junior high)
If that doesn’t work, reach out to local teams. We’re about 2-3 hours away from you but I would be more than happy to remotely assist you (we use java). Shoot me a pm if you’re interested.
You guys had a really cool robot this year! I talked with one of your mentors for awhile and you guys have a great program!
Hope to see you on the field sometime!
Agreed, I cannot emphasize enough how important this is for programmers.
+1 to putting a programmer on the drive team. Not related to the turnover issue, but still important to note. It shouldn’t be a giant thing, but if two people of equal merit are under consideration to be the operator, its really helpful if the person who wrote the code for the buttons is pressing them.
I can’t count how many times I’ve seen something wierd happen while operating, and simply known how to work around it because i knew the cause
And then was able to fix immediately afterwards.
My team is having largely the same problem, except we will still have one programmer by the year’s end. I and a few others have been learning Java on Codeacademy, a free website for people to learn all manner of code. It does not cover the entire language, but it definitely encompasses most of the basics.
In 2014 I knew nothing about programming a robot. I had a lot of experience programming but not much related to robotics. I had experience in C++, so I choose that, and I learned to program the robot on my own using the wpilib documentation. It’s not difficult to create programs to control most aspects of the robot. It only gets difficult once you start using encoders and sensors, and vision. Since the control system is not changing, just have them reprogram this year’s robot. If you have multiple programmers, it’s not difficult to have them work together. My team(not robotics) uses our own git server that we host, but I think that FRC teams can get a free github repo if they want it.
Pneumatics, pneumatics, pneumatics.
As a backup plan, make sure you fully understand how to utilize pneumatics on your robot if you aren’t able to find/train new programmers.
I say this because a lot of common tasks (i.e. rotating a intake down, adjusting shooter pitch) that require moving a mechanism to a precise potion can be accomplished using either a motor or a pneumatic cylinder. Using a motor will generally require adding a sensor and some sort of control algorithm to ensure that the mechanism stops exactly where you want it to stop. Pneumatics limit that mechanism to two positions, but makes it significantly easier to ensure that the mechanism ends up in the correct two positions.
I think one of the best ways to get programming going on your team would be to find a programming mentor. Here’s my rationale: Over the span of my FRC career thus far I’ve seen countless times where people turn away from a task or leave it to others to figure out because there wasn’t steady leadership. Having someone to guide the new students on the team to become leaders themselves is of the utmost importance.
I would definitely look to the coding club for potential students. If they are already in a club at school for coding I don’t think it will be hard to convince them to join a team where they will write code for real robots
Yup, we literally have an entire pneumatics system on our robot just for the one cylinder to raise and lower our arm. All because it would simplify the mechanism as compared to a motorized solution.