Programming "Bootcamp"

We had some pretty significant turn over on our team this year. Combine that with COVID and sadly we didn’t get the much knowledge transfer from the senior class down. Because of that we’re hoping to do a summer “bootcamp” to get everyone up to speed as best we can. I’m looking at building out the programming side of it.

I’m wondering if anyone has experience holding these types of bootcamps. Rather not recreate the wheel on a curriculum if possible.

I’m hoping to covering the development environment, robot electronics and programming fundamentals. For the programming fundaments I’ve been digging into online tools (codecademy) and checking out some seminars. But I’d love to hear if anyone has advice on this topic.


A few resources I really like and that we use for our (C++) training include:


This is something that we (“Quasics”, 2656) have been talking about for a couple of months, too: we’re losing a big portion of our team due to graduations this year, and while we’re hoping to be able to bring in a good sized-group to help fill the ranks, we’ll obviously need to recover from the “brain drain”.

We’ve had an informal program that has evolved over the last 5-6 years, based in part on some courses that I used to teach at university before moving to the Pittsburgh area.

We often start with a little digital electronics using Arduino boards, basic components, servos, and NeoPixel strips/rings that help to quickly move people from effecting only cyberspace to making things happen in “meatspace”. This also lets us introduce some very basic C++.

We then move on to working through a small handful of coding labs/projects that build on each other, and focus on building some comfort with key concepts (e.g., compiling/debugging code, variables and “computer math”; decision-making with “if” statements; loops; simple functions; the basics of working with classes; etc.).

Historically, that’s been followed by a brief tour of the code for our previous year’s robot, along with a high-level overview of the WPI library framework. This also gives us a chance to introduce them to the idea of “version control” for source code, since we’ve been using GitHub to host the code for all of our projects since 2015.

We then work as a group (with one of the coding coaches behind the keyboard and providing hints along the way) to write a simple command for the robot (generally making it drive for a fixed distance at particular speed) and wiring it into the control system. From there, they move on to writing a simple command (as a group exercise), or augmenting an existing command to allow for more flexibility (e.g., variable distance and speed, and handling special cases like driving backward).

The “final stage” is generally when they each propose some sequence of operations that they want to make the robot do (sometimes it’s stuff like “drive in a square”; one student decided to make the robot “do a dance”), and then write/debug the code to do so.

When they’re done, we declare them “official dangerous”, and start having them work on whatever needs to be done, often accompanied by a more senior student from the team to act as a partner/mentor. This may include exploring other options, such as figuring out how to do vision processing using a RasPi, or using some of the more advanced techniques available in the WPI frameworks. (This code then turns into examples that we can use for future years, and we’ve also started trying to turn some of it into examples that can be used with Romi devices, so that it’s easier to scale it, as well as removing dependencies on the robot hardware from a given year.)

The learning obviously doesn’t stop there, but it at least brings folks to the point where they’re able to begin contributing to the team’s work.

We’ve been talking about turning this into a short “boot camp” program that we can hold for our students in the summer/fall, and possibly open up to other teams in the area, once we’ve had a chance to work out format that we think would work well. (It’ll obviously mean expanding some of what we do: for example, our team uses C++ for the robot, but a number of other teams in the area that we partner with on other stuff use Java.)

1 Like

Below are some things I think you definitely need to start building up. I’m going to organize them each into hidden details to minimize the length of this post.

Post Note: I didn’t expect to write this much, that was a lot. Please ask lots of questions.

The Basics

The core of you programming team is absolutely critical. Without fundamental building blocks, you will struggle through writing code.

Hello World
Data Types
Method Parameters
Method Overloading

I highly suggest the How to Think Like a Computer Scientist series. It’s free and incredible intuitive. For practice writing code within methods, Codingbat is a wonderful site with tons of exercise, test cases, and solutions for one to learn and teach from.
One of the best introductions to object orient programming is Oracle’s examples.
Finally, don’t teach everything yourself. Force learners to have to figure out how some things work on their own, using documentation sites like w3schools or tutorialPoints. This will promote future learning.

Please Please Please teach how to comment early on. commenting is like flossing. If you weren’t told early on to do it, you forget. If you learned it early in life, you fell icky not doing it. Teach your students to write code as if the one maintaining it is a homicidal maniac that knows where they live.

Other resources:
Teaching Students to Recognize and Implement Good
Coding Style

Version Control

Next, you’ll really want to dive into version control. Github is critical. I highly suggest reading the git guides as well as printing out copies of github cheatsheets.

Github also releases a free educational classroom that will allow you to post projects for others to learn pull and learn from. This would be beneficial for both getting everyone code as well as getting them used to doing it.

This article is really good for teaching proper commit message standards.

Other Resources:
Importing your project to GitHub
Adding Existing Project to GitHub via command prompt


Next, I believe it is critical to make sure that you know how to read WPILIB libraries and their Java or CPP API. There is so much information that can be really really important to know. Allowing coders to be able to get to these docs and read from them is critical in the process of self-sufficiency.

As for your own documentation, I’m a big fan of writing specs. Not some hardcore technical spec that drains the living soul out of every being because it goes into detail of every little function. Rather, tell me before I even code: What motors/pneumatics/sensors are in each subsystem. What should each button do? Force yourself to design the program before you dive in. Joel Spolosky has an excellent guide on it.


A programming team should always always always have a robot to test their code on. Always. No matter what. Maybe it’s not “the robot”, but it’s a robot.

If you don’t permanently have a robot to test with, two things:

  1. Seriously examine why you don’t. You need that for Demos, Drive Practice, and Programming. That’s 3/4 of FRC. Very often the excuses given by a Tech team as to why you can’t always have on are garbage. They don’t have the right to hold all those aspects hostage just because they can’t keep one robot running.
  2. Consider buying a Romi! There is a lot of good documentation on how to use them, and they are a great price to always have a tiny drive base.

Along with always having a drive base that works, always have program that works. Start with very very simple code. Get a robot moving, then commit that to the main branch of your repo. Then, whenever you want to make something new, create a new branch of your repo, commit and test within it, then only merge it into main once you are certain it works. You should always have something to fall back on if need be.

The Culture

Finally, develop a really good culture. Your programming team is just that. A team. You want them to act like one.

I really have been enjoying a 20 minute team building exercise each meeting. It gives students a good break from what their working on, while also building stronger bonds with each other. It requires everyone to work together and develop.

We also end each meeting with two things. We review what went well for the meeting and what could have gone better. Finally, after the whole team meeting, we yell “Break on break, 1, 2, 3, BREAK!” and clap all at the same time.

As a leader, I also highly suggest asking your follower, “How can I help you?” often. Here’s a good video as to why.

The Joel Test

Just to throw more at you, cause why not? Someone will probably find this useful.

The Joel Test is a quick way determine how effective your team is. I highly suggest reading it.

Did you read it? No? Then go back and read it before moving on. Sheesh.

Good, glad you read it. Some of these I believe are a little tricky to translate to FRC, so here are my adjustments.

  1. Do you make daily builds?

    Do you test you main branch of code every meeting that you have a robot functional to make sure it isn’t broken?

  2. Do programmers have quiet working conditions?

    This I believe is the most difficult one’s to achieve. Yet it’s so important. Covid Virtual meetings were actually the most productive my programming team ever was, since we didn’t get distracted by other sub teams. I’m considering buying 5 pairs of noise cancelling headphones for this express purpose.

  3. Do you have testers?

    Why are we having programmers test for bugs when we could be having drivers and operators test for bugs instead? (This isn’t true for all things, but important to consider)

  4. Do new candidates write code during their interview?

    Of course not every student will come in with major programming skills. This one really mean that we need to make sure those students are sufficiently up to par on basic coding before trying to push them off the deep end into FRC coding.

  5. Do you do hallway usability testing?

    Could you hand a laptop with instructions to a student or mentor and they could completely figure out how to use the robot from that? If not, then use of the robot will become dependent on programming. Make sure every person on the team has the resources to start the robot up and run it.

Final work of advice: If you don’t know something about the above, go learn it before teaching it. It baffles me how many people teach robot programming without ever having coded one completely by themselves.

There is a lot hear, and so much more I wish I could say. If you are interest in going a zoom call that we could record and post here, I would be 100% down.


Last summer, 6328 developed a beginning software curriculum for remote learning (a requirement at the time) using small Zumo robots from Pololu which is published on our website. We know of several teams that have used some or all of the curriculum, so maybe there are pieces that would be helpful for you too. Take a look and see what you think. The 6328 software team is happy to answer any questions, too.


Spectrum 3847 has an extensive online curriculum.

Am I really the first one to drop the “R word” in here?

Last season we held a range of special interest training series over Zoom / Google. We met weekly to discuss: CAD, Java programming, Web Design, and basic Electronics with the Arduino. When WPILib support for the Romi was announced, we shifted our Arduino and Programming groups to use that.

Next season we are planning to focus more of our fall training around the Romi, which will allow us to cover many of the same topics we did in our Arduino classes, combined with actual exposure to the WPILib framework, languages, and coding tools.

You could do a lot worse than to get a Romi and run through the tutorials. From there, you can branch out to study a wide range of robotics topics that transfer directly onto your full scale competition robot.

(EDIT: Sorry, wrong “Reply” button.)

Technically no, but I buried my endorsement pretty deep in my reply. Glad to see it getting some attention.

1 Like

You buried it under “testing” where I was guaranteed not to see it. :stuck_out_tongue:

1 Like