Example Best-Practices of Command-Based usage

[tom131313]

Add an Example Best-Practices of Command-Based usage.
Issue #6616
Reference: CD thread
Utilize an LED-based system to show various best-practices in coding Command-Based programs.

[illinar]

Did you mean to put strip.setData(buffer) in the periodic callback and remove periodic() altogether? strip.start() should be invoked once. Any specific reason to offset by 1ms and run at 100ms?

[illinar]

Not sure why such a verbose name, also I would not include Subsystem suffix since this is no longer a subsystem. How about LEDResource?

[tom131313]

I apologize for leaving some trash from the start and then got distracted trying to get output from the example and getting it into a WPILib Pull Request.

My refactored version is available here. Believe it or not it does resemble the original except I have added working output with commentary and didn't pursue the anticipated new AddressableLED functions which we can add when they are readily available. (Xbox controller buttons A, B, and X do something in different robot modes. Now I see that I should document the expected behavior.)

I can't remember - are we including the word subsystem in the Java class/file name or not? I left in subsystem but scrubbed Command and Trigger from names.)

I would appreciate your and @Oblarg comments on what can be done better as a best practice. Thanks.

[tom131313]

@illinar I have completed a working example LED resource/subsystem/view based about 99% on your example code.

I did find @SamCarlberg nice addition to the LED process that you recommended. I copied his entire work into my example since I don't see any other way to reference it in my code. All those files would have to be deleted from my example and appropriate imports made to the WPILib when it has those files available.

My changes to your code are trivial to make it a little easier to test. I simulated a couple of events with Xbox controller button presses and changed an onTrue to whileTrue. I added a third view of the LEDs only to display your dynamic Enable/Disable Patterns.

Since the basis of all LED addressable views is the same I have only one class for the LEDview and instantiate it three times for the Top, Main, and EnableDisable views.

I welcome comments from all - you, @Oblarg and anyone to further refine structure.

Thanks for your contribution of a fine example.

[illinar]

I feel like this should be part of WPILIB API surface if this pattern is an officially blessed mechanism of injecting periodic processing support.

[calcmogul]

if this pattern is an officially blessed mechanism of injecting periodic processing support

It's not. The official mechanism is TimedRobot.addPeriodic().

[tom131313]

@Oblarg I've completed the "best practice" example usage of command based (I haven't changed anything in 5 minutes now so it must be done!).

It is composed of the work of @illinar , @bovlb , @SamCarlberg plus I added the methods and tests I created for the "DisjointSequence" project. I think it demonstrates the ideas that were listed in the CD thread with some brief but far from complete commentary on why things are as they are.

There are some deficiencies as far as a WPILib submission goes: no C++, no Python, and only once did I dare to type "m_" variable prefix and sure enough my keyboard caught on fire and that was that.

I learned a lot and will use this for my team. I'm happy to share with anyone. If it misses the point as a WPILib example, I can close the PR and delete it as I have my own copy also in my GitHub repositories. I'm happy to do some more work on it if that is useful.

Thanks for your leadership on this subject.