What New FIRST Programmers should be taught

[Robototes2412]

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?

[apalrd]

Originally Posted by Robototes2412

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.

[gblake]

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.

Blake

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

[MPlant]

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

[Billfred]

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.

[Dustin Shadbolt]

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!

[StevenB]

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

[EricH]

Originally Posted by StevenB

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

...

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

[Radical Pi]

Originally Posted by EricH

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

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

[Tanner]

Originally Posted by Radical Pi

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.

-Tanner

[byteit101]

Originally Posted by EricH

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

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)

Originally Posted by Tanner

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.

-Tanner

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

[demosthenes2k8]

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.

[Andrew Schreiber]

Originally Posted by StevenB

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

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

[StevenB]

Originally Posted by Andrew Schreiber

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

[Andrew Schreiber]

Originally Posted by StevenB

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.