What to use!

Technical Programming
1

I am the new head programmer for my team this year and I would like to switch to command based programming but nobody else seems truly on board with it as it is very different. As of now, there is only one other programmer. What does everyone else use and what are the advantages?

2

Yes, it’s quite different than the approach used for sample and even iterative. That’s actually a good thing. Command-based programming makes it much easier to properly decompose your code into small manageable chunks, which is essential even if you were the only coder, but it becomes critical when you have the number of people programming which you seem to have.

Note that the command-based codebase is being re-done this year. It should fix a lot of the weird interdependencies of its parts, and be far easier to use, especially for building complex functionality out of simple commands. You can see the topic below for more details. If you do go command-based and are starting fresh, I recommend going straight to this version and not learn the weirdness that is going away.

1 Like
3

The (WIP) docs for the new command-based framework can be found here:

https://frc-docs.readthedocs.io/en/develop/software.html#command-based-programming

4

IMO the iterative system is going to be simpler. The command system is a decently complicated abstraction and you should be confident that you can debug it if something goes wrong. I remember back in 2012/2013/2014? when NetworkTables caused a bunch teams’ robots to freeze. Those bugs have long been fixed but I’m still left with some skepticism towards WPILib, take that as you wish.

TL;DR just make sure you really understand your abstractions before you rely on them.

Here’s 1114’s very clean TimedRobot code if you’re interested in a reference point: https://bitbucket.org/kaleb_dodd/simbot2018public/src/master/

5

Is there a guide to using the new command based framework? I would like a couple of my programming kids to try it out this summer, but not sure what is required to test it out.

Maybe the question is how do you build wpilib from source and then link that to an existing robot project?

6

It hasn’t been merged yet, so it’s a bit difficult to use; you could use jitpack to add the version on my github as a dependency.

1 Like
7

We use Java iterative for our bots. We switched this year from command based because we wanted more control over how the code worked.

That all said, I have a few questions for you. What is your teams level of code? (Commonly use sensors? Do your autos work well? Have you used PIDs successfully? How about your teams level of knowledge about vision?)

Finally why do you want to move away from iterative?

8

I don’t see anywhere what OP was using last year, except that going to command based would constitute a switch. It could have been LV or Python for all I can tell. Do you have more detailed info?

Simpler for whom, based on what assumptions? I’ll admit that it took a while for me to wrap my 1980s/1990s programming brain around command based programming, but students always seem to grasp at least enough of it to work with far more quickly than sample or iterative, and once I had an OO-epiphany*, I currently can’t imagine a reason to program an FRC robot with sample or iterative/timed unless you’re pushing the metal to its limits.

* Personally, I had my OO epiphany in the mid-90’s, when I was the only person I knew who was interested in java for anything other than web apps. My first exposures to OO programming was most of a decade earlier, but I recognized (1985?) that Ada was probably never going to be a real thing for reasons I couldn’t pin down, and that (1989?) C++ is just a sneakier to point links to the wrong place, so I never spent enough time with either for the epiphany.

9

Well, I’d like to switch because it is much more organized for me and it is easier in my honest opinion for new programmers which I have to teach to see where the errors exactly are coming from. Also, for whatever reason our robots run much smoother when running on command based.

10

Well, the other coder isn’t so proficient but I program for my job so I’d call myself quite proficient and we have had very much hasn’t luck with vision programming and sensors are a whole different story as we couldn’t get any input from our sensors at all and I can guarantee all my code was correct.

11

I’ve put the command rewrite (minus a very small number of changes to objects not in the experimental namespace) into a separate project, so it can be easily jitpacked by early adopters:

4 Likes
12

Thanks, for first timers (me), I think you want do the following to your build.gradle file (see below for full file):

// Maven central needed for JUnit
repositories {
   mavenCentral()
   maven { url 'https://jitpack.io' }
}

dependencies {
  implementation 'com.github.Oblarg:command-rewrite-jitpack:1.1.2'
Summary 
plugins {
    id "java"
    id "edu.wpi.first.GradleRIO" version "2019.4.1"
}

sourceCompatibility = JavaVersion.VERSION_11
targetCompatibility = JavaVersion.VERSION_11

def ROBOT_MAIN_CLASS = "frc.robot.Main"

// Define my targets (RoboRIO) and artifacts (deployable files)
// This is added by GradleRIO's backing project EmbeddedTools.
deploy {
    targets {
        roboRIO("roborio") {
            // Team number is loaded either from the .wpilib/wpilib_preferences.json
            // or from command line. If not found an exception will be thrown.
            // You can use getTeamOrDefault(team) instead of getTeamNumber if you
            // want to store a team number in this file.
            team = frc.getTeamNumber()
        }
    }
    artifacts {
        frcJavaArtifact('frcJava') {
            targets << "roborio"
            // Debug can be overridden by command line, for use with VSCode
            debug = frc.getDebugOrDefault(false)
        }
        // Built in artifact to deploy arbitrary files to the roboRIO.
        fileTreeArtifact('frcStaticFileDeploy') {
            // The directory below is the local directory to deploy
            files = fileTree(dir: 'src/main/deploy')
            // Deploy to RoboRIO target, into /home/lvuser/deploy
            targets << "roborio"
            directory = '/home/lvuser/deploy'
        }
    }
}

// Set this to true to enable desktop support.
def includeDesktopSupport = false

// Maven central needed for JUnit
repositories {
    mavenCentral()
    maven { url 'https://jitpack.io' }
}

// Defining my dependencies. In this case, WPILib (+ friends), and vendor libraries.
// Also defines JUnit 4.
dependencies {
    implementation 'com.github.Oblarg:command-rewrite-jitpack:1.1.2'	
    compile wpi.deps.wpilib()
    compile wpi.deps.vendor.java()
    nativeZip wpi.deps.vendor.jni(wpi.platforms.roborio)
    nativeDesktopZip wpi.deps.vendor.jni(wpi.platforms.desktop)
    testCompile 'junit:junit:4.12'
}

// Setting up my Jar File. In this case, adding all libraries into the main jar ('fat jar')
// in order to make them all available at runtime. Also adding the manifest so WPILib
// knows where to look for our Robot Class.
jar {
    from { configurations.compile.collect { it.isDirectory() ? it : zipTree(it) } }
    manifest edu.wpi.first.gradlerio.GradleRIOPlugin.javaManifest(ROBOT_MAIN_CLASS)
}
13

From my experience, I can tell that comand based can be very unpredictable, especially when combined with PID controllers, where commands don’t act as you would expect them to (especially isFinished() method). Also, the number of files in command based code can get up to twice as much as you would have in iterative. That makes it difficult to look for an error (or read through the code, trying to understand it).

14

I expect isFinished() to return true or false. Is it doing something else for you?

15

I actually disagree 100% with everything you’ve stated here.

Splitting code into different files actually makes it easier to debug and read, not harder. You’ll typically know based on the behavior what section of code the bug will be in because each piece of separated code is going to be doing something specific. It also reduces the amount of code you have to read at a single time which makes understanding that small piece that much easier.

I would like to point out that NetworkTables and CommandBased are completely separate entities. NetworkTables is actually shared between all of the structure implementations, not just CommandBased.

For anyone interested in learning more about the CommandBased structure here is a presentation that our team has been giving for years. I have the intent to do a video series if I can find the time.

3 Likes
16

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