[Katy]

Originally Posted by Lil' Lavery
It's still better than last year, when the scoring system went down (and even often when it was up) there was little indicator of the exact score as the game pieces were recycled back into play. After seeing pictures taken from the alliance stations in New Hampshire, it isn't quite as hard to see the other side as one might imagine.

It is unquestionably better than last year but last year was not very good and so that is not a particularly narrow category. I'd rather talk in terms of "good enough" and "not good enough" and I am afraid this may eventually fall into the latter.

Originally Posted by Lil' Lavery
I people got shot with poof balls, tetras broke, balls popped, and just about all that stuff before too...

I was thinking on the order of magnitude of stack attack bins...basically enough that it could possibly be a reasonably sized additional cost to running a regional. Also it I assume it is probably more difficult by a significant margin to injure yourself with a poof ball than a large chunk of swinging metal.

Originally Posted by Noah Kleinberg
Another concern with the rack is that it's expensive to build. Somewhere on chiefdelphi someone said that the wooden version of it costs around $500 to build, and it's still not going to be the same as the competition model. Even if you have the money and space for a rack, your next problem is time, especially on smaller teams. Rookies are going to have a pretty hard time this year I feel...

Wow that is even worse than I had imagined! Can anybody confirm the source/provide a link?

Originally Posted by Lil' Lavery
How would rookies learn to program better if older teams had to learn a new sensor? That makes no sense to me. If anything, it's easier on the rookies, because mentoring teams can help them with far more expertise than if they were learning new technology as well.

The the benefit that somebody can teach you the system is small compared to the advantage the teaching team has. Many teams are kind and generous to all in need this is true but I do not think FIRST should be banking on the good will of the teams in the league to ensure a level playing field. I think the game design itself should cause a level playing field. I think things would be a lot more even if every team was struggling to learn the new sensor.

That said I can respect the fact that FIRST has perfected the use of the camera and they know this one works. There is a lot to be said for having working parts. If somebody can show me that the lack of resources to test and debug new sensors is why we do not have new sensors I will respect that. I'll also gladly offer to help test and debug new sensors myself.

Originally Posted by Tetraman
I think you underestimate what rookie teams and low budget teams can produce. Rookie teams can be powerful for the reason they don't have background knowledge and can work with a greater number of possibilities than teams who know what works and what doesn't.

My team I'm mentoring is a low budget team. It's different from 174 which had money to spend as needed. I actually found it slightly easier to design with simple materials and cheap design than get into lots of mechanisms.

I know rookie teams are powerful. I mentored one last year that went to semifinals in Boston and I spent highschool on a low budget team in WA which did well on several occasions. If they were hopeless cases there wouldn't be much point in attempting to look out for them because they'd be well...hopeless. It is out of a deep respect for rookie and low budget teams that I attempt to speak out for their interests.

Originally Posted by Kamikaze
An observation about game complaints: Speaking as a 4th-year FRC programmer, I would say that the differences between the competence of programming teams will be more related to the programming skill, enthusiasm, and awareness of good development practice of the team members more than a particular familiarity with a specific component.

So I don't think the arguments about cameras being easier for veterans that have been presented in this thread hold much water. Teams with quality robot code will have good programming as long as they can retain their skilled members and good practices (e.g. use revision control, sub-divide tasks, test at every step, etc.). The best way to improve your programming team is by having members become passionate about computer science in their own time and investing some effort to go read a few books and papers (and you certainly can't level that out with rules).

Speaking as a 6th-year FRC participant who happens to be majoring in computer science I can agree with you that there are obviously more important things that determine the difference between a competent programming team and an incompetent one. I consider the things you listed to be basic requirements to a functioning programming team. However once you have those basics, having somebody who has done the task before (in this case finding a green light and steering with it) it a tremendous advantage. Your argument strikes me to work along the same lines as if I said, "we shouldn't worry about having programmers who can code or not because nobody will have a working anything without oxygen." While the logic is absolutely true it is rather irrelevant. I am assuming already that most teams which would gain a competitive edge from being in the same starting place as older teams on a sensor have programmers who know how to program with common sense, communicate with the rest of the team and teach themselves more. This is probably the same way that you assume a competent programming team will be programming in a setting with oxygen.

I can't tell you how comforting it is to see you guys argue with me. I really want to be wrong on all of this.