FRC Primer for Programmers

[rich2202]

Originally Posted by Katie_UPS

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.

[jtrv]

Originally Posted by rich2202

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.

[Monochron]

Originally Posted by rich2202

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]

Originally Posted by Monochron

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]

Originally Posted by rich2202

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.