What New FIRST Programmers should be taught

[Robototes2412]

Hey,

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?

[Ether]

Originally Posted by Robototes2412

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.

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.

[apalrd]

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.

[Andrew Schreiber]

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.

[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

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