How much of WPILib is required for robot code to be legal?

[William Kunkel]

I've been considering making a sort of fork of WPILib, to fix some of the problems that my team had with it this year. However, I don't know how much of WPILib is needed for a robot to be legal. I assume modifying some basic things like the Joystick class would be fine, but where is the line drawn? If I were to modify, say, START_ROBOT_CLASS, would that make the robot illegal for competition?

[connor.worley]

WPILib is not required for your robot to be legal. Don't expect FIRST/NI support if you change anything major, though.

[William Kunkel]

If WPILib isn't required then how do they enforce things like the FMS? Clearly that's handled somewhere.

[Tanaythan]

Originally Posted by MaraschinoPanda

If WPILib isn't required then how do they enforce things like the FMS? Clearly that's handled somewhere.

What Connor means is that you do not need WPILib on your robot. You can remake all the files in WPILib to your own needs or even rewrite the whole code. WPILib is there to make the job of programming in FRC much easier.

[William Kunkel]

Yeah, I understand that he means you don't need WPILib. But without WPILib, how does the FMS have a common interface to your robot? How is that handled?

[connor.worley]

Originally Posted by MaraschinoPanda

If WPILib isn't required then how do they enforce things like the FMS? Clearly that's handled somewhere.

Either your robot connects and works or it doesn't... If it never connects your robot will just be bypassed every match.

[RufflesRidge]

Originally Posted by MaraschinoPanda

If WPILib isn't required then how do they enforce things like the FMS? Clearly that's handled somewhere.

Based on the headers I would say it's handled in FRC_NetworkCommunications.out which is part of the cRIO image. The system watchdog component is presumably in the FPGA because one of the reasons you would need it to activate is if the NetworkCommunications Task crashes.

If you had problems with WPILib have you tried filing a bug report on the Tracker? FIRST/WPI may either fix them for you or merge any patch you submit into WPILib. That would likely be much easier than trying to maintain a fork and merge in any desired changes from the main branch at kickoff.

[androb4]

Originally Posted by MaraschinoPanda

Yeah, I understand that he means you don't need WPILib. But without WPILib, how does the FMS have a common interface to your robot? How is that handled?

Well to put it in a simple way.. Without WPILib, that's your problem.

[Greg McKaskle]

WPILib provides easier-to-use wrappers to some of the control system elements, but it doesn't directly interact with the FMS, in fact nothing on the robot does.

When the robot receives a packet from the DS, the info is parsed and held by the FRC_NetworkCommunications task. When you ask WPILib for joystick info, it asks FRC_NC and returns the latest. This also tells you what mode (auto, tele, or disabled) that the DS told the robot to be in. When an FMS is present, it coordinates the DSes and they tell the robots.

To set a motor, you tell WPILib, and WPILib eventually calls into the ChipObject component that pokes an integer into a memory-register on the FPGA. The FPGA also knows about the mode and ignores the PWM register if the robot is disabled.

So, I'd encourage you to look through the WPILib code, put in print statements, put in breakpoints, etc. I think you'll find that the lower levels that set motors and such are still understandable and are probably doing what you'd do in your new code anyway. If not, you can be more specific in your request or rewrite.

Greg McKaskle

[William Kunkel]

Thanks for the clarification. This isn't really intended as a set of bug fixes for WPILib, it's more a result of dissatisfaction with the way robot code is organized, as well as an attempt to learn more about how the code is handled at a low level. It might not result in anything, but I think it would be a good experience to try rewriting some or all of WPILib.

[Greg McKaskle]

It's all about the learning. That is why I offered up the lower level details. In my opinion, learning to read the code of others and understand why it was written that way is probably the single most critical skill for a programmer to develop.

Rarely is code perfect, and even if it is, there are alternatives which are likely just as good or better based on the judgement criteria. Being able to read WPILib well enough to improve upon it or discuss alternate implementations may be the reason why it was distributed as source code ... in several different languages.

Greg McKaskle

[rbmj]

If you come up with any good bugfixes or additions, please pull request to https://github.com/rbmj/wpilib

I won't take compatibility breaking changes, because I'm trying to stay source-level compatible with upstream to make it easier for teams to drop in - right now it's mostly just changes to build system, c++11 stuff, and killing warnings.

I was thinking about making a community developed fork of wpilib - I've always been a tad dissatisfied with how opaque development of wpilib is, the release cycle, and how difficult it is to get changes in from outside the project. If I thought there was enough skilled manpower to sustain it...

I wish I still had a cRIO.

[MrRoboSteve]

I'd be interested in hearing more about the issues that you ran into with your robot code this year. While I have some "would have done it differently" moments with the command-based approach, we have not run into anything that prevented us from achieving our goals.

I mentally model WPILib as having several different subsystems, with important ones being:

. a class hierarchy that represents all of the physical devices that can be attached to the robot
. the NetworkTables abstracting, which is a state sharing mechanism between the DS and the robot
. A layered set of application-building frameworks that allow you to build a robot control system at one of three levels of abstraction:

Simple -- you handle the loop
Iterative -- loop abstracted out
Command-based -- event-driven

If you don't like the application-building frameworks that are provided, there's nothing in WPILib today that prevents you from building your own along side/above what is already there. In fact, if you build something new, it's adopted by teams, and you are careful about code ownership issues, you'd be in a good position to lobby to get your framework adopted into WPILib. The best model for this would be a library that is designed to work alongside WPILib.

If there are bugs in WPILib that you'd like fixed, the best approach is to report them with good repros attached, or a fix if you have one available. I've found the maintainers are very responsive to issues that I've reported. If you need the fix for your robot to work, bring the code for the class into your robot, give it a different class name, fix the bug, and run with that. No need to fork the whole thing in most cases.

Be sure you're ready to take on these issues with your fork:

. competition year updates (1-3) will need merging and resolving
. will need to quickly handle (1-2 days) any week 1 software updates (a la this year)
. harder for CSAs to provide support at competition (e.g., validating all required updates have been applied to the library)