Is it required to use 2017 control system?

[Oblarg]

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...

[Jaci]

Originally Posted by Oblarg

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.

[rich2202]

Originally Posted by Oblarg

updating all of our legacy code to work with the new versions of all the software is a huge job.

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.

[Oblarg]

Originally Posted by rich2202

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.

[ollien]

Originally Posted by Oblarg

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.

[KPSch]

Originally Posted by ollien

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.

[euhlmann]

Originally Posted by KPSch

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. http://wpilib.screenstepslive.com/s/4485

[KPSch]

Originally Posted by euhlmann

It has. http://wpilib.screenstepslive.com/s/4485

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.

[Joe Ross]

Originally Posted by KPSch

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.

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?

[bobbysq]

Originally Posted by Joe Ross

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 )

[MrRoboSteve]

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

Command.h

CommandGroup.h

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.

[KPSch]

Originally Posted by Joe Ross

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?

Our team always uses the FRC Eclipse plugins to generate new command-based project as well as create new commands and subsystems. We feel reasonably sure we were careful and installed the 2017 plugins. However, the new project that got created would not even compile (with no changes made). New subsystems and commands don't compile either. It's possible we don't have the plugins installed correctly or are inadvertently using the 2016 versions. It's something we plan to double-check after we get some forward momentum after spending all of Saturday trying to get a simple project to drive the robot.

We finally were able to make some headway by making a quickie project with RobotBuilder. What it generated looks WAY WAY different from past years and from what the project wizard in Eclipse makes. RobotMap was the biggest change. It's no longer a simple header file, but a class with static member variables.

This is our team's fifth (or sixth) year using command based C++, so we certainly have some experience using it. I'm hoping we just accidentally reinstalled the 2016 plugins or something. That would explain a lot.

[wesleyac]

Originally Posted by Oblarg

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...

Originally Posted by KPSch

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.

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.