What New FIRST Programmers should be taught


I found out that the arduous task to teaching not one, or two, but four freshmen to program Java for a FRC robot has been lumped onto my shoulders. What should I do to help them learn how everything on the robot works and how to program it?

It’s easier to teach 4 than 1. They can help and compete against each other. Keeps the interest level up.

What should I do to help them learn how everything on the robot works and how to program it?

Find out what their individual learning styles are, and play to their strengths.

Recruit other mentors and experienced team members to “help them learn how everything on the robot works”, especially the sensors and actuators.

For those willing and so gifted, have them read the FRC Java programming documentation - and have them help teach it to those who do not learn easily from reading.

Sun (now Oracle) has an excellent on-line Java tutorial.

Make sure they understand the “big picture” early on, so they have a mental framework on which to hang all the new stuff they will be learning. Explain the development environment and the target, and how they interact. Start will the example framework that comes with the Java installation and run through the steps of building and uploading and running it on a robot. Give them confidence that this is comprehensible and actually works.

Teach them, or find someone who can teach them, the rudimentary concepts of realtime embedded programming and concurrent execution.

Make sure they each have a laptop computer with FRC Java installed so they can continue learning at home.

  1. Lucky You. I have taught FLL kids Mindstorms, and that was fun.

  2. I will teach some freshmen LabVIEW next year. I do not know how many.

  3. Start with the basics, and see how far they can go with that before introducing more advanced topics (especially classes and pointers). They will learn from experience, so having something to program (not necessarily a cRio, you can run Java code on your computer too) helps them. I have found that the easiest way to learn a language is to solve a problem, as this requires more thought then just throwing down some code for the purpose of learning the syntax. They will then learn where each object is most useful, how it can be used, etc. while thinking through the problem.

Don’t teach them to code. Teach them to program.

Don’t teach them a language, teach them how to think logically through a problem. Teach them to spend time figuring out a solution rather than coding. Make them realize that writing the code is the easy part and that finding a solution to the problem is the hard part.

When they can walk you through how to complete a given task (something simple, like drawing back your kicker) then start teaching them whatever language your team uses.

These kids already know “traditional” programming, and i wanted to get them diving into wpi java.

How should I show them what I did without making them rely on my code?

Take the robot, and show them the end result of your code, and explain the concepts in the algorithm. Don’t show them the actual code itself, just the end result and the concepts involved, then make them re-implement it as a challenge.

For example, say you have something (preferably something that is not easy to break) like a kicker. It has a motor and a potentiometer. You want them to learn about PID controls between the motor and potentiometer, so you explain the basics of PID control while demonstrating how it moves the kicker to the desired position and slows down to not overshoot. Then you let them implement it themselves, and check their results.

Unless you specifically give them the output = (setpoint - process_variable) * gain equation for P, they will almost certainly try to have some IF’s and drive the motor based on cases. Then, tell them why that is not the best way, and explain the correct algorithm, and let them try it.

I can’t resist: Show them a hole in the ground. Show them the robot (or optionally some part of their own anatomy). Describe the differences. :wink:


PS: Also, describe/teach your team’s criteria for starting and for finishing any part of programming the robot (aka Entrance and Exit Criteria for each step in the process).

The actual writing of the code is typically one of the easier parts of the process, once someone has a basic familiarity with any language.

Designing the code carefully enough before writing it takes some time.

Planning/writing Test Procedures containing appropriate amounts of detail takes some time.

Integrating chunks of code and Testing_The_Result takes time at each level of abstraction you use (units/modules/packages/components/system/whatever).

Writing repeatable, automated continuous-integration tests takes time.

Are your team’s software developers done when something they hacked together doesn’t cause the robot to catch on fire or put out an eye? or ar they done when each of the steps above has been completed and the resulting “artifacts” are ready to be understood or used anyone on the team?

PPS: I loved reading eXtreme Programming Explained by Beck. Whether or not you become a fan of everything he espouses, I think that it is packed full of wisdom (and it’s thin enough to be easily read cover-to-cover in a single weekend).

Here’s how it goes:
1.) Unix
2.) SICP
3.) K&R

What should they be taught? How to turn a wrench!

You may think I’m being flip about this, but I’m not. With the 2815/1398 collaboration this year, we had two drive bases floating around. 2815’s was assembled first, so it went off with the programmers so they could get to work. While they were heavy in programming knowledge, they proved less skilled at handling the little quibbles of any new FRC drivetrain. (Compounding this problem was the fact that their work space was on the second floor of another building about a quarter-mile walk away from the machine shop…but that’s life.) It reached the point that I spent several build sessions camped out in the room troubleshooting minor wiring and mechanical bugs just to keep them working while our kids were busy working on the kicker and the (ultimately-abandoned) hanger.

