FRC Blogged - Frank Answers Fridays: August 30, 2013

[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.