Releasing software before kickoff

Technical Programming
1

So, as I struggle through installing LabVIEW DVD’s from the kit on all of the team laptops, and activating them all at home (since we don’t have internet at our shop), while writing software and re-learning the library since a lot of stuff changed, I wonder:

Why do they have to release the software DVD’s and updates on kickoff? What do they really gain?

It’s not a mystery that the libraries will contain something similar to last year. We could ask any of the beta teams to show us exactly what changed, if we wanted to. However, there have been cases in the past where major library changes have happened (e.g. from 2009->2010 in LV, the basic framework was completely dropped and the refnum registries were added), forcing teams to re-learn a lot of what they used to know about the library, in the most precious time of the year (build season).

Also, with LV at least, the SW licenses from last year expire mid-build season and they switch to a different version of Labview every year, forcing us to uninstall and re-install everything on all of our computers, every year, during the first week or two of build season.

There just doesn’t seem to be any reason to hide and encrypt the new software updates until kickoff. Releasing them earlier would give teams time to install and learn the new features (IMHO the library should be stable enough to not require significant changes each year, but for some reason they keep developing new major additions to it, making the learning issue worse).

2

I have to agree. I can’t think of a very good reason not to just release the software publicly before build season. This kind of thing does not apply for building material or CAD software, so I’m not sure why it would have to for the software of the robot. It’s even completely possible to code the robot in the previous year’s libraries, so there really is no “even playing ground”. I would understand if the reason is to make sure rookies have just as much time to practise as veteran teams, but it simply isn’t the case. We’ve been able to practise and learn on 2012 libraries for months, not to mention 2013 beta releases being available publicly (with a link). It might be a habit FIRST has got into, and just does it for the sake of doing it.

I for one would not mind having the next year’s software even a month earlier. It would let us worry about things we need to do this year, as opposed to bugs and fixes from last year. (for example, we spent hours finding a solution to bug #2 here)

Maybe there’s a good reason to keep software from teams before build starts, but I haven’t found one yet. Installing plugins all day is not my ideal first day of build season, and would probably give a bad impression on someone new to FIRST.

Just my 2 cents.

3

Maybe all the updates are not complete, tested, and packaged until just before kickoff.

Although I do agree with the OP that FIRST should move the GA date for software to Nov. Let teams download and install and provide some time bugs to be reported and fixed before the build season.

4

Not sure, but I know that the Java wpilibj for 2013 was in production stage (as in ready to go) around mid-November. There’s been some bug fixes, but it certainly could have been released earlier than January.

5

Technically speaking, they were. Just change the plugin target to the updates.xml in the “Development” or “Stable” channel rather than “Release.”

first.wpi.edu/FRC/java/netbeans/update/

6

That’s exactly what I was talking about. They have it ready, but just don’t tell anyone.

7

Ideally, the library is stable, provides the functionality that we NEED (getting IO data from the IO, and control packets from the DS) and never changes. The only beta test that would have been needed would have been the initial test pre-2009 (when the system was new and full of bugs) and pre-2012 (when the 4-slot cRio was new). Every other season would just have carried over the libraries with the previous season, plus bugfixes from the previous season, without even carrying out the beta test process.

But, the library keeps changing, and there’s a lot of visible scope creep. IMHO, the purpose of the library is to provide an API for the black-box FPGA and Netcomm modules, and provide a default framework to assist inexperienced programmers. The Basic Framework that LV had way back in 2009 was very easy to use, easy to understand, and worked well. I would be happy if we just stayed there and fixed bugs and fixed bugs and supported the 4-slot cRio.

Another thing the WPIlib lacks is a ‘default code’ which requires absolutely no programming skills to learn, PERIOD. IFI and Vex controllers always came with code which would map all of the joystick inputs to PWM and relay outputs, and provided a nice tool to download the default code without a compiler installed if you ever needed to get back to that state. You could reasonably build a robot without ever installing the development environment, and be competitive. Most OCCRA teams still run default code, since it works well enough for them. WPIlib lacks this, and requires a team to at least:
-Install the full development environment for one language
-Install at least the Labview runtime for the Driver Station and tools utilities, if they didn’t choose LabVIEW.
-Create a complete code project
-Write in the code to support anything other than a drivetrain.
This is non-trivial for a team without any software skills. I have seen many team programmers who spend an entire season getting buttons to map to solenoids and joysticks to map to PWMs.

8

This is exactly why I’d like the libraries to be available earlier than build season. If your team doesn’t have the support to do it, I think you should have time to learn.

9

So the questions I saw were …

Why not release SW earlier?

Why does WPILib keep changing?

and

Why isn’t there default code?

The first question is really one for FIRST. They choose to have a kit of parts and it includes software. Sometimes they tell you what will be in it, other times they want it to be a surprise. As mentioned, Java was put up early, others were not. I don’t think there is a simple answer.

The second question I can answer directly. It is changing to try and make it easier and more effective for the FIRST competition. WPILib is not meant to simply be a few wrappers above the FPGA. It is that and much more. By mapping measurements to engineering units, it allows for more direct comparison to modeled and theoretical estimates. It includes vision and other libraries that have nothing to do with the FPGA, and it attempts to organize the code into a framework useful for a large number of programmers of varying capabilities. From my point of view, it is changing very little. The refnum registry in LV is an optional part. It adds overhead to avoid clusters and connector panes. It lowers the bar for using the framework, but is optional. SmartDashboard is optional. Except for error handling deep within the libraries, little changed to the LV library this year, but still, there were improvements. Java and C++ changed to add commands and RobotBuilder and LV integrated simulation. These were intended as enhancements, not as major rewrites.

An additional answer to the second question is … it gives returning teams something else to learn. This is a design competition, and in my mind, it should offer opportunities to learn new stuff and appeal to new types of people.

The answer to the third is also pretty easy to explain. NI, WPI, and members of FIRST all agreed that building a robot without needing to programming wasn’t a requirement. Neither is building one without having to wire or having to use nuts and bolts or fasteners of some sort. As a quick comparison, even FLL teams program. They don’t even have a framework. FRC teams are clearly capable of installing one of the tools and building the default code, even making small changes to channels. True, there are faster ways to do it, just like it would be faster without nuts and bolts and without having to wire. Providing a binary version to ftp to the controller is clearly not hard, but it deprives exposing teams to a major aspect of the robot.

As I"m reading my post, it comes off a bit stronger than I’d intended. I look forward to hear other’s perspectives on how to make the SW be more inspiring.

Greg McKaskle

10

I’m a new programming mentor. I tagged along with the team for summer events, but didn’t get really involved until last fall.

I’d like earlier releases. The WPILib is Open Source and new mentors probably become available to help with development and training in the fall. I didn’t even know we had to sign up for a beta until it was too late.

The majority of the toolchain is commercial off-the-shelf so release date won’t matter. Unless it’s a water game. (ha! even noobs know about that joke)

Why does WPILib keep changing?

Because it’s not dead. The problem domain is way too large to ever be solved, so the only way it’d stop changing is if everyone loses interest. I’ve only been working with WPILib for a couple weeks and I already have a huge TO-DO list. Robot Builder and Smart Dashboard move things in a good direction, but they are far from complete. Error handling, diagnostics, and testing don’t really exist yet.

Why isn’t there default code?

Lots of teams put their code up in a public repo. I learned a ton from their generous examples. We will put our code up this year.

If someone wants to lead the development of an example or reference control system, I will help. I don’t know enough yet to organize it. This would make a great off-season project for teams wanting to stay active without the pressure of a competition schedule.