There was some good off-topic discussion in This Thread about the WPIlib, specifically efficiency and bloat in LabVIEW. However, I was off-topic for that thread, so I’d like to move it to this thread for comment. This isn’t just focusing on LabVIEW, I’d like to see some opinions on all languages or just FRC programming in general. Also related to This Thread about Default Code.
IMHO, the core purpose of the core libraries are to provide access to IO and control data. Not even framework, just IO. Framework can be provided through examples and default programs, but should not really be part of the library. Teams need the library to read and write sensors and actuators, and read control data. Anything else is secondary to this goal, or should ideally be moved from the library to example programs or the like.
Every FRC programmer (in any language) I have ever talked to assumes the WPIlib to be a golden black-box, which is to be used as-is. I’ve seen quite a few teams write wrapper libraries (especially Java and C++ teams posting them to CD) to address shortcomings in the library without modifying it directly. In many ways it’s hard to modify the WPIlib, since any changes you make have to be moved to all laptops you use and saved during updates. I know I had to intentionally run 1 version out of date in 2012 and update other machines for images so it wouldn’t overwrite my changes. While there is some challenge to writing efficient code, there is absolutely no reason our simple control loops shouldn’t be able to run at 200hz on a 400mhz PowerPC, but we’re limited to 50hz or less due to CPU loading. Its not that FRC should necessarily be easy, but if the Vex Cortex can run code of similar complexity and spend 3ms in the loop (with interrupts) and we’re running out of CPU in 20ms and 15ms loops, with an FPGA handling all of our high-speed IO, we’re clearly wasting a LOT of CPU.
What are your thoughts? What do YOU expect of the WPIlib, what issues do you see and feedback do you have?
WPIlib is pretty inefficient, and it’s not really set up to be modified easily. In 2011 / 2012, we tried to add in the functionality of the “number of samples to average” to the counter class, but it would cause really weird problems after the counter would run for a minute or so.
The cheesy poofs also modified their gyro code so that the gyro could be reinitialized, but they had better success.
Also, the whole speed controller setup seems to be way more complicated than it needs to be. Right now, victors and jaguars, are two classes, which both implement a Speed Controller interface. They could save some space, by making one speed controller class, that took a type argument during initialization. In LV, the setup is much better, because it uses a polymorphic vi to choose between setups. Also, the number of classes is higher than it needs to be, as several interfaces are completely empty, and don’t really help the software at all.
Another interesting issue is the number of really strange undocumented methods that show up whenever you write code. For instance, when you look at available methods on a digital input, you get really cryptic things such as
digitalInput.getAnalogTriggerForRouting. What is an analog trigger, and why do I need it for routing? This method returns whether or not this object that extends digital source is actually an analog input, acting like a digital input. It should be named isAnalogTrigger, or something that is understandable. Also, the CANJaguar has a neat undocumented method, canJaguar.getX. What is X, and why do I need to know what it is?
All of those can be explained by actually looking at the WPILIB source code. We program in Java and I always have my students keep open the WPILIBj project as well to our source to be able to see what the library source is actually doing. For example CANJaguar.getX returns the current Jaugar setpoint regardless of control mode, so potentially a current, voltage, rpm or normal -1 to 1 value.
I don’t mind having a lot of the included functionality it’s very helpful for most teams. I do see how having a stripped down version of the library could be useful for some of the advanced teams.
We also do modify the library but only when necessary. For the past few years it was to add a ToggleWhenPressed method to the Button class, but I think WPILIB is finally going to include it by default in the next release.
From my experience, the text based libraries is much different from the LabVIEW Library. In the text based, the IO and the Framework are combined, but they are much less integrated together, and you could take out most of the framework and the IO would most likely still work. I do not think the same thing could be said about LabVIEW. I also think the text based libraries are more efficient as well. The biggest problem is think that is lagging code is networking. back when i started programming FRC, i was using alot of back and forth dashboard networking, and was always lagging code. As soon as i slowed down the networking code, the code instantly sped up, and ive never had any cpu load problems since then, using either java or LabView.
. consumes as little memory as possible
. consumes as little CPU as possible
. flexible and easily assembled in a variety of configurations to quickly solve problems
. addresses scenarios that I’m interested in
. many resources available that I can rely on to help solve my problem
My issues with WPILib are documented in other places on this forum, but they primarily are not with the library itself, but with its development process.
For the record, I use C++.
I may be alone in saying that I find reading, understanding, and making changes to WPILib to be relatively easy. I’ve never had real issues with it.
I do agree that there is some bloat, however, at least with the C++ version I believe that the linker will only include the object files that are necessary to resolve any missing symbols in the library and their dependencies, so I don’t think that “stripping down” WPILib offers any real-world benefit - just don’t use what you don’t need.
However, I do think that WPILib development should be a community effort rather than a centralized effort. I think that teams should be encouraged to contribute changes and code back to the WPILib project to be integrated and used by all teams. I’m not saying that it should accept everyone’s code - it would take a good core team of maintainers to weigh the pros and cons of integrating each change - but even levels of openness such as having a public patch submission and discussion mailing list and allowing anonymous checkouts would be a huge step in the right direction.
One of the biggest issues with this sort of approach would be that the different language versions of the library might diverge. However, a good maintenance team could work around this.
I think it would be more in line with the purpose of FRC to open up development of the core libraries to the teams.
Also, with regards to the feature creep of the core libraries, there’s nothing stopping you from compiling real-world libraries for the cRIO and linking them into your program. Since vxWorks is (partially) POSIX compatible the porting usually isn’t inordinately difficult for small libraries. This seems a better solution from the perspective of education than using specialized FRC only libraries for absolutely everything. I see the most potential for this sort of use in network communication, but other areas can benefit as well.
There is nothing stopping this from happening as a fork, or in parallel to the code we are supplied. It would require some very dedicated developers with a lot of resources (time and knowledge) who could debug, validate and implement the code changes. The programming assets of FIRST are fairly limited and what they provide us now works for 99.31459% of the teams.
Correct me if I’m wrong, but while they don’t allow any anonymous checkouts, there isn’t anything stopping you from making an account and performing a regular checkout, and then stripping WPILib down to suit your needs.
At least for Java, they include the source for WPILib in the sunspotfrcsdk directory. I’ve personally made some adjustments and added some convenience classes for my team’s use. There is a Java library hosted on GitHub – atalibj – that seeks to remedy some of WPILib’s perceived flaws.
You do make a good case though for the separation of the business logic from the abstraction. Maybe we could have a bare bones WPILib, and a forked, framworked WPILib++.
Just my 2 cents, but many of the teams that fall into the .68541% are fairly capable of handling their own programming and making their own modifications.
But beyond that, the constant dissatisfaction with materials and resources we’re handed (whether it be mechanical or programmatical in nature) is what drives a lot of student creativity. Dissatisfaction (no, not necessity) is the mother of invention, and in FIRST, dissatisfaction with something is the perfect excuse to go find a reclusive student and inspire him or her.
