FRC Primer for Programmers

[rich2202]

As my summer project, I am going to create a power point presentation to train new programmers. Note: I am not trying to teach them Java or C++.

A rough outline is something like this:

1) Overview of the Game
Autonomous
Teleop

2) Overview of the Hardware
RoboRio
Driver Station
Connection through FMS


3) Overview of FMS
Robot Init
Autonomus Init
Autonomus periodic
Autnomous continuous
etc.


4) RoboRio I/O
PWM
DIO
AIO
Can Bus
etc.

5) RobioRio/Driver Station interaction
D/S is like the keyboard/monitor, roborio is the computer

6) Structure of our code

7) Joysticks
x box controller
debouncing buttons
"dead zone" for joystick (not 0,0)

8) Motor controllers
ramping up acceleration
break/coast motor controllers
encoders

9) Sensors

10) WPI Lib

11) compiling and deploying code

12) Networking details
10.TE.AM.xx
Fixed vs dynamic IP addresses
Default Fixed IP Addresses
Router
RoboRio
Driver Station
Camera


Outlines, slides, docs, would be appreciated.

[Ether]

A rough outline is something like this

Where do state machines and parallel processing fit into your outline? These are areas where many new programmers struggle mightily.

[Saventi]

I made bunch of documentation to train new programmers for the recycle rush competition. Most of it focused on teaching java, but there are some bits on stuff like setting up a radio and whatnot. Most of it is still on our trello board (https://trello.com/b/hKjRwV4B) that we no longer use if you want to look through it.

[teslalab2]

could you also touch on P.I.D's?

[virtuald]

Sounds like a great idea. I've done something vaguely similar (though, it needs to be expanded) for RobotPy. Check out my anatomy of a robot (http://robotpy.readthedocs.io/en/latest/guide/anatomy.html) page.

[GreyingJay]

I'll be interested in watching the progress of this as well!

[phurley67]

Personally, I would also throw in a bit about version control, network tables, and logging.

[doge-in-a-bush]

I'd be really interested to see the powerpoint when you are finished!

[Dan Waxman]

If you're up for it, I've wanted to make YouTube videos for this stuff for a long time now. Maybe we could correspond in writing material then I can make videos explaining everything? Please PM me if you're interested. Thanks.

[WSiggs]

Is there anything like this already for java out there other than what's on the wpilib site?

[Katie_UPS]

2) Overview of the Hardware
RoboRio
Driver Station
Connection through FMS


3) Overview of FMS
Robot Init
Autonomus Init
Autonomus periodic
Autnomous continuous
etc.


.....

12) Networking details
10.TE.AM.xx
Fixed vs dynamic IP addresses
Default Fixed IP Addresses
Router


Why do they need to know this in depth? Why is "Deploying Code" not closer to the top? You're going to bore 99% of them to death. Why would I as a high school student spend my summer watching power-points on dynamic IP addressing?

