[FRC Blog] Control System Update

[SoftwareBug2.0]

Originally Posted by ollien

Not psyched about the WPILib changes, but it is what it is. I understand the sentiment behind it, but CANJaguar and CANTalon just seem like two hugely integral classes to remove.

What's done is done, I guess. I suppose I'm more not psyched to be debugging build path errors than anything. (Though, in theory, and not reality, those shouldn't happen.)

Perfection is less about effort or skill than it is about having a clear and limited goals. If this is a sign that the WPIlib authors are looking to reduce scope then I'm happy because it means that their efforts can be more focused on fixing their existing problems. If it turns out instead that they've taken this as a chance to implement some crazy plugin architecture I will be less pleased.

[calcmogul]

Originally Posted by SoftwareBug2.0

If this is a sign that the WPIlib authors are looking to reduce scope then I'm happy because it means that their efforts can be more focused on fixing their existing problems. If it turns out instead that they've taken this as a chance to implement some crazy plugin architecture I will be less pleased.

The CAN motor controllers are a big maintenance burden for us. At least in C++, the CANTalon code is 5.5k lines of code spread over two classes (we use a PIMPL pattern). Half of this is a class we can't touch since it comes directly from CTRE, but we have to maintain testing infrastructure for it. Moving CANTalon out of WPILib gives CTRE more control over testing/QA and gives them more freedom to add features / do bugfix releases independent of the WPILib release schedule.

CANJaguar is basically a giant, ugly, 10k-line ball of code that we are hesitant to touch. Few teams use it, so we can't justify cleaning it up, and teams still use it, so we can't just drop support. We're supporting it for 2017 as a third party library, but we're probably going to stop maintenance in 2018.