![]() |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
Although there is no way to say for sure what the GDCs intent is, one could argue that 179's bot goes against the GDCs intent of the game because the robot is not on top of the bridge when it is balanced. Following the intent of the rules would seem to allow 179's bot because it is fully supported by the top of the bridge, but wouldn't allow a troll 'bot, whereas following the rules exactly (before the update) would allow a troll 'bot. Hopefully this is a good enough example to show the distinction between following the GDCs intent for the game, their intent for the rules, and the rules as they are written. To me, the first option is kind of boring because it limits some of the greatest ideas (179 this year, 469 in 2010...), and the last option is only going to make the teams who didn't notice a loophole jealous of the teams who did. |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
Quote:
|
Re: The Ultimate Game-Breaker Robot: 2012 Edition
In my unimportant honest opinion:
Whoever built a trollbot: You took a risk knowing that the rule could get overturned by the GDC at pretty much any time. Obviously you would hope it wouldn't, but it has, and you took that risk. Its quite obvious what they intended you to do with the bridges. Deal with it, just as you would have to in the real world. To the GDC: Next time, don't wait until week 6 to pull something like this. It clears up what you intended the bridges to be used for/as, but this should have happened at maybe week 3 at the latest. To both: The Q&A is a unspecific mess, thanks to the "We wont comment on exact robot design" rule that I heard somewhere from the GDC. Sometimes, you have to see an example to see where the poster is coming from. This probably would not have helped much in this case, as only a "What makes up the bridge?" question was asked, but if the question was more specific they most likely would have flat out given you a "No, you can't do that" on the spot. As long as the poster doesn't supply detailed drawings and such, it really should be allowed. My 2c |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
Quote:
Quote:
Quote:
If one needed to hire some engineers, doesn't it make sense to hire at least one who is willing to point out when the spec might be ambiguous, or when the customer's expectations might not correspond with the contract language? By arguing the point, that's exactly what Andrew is expressing to you. Is it cheaper to hire him now (and waste a little time/money now and then), or to wait, and hire a lawyer later? |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
I can forsee a new adjunct activity for FIRSTers that maybe goes along with Fantasy FIRST (FF) or maybe it will be a sidebar in that popular game. It involves assigning a probability to each and every rule in the 2013 manuals concerning whether it will be changed during the season by team update or Q&A. Tiebreaker points for those guessing the update or distance into the season at which the rule is altered. Nolo contendere applies for obvious spelling errors.
Of course, there will have to be a point in week 1 when the parimutuel window closes but I think there's a good chance it will have the effect of EVERYONE taking a good hard look at the rule book before much metal gets cut or even before too many CAD electrons are spun into fruitless webs. I made a post (somewhere) about my observation of teenagers' reaction to hearing about rules they hadn't read well enough to know if they could be ignored. I will find it again when I click on my name in this post. ;) :D |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
I think it could be done. But I'd do more of a pick-em style, where you could choose whether or not to make predictions on a rule. Such as: # of Q&As, # of posts on CD discussing the rule, if there would be a change (and if so, when), and whether the change would be made by Q&A or Update. :D Points awarded by accuracy (0 for fail, 2 for full accuracy on any one prediction (within reason), 1 for being "in the ballpark, but you're in the stands part of the ballpark"). Bonus points for predicting what change will be made. No making exactly the same prediction as someone else on a given rule. |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
Quote:
Quote:
Fundamentally, we're not being asked 'build a robot that confirms our expectations about how robots can complete certain tasks'. The fundamental intent and the fundamental constraint is merely 'here are the rules, go play and maybe learn something about the value of engineering'. That encourages creativity and allows teams to try things that would never fly in a conventionally risk-averse engineering environment. That sandbox mentality is a big part of why it's fun. (And let's be perfectly honest: if this was a real engineering task, there are all sorts of things you'd rarely do—like spending time teaching the least capable members of the team new skills, or humouring bad ideas for educational value.) I say that because FRC is unusual, even among competitions: the game rules are freshly written every year, and there's little weight in precedent or unwritten convention. By choosing to create a new game every year, the GDC has both the enviable opportunity and the significant responsibility of creating an internally-consistent set of documents that describe all of the critical parameters of the challenge. Worse, when they resort to cop-outs like 'sorry, that's not what we intended', or 'use engineering common sense', they're betraying the essence of any competition—that the competitors are treated equitably so that any difference between them comes down to skill, preparation and the luck of the draw. Taking the role of the capricious god who strikes down his loyal subjects is no way to administer a competition. FRC is not about a relationship between equals like the engineer and client, both of whom are equally able to negotiate a contract on mutually agreeable terms. Instead, it's like a contract between entities of disproportionate power—like you and the government, for example. In those cases, the more powerful party bears an additional equitable burden to ensure that they are treating those who have no recourse in a reasonable way. In FRC, that means setting expectations and sticking with them, unless there's a compelling reason to do otherwise—and only then, with due consideration of the impact on the weaker parties. This situation violates that equitable expectation, because teams should have been able to rely on FIRST's past explicit statements. I of course realize that FIRST probably made an innocent mistake—and that has mitigating value. But FIRST missed other opportunities to mitigate the damage. They could have written the rule more clearly in advance, or labelled the diagram better. They could have explained that they surveyed all the teams, and if none were using this strategy, then the issue would be moot. They could have explained that the GDC had considered all of the issues, but upon reflection, decided that this was the best course of action. Indeed, I think it's that last one that's annoying people. Probably for eminently practical reasons, the GDC is like a machine where questions go in, and dicta come out. There's rarely any indication of what's going on inside. Did the GDC actually understand the question, but deemed it unreasonable? Did they misunderstand the question? Did they spend more than 30 s discussing what a team feels is a crucial and complex issue that doesn't easily lend itself to a fair resolution? Occasionally, we even hear that the GDC has rather heated arguments over points of principle—is the ruling the result of level-headed conversation, or a shouting match? Knowing these things isn't crucial, but it is beneficial, because it establishes a frame of reference for the team that was just told their robot is pretty much useless. It also dampens criticism, because the explanation crowds out alternative theories like incompetence or ulterior motives—theories that can spread unchecked when the only response amounts to 'it's week 6: now the rule means this'. The other factor feeding this discontent is the fact that the GDC had three perfect opportunities to get the definition right: once when they wrote the rules, and twice when teams asked for clarification. All three times it was an (understandable) oversight, but that doesn't change the fact that teams would desperately like to believe they can trust what the GDC has to say. And that brings me to risk. Having been involved with this competition for a very long time, in many capacities, I know a lot about how the organization operates, and how GDC decisions are implemented in the field. There's a substantial amount of variability (most of which is undesirable), and this makes for a lot of risk, when it comes to non-mainstream designs. Will your inspector pass you or fail you, based on their understanding of the rules, and their willingness to tolerate equitable deviations from the rules under extenuating circumstances? The same goes for the referees. This has to figure into your risk estimates, if you're trying anything even remotely controversial. Sometimes you make out well—like 190 in 2008, who managed to convince the officials (at one regional) that the rules referred to a robot-based co-ordinate system, rather than a field-based one. And sometimes you don't—like 1519 in 2008, who complied with all of the rules, but were dealt a mortal blow as a result of a dogmatic interpretation of the undefined term "robot". Another aspect of risk is based on the likelihood that the GDC itself will change the meaning or interpretation of something that a team relied upon. Again, in my long experience, this happens all the time in FRC. The examples are too numerous to count, but sufficient to say, all too often they occur late in the build season or even during the competition season, when the impact on affected teams is most severe. Now, I know about these aspects of risk, and because of that, I make contingency plans when I'm trying something controversial. I wasn't exactly surprised by this ruling. But the biggest problem with FIRST-induced risk isn't its effect on me, but rather its effect on less-well-prepared teams. If something isn't clear to a well-informed rookie (who has read the rules, but has no special insight into what the GDC is, much less today's definition of "engineering common sense"), it's not clear enough. Quote:
Quote:
We can say that it's common sense that driving under the bridge is not balancing it. But that presupposes a whole bunch of assumptions about what things are, and what terms mean. Since those terms are not all clearly and precisely defined in the rules (much less in common parlance), those assumptions are inherently open to debate. That doesn't make it not common sense—it merely demonstrates that nobody has a monopoly on common sense. If I disagree, based on my own self-consistent and reasonable interpretation, there isn't really much you can say to prove me wrong. We just disagree, because we have different worldviews. For that matter, isn't it also common sense to observe that a robot can be round (ever see a Roomba)? If common sense is so important, why did the GDC fail to employ it in that case? Could it also be true that common sense is not always obvious, even to our esteemed rule-writers? If they can't get it straight all the time (and why would we expect that of them?), why should we? Holding every team to their brand of common sense is untenable—and apparently unreasonable if they can't manage it themselves. Actually, the history of the rounded robot question is even more sordid than that. In 2009 FIRST actually said that a curved bumper was composed of an infinite number of corners, and thus each needed to be protected individually. (Again, that's something that a rookie wouldn't know, and therefore couldn't easily rely upon to assess the likely actions of the GDC.) They've said other nonsensical things, like plywood isn't plywood if you made it from plies of wood, or that the frame perimeter is necessarily a polygon (it's not: polygons are planar, the frame perimeter need not be). Give me a while, and I can go on and on—but the point is that I can say with some authority that many GDC interpretations do not reflect my understanding of common sense, and that they probably set off red flags for others as well. And as Bill noted, it should be pretty obvious that the average teenager has a different attitude toward common sense than people the age of their parents (like some GDC members). It's stuff like this that makes me adamantly opposed to the use of common sense as a crutch for bad specifications. |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
No doubt the teams that started a troll bot are pretty upset but it was a risky design decision. No amount of rule parsing, pre or post GDC, is going to change that. So how about we all learn from this and pose less obtuse questions to the GDC next year? |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
Quote:
And FIRST is nothing like "you and the government". FIRST is voluntary, one is compelled to do nothing. Quote:
I have designed some innovative control systems in my career. I have to work hard at not straying so far outside the box that I can't see the box. And I can honestly say that I would not have derived the trolling strategy from the GDC queries. Even now I can't believe anyone would think this a valid strategy - what on earth were they thinking? Quote:
Quote:
Quote:
|
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
The purpose of the bridge is pretty obvious. to balance. not to find loopholes to score more points. And I also completely agree, if someone flatout asked if it was legal, and they said yes, then overturned it, there would be a reason to be angry. But what is going on here is completely ridiculous. If you can figure out how to make a robot that small and still score 3 pointers you can suck it up and put a bridge manipulator on your robot. |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
The purpose of the bridge is what the GDC said it was, nothing more, nothing less.
And of course they didn't post a clear Q&A. The public nature of the Q&A would make that require revealing their whole strategy. They had the GDC state regulations which made them perfectly legal according to the rules and that should have been enough. |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
My first boss had a saying - "don't make big mistakes and don't make little mistakes twice". Trolling-gate was a big mistake that hopefully will not get repeated. |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Spotlight took me to this:
http://www.chiefdelphi.com/forums/sh...ad.php?t=18309 What would you have said? |
Re: The Ultimate Game-Breaker Robot: 2012 Edition
Quote:
|
Re: The Ultimate Game-Breaker Robot: 2012 Edition
I haven't followed this whole thread (read the beginning), so forgive me for being a bit out of context but...
It seems to me there should be an alternative way of submitting these types of questions to the GDC when it involves a unique strategy that you don't want to share with the world if it's legal. The reason the Q&A question was so ambiguous is likely because teams didn't want to tip their hands; but if they could ask the question and privately get approval that it is within the intent of the game, and if the strategy is denied then the private Q&A is made public so other teams are made aware of the ruling and subsequent clarification to the rules. I don't think world class teams should be forced to gamble their success on whether or not something is legal. If you decide a strategy probably isn't really "the intended game design", but it turns out to be legal, you'll be kicking yourself when you get schooled by someone who took that risk and "got away with it". To me it seems the only arguments for not having a privacy option to the Q&A would be to minimize the amount of work required and to protect the "not comment on a specific design" clause. |
| All times are GMT -5. The time now is 20:13. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi