Discussion: Fully Switch to WPI

[tomtzook]

Originally, when first developed, FlashLib was made to provide components which did not necessarily exist, or had some problems, in WPILib or otherwise.

But over the years, we started switching to different, better, and sometimes new frameworks or produces. For example:

• from Flashboard to Shuffleboard
• from flashcomm to NetworkTables
• from flashvision to Limelight or PhotonVision

Now the one components which is fully used is the scheduler.

So the question must be asked: should we stop using it in favor of replacements?

I will be using this issue to discuss (sometimes with myself) whether to stop using flashlib or not.

[tomtzook]

So some good reason to switch:

• FlashLib is generally only maintained by me, while most replacements have a dedicated team that are responsible for it. That should make them generally more tested and robust.
• I may be the core maintainer, but the field of robotics is far from my expertise. On a daily basis, most of the things I do have to do with fields that have hardly anything in common with the FRC.
• WPILib is already a must for FRC robots so we are already using it.
• Switching will allow easier work with other Teams and their code.
• Most third-party FRC framework (like pathplanner) are already integrated with WPILib. For our use, we must make some extra work to integrate.

[tomtzook]

Some reasons to stay:

• I do prefer the design and implementation of FlashLib and especially the scheduler to WPI's. Although on the surface they are similar, at least for some parts, but there are huge implementation differences.
  • Some features and behaviors of our scheduler do not exist in WPI. Although the same thing goes the other way around.
• A lot of features are in design for FlashLib which do not exist in WPI. Though perhaps these features can be built on WPI and not FlashLib instead. But some examples include:
  • State Machines
  • Uniform smart motor controller abstraction
  • Simulation code generation and separation
• More freedom in our code usage. Which was one of the biggest motivations for the creation of FlashLib. It basically allowed us to develop and use our own code and change it as we like, instead of depending on whatever others decide.

[tomtzook]

I should add, that this switch would not necessarily mean we abandon the idea of using our own library for improving over the years. We can still do that, and will. However, the base of our code will be with WPI.

I would also probably never fully abandon FlashLib, as I sometimes find it useful as a platform for other things. But these would not be used in our team.

[tomtzook]

@yaronkle @Maayan-Luzon @NoamZW

We would need to discuss this after the competitions.

[tomtzook]

I mentioned these two points in favor of switching:

Switching will allow easier work with other Teams and their code.

Most third-party FRC framework (like pathplanner) are already integrated with WPILib. For our use, we must make some extra work to integrate.

However, these points may be mitigated without switching by running Commands over our scheduler using a kind of wrapper, which will be some special Action. Its really not that complicated for most situations. For groups, this will be kind of a problem.

Obviously, we can always make integration for which framework manually. Though changes to that framework will require us to make some extra work. So the first option seems more realistic.

[tomtzook]

https://docs.wpilib.org/en/stable/docs/software/commandbased/index.html

[tomtzook]

Recently I was required to debug a problem with a Command, as part with my work with another team. I found the CommandScheduler (WPILib's Scheduler) lacking in terms of information provided as to the execution of Commands. Other than the ability to attach a few callbacks and limited information available as a Sendable, there wasn't much else.

In contrast, FlashLib's Scheduler extensively uses logging and provides much information through OBSR (NT for FRC). Which makes it easier to know what's going on. With the addition of features from #111 , users have a lot of power in their hands to understand the execution state.

[tomtzook]

Honestly, I'm just really biased. We should make the switch.

[yaronkle]

LOL, Is it possible to create plugins for specific functionalities instead of everything?

…

On Mon, Mar 18, 2024, 12:31 PM Tom Tzook ***@***.***> wrote: Honestly, I'm just really biased. We should make the switch. — Reply to this email directly, view it on GitHub <#113 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCQSZDCATQDVY5KINYGAJDYY267PAVCNFSM6AAAAABEAN3NTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBTGUYTSNJTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tomtzook]

LOL, Is it possible to create plugins for specific functionalities instead of everything?

Not so much plugins as extensions built upon WPILib. But yeah, it possible, with limitations of course, as the code isn't meant to be extendible in various locations. It is what I'm planning to do though, given a full switch.

[tomtzook]

Which parts of FlashLib do want keep?

[tomtzook]

We are making the switch.