Value of Coopertition

[XaulZan11]

Many teams in FIRST view the 'main challenge' as "Designing a robot that gives us the best chance at winning" opposed to "Designing a robot that scores baskets". In this sense, the teams that focus on endgame or other support roles are certainly attempting the 'main challenge'.

[Tom Line]

It's all part of strategy - which is a huge part of FIRST.

One of our rookie teams had just enough knowledge to build a defensive toaster with a arm to drop the bridge. They were extremely proud that they consistently had one of the top balance scores.

I might argue that the 'point' of the game isn't necessarily what you think it is. In 2007, the majority of the time was spent hanging tubes - but most of the time robots on other robots won the match.

In 2009, the point of the game was to shoot balls into other people's trailers. Yet if I remember correctly, good human players consistently scored on par with robots.

In 2011, for the first 4 weeks of the season, a fast Minibot guaranteed a 85%+ win rate. In fact, a team on the World Championship Winning alliance was picked because they had the fastest minibot at Worlds.

[Nemo]

Originally Posted by Tom Line

In 2011, for the first 4 weeks of the season, a fast Minibot guaranteed a 85%+ win rate. In fact, a team on the World Championship Winning alliance was picked because they had the fastest minibot at Worlds.

That particular robot was also quite good at scoring tubes. And had a really good drive + drivers.

[Cory]

Originally Posted by Nemo

That particular robot was also quite good at scoring tubes. And had a really good drive + drivers.

Their minibot had very little to do with why we picked 973. They were simply at worst the 6th or 7th best robot in the division and as mentioned, the most important part was we knew they had a rock solid base, good drivers, and a coach we have worked extensively with.

[F22Rapture]

Originally Posted by Tom Line

It's all part of strategy - which is a huge part of FIRST.

One of our rookie teams had just enough knowledge to build a defensive toaster with a arm to drop the bridge. They were extremely proud that they consistently had one of the top balance scores.

We were one of those teams as well (almost down to the letter, in fact I just had to check the Spyder app to make sure it wasn't us ). Being a 2nd year team with few resources in a small town in rural NC, we barely had enough money to do much else. I think the final total for the robot was 430-something dollars, including an axis cam we had to replace.

Due to a massive amount of overthinking things, we spent almost 3.5 weeks on design with most of that time wasted because we ultimately didn't have the resources or time to manage it. And then our sole programmer was grounded, with the result being that we the very first time we were able to drive the robot was our first match on the field. Despite all of this; only having an arm with no way to shoot baskets, having no driver practice whatsoever, finicky programming and fail-prone hardware, we still managed 17 seed out of 53 teams from a mixture of very reliable balancing and coopertition.

While I am glad that we managed to do as well as we did, I do think it reveals some weaknesses in the way FIRST handles balance overall.

Bot in the foreground:
https://picasaweb.google.com/1016099...67442407026626


(We are significantly better off this year, and we're definitely trying to make sure that never happens again)

[Craig Roys]

Originally Posted by F22Rapture

Due to a massive amount of overthinking things, we spent almost 3.5 weeks on design with most of that time wasted because we ultimately didn't have the resources or time to manage it.

This is a bit of an aside from the actual discussion, but I would argue that the time was not "wasted". Did the team members learn anything from the experience? Even if it wasn't used this past year, there was probably learning that will carrying into future seasons. In 2008 we spent almost 4 weeks on trying to design a new drive system that we ultimately scrapped for a much more simplistic design; however, the time we spent working on and troubleshooting was not "wasted" - we learned a lot of valuable lessons that we still draw from today. Failure is not necessarily bad...it depends on what you do with it.