Its cool to teach them everything (though most of it isn't really necessary, just interesting to some), but get them interested first. If they signed up for "learning to program" maybe programming should be in the first few topics.

None of this is going to have any context until they start writing code anyways, so why not start with code?

Personally, I would also throw in a bit about ...network tables

Again, what does this add? How does this help them write an autonomous program? If a student shows interest in the deeper parts of how-things-work then explain it (or if it becomes a relevant lesson because of a problem they're having).

They're not starting Computer Engineering. They don't need to know the networking layer right now, or how the FPGA in the roboRIO works... It's cool and useful eventually, but you're just going to scare away anyone who doesn't think they're smart enough.

[Jaci]

Why do they need to know this in depth? Why is "Deploying Code" not closer to the top? You're going to bore 99% of them to death. Why would I as a high school student spend my summer watching power-points on dynamic IP addressing?

Its cool to teach them everything (though most of it isn't really necessary, just interesting to some), but get them interested first. If they signed up for "learning to program" maybe programming should be in the first few topics.

None of this is going to have any context until they start writing code anyways, so why not start with code?



Again, what does this add? How does this help them write an autonomous program? If a student shows interest in the deeper parts of how-things-work then explain it (or if it becomes a relevant lesson because of a problem they're having).

They're not starting Computer Engineering. They don't need to know the networking layer right now, or how the FPGA in the roboRIO works... It's cool and useful eventually, but you're just going to scare away anyone who doesn't think they're smart enough.

I have mixed feelings, some disagreements and some agreements.

Learning about the hardware in the robot is important. We're not building desktop applications here, we're building applications that make a robot run. Students are learning to program for an embedded system, and with that comes some limitations and gotchas that don't come with regular programming lessons. For this reason I think (2) should be included.

FMS -> If your robot is dead on the field, your electrical and programming teams will be the first port of call. Most of FMS is a black box, but things like Periodic and Iterative functions are important as they're important for the control of your robot. I've taught FRC software classes before, and I've had many students come up to me and as "wait, so why do we run the same code over and over again? Can't we just put it in init and it will work?". Students need to understand how states in the robot work, otherwise their code is just plain not going to work. If you look at any child of the RobotBase class, you'll see the words "{state}Init" and "{state}Periodic" pop up very commonly. This grants (3) a pass in my book.

(12), Network Details. Robots don't always work, especially when they're on the field with 6 other robots. While this isn't as important as the other topics, and maybe shouldn't be included in the general, introductory course (sorry op), I think it has a place in more advanced classes maybe later in the pre-season. I'd have to agree that it doesn't belong in the 'primer' course.

NetworkTables. I'd recommend swapping this out for SmartDashboard in the primer, since most of the time (unless your programmers have spare time), you won't be dealing with your own network data transport. I'd have to agree that this doesn't belong in the primer, either.

When you're providing a primer course to students, you're setting the foundation for what they'll do later on, when they start to get more in depth and more advanced. Unfortunately in FIRST, a lot of the code resources are just examples without any real explanation, which places some programmers into bad practices, or in the horrible state of knowing but not understanding. Understand first, execute second. Not the other way around.

~Jaci

[Katie_UPS]

FMS -> If your robot is dead on the field...



cut for length: I do agree that a lot can be useful, and you brought up some points I didn't think about.

My suggestion OP is that you reorder your topics. Start with what gets them hooked: writing a program, making a robot drive. Expand from there. Focus on whats the most relevant to making a robot move and work your way out. Save advanced topics for advanced students. No one starts out robot design with stress analysis and motor-curves. Programming is already scary and daunting for some students. Don't push them out by making it harder/more complex than it needs to be.

[rich2202]

The intent is to give a high level overview. Not to make them experts. The idea is to give them context for what they will see in the production robot code. Knowing the sequence of calls from fms helps in understanding what gets called when in the robot code.

Once the high level overview is created, I could see expanding each topic to a more in depth tutorial.

Note: the purpose is not to entertain. That is for others to work on. The purpose is: in order to understand the code, here is what you need to know. Enough to understand, not enough to program.

Sitting around watching the experienced programmers is no fun if you have no idea what they are doing.

[rich2202]

Why do they need to know this in depth? Why is "Deploying Code" not closer to the top? You're going to bore 99% of them to death. Why would I as a high school student spend my summer watching power-points on dynamic IP addressing?


It is an overview, not in depth. It is a one session overview, not a summer long class. The summer is for me to put it together.

Deploying code is at the end because that is the last thing you do.

The idea is: when something happens, and the programmers start looking at ip addresses, they have a context on what is being debugged. As they gain experience, when something goes wrong, they have some idea where to start looking.

[jweston]

As my summer project, I am going to create a power point presentation to train new programmers. Note: I am not trying to teach them Java or C++.

May I suggest a slightly differnet approach in order to avoid information overload? Start with a simple code exercise that gives an immediate result, such as making a tank drive train move forward. Let the new students create the project, write/copy the code, and deploy it themselves to see it run. Let the students make simple modifications to the code, such time or distance constants.

As you walk through this simple exercise, you can use additional power point slides to discuss some of the basics like init vs periodic and what the various modes mean. You can also use it to intro tools like the debugger. Having students engaged in a concrete example gives much richer context to what you're saying than having it in power point by itself. This is definitely a time to keep it simple.

Once you've covered what you can through that exercise, decide what you want to illustrate next and design another interactive exercise. The important parts are keep it focused and keep it interactive.

The outline you have strikes me as being great for a reference. A reference provides great value in case someone wants to do some more in-depth reading on a particular topic.

It's tempting to try to ground new students thoroughly in How It All Works. But it's so much more important to not make new students drink from the firehose of information. They will learn through guided doing.

Sitting around watching the experienced programmers is no fun if you have no idea what they are doing.

Sitting around watching the experienced programmers is never fun. Listening to lectures is not fun. Writing code and watching it work is fun.

[Ether]

Listening to lectures is not fun.

Not true as an unqualified general proposition. Some students enjoy and thrive on lectures.

But you're probably correct that most new programmers will thrive better with hands-on simple exercises to get them started and pique their interest.

[jtrv]

Deploying code is at the end because that is the last thing you do.

I'm not sure if this is a perfect idea. I understand where you're coming from- but personally, if I sat through a lecture on a library and I wasn't shown how it deployed until the end, I would be constantly wondering and trying to figure out how it all works together until the lecturer finally shows it at the end. I'd wind up distracting myself from the more important content at hand. I think showing that it is as simple as hitting Build on whatever development setup you have going is a good thing to show at the start. Say that for now, it just sends the code to the router and compiles it or what have you, and that you'll address it more in-depth later.

Just my $0.02 as a student in the middle of many years of lectures.

[jweston]

Not true as an unqualified general proposition. Some students enjoy and thrive on lectures.

Fair enough. :) I've been known to enjoy a lecture on the likes of ancient Crete or partical physics. No reason someone shouldn't enjoy an engaging lecture on the finer points on, say, control system programming theory.

I think we can agree that competitve coding as a spectator sport is not likely to take off any time soon. ;)

[Monochron]

It is an overview, not in depth. It is a one session overview, not a summer long class.
It still sounds like "one session" is going to take quite a while. If your goal is get students interesting in working on the robot programming, you may want to give higher priority to piquing that interest.

Deploying code is at the end because that is the last thing you do.
Are they not going to deploy any code until the very end? I guess it depends what your goals are for this class. If you have students who are already programmers or who are already certain that they like programming, then you don't need to get them hooked first. And the topics you have planned are all definitely necessary if you want to build a strong programming team. But if you are hoping to grow your programming team with this lesson plan, I'm not so sure.

[rich2202]

It still sounds like "one session" is going to take quite a while.

Maybe 2. But definitely not an entire semester.

If your goal is get students interesting in working on the robot programming, you may want to give higher priority to piquing that interest.

Oddly enough, piquing their interest is not the goal. Over the last few years, the team has grown from 30 to 70+ students, with 15 of them programmers this year. In the past 2 years, the programmers have been pretty autonomous of the Mentors - we pointed them in the right direction, and they did it all themselves. Unfortunately, the 2 strongest programmers graduated this year.

The goal is to make sure everyone has a high level overview of how the robot works (code wise).

Are they not going to deploy any code until the very end? I guess it depends what your goals are for this class.

For the 1 or 2 (or whatever) number of sessions, it is purely lecture. No coding. Once everyone has a foundation of the basics, then the programmers can have at it - "Hello World" exercise, or whatever they want to do.

If you have students who are already programmers or who are already certain that they like programming, then you don't need to get them hooked first. And the topics you have planned are all definitely necessary if you want to build a strong programming team.

That's the plan.

But if you are hoping to grow your programming team with this lesson plan, I'm not so sure.

At this time, growing the programming team is not a priority. This year, we had too many. It was challenging keeping them all involved. I was trying to get the 2 lead programmers to become more Project Managers and divide up the tasks, but that didn't work so well. Fortunately, one is hopefully coming back next year as a Mentor. Definitely needs to be more hands off as a mentor. It will be interesting watching a College Freshmen develop management skills.

[AlexanderTheOK]

with 15 of them programmers this year.

Oof. Well there's your problem. Thankfully (or oftentimes not), on both teams I've participated on, programming hasn't been the greatest interest, so for teaching I've generally got one robot/roborio per student/2 students.

I do have to say though that a lecture on basic FRC programming would bore the crap out rookie student me. I would have remembered very little, and decided I wanted to build stuff, taken the more tangible safety certifications, and started machining/designing parts.

Thankfully, instead of a lecture, we got to write some code for an old robot and make it run. I've found that this strategy works rather well in general. It means the student is more willing to read documentation on their own with the idea ahead that it will lead to more of the robot functioning. I say this having both trained my successors for two years as a student and mentoring a team through it's switch from LabView to Java.

Of course, I doubt many teams have ceil(15/2) = 8 mostly identical robots to program on, so you're in a bit of a pickle. If I was in your situation I might have broken up the students into several sessions so they could all take a crack at making a robot work.

However I am not in your situation. Best of luck.