Today’s question is from Andrew Palardy, from Team 33, in Pontiac, MI. I asked one of our great FRC staffers, Matt Pilotte, to respond to this one directly. Matt is our Electrical Engineering Manager, and manages all FRC Engineering work on the control system and FMS, including software. He also monitors, along with other staffers, event activity as official FRC competitions are taking place. If you’re at an official event anywhere in the world, Matt is likely keeping track of what the FMS is doing and watching the webcast if there’s one available.*
Question:
Why is it that the new software for a given season is released at kickoff for download, or password-protected until then? Things like driver station updates, utilities, and LabVIEW updates aren’t related to the game at all, and installing them on many computers is a rather long task during the first few days of build season.
Would it be possible to release unencrypted software downloads for the next season a few weeks prior to kickoff, to allow teams to prepare better for the season?
Andrew Palardy FRC33 - The Killer Bees
Kettering University - Electrical Engineering
Chrysler - Powertrain Controls and Calibration
Answer:
Thanks very much for the question Andrew. I recognize that applying multiple software updates to several computers can be time consuming.
The software tools are essentially an extension of the Kit of Parts, which is, with some exceptions like FIRST Choice items, distributed on Kickoff day. We post the software packages prior to Kickoff so teams can download them at their convenience. Each of these packages can include game specific material, so it’s necessary to password-protect the content.
The objective is to minimize the number and frequency of software releases. We do this for a few reasons…
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.
Minimize team confusion (e.g. what the is the most recent version? Which version do I need to compete on the field?)
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)
Providing teams with the opportunity to download the files before the build season starts reduces the number of tasks on Kickoff day. This is particularly helpful to teams attending Kickoff events with Quick Build sessions where Internet access may not be convenient or available. If the software updates are already saved to a USB drive or copied ahead of time to a Driver Station or development computer, the team only has to enter the decryption code to decompress the files and begin the update process.
-Matt
*In case you were thinking otherwise, Matt is NOT a creeper, he’s a really nice guy. This is part of his job.
*Frank Answers Fridays is a weekly-ish blog feature where I’ll be answering ‘good questions’ from the FRC community. You can e-mail your questions to [email protected]. Please include your name, team number and where you’re from, which will be shared, if selected.
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? :rolleyes: )
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”)
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.
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.
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.
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.
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.
Here’s a list of all the stuff released after kickoff that teams needed to find and download.
This is more than 1 package download, so they already don’t achieve their goal.
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
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!
In support of releasing software kit sooner. Here are my reasoning.
Game specific examples/sample codes is a very small part of the entire development kits. It can be released during kickoff with relative ease.
Doing it prior to kickoff enables FIRST to spread out the network bandwidth demand, making it easier for teams to get the manuals and rules efficiently. Thousands of big downloads can really slow things down.
‘Leaking’ a little bit of the game is actually good for generating excitement and fun.
As the lead teacher and manager of IT resources in our engineering labs, installing the software after kickoff is a nightmare for me, and I can’t imagine how difficult it must be elsewhere. FIRST needs to realize that teams are working in shared school labs where students and even sometimes teachers do not have software install privileges. In school districts such as ours, getting district tech personnel out on a work order to install software can sometimes take months. We don’t need to deal with this in January. Please give us the software in November.
I would disagree with a more wide-spread Beta Test.
The coding team that works for FIRST is fairly small. Even with the current Beta-Testing setup, the FIRST volunteers have a ton of data and questions flowing back toward them: far more than they can handle in many cases. In addition we (the beta testers) tend to stay in touch with them, not just during the beta testing period, but year round.
Opening Beta Testing to all teams would create a flood of complaints and bug reports. Many of which would be false, due to inexperience or incorrect expectations. It would overwhelm the FIRST volunteers quite quickly. Quanity is not quality.
True Beta Testing is quite rigorous. We meet 3-4 times a week for 3-4 hours each meeting. Usually we recode for our last 3-4 robots in the new environment and test. Biweekly webpage updates, community updats, and seminars follow.
By having a limited number of teams who have programming expertise learn the software early, you’ve easily tripled the number of people who can provide knowledgable, correct answers to questions.
I believe the frustration level on the team side would be much higher if they received software that didn’t work as they expected it to. People tend to be negative when things don’t work. Multiply that by a couple thousand.
HOWEVER. I’d wager that FIRST and their volunteers don’t work on this stuff through kickoff and New-Years. I like the idea of the base development environments like LabView being sent out pre-holiday so that we can install the main portions of them before kickoff. Then they could release the updates like they normally do for us to download.
That will never happen. You really won’t know what product they have delivered until it gets in the hands of all the teams and they try to apply it to the game that year.
It might never happen, but not because it is hard. It would require a different design philosophy: Correctness over features.
The mandatory part of the code should be as minimal as possible, and anything that is merely a convenience should be optional. This would cut down on both the size and number of mandatory updates.
Then, updates to the core could be mandatory while updates to any optional part could be applied at a team’s leisure, allowing for a proper testing cycle.
Why do we even have updates, with the thread of not being able to connect to the field or stuff like that, after 5 years with this control system? Haven’t they ironed out all of the field comm bugs yet?
Good question. The reality is that some portion of the system changes each season. Bridges are discontinued, manufacturers release firmware updates which they highly recommend using. The Einstein problems meant that many weeks were spent identifying what could have happened, investigating what probably happened, and confirming what did happen. Because of what occurred, radio configurations changed, antennas changed, DS had new responsibilities, logging was enhanced, etc.
And yes, features were added as well. NI had postponed releasing simulation for several years already and we decided to squeeze it in. SmartDashboard/NetworkTables had some issues that needed to be resolved from the previous year, so it was reworked for each language.
I’ve released SW with large betas and small ones. There are benefits to each approach. I’m not sure how much this really impacts the policy in the original question.
