FRC Programming & Managing > 20 Programmers

Technical Programming
, ,
1

Before I begin, I would just like to give some context as to who I am, and why I am posting this. I was the lead programmer for Team 694, and I’ll be graduating this year. I was really worried about how our team would fair after quarantine as not many students had programming experience, but I was pleasantly surprised when we managed to get a classroom of ~50 kids to all break up into groups and work on subsystems.

If you were to open our Conveyor Subsystem, or Climber Subsystem, you would get to see the author tags of everyone who helped collaborate on that one part of the robot. The level of collaboration that I saw was incredible. We ended up completing a 5 Ball Auton on our 4th day of testing, which not a single senior programmer/mentor even touched. We won 3 Innovation in Control Awards, which despite being a very niche award, became a source of pride within the software department.

But how was this possible, and how can you do the same? While it might be difficult to capture lightning in a bottle twice, I’ll try to list out a few things I found that helped us succeed, which hopefully you’ll find helpful as well.

  1. Prioritize Newbie Education

The hardest part about robot education is finding the right people. We had spent a lot of time creating a very inclusive curriculum for new members. We were not focused on finding the “smartest ones” or the “best programmers,” but just created an environment for people to stay after school, learn robot programming, or just do homework if they needed to. While many of them were not super involved, it created a low-stress environment that allowed those who were dedicated to really shine.

It’s the most difficult part, but if you manage to pull it off, you will reap the rewards of it very quickly.

  1. Lead Programmers, try not to write any robot code.

While this might seem counterintuitive if you are about to graduate or are a mentor, try to be as hands-off as possible when it comes to writing code. You will graduate, and your knowledge may not pass down as well as you think it will, so give your underclassmen a chance to show off. While it might make you pull your hair out trying to explain advanced concepts to underclassmen, just doing it for them robs them of a chance to learn.

  1. Organize, organize, and organize

Just because you shouldn’t be programming, does not mean you shouldn’t be involved in the process of programming. As the lead programmer, be critical of pull requests and encourage teammates to write the best code they possibly can. Organize code reviews. My team HATES code reviews, but I make them do it anyway because it catches everyone up to speed with what our robot can do, and it helps catch little errors we find.

Make sure you familiarize yourself with the subsystem/command programming model and make sure people stick to it. Life is easier for everyone when the entire robot is programmed in such a modular way. Even though I might have sent a PR back like 5 times in a row in order to fit some arbitrary “command-based model,” they thanked me later when our autons just fit together like lego bricks.

  1. Consider writing your own team library?

This one might be for the bigger teams, but my team had a lot of success with our own library called StuyLib. It was full of classes I had written in previous years and mainly helped us with things like, writing code that was gamepad independent, having all our constants on SmartDashboard in an easy way, ramp our driver inputs for smooth driving, read from the limelight, or just fun ways of processing sensor data. All these things were a lot of fun for me to write, but they helped make the lives of the underclassmen easier, so they could focus on programming the robot instead of writing wrapper java classes.

It also allowed some of our students to work on a side project without affecting our main code base. One of our students was really interested in writing an Interpolator Class that would let us shoot from anywhere. So he decided to write it in StuyLib, allowing him to then import it into the robot code and use it very easily.

WPILib does do a lot of things for you, and it always feels bad when they implement a feature you worked really hard on, but there are always other fun things to implement for your team. Just be sure to document and keep your code open-source, nobody likes private repos, especially in FIRST.

But as FIRST continues to grow, and computer science becomes more and more popular, the issue of how to collaborate effectively will become even more important. These tips are in no way complete, as they were just what popped into my head while writing, so if you have any more tips, be sure to drop them in this thread.

41 Likes
2

Thanks for posting this. Can you talk more about your curriculum? Do you have documents or slides you can share? Tasks or assignments?

5 Likes
3

Totally, our entire curriculum was in the form of slides on google drive, which you can totally take a look at. However, I would recommend making sure that your members are making slides, as it makes it easier to teach and lets you adapt the curriculum depending on how well your members are following.

22 Likes
4

These are really great, thank you.

2 Likes
5

So our team has our own slides that are similar to the slides that your team uses to teach programming. However, one of the most glaring issues for us this year was that only those who were already experienced with programming continued to do programming. How did you manage to keep a balance between engaging those experienced with programming and keeping those new to programming on track? We had assignments and projects for them to do, but it was difficult for many newcomers to understand and grasp the concepts. We also had biweekly meetings that lasted about 30-40 minutes each and made sure not to rush through content.

2 Likes
6

You have to run two separate curricula. Learning language syntax and semantics is a necessary prerequisite to learning how to code a robot; it’s very hard to teach both at once.

3 Likes
7

@Andrew_L did you see this thread?

I wonder if similar structures could be implemented in the mech design side - seniors having younger designers put each piece together and manage the overall integration and methods instead of specific subsystems solutions.

3 Likes
8

Ooooh, will definitely read through this. Thanks, Sam!

9

This is very difficult, we used to run 2 separate where one would teach how to program and another would be more robot oriented, but it was usually less effective at retaining members as you would split your resources up.

As long as you provide an environment where people can make friends, people who already know programming will just be able to spend more time meeting people. But different high schools vary so what works for us might not work for you.

2 Likes
10

Also worth noting is that the curriculum changes every year. You can still reuse a lot of materials. But the exercise of determining how to make it fit the team you have each year is a valuable exercise. Priorities change. Skillsets change. You learn from what people were confused about how to make it better.

The team has already started doing that for next year’s newbies. For example, last year we weren’t hands on with the robot as early as would have been ideal. Not enough people knew how to flash, etc. So next year’s outline already deals with that.

ps - I’m a mentor on the team Sam wrote about. The kids have never seen me write a line of code. It’s their robot. I shouldn’t be typing!

5 Likes
11

I see what you mean as our school is in a similar environment to that of @Oblarg which has people having large extremes of coding experience. We currently are deciding on whether to split up into different smaller groups or still follow a one group model, but I think we’re moving more towards the multiple group model as a singular large group hasn’t worked too well for past few years we’ve been doing it.

Some other questions I have are: How many people aided in the teaching or curriculum process? How did you handle individuals not learning the content as quick as most others? Out of the ~50 kids, how many stayed till kickoff and competitions?

2 Likes
12

out of the 50 kids about 30 stayed until kickoff, and while not all of them did stuff, then seeing the code and watching the robot play inspired them to stay. We have like 5-6 groups of people working on newbie eduction and they prepare slides and prepare to teach. The group is mostly made of sophomores and juniors, while the slides are edited by juniors and seniors, as it can help younger members solidify their knowledge.

2 Likes
13

The slides are wonderful and a great help. Do you have the slides for folder 10 it is empty.

14

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.