If you’ve got trained programmers, spend some of that time savings on making sure they can make minor repairs to the robot–troubleshooting the control system, fixing a bad crimp, adjusting a chain run, That Pesky Thing Your Robots Always Do–and you will reap the benefits in less down-time for the programmers and fewer drug-away-for-two-minutes moments (or, if you’re like us up there, 20 minutes) for your full-fledged hardware guys.

I agree with everyone here. You just need to teach to their own learning styles. Seeing you have 4 kids, it should be easy to teach them programming. They could split up the more complex topics and then work as a team to put it all together in all program. This is how it is done in the real world and it would definitely help them learn to cover their own parts. Using your own code could be a benefit, I know when I started programming I used a lot of open source code or snippets from other teams. (I had no previous year’s code to work with). After time I would start to see better ways to code it, or i would see errors in the code it self. You could possible mess up some of your code so they can learn to find it and fix it. Tell them they need to plan everything out and have a running chart of what needs done and what’s done. And again just make sure they all have FRC Java on a laptop, so they can work/learn at home! :slight_smile:

Teach them version control. It doesn’t matter what tool you use, but getting into the habit of documenting your work is essential.

For most teams, all of the software fits inside one person’s head, and they do most of the work. They know what things they’ve changed, and how their code works. Because of the intensity of build season, they can even keep track of things without putting in any comments. I know, because I’ve been that person before.

If you’re fortunate enough to actually have several people working on the software, keeping track of what you’ve done and what has changed is essential, even if all of your code is in one place. You don’t ever want to be stuck in a situation where “Johnny changed the code, and I don’t know what he did, but now it doesn’t work…”.

And version control programs can also keep a copy of the last version of the code known to work handy, for when the above situation happens 5 minutes before a match. Not that that will ever happen…:stuck_out_tongue:

If only we were able to do that. For some reason our subversion server doesn’t play nice with regionals.

Not to just sound pro-git or anything, but git (and some other VCS) work distributed so they don’t need a server. Sure it’s a tiny bit more work to do it, but no server.


2337 is currently looking into using Dropbox for CAD and Programming version control. So far the hardest part has been setting two instances of Dropbox up on the local server (Ubuntu Server).

Maybe I should retract or qualify my statement that “it doesn’t matter what tool you use.” Dropbox is probably a decent solution for CAD, but in my opinion, it’s a poor choice for code. Unless you’re using Pack-Rat, it doesn’t indefinitely keep track of old versions or allow you to compare them. At best, you’ll still end doing things like zipping up a copy of the code each day and giving it a datestamp. Having a solid understanding of the diff and merge tools associated with VCS software has helped me a lot both at school and at work.
A real version control system is somewhat harder to set up and requires more conscious effort to use, but it’s a move you won’t regret.

Sorry for hijacking the thread…

Thank you for the information. We are currently evaluating it and haven’t decided on it yet. I’ll probably suggest we go with a Google Code type repo for our code. I used it for FRCFeed and liked it.

We were lucky we did VC this year, at Pittsburgh, in the practice matches we were going to enable our ball recognition, but wanted to test it, so we sent it to our dashboard. But it had major bugs, and caused the robot to at some point stop recieving commands, and drive forward full speed (and its a fast one!) for a second or two, then start twitching. Back at the pit, I quickly diffed the previous version to the new version, there were two differences, vision code to zomb (dashboard), and a number tweak so our robot would be bit more managable. since another match was about to start (3 or 4 matches apart), I restored the previous version, downloaded it, and no problems! (later I figured out it was the vision code, somehow it was effecting the motors)

Subversion doesn’t need a dedicated hardware server, just a computer that can have apache or svnserve installed on it. We have a “Code Master” computer that has apache and svn installed, and is the main dev computer, and the others just hook up to it if necessary (switches are nice at competitions, no wireless to worry about).

I agree with Andrew Schreiber. A problem that I had this year with training was that I focused too much on the language and not enough on reasoning and problem solving. I would suggest learning about the people you’re training, and see how they learn best.

I agree, source control is immensely important. When I joined the team three years ago, “version control” meant “datestamped folders”. Last year I was in charge of setting up SVN on googlecode, which wasn’t used as much as it should have been. This year, we used it a lot more. (There are quite a few people on software in 166) Unfortunately, we had some issues with the internet, and so over the summer we’re converting to Mercurial, which is also better because it supports branching, and unlike Git, is built for Windows by the HG team. It saved us big time at Battlecry, when our robot stopped working right before a match and we had to go back through the revisions to find a stable one. With SVN, it would have been harder because it’s not distributed.

Git does require servers for sharing and what not, but I think Git would be easier in case I don’t have a server, which may not be often, but it’s just something else that I have to do. It’d be just easier.