I spent a good 20 minutes trying to get up to speed with the FIRST forum Beta posts. I was disappointed at the lack of software posted for the # of Beta teams supposedly testing this software.
What alarmed me the most is that Labview will not be releasing the library upgrades until after Kickoff? Not being able to download and test the software is a big setback to non-Beta teams for FIRST preparation.
I think my team (1714) is planning on posting something before Kickoff, if you’re looking for C++. Not sure on the progress, I’ll find out next meeting.
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?
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.
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.
I don’t believe it is right to deny the rest of the teams of the benefits of what the beta teams produce.
The things that Phil, Joe, Rick and the rest of the beta-ers do behind the scenes would astonish you. What they publish is only a small part of their contribution. What they are really contributing is scraping their knees against our mistakes over and over again until we figure out how to fix it.
Please do not assume that because you have not read a document with someones name on it that they have not directly contributed to your experience.
First off, I truely believe that the beta testers are teying their best to help the FIRST community, and I don’t doubt that they do a lot more than what we see. My hat is off to those who have worked so hard to get the teams a excellent set of hardware and software.
but …
and I guess this was the point of my OP … It is difficult to deny that having the software/hardware to use/work with/play with doesn’t give you a familiarity with it that teams that do not have the new wiz-bang stuff don’t have.
And, as far as open source, I was talking about the libraries. Seems to me we could create far more, and debug them far faster as a community. I also believe that this would be an excellent learning oppertunity for those who take part.
P.S. Alan – I apologize. You were silent on opening up the beta process. It was not my intention to create a strawman argument.
I can confirm that the beta test ran pretty much the same as most others I’ve been a part of. People have good intentions, they are gung-ho and sign up for the beta, but then life happens and there are only so many hours in the day. Some teams are able to be far more active than others. I suspect you will continue to see code posted in the coming weeks. Beta testing is certainly not easy, and not fun. The additional responsibilities placed on the team may indeed cause them to excel, but it is more likely to be organizational rather than competitive success, IMO.
As for the LV upgrade, I’m glad to hear you are looking forward to it, and I’m sorry to disappoint, but you will have to use 2009 tools until kickoff. There have been a number of presentations detailing the new feature to the WPI libs, and I’ll be happy to wax poetic about new features, but the SW is part of the kit of parts, and my observation is that if it isn’t brand new, then it will likely be treated as any other kit element. At least they still allow us to present and teach about the new features before kick-off.
As for open sourcing WPI Lib, the following is placed in each file in the LabVIEW WPI Lib implementation, and presumably in each file of the other language implementations as well.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the names of FIRST, NATIONAL INSTRUMENTS, WORCESTER POLYTECHNIC INSTITUTE, THEIR LICENSORS-nor the
names of their contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY FIRST, NATIONAL INSTRUMENTS AND WORCESTER POLYTECHNIC INSTITUTE AND THEIR CONTRIBUTORS ``AS IS’’ AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL FIRST, NATIONAL INSTRUMENTS, WORCESTER POLYTECHNIC INSTITUTE OR THIER CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
I’m no lawyer, but that seems pretty open source, and with a public repository such as FirstForge, all sorts of team-improved features could become part of the libraries or could spawn alternative derivations. On the other hand, this doesn’t remove the benefit of targeted beta programs, especially when there is HW being developed in tandem. It always has more limited availability. So, perhaps in the future the SW development will be a combination of all these good ideas.
Excuse my ignorance, but are any major changes being made to the existing C++ base, or does the C++ update mostly contain bug fixes and better implementations? What new functionality is being added, and what changes should teams planning on using C++ be aware of?
There are some C++ presentations on the FIRST site which may have more details, but there will be additions to the library for the I/O board, vision has been redone I believe, and there is a serial port proxy console.
I just wanted to add that a lot of the results of the Beta test may not be in documentation format. How many teams that are implementing advanced traction control go out and use someone else’s code? Its not cut & paste, and the differences between 2008 & 2009 coding style may not be that different.
I see the biggest benefit of the beta test being the experienced users that come out of it. Last year 1511 helped 340 Beta test, and consequently the two teams were able to get all of the Rochester area teams (20+) up and working on the system relatively quickly. Additionally 3 of the 1511 programming mentors (including a labview guy), instead of helping their own team make bigger and better and more perfect code, left the code to the kids at competition and went off and helped other teams with the control system at all 3 of our events, and traveled to a 4th that was in need of help. You can bet that is VERY likely to happen again… and honestly was much less likely to happen if they weren’t part of the Beta test.
It is probably very hard to sit on the outside and see very little released to the public, but a lot of what is being done is working through tedious and annoying bugs… and what do you care about the bugs if they are going to be gone before you get there? Could there be more documentation released? Likely true, but there are some rules FIRST imposes, and there are the hours in the day limits (making something readable/useful for others is much harder than just posting up what you have done at the end of the day). 1511 had proposed a wiki-type setup for the 2008 Beta, but I think a lot of that was knocked down by FIRST trying to keep things under wraps.
I see both sides… but just try to look at what is useful coming out of this - teams that can help other teams, and maybe future Beta tests will start early enough that teams will have more time to document and get others up to speed.
Very well said, and YES it is difficult for me and many eager teams to sit by and watch.
Most open source models still publish a bug report to inform the other users of their development.
The fact that FIRST imposes rules makes be very uneasy… but that’s another story.
I agree that documentation is very difficult, I just wish the Beta Organizers would have encouraged more team created tutorials. The community really needs Beta teams to put proper time into creating tutorials. The Java WPI page is a good clean web page tutorial, hopefully NI takes notes and organizes their pages into one cohesive page.
“Knocked down by FIRST” sounds very discouraging for a community that should be encouraging creative ideas. I hope that you bring back your wiki idea because it sounds great !
Thanks for taking the time to talk about this important issue.