Your Team Sucks At Programming: Here's Why

Your teams main problem was most likely in project scoping and project management. No piece of code or mechanism should be expected to work first time. It typically requires 3 to 4 iterations to get something that is acceptable for use in competition. This point of view comes from working with many robotics teams in various leagues and from doing new product development for many years.

I’d second this advice. Between adding various set points and variables the code I’d estimate the code for our robot was modified well over 500 times in the course of the season. Just the intake wrist alone probably went through 50 refinements. Step 1 is to get it to stop at approximately the right height for objective #1, then fine tuning that. Then code for objective #2 and tuning that etc.

During build as you are settling on and solidifying the mechanical design for various parts of the robot, you should already be noting what type of code will be needed to make it as effective as possible. Will it be purely operator controlled? How much code will that require? Will it require multiple positioning capabilities? How much code will that require? Write down the various possibilities and what will trigger those to be executed. These would typically be:

  1. code from a related component
  2. Human input
  3. Input from a sensor

Depending on the game and the mechanism, you might find you require 20 major functions (on the high side but possible) just for a single mechanical component. If this is already going to be a challenge for the team’s level of programming ability and speed to deliver, it may impact what mechanisms you actually choose to build.

I think a lot of teams believe that the mechanical portion of the build is where they are overly ambitious when in reality it may be developing suitable code that causes things to fall behind.

1 Like

It sounds like the problem was something other than having the code written early. It’s possible that if you hadn’t had the basic code written in advance, your team would have fielded a door stop.

This is huge. If you have a spare control system (if not, seriously think about getting one) build your team a plybot, which is a control system mounted on a board with all the standard stuff you use (motors, controllers, sensors, etc). The next level is to take an old chassis, with your team prefered drive train and mount the control system on that. That gets you a fully drivable plybot, with the ability to mock up most of the standard mechanisms, while the design&fab team is just coming out of prototyping. It obviously will require tuning and sorting out the PID values but done right you can run the full robot code on it. Plus validate motors are tuning in the right direction, before you deploy to the potentially breakable real robot.

The code should be written and tested before you actually have the real robot. All that should be left is the fine tuning.

The plybot also gives the design&fab team something to test prototypes and modular mechanisms on.

1 Like

This is almost never actually the case unless you have a bunch of mentors who specifically know LabView.


Honestly, even then… The skills using LV in an industrial setting don’t necessarily prepare you for the quirks of using it in FRC… That goes for any of the FRC languages though.


I split off the discussion of the RoboRIO as a general purpose computer since it wasn’t really related to this topic.


I can definitely second this. Our 2018 code was only thoroughly commented after the fact and it is a jumbled mess. We made a concerted effort to make quality comments and held regular code reviews to make sure everyone understood what the code was doing.

One point I would add to this section is to avoid band-aid fixes, such as what we did by using a gyro-based drive PID to fix an underlying veer problem caused by the limit switch plugged into the drive talon putting it into break mode when it was pressed. This came back to bite us in Asheville, which as you can see we lost in rather humiliating fashion.

Emphasis mine - this is the important part. Many times, people take “you should comment you code” way too far and you end up with many meaningless comments that simply reiterate line of code below. It’s more important that your comments document why the code is doing what it is rather than what it is doing.


Is the java you learn on let’s say codecademy the same as the java you use in FRC?

Yes and no. You’ll learn the java basics from codeacademy but none of the FRC specific structure and objects.

1 Like

If you’re using PWM, you can also use servos for this sanity check.

1 Like

C++ isn’t faster enough to bother using it right.
While I’m on the subject of languages, does it still take forever to compile and deploy LabView? I saw a team stand around for like five minutes waiting for their code to deploy in 2017. (GradleRIO wasn’t much of a thing at the time but it was way faster.)

This has been so frustrating for me. We have AP Computer Science… Principles. There’s a few problems there:

  1. It’s not Java. The class has been taught in Python and Javascript, I think it’s currently Python again?
  2. (at least when I took it) it doesn’t cover OOP
  3. Very few people seem to enjoy or get much out of the class. Might be biased here.

