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.)