FRC Blogged - Frank Answers Fridays: August 30, 2013

[magnets]

Releasing the software earlier would make everything easier. The argument that multiple versions would be confusing is not a valid one, as there are always several different versions of the software and the updates aren't always the greatest.

Right now, the update system for Java is a disaster. Googling "frc java update" gives you a site where the 2011 Java updates are located, which links to the firstforge site, which gives you the 2012 version.
In 2011, they used "WPI first robotics resource center", in 2012 they used "FIRST forge", and in 2013, they used Screenstepslive.


The new software libraries tend to have some bugs (2012 smart dashboard memory leak, 2010 encoder issues...).
For 2013, I'd argue that the provided software actually went backwards and got worse from the 2012 version. For instance, PID in C++ had issues where it would stop working that were not resolved until 1 month after kickoff. Also, one of the most useful features of the driver station, the charts, did not properly display CPU usage, as the scale in the graph was off (it only showed up to 15%). Attempting to look at the log files was useless, as a version of the log file viewer that worked with 2013 log files was not released until 28 days after kickoff. (What happened to the improved diagnostics promised in the Einstein report? )

If a "pre-release" version was released before kickoff, teams that worked before the season started would be able to easily catch bugs and typos that would save tons of time, such as networktables2, which wasn't really ready. Networktables prevented labview code from deploying, and attempting to use networktable and live window with C++ when using threads caused null pointers. (Again, the Einstein report said "Improved Documentation on Advanced Coding – Documentation on advanced code features, particularly
threading and networking will be improved")

</rant about control system>

[codedr]

I agree. This isn't a list of valid reasons for not releasing the software early, it's a list of excuses on why they don't want to.

Kickoff is already busy enough with parts and game design. Taking the software distribution issues off the table at kickoff would take away another headache.

Releasing early would also give teams time to evaluate the software and fix issues.

[Chris is me]

I don't know enough about software to justify expressing an opinion here, but I was just wondering what game-specific software components existed in the past.

[DonRotolo]

Most folks seem to be talking about a week early being plenty of time.
I, too, wonder what game-specific info anyone can mention?

[magnets]

Originally Posted by Chris is me

I don't know enough about software to justify expressing an opinion here, but I was just wondering what game-specific software components existed in the past.

The vision examples usually give away the vision target designs for the game.
What bugs me is that they claim waiting simplifies things. If teams got the software earlier, they'd figure out the problem, and there wouldn't be a whole bunch of midseason updates.

Originally Posted by The Answer

1. Streamline the effort. We’d prefer that teams only need to download packages once, rather that download one set and require them to come back later to get the updates that include game-specific content.

Here's a list of all the stuff released after kickoff that teams needed to find and download.

1. C++ update 3/4/2013
2. Driver Station Update 2/5/13
3. C++ 2nd update 2/7/13
4. Java Update 1/18/13
5. LabVIEW update 2/2/13
6. C++ 1st update 1/18/13
7. FRC utilities update 1/8/13
8. Bridge Configuration Utility Update
9. LabVIEW 2012 Update (improved simulation performance)
10. First Driver Station Update (sometime in January)
11. Robot Builder r620
12. SmartDashboard 1.04 1/16/13
13. SmartDashboard 1.05 2/14/13
14. 2nd Java Update 2/7/13

This is more than 1 package download, so they already don't achieve their goal.

Originally Posted by The Answer

Minimize team confusion (e.g. what the is the most recent version? Which version do I need to compete on the field?)

This is pretty confusing if you ask me...

For C++, Release rel1424 rev 3622 mandatory update.
Possibly 2nd C++ midseason update rel1419
Possibly C++ midseason update rel1416 rev 3599

For Java,
2nd midseason update
1st midseason update

For LabVIEW
LabVIEW 2012 update 5.10

For everybody
Driver station update 3

Originally Posted by The Answer

3. Avoid distributing software that may not be the legal version for competition (this gets back to #2, teams think they have the right stuff, it was distributed by FIRST after all, only to find out that they need to update before getting on the field – a frantic and frustrating experience)

Well, I know our team got confused because of the two driver station updates. We performed the first one, but not the second one because when the second one was released, all evidence of the first one was gone, and the web page for the first one redirected to the second one. So we saw that we had downloaded a file from the same website, and assumed we had the most recent version.

FIRST needs to open software beta testing to all teams, so bugs can be found, tons of updates removed, and teams can get the software before kickoff. They should NEVER release software that hasn't been looked at by teams on kickoff. I know some bugs in 2013 weren't present in the beta test, and it makes no sense to do beta testing, if you're going to add more code/bugs to the finished product!

[techhelpbb]

With respect to Matt I saw plenty of confusion about versions last year.
As a CSA last year was the first time I actually felt confident I knew for certain which versions were utimately the 'gold' versions for the competition.
Only because I had official instruction prior to arrival on the field.

Although I know the information is scattered about I wonder sometimes how effectively the bugs and reasons for modifications are being communicated.

I can say for certain that from start to finish to install: all the development software and updates, Microsoft Updates for Windows 7 (drawn off my local Microsoft Update server at WiFi-N speeds) and generally prepare a laptop for last year it took more than 10 hours. For teams that do this 3 or 4 hours a night I can see the better part of a week spent getting the show on the road. Let alone dealing with the eventual updates and that's not potentially installing SolidWorks and/or Inventor (which is not fast to install even on my SSD because of the shear size). Never mind that as of now there are some issues apparently installing Inventor (with Microsoft Office 365 & 13) for some people. Though I do recognize that both SolidWorks and Inventor are available to teams right now surely some people will wait until kickoff to install those programs.

If the ultimate goal was really to float into production a work environment from the second of roll out I wonder if distributing some sort of virtual machine pre-configured would be more sensible. Not to mention potentially easier to support.

[apalrd]

I submitted a comment to the original FRC blog post asking:

Which software modules contain game-specific elements:
FRC Imaging tool and images
FRC Driver Station and Dashboard
LabVIEW and WindRiver (not even FRC specific)
LabVIEW/language updates

I believe the game-specific software in the past has been just the vision examples in the language updates, which really should move to their own place anyway.