This is one of the big problems I see (from my limited POV) - having to teach kids Java or any language to a level of proficiency, often starting from nothing, in four to five weeks is ridiculously hard (maybe harder than teaching CAD or machining, but IDK.)

The right answer to the problem. When does ScreenSteps/its replacement get a git tutorial?
(Hey by the way - it’s way easier to comply with the “release previous work” rule when you already have a GitHub or GitLab repository to make public.)

Hey. I gotta secret. Come closer. Closer. Lean right on in.

If you know what’s going on the robot by week two, you can probably sketch out some Subsystems and such. In the platonic ideal FRC team, you could probably give each prototyping group one programmer to work on a VCS branch that follows the prototype. (See also: git-flow for how to organize that many branches.)
Scrolling through the thread, someone basically already said that entire paragraph but /shrug

Please do this. I would still be floundering in C++, would be totally sidewinded by GradleRIO, and probably a bunch of other stuff if our mentors didn’t do this.

1 Like

My suggestion for this is, don’t. Only teach the FRC specific stuff and they’ll pick up the rest as you go along.


Right, but to understand what the heck is going on in FRC specifics, a student needs to have at least a foundational understanding of Java or C++ or what have you - mostly object-oriented programming.

// some "real" snippets of Java robot code
// pretend you're learning to program, possibly for the first time ever
// with this sort of code
TalonSRX talon = new Talon(RobotMap.DRIVE_LEFT_MASTER);
public class LiftArm extends Command {
    /* etc */
someButton.whenPressed(new MemeCommand(0.5));

A student might grasp what these do if they’re really smart (make no mistake, almost all kids in FRC are smart) but they’ll only know it as “the magic words that make the robot do the thing.” With that level of comprehension… sure you can drive a robot around, you can compete, but adding new things you don’t have examples for on-hand will be much more challenging.
(Fun fact, one of the reasons we abandoned C++ was due to the fact that I was the only programmer and I didn’t understand it well enough to actually program a new robot.)

If someone on CD says “oh just make an instance of UsbCamera and …” and you don’t know what it means to “make an instance of X” you’ll have a hard time not only following the given advice but maybe even getting it at all.


Yes. Sometimes while we wait around for a “simple” fix to compile and deploy, I imagine how many paper cuts I could get to numb the pain.


Yes. The LV build process has nothing to do with the GradleRIO switch for Java / C++.

True that, APCSP is not APCS unfortunately.

Couldn’t agree more, and it’s something I’ve been advocating with the teams I work with, and my own team for the coming season. This as much a public gripe list as a personal benchmark.

True that, but my students also catch me off guard too, we’re all learning together. Just gotta do our best.

1 Like

Which is why 6844 teaches CAD, programming, machining, etc., before the build season. IMO, the offseason and preseason is the time to learn. The build and competition seasons are the times to apply what you’ve learned.

If you’re saying “with the time frame you’ve described, then this is probably what will give you the most bang for your buck,” then sure, I guess. But if you’re saying that only covering FRC-specific stuff is going to give someone an optimal programming experience, I disagree.

I often take several hours in preseason whiteboard discussions to demystify things. The why is so much more important than the what.

Some examples:

  • I spend at least two or three 30-minute sessions on the distinctions between static vs. stack vs. heap memory allocation. This does wonders for understanding why primitives are passed by value, but why objects are passed by pointer. Stack overflows now make sense too – because they know what the stack is. And with a bit of C/C++ history, it also makes it much easier to understand the new and static keywords in Java.
  • One or two sessions on design patterns. Understanding singletons makes understanding some WPILib calls make sense because they use the pattern. Plus, these patterns help us write better code - we came pretty close to rewriting a subsystem to use the state pattern, for instance.
1 Like

I do neither of these things until the students would get to a spot where they would need the information. I’d rather get them writing a basic robot then bog them down in learning the languages, especially memory management.

See, here’s the thing. When teaching object oriented programming, do you know what you are supposed to start with?

Hint: It’s not helloWorld


Maybe there’s something weird going on in the FRC stuff, but with the standard LabVIEW + RT module, it takes 5-10 seconds to deploy to a cRIO after the first time.