Is it required to use 2017 control system?

I don’t feel like reimaging the RoboRIO, installing other C++ stuff, etc.

I dunno, take a look at this year’s rules.

You are going to be in for a bad time, my friend.

If re-imaging the roborio and installing some updates is too much work, you’re in for a rather rude awakening when you see just how much more work is needed to make a functioning FRC robot in these 6 (now 3) weeks.

Is it required to use 2017 control system?

Only if you want to compete in 2017.

Sorry folks, but I can’t pass this up. . .

Was this question posted by RyZeRun, or by LazyRun?

If you do become interested in updating everything, 4513 is willing to help you guys. Feel free to message me and ill get something set up.

I will remark that it is highly inconvenient that you have to update everything to the 2017 versions during build season. Our team has recently moved to a persistent framework from which we build all our code, and updating all of our legacy code to work with the new versions of all the software is a huge job. It’d be lovely if this stuff could be released a few months earlier…

You can access development versions of WPILib from their github page and from their maven.

If you want even more stuff, you can always apply to become a beta testing team.

Remember that if you do, you must open source your code before the start of the new season, or it will not be legal to use during competition.

Hmmm… I don’t recall our team having to do much, if anything. What changed that requires updating legacy code?

I know when we went from crio to roborio, there was a big change. However, I don’t recall our programmers complaining about code not running on updated roborios.

That’s curious, because 2016 code pretty explicitly does not run on 2017 roborios for us. Lots of dependencies break.

Should be mostly CANTalon and CameraServer dependencies, no? Those are easily fixed.

For teams that use Command-Based C++, the changes are significant. Our team spent several frustrating hours getting a Command-Based C++ project built and running. The biggest hurdle was the fact that ScreenSteps has not been updated for 2017.

It has.

In the section “Command Based Programming”, the only page that has been modified in the last 18 months is the one titled “Simple subsystems” and all the code examples on that page are in Java (despite the fact that the page is in the C++ section).

Yes, the sections on installing were updated for 2017. My point is, I don’t feel ScreenSteps does enough to explain how Command-Based changed so much with 2017. The core concepts are the same, but the implementation has changed quite a bit.

These are some of the (many) reasons that we abstract WPILib away from our code as much as we can. IMO other teams that want to reuse code year to year should probably try to do the same.

Updating WPILib and reflashing everything is still a pain, but it’s much less so than if we did things the WPILib way of doing them.

I believe the significant changes occurred prior to the 2016 season, not the 2017 season. Can you explain the changes you found this year that are causing issues?

Seconding this. We were a beta team and we had our command based code build perfectly, and it all went fine except for a minor non build related bug. (which is good since we couldn’t find the beta porting guide :eek: )

Here’s the history on key command-based robot header files:



The change that would definitely break things at compile time is the namespace change. According to the commit message, it requires a one line change to fix.

Even in a large robot codebase, it’s probably a 10 minute job to fix. Easier if you have a shared header file throughout your codebase – for many teams that would be robotmap.h.