RACK & ROLL Reaction

[KTorak]

My first reaction was "Where am I am gonna find pool noodles AND inner tubes in the middle of winter in Michigan?" As for the game, it has potential to be pretty interesting, but I suspect we'll see a lot of similar appendages that we have seen from 2005 (most likely) and other past games.

[BBnum3]

At first I was sad because we weren't shooting anything. I really liked that aspect of the game last year and that it felt like a real sport. After thinking about strategies and game tactics more though, I am starting to like Rack and Roll a lot. I love the elevation of robots in the home zones and the different weight/height classes. They offer an interesting trade-off. It is nice to see something different, and I think it will be great to see how the game is played.

[darkember]

you know what will be hard, if a robot is nearly six feet tall and it trys to climb a ramb onto another robot. The robot will probably fall over.

[darkember]

The bonus points seem to be harder to get then the game points.

[Billfred]

Originally Posted by darkember

you know what will be hard, if a robot is nearly six feet tall and it trys to climb a ramb onto another robot. The robot will probably fall over.

That's far too broad a statement to be making. Lots of six-foot robots climbed the ramp in 2006, which was far steeper than teams have to make theirs this year.

[darkember]

Originally Posted by Billfred

That's far too broad a statement to be making. Lots of six-foot robots climbed the ramp in 2006, which was far steeper than teams have to make theirs this year.

but what if the ramb is steep and the robots center of gravity is above the center of the robot. Also, you wont have as good of a traction going up the ramp.

[DanDon]

Originally Posted by Billfred

That's far too broad a statement to be making. Lots of six-foot robots climbed the ramp in 2006, which was far steeper than teams have to make theirs this year.

If I recall correctly, last year's height limit was 5ft.

[edit]

Darkember: that all depends on the robot's drivetrain, and the way the robot with the ramp builds it.

[/edit]

[darkember]

This year they are letting you go up to six feet but the robot has to be under 100 pounds.

[eshteyn]

Originally Posted by darkember

This year they are letting you go up to six feet but the robot has to be under 100 pounds.

It does not matter what the weight of the robot is as if its center of gravity is high it may fall if it tries to go up a ramp at a high speed.

[darkember]

i said that earlier

[Pavan Dave]

very true....CG is very important when people are considering ramps on their robot.

Pavan.

[Dominicano0519]

Originally Posted by Billfred

That's far too broad a statement to be making. Lots of six-foot robots climbed the ramp in 2006, which was far steeper than teams have to make theirs this year.

the limit was five feet last year

[MikeDubreuil]

My reaction...
Not as good as my favorite year (2000), but I like it. Apparently FIRST threw out that whole philosophy that the game should be easily scored/explained to your grandmother.

[darkember]

Originally Posted by darkember

you know what will be hard, if a robot is nearly six feet tall and it trys to climb a ramb onto another robot. The robot will probably fall over.

Im sorry for this earlier comment. i didnt mean to cause so much arguing.

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