About the WPI Library

[Rapture'sFinest]

I was poking around the WPILIBj and found the source code. Now typically I would get skeptical and attempt to open this on a Virtual Machine, but I figured "eh whatever it's only wpi" so I continued to copy the .jar files to the desktop, rename them to a .zip, and extracted them to the Desktop.

The Java files seemed a bit funky when copied to Eclipse because there was source code in the wrong folders and I'm pretty sure that they're in the same folder as they are in the WPILIBj.jar file that is used during competitions.
To save myself the time of ranting and save this decently peaceful place of a long, weird post about bad code (similar to what other mentors have posted about), I'm looking into fixing up this code and keeping in on GitHub. If anybody would like to join me and one other person right now, feel free to. We'll possibly add jokes into the comments along the way and hopefully make things quite a bit more understandable.

Some things we are thinking about adding: motion profiles, state machines, and neural networks (as a form of closed loop control, a PID replacement)

TL;DR: You wanna help some mentors poke around with the WPILIB-Java and optimize it?

Link drop: http://www.github.com/LTGLambChops/WPILIBj[1]
Cheers!

[Thad House]

The odd folder structure is because the original source tree is split into multiple different folders. You can actually download the original source tree from here. git clone https://usfirst.collab.net/gerrit/allwpilib

I would recommend cloning that, and pushing new updates to that clone if you would like to make changes, that way they are easier to merge.

I know there is some work already being done this summer to try and clean up some of the leftover code from the cRIO, and more help would definitely be appreciated.

[Rapture'sFinest]

the link is broken for me..? Derp, your hyperlink includes the git clone

[Thad House]

Its on Gerrit, not github, so theres not an easy way to browse it online. Its just easier to clone it to your local machine and view it there.

[LTGLambChops]

So, can we add to the repo items that weren't originally there? The re-poster for that and myself are interested in adding some cool stuff to the source code for 2016, plus open source has been easier for some students to learn and it's cool to see what actually comes from open-source later on.

Yes, I am actually a mentor but I recently switched from student to mentor and am very curious about the possibilities of an open source Java Library.

Cheers!

[gblake]

Originally Posted by Rapture'sFinest

... To save myself the time of ranting and save this decently peaceful place of a long, weird post about bad code (similar to what other mentors have posted about), I'm looking into fixing up this code and keeping in on GitHub. If anybody would like to join me and one other person right now, feel free to. We'll possibly add jokes into the comments along the way and hopefully make things quite a bit more understandable. ...

Before you take a single additional step along this path, I suggest you contact someone at WPI who has been a part of developing and maintaining that repository for the last several years. That probably means you should contact one of the WPI faculty members who works closely with the code base, and the FIRST community.

When you find the right person, I am optimistic that they will describe more than one way you can helpfully integrate your talents, ideas, and outputs into the many hundreds (thousands?) of hours of effort represented by the current code.

Being successful might require a bigger and more complex undertaking than you are envisioning right now.

Blake
PS: In those threads where others have posted about "bad code", wise readers will have noticed that other, well-founded opinions were expressed, and will have noticed that evaluating code quality from more than one perspective is valuable.

[BradAMiller]

Hi -

I am probably the person you're looking for at WPI.

We are in the process of setting up a procedure for community contributions to WPILib. In fact we had several mentors contributing new additions to the library over the past summer and into the fall beta and I believe that the collaborations were both successful and productive. We also had a number of mentors that contributed code to the initial roboRIO release last year. You can see the list of contributors here: http://wp.wpi.edu/wpilib/wpilib-supporters/

While we are very happy to accept contributions to the library, there are some constraints that we operate under that are a little different than doing code for a particular team or a few teams. If the code can fit those constraints, and it is something that we believe would be used by a large number of teams then we are likely to consider incorporating it. We do our best to make our code fit these guidelines, sometimes more successfully than others, but these are guiding principles that we operate with.

First it that the library must work for all the teams that use it. This is the first and most important requirement. It's easy to write code that works in a particular situation, with a particular robot configuration, for a particular team. But the software that we release has to work for everyone. That means thinking about the corner cases that 3000 teams will find and for the most part is reliable. As I said, we try hard to do this, usually pretty successfully.

We (the development team) have to guarantee that as the library changes, all the code continues to work. That means that any code added has to be pretty easily maintainable and understandable. I think we've done pretty well there, with some exceptions, and in those cases we try to go back and fix them. You can imagine that if someone from the community graciously contributes some complex piece of code, then a year or two later, for whatever reason stops participating, then the maintenance of that code falls upon the remainder of the development team to ensure that it continues to work.

We operate under a mandate from FIRST to have parity across all the languages. That means that if a significant feature is added to one language, we try to get it into all the languages. To do this we work very closely with NI, CTRE, and FIRST on all significant changes. For example, this summer we are working on a new NetworkTables implementation and it will be rolled out across all three languages. What this means is that a developer contributing a change for one language possibly obligates to implement it for all the languages. This doesn't necessarily apply to every new feature because everyone understands that each language is different and some library features just don't make sense to be implemented everywhere. For example, we have been upgrading the C++ library to take advantage of the, now available, C11/14 language features to make the code more reliable and unerstandable. This clearly has no analog in the other languages.

We have a hardware test system at WPI, FIRST, and NI and all the code checked into our version control system is automatically tested. We currently have several hundred Java and C++ tests that are automatically run against every checkin and every release. We ask that people who are adding core features also create tests to add to the test system to help ensure that we don't break everything from release to release.

And it often, if it makes sense, needs to work in simulation. There are significant improvements coming this year in this area and we try to keep everything working in the real and simulated environments.

Maybe some of you remember back in 2009 when the cRIO first rolled out with WPILib, we had a server called FIRSTForge which was a collabnet project server. We ran the betas on that server and kept all of our code on it. Back then, we allowed teams to use the server to host "community" projects - those projects that were open source and of general use to the FRC community. Those projects were run by the team or teams that created them. The idea was, by having them all in one place it would be easy for all teams to find everything that was available rather than hoping to notice that a team posted an announcement on Chief Delphi or somewhere else. That worked somewhat, but teams like to keep their own identity and host their code in the location of their choice.

What I'd like to see happen is the creation of a directory of projects with small description of each project, maybe tags to help find things, and a link to where that group is storing it. Github has been a very generous supporter of FIRST and would probably make a good place to host these projects, although that shouldn't be mandated. The key is that there would be a single directory of all the projects so it would be easy to find that code that, maybe, didn't meet our constraints for contribution to the WPILib main code release, but useful none the less.

So, in summary, I propose that there are two classes of contributions:

1. Those changes that fit the constraints described above. Those improvements we will gladly accept, although I suggested contacting us before spending too much time to make sure it doesn't conflict with something that is already going on.
2. Those changes that, while are useful, don't for whatever reason qualify to be part of the main library. And they can be developed by one or more teams in collaboration and added to this directory that I'd like to see be implemented, where anyone is free to grab the code and add it to their own robot projects. Maybe in some cases, this code will prove to be so popular, that it is moved into the first category.

We will soon post the guidelines for contributing to the library, although we're pretty busy right now getting ready for beta. So it will probably come after that. But for now, feel free to clone the repository and look around. That represents the most up to date version (not necessarily released) at any instant.

My two cents.

Brad

[LTGLambChops]

Thanks Brad for the response!

I'm hoping that this season I'm not seeing too many "else throw new Exception("We can't do that.")" lines of code. Looking through the 2015 library source code it looks like the team was horribly rushed to get past this point. My suggestion is to force the application to change something and, by using a log, teams would be able to see what's going on on the Rio. There are other things that we (current two mentors wanting to add things into the WPILIB) will pull together some projects that we've been coding and will try to see if we can set it up for both C++ and Java, LabVIEW would still take time to figure out.

However; my concerns exist within the WPILIB and, I guess this may the only way to put it but, the prevention of Application closures. Either a logging system that details which file's source code it's coming from or else a way to tell them (the teams) that the system is being changed in order to fix a current system in place. For instance, rather than shutting the application down in PIDwrite for CANTalons it may be easier to give a warning that the system cannot handle specifically requested settings and they will be changed rather than simply shutting the program down. If that doesn't sound likely due to time constraints I'm sure there are a bunch of teams willing to help go through beta code and set those features up.

Thanks, again, for the response Brad!

[calcmogul]

LTGLambChops, the latest roboRIO image has logging functionality that could help you, once it becomes available. There's a patch under review at https://usfirst.collab.net/gerrit/997/ that adds language-specific interfaces for it. I'm not sure if WPILib works with the new image yet.

[BradAMiller]

We are in the process of moving our test system to the newer image that has support for the driver station logging. That way all the runtime errors will be shown in context with the other driver station logging information. As pointed out, the logging interface is there waiting for the image and we need to replace the sites where errors are detected to use it.

The DS will have an enhanced logging window to present all the information.

Brad