Thank you for sharing! Your graphics for explaining the difference between command groups and the one for triggers should be added to wpilib docs. Cleanest explanation I have seen. (All of your docs are great, just sayin’ steal from the best! 
)
2 Likes
Thank you.
I’ve found that students have a variety of learning styles. A few are happy to read walls of text on their own, many prefer face-to-face conversations, and almost everyone likes visualisations and interactive demos.
My documentation is a gift to the FRC community, and I’m happy to see it used, but I’m no graphic designer, and I’m sure someone else could make a better job of it.
2 Likes
I agree with this, having one universal structure everyone uses makes it easier for others to understand that code, and for other people to help with that code if everyone is on the same page.
As a CSA, if every team had the same code (excluding differences in functionality of course), my job would be MUCH easier
4 Likes
I like going around and helping when teams need it, and I agree it would be so much easier. like i’ve seen people put all of their swerve into their robot.java file 
2 Likes
Indeed. Once you get one or two done so I can really wrap my head around it, I might just take you up on that. Is there an example already done?
RapidReactCommandBot is the newest one, I believe.
A lot of what needs to be done, unfortunately, is removal (or consolidation) of old/outdated example content. New content won’t help while the clutter is ruining the signal to noise ratio.
3 Likes
Sounds like a bug, I’ve opened an issue: Command unscheduling order is inconsistent · Issue #5467 · wpilibsuite/allwpilib · GitHub
3 Likes
A pull request reverting the change for SubsystemBase was just merged
2 Likes
Wow… I was not expecting that… thank you too the WPILib devs responsible!
since I don’t remember the whole context of this… Is the plan to change Subsystem to some sort of CommandMutex?
Not at this time. I mocked up some changes that would do this but I don’t feel comfortable making a change of that type for this season.
More detail...
Little more detail…
I’d like to separate the primary purpose of Subsystem, a mutex for commands, from its secondary purpose as a command scheduler callback function (currently Subsystem.periodic).
For a command mutex by itself, no external api is required; that is, the “CommandMutex” interface can be a marker interface.
For the callback functionality, the only contract Subsystem currently enforces is public void periodic(). This could be separated to use Runnable.
Functions (as Runnables) could be registered with the scheduler, which would allow for arbitrary functions to be hooked into the scheduler lifecycle in addition to traditional Subsystems.
For ease of use, there could be a Subsystem class similar to SubsystemBase which implements the CommandMutex interface, and also has a periodic function. The function could be registered with the scheduler automatically at construction (just as SubsystemBase does today).
With this, most users could continue to use Subsystem as they do SubsystemBase currently. If you need more control over inheritance, CommandMutex is there as a marker interface.
None of these are concrete decisions, just an idea that’s been floating around in my head.
3 Likes
Wouldn’t this be somewhat of a duplication with TimedRobot.addPeriodic?
Sure? We could get rid of periodic functions in the command library altogether, but that comes with some usability/code cleanliness limitations (in particular, accessing the Robot class from subsystems is difficult within the recommended command-based project structure). I’m not too much of a fan of that idea.