2010 Control System Getting Started

[lynca]

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.

Here is a quicklist of Beta Documentation !

Introduction Presentations
67 - Java Overview
330 - Labview Feature Overview
Java Early Access
1089 - Java Test Documentation
1279 - Java Presentation

Labview Code Samples
330 - BeachBots BETA Code
1718 - Labview Code -

Java Code Samples
341 - Miss Daisy Code
339 - Kilroy Code

C++ Code Samples
67 - HOT Team Code

Hardware
67 - CAN Presentation
330 - Drivers Station

2009 Documentation is still useful but outdated

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.

[Chris is me]

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.

[Daniel_LaFleur]

I've said it before...

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

Maybe it would be better to open source the whole thing and see what the FIRST community comes up with.

JMHO.

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

[EricVanWyk]

Originally Posted by Daniel_LaFleur

I've said it before...

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

Maybe it would be better to open source the whole thing and see what the FIRST community comes up with.

JMHO.

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.

[Daniel_LaFleur]

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.

[David Doerr]

Originally Posted by lynca

Java Code Samples
341 - Miss Daisy Code
339 - Kilroy Code

More Java Samples:

67 - HOT Code
330 - Beach Bots Code
3006 - 3006 Code

[Greg McKaskle]

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.

* Copyright (c) 2009 FIRST, NATIONAL INSTRUMENTS, WORCESTER POLYTECHNIC INSTITUTE AND THEIR LICENSORS

* All rights reserved.
*
* 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.

Greg McKaskle

[slavik262]

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?

[Greg McKaskle]

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.

Greg McKaskle

[Jon236]

Greg,

Can the presentation at Kickoff in NH on enhancements in code and hardware to the Control System be webcast, or recorded and posted later that day?