2010 Control System Getting Started

[Alan Anderson]

Originally Posted by Daniel_LaFleur

I don't believe that it is right to give a handful of teams an advantage by letting them 'beta' the control system.

I still think you're missing the point of a Beta Test program.

Any team could have used the 2009 FRC software to practice programming and gotten as much or more out of it than the 2010 Beta Testers. They could have focused on using the system and getting useful results. Anything added or changed for the upcoming year won't take away the benefit of that practice.

The teams involved have spent significant effort using tools that were just short of ready, finding and overcoming obstacles, documenting (and often correcting) errors, redoing work when updates occurred, exploring use cases that weren't considered by the developers, troubleshooting problems with the libraries, helping to make the documentation useful, and generally making it possible for the rest of the teams to get a system that works well out of the box.

What these "privileged" teams have done over the past few months is only slightly relevant to what they will have to do after Kickoff. I don't think working with the unfinished software has given them a significant leg up on everyone else, and I know their work is going to give everyone else a better experience than they would have had otherwise.

[Daniel_LaFleur]

Originally Posted by Alan Anderson

I still think you're missing the point of a Beta Test program.

Any team could have used the 2009 FRC software to practice programming and gotten as much or more out of it than the 2010 Beta Testers. They could have focused on using the system and getting useful results. Anything added or changed for the upcoming year won't take away the benefit of that practice.

The teams involved have spent significant effort using tools that were just short of ready, finding and overcoming obstacles, documenting (and often correcting) errors, redoing work when updates occurred, exploring use cases that weren't considered by the developers, troubleshooting problems with the libraries, helping to make the documentation useful, and generally making it possible for the rest of the teams to get a system that works well out of the box.

What these "privileged" teams have done over the past few months is only slightly relevant to what they will have to do after Kickoff. I don't think working with the unfinished software has given them a significant leg up on everyone else, and I know their work is going to give everyone else a better experience than they would have had otherwise.

No. I believe you are missing the point of my post.

According to Bills blog, 43 teams were set up as beta testers (Sept 3), yet the OP states that only 7 teams have provided results. Most of which does not include specifics about the changes in FPGA code or how much editing it will take to convert their labview/C++ code to Java (Things that at least 20 of the beta teams have done).

My suggestion in my previous post was not an indictment of the teams, but rather a suggestion that we look at open sourcing the libraries to all of the FIRST teams and see what comes of it.

My question back to you is: If there is nothing gained by having the software, then why are you so against opening up the beta process to all teams?

[IndySam]

Originally Posted by Daniel_LaFleur

My question back to you is: If there is nothing gained by having the software, then why are you so against opening up the beta process to all teams?

where did he say he was?

[rsisk]

If there is nothing gained by having the software, then why are you so against opening up the beta process to all teams?

It is much easier to manage a limited number of teams beta testing a new system than opening it up to the whole community.

The goal is to shake out problems in a manageable way with a limited number of resources. Some resources have to manage the beta process (deliver updates, answer questions, feed information back to the developers, etc) and other resources are trying to finalize the product (finish promised features, internal QA, roll in beta feedback). If resources are limited, which I assume is the case especially in this economy, then a limited managed beta is more productive than an open sourced test.

If new hardware is required, that is another resource that can constrain the size of the beta test.

[Alan Anderson]

Originally Posted by Daniel_LaFleur

No. I believe you are missing the point of my post.

Your post had two points. I chose to answer only the first one. The second one seemed too speculative to address well.

According to Bills blog, 43 teams were set up as beta testers (Sept 3), yet the OP states that only 7 teams have provided results.

Where did it say that? Andrew gave a summary of 20 minutes of browsing in one forum. I've seen contributions by many more teams than that.

Most of which does not include specifics about the changes in FPGA code or how much editing it will take to convert their labview/C++ code to Java (Things that at least 20 of the beta teams have done).

Changes to the FPGA are out of scope for the teams. Nobody outside NI really knows the specifics. I don't know anything about Java for FRC beyond the fact that it's being supported, but asking about how much "editing" it will take to "convert" LabVIEW to Java suggests that you don't know enough about either for an answer to be useful. Teams didn't edit their old robot code to turn them into Java programs. They wrote new ones in Java.

My suggestion in my previous post was not an indictment of the teams, but rather a suggestion that we look at open sourcing the libraries to all of the FIRST teams and see what comes of it.

The libraries were not the most important part of the Beta Test process.

I'm not quite sure what you mean by "open source", though. Are you asking for WPI to make the libraries available for anyone to modify?

My question back to you is: If there is nothing gained by having the software, then why are you so against opening up the beta process to all teams?

I didn't say I was against anything. I said that being part of the Beta Test isn't as advantageous to the participating teams as you believe.

If I did want to explain why limiting the process to relatively few participants is appropriate, I would give pretty much the same answer Richard did.