legality of bolt and screw heads breaking plane of chassis meeting bumpers

[3286]

Without pointing fingers or fanning flames, in my humble opinion, and we all know what opinons are worth in todays market, this is an example of an area in the rules where graphics would be extremely helpful.

I know the GDC is probably up to here with opinions and I respect what they have to do each year, and I have no doubt they put a lot of time and effort into this to ensure that the playing field is level for all, but this would probably remove a lot of the questions that inevitably arise from taking ideas that are expressed in text only and the resulting confusion from interpreting these ideas.

Mike

[Don Wright]

The sad thing is as I look through the pictures posted of team's robots, I would be willing to bet that >75% are illegal due to this stupid ruling.

IMHO, the GDC made a hasty ruling, and instead of eating crow and retracting or changing it like they have in the past when such a thing happened (like the "no band saws in the pits" ruling), and correct it to the obvious and rational ruling, they are sticking with it and it's going to really cause a ton of problems at the early regionals.

All for nothing.

[Daniel_LaFleur]

Originally Posted by Don Wright

The sad thing is as I look through the pictures posted of team's robots, I would be willing to bet that >75% are illegal due to this stupid ruling.

IMHO, the GDC made a hasty ruling, and instead of eating crow and retracting or changing it like they have in the past when such a thing happened (like the "no band saws in the pits" ruling), and correct it to the obvious and rational ruling, they are sticking with it and it's going to really cause a ton of problems at the early regionals.

All for nothing.

Stupid ruling? Hasty ruling? Not the correct or rational ruling?

... seems to me that we have been given a requirements specification list from our customer (rules from FIRST) that we need to comply with. Whether you agree with these requirements or not, you accepted them as a part of your terms so that you could compete and now that you've shipped your product and it doesn't comply you call the requirements stupid?

Doesn't make much sense to me. Seems your time would be better spend figuring out how to comply with the requirements and not bashing them.

JM(NS)HO

[Chris is me]

Originally Posted by Daniel_LaFleur

Stupid ruling? Hasty ruling? Not the correct or rational ruling?

... seems to me that we have been given a requirements specification list from our customer (rules from FIRST) that we need to comply with. Whether you agree with these requirements or not, you accepted them as a part of your terms so that you could compete and now that you've shipped your product and it doesn't comply you call the requirements stupid?

Doesn't make much sense to me. Seems your time would be better spend figuring out how to comply with the requirements and not bashing them.

JM(NS)HO

Rules don't become not stupid just because we have to follow them. Of course everyone's going to follow and accept the rules, and most if not all of the people complaining have made their robots compliant. I don't see why we have no right to complain over something that was legal week 3 and then illegal week 4.

If no one ever complains, how would anyone ever know anyone had a problem with any rule? The rule IS stupid and hasty, even though we do have to follow them. Yeah, in the real engineering world, complaining that your boss or client gave you a requirement isn't a good idea, but I'd rather not jade my teammates into the philosophy that there's no use expressing an opinion on anything. Just yet.

[Don Wright]

Originally Posted by Daniel_LaFleur

Stupid ruling? Hasty ruling? Not the correct or rational ruling?

Doesn't make much sense to me. Seems your time would be better spend figuring out how to comply with the requirements and not bashing them.

JM(NS)HO

And I think you missed my point completely.

Our robot is bagged and meets the requirement. If I was only worried about our robot, then I wouldn't be spending my time "bashing it".

But, I have a broader view of the problem outside of just my team and I'm thinking of the 75% of the robots that show up at the competition and have to really work hard to make their robot legal due to a stupid ruling instead on focusing on better things...if they can even make their robot legal.

Now, if the ruling was just changed to allow fasteners (welds, strings, etc.) outside the bumper zone...we can stop bashing...and I can stop worrying about all the teams that have no idea that this problem will be there when they go to inspection on Thursday/Friday...

[Dmentor]

Originally Posted by Chris is me

Yeah, in the real engineering world, complaining that your boss or client gave you a requirement isn't a good idea, but I'd rather not jade my teammates into the philosophy that there's no use expressing an opinion on anything. Just yet.

Segue to the real world for a moment… I agree that simply complaining is not a constructive approach for resolving issues (requirements or otherwise) but communications is absolutely essential in engineering. My experience has been that in complex projects there is almost always a two-way communications channel between the engineer and the customer. Requirements are an abstraction of what a customer wants (by the way this leads to the distinction between system verification and validation). Said another way, requirements are a powerful communication device but they don’t always perfectly reflect the customer’s desires. Many times the customer’s need can’t even be fully articulated. That is where direct dialog with a customer is crucial to ensure that we aren’t spending disproportionate time and material resources on meeting requirements that don’t really represent the customer’s need in the first place. As an engineer, when I don’t understand the rationale behind a particular requirement that really means that I don’t fully appreciate the customer’s problem and means I better spend more time communicating. So please don’t think that in engineering requirements always come down from high engraved in stone.

I think the frustration that we see in many of these requirements "debates” is that we have a limited communication channel for understanding the rationale behind non-obvious requirements. As practicing engineers, we are trained to think critically about requirements, figure out how to make improvements, and then communicate this back to the customer. Friction results when we can’t “close the loop” between our thought processes and our customer’s. In FIRST, the GDC obviously has the authority to define the requirements any way they like. I would like to think that they aren’t intentionally trying to irritate their engineering mentor base with arbitrary rules, but the question remains how can we bridge the gap in our understanding without an appropriate communication channel? Since we haven’t been able to carry on an effective dialog with the GDC, we instead turn to our peers on Chief Delphi in hopes that maybe they can set us straight.

[artdutra04]

Originally Posted by Daniel_LaFleur

Stupid ruling? Hasty ruling? Not the correct or rational ruling?

... seems to me that we have been given a requirements specification list from our customer (rules from FIRST) that we need to comply with. Whether you agree with these requirements or not, you accepted them as a part of your terms so that you could compete and now that you've shipped your product and it doesn't comply you call the requirements stupid?

Doesn't make much sense to me. Seems your time would be better spend figuring out how to comply with the requirements and not bashing them.

JM(NS)HO

Rules and laws are just contracts between people, and when we find them to be misguided, we continue to follow them but heavily lobby for their repeal (hopefully with the pen and not the sword). Right now, I can't see any logical reason why a bolt head that sticks out a quarter inch past the FRAME PERIMETER (but remains inside NORMAL CONFIGURATION) is illegal except for "because the GDC said so". I never accept "because we said so" as a valid reason, because it reeks of arrogance on the part of the person or entity making the rule and only seeks to downplay the intelligence of those to which the rule is given.

We're smart people. If the GDC gave us a logical reason why bolt heads couldn't extend past the barrier, then most rational people here, myself included, would accept it and move on. Until then, I think this is a pretty dumb rule.

If this was the real world, and a client specified that no bolts could stick out, I'd personally ask why. For all I know it could just be that the boss of said client's company thinks flat head bolts look nicer than socket head bolts, but would compromise with button head bolts in order to save the costs of countersinking lots of bolts. When engineers know why specs are the way they are, they can better design systems to meet the genuine intent of the client, as opposed to the what the client thinks they want/need.

[Bharat Nain]

Last time I checked, we are a part of a high school robotics competition meant to inspire young students into science and technology careers. FIRST is a lot of fun and it keeps us all in it.. but that does not mean we should have to deal with rules nobody can comprehend the reasoning behind. I don't blame anyone for being upset about this rule. Saying "I'm sure GDC has a sound backing behind this rule" soothes no one. Fortunately, our robot was relatively simple but I pity teams who have to re-build parts of their robot at the regional... or rebuild an entire robot at regional because of a shipping mishap.

[Daniel_LaFleur]

Originally Posted by artdutra04

Rules and laws are just contracts between people, and when we find them to be misguided, we continue to follow them but heavily lobby for their repeal (hopefully with the pen and not the sword). Right now, I can't see any logical reason why a bolt head that sticks out a quarter inch past the FRAME PERIMETER (but remains inside NORMAL CONFIGURATION) is illegal except for "because the GDC said so". I never accept "because we said so" as a valid reason, because it reeks of arrogance on the part of the person or entity making the rule and only seeks to downplay the intelligence of those to which the rule is given.

We're smart people. If the GDC gave us a logical reason why bolt heads couldn't extend past the barrier, then most rational people here, myself included, would accept it and move on. Until then, I think this is a pretty dumb rule.

If this was the real world, and a client specified that no bolts could stick out, I'd personally ask why. For all I know it could just be that the boss of said client's company thinks flat head bolts look nicer than socket head bolts, but would compromise with button head bolts in order to save the costs of countersinking lots of bolts. When engineers know why specs are the way they are, they can better design systems to meet the genuine intent of the client, as opposed to the what the client thinks they want/need.

Art,

First off, I don't like the ruling anymore than the next guy, but ...

Asking your customer for the reasoning behind a spec is all well and good (and actually very wise), but posting on a unofficial, public forum that their specifications are "stupid" is niether proactive nor wise. This is neither the proper forum, nor the proper way to get an appropriate answer ... hence my "whine" comment.

Also, when asking for the reasoning, you might want to consider "because we said so" as a valid answer, lest your customer take his multi-billion dollar buisiness elsewhere. You see there may be many possible reasons why they cannot disclose information to you (IP issues?). Consider this just a design constraint.

All in all, you might consider just putting your efforts into making sure that those who didn't follow the letter of the rule still get on the field, rather than bash those who put the design constraint in place.

[Bharat Nain]

Originally Posted by Daniel_LaFleur

Art,

First off, I don't like the ruling anymore than the next guy, but ...

Asking your customer for the reasoning behind a spec is all well and good (and actually very wise), but posting on a unofficial, public forum that their specifications are "stupid" is niether proactive nor wise. This is neither the proper forum, nor the proper way to get an appropriate answer ... hence my "whine" comment.

Also, when asking for the reasoning, you might want to consider "because we said so" as a valid answer, lest your customer take his multi-billion dollar buisiness elsewhere. You see there may be many possible reasons why they cannot disclose information to you (IP issues?). Consider this just a design constraint.

All in all, you might consider just putting your efforts into making sure that those who didn't follow the letter of the rule still get on the field, rather than bash those who put the design constraint in place.

Wait.. FIRST is our customer??

[Pausert]

I understand the idea that real world engineering has to respond to a customer's constraints, but in the real world, how often can customers change an extremely important facet of the their specifications 75% through production without having to pay some sort of price or be told they need to wait a bit longer?

[SteveGPage]

After this ruling came out, I took a look at our design and pointed out where we were in compliance and where we were not. The lead mentor looked at me like I had two heads. I told him "We either change it now, or change it on the first day of the competition. Your choice." We changed it then and there, while we still had the luxury of making the change in the shop, and not the pressure of a competition starting in a couple of hours. I agree that the perhaps the ruling could have been handled better, but teams were given the chance to respond to the ruling and make the needed design changes. So file this under "life isn't fair" and move on.

Adding to what Daniel said, so now we have a different issue, and one that has some degree of urgency. The week one competitions start in 60 hours from now. We have recognized that this year, more than most years (in our case, due to Snowmeggeddon primarily), we will need to be organized and ready to assist other teams to help get them ready to compete. We have communicated with the other teams at the Chesapeake regional to see who has the ability to help, and who needs help. My suggestion would be - get a bunch of pre-cut plywood strips and bring it to the competition and be organized and ready to assist as soon as you can. Maybe next year things can be done differently, but doubt we will see much movement on the change to this rule this year. Think of this as a major glitch, barrier, crisis, etc... and find a way around it/fix it/solve it. Who knows, maybe the GDC wanted to introduce some crisis and see how everyone responded? I know half the major projects I manage, that usually happens too!

[cabbagekid2]

Originally Posted by Al Skierkiewicz

I know that this is a complicated area of the robot rules. You must look at all the rules and the bumpers must satisfy all the paragraphs in R07. Fasteners and bolt heads inside the bumper zone are permitted to extend beyond the FRAME PERIMETER and in R07, par D, holes and pockets are allowed to be made in the backs of the bumpers to facilitate secure mounting of the bumper system. In no configuration may any part of the robot exceed the maximum dimensions of R10 whether that be inside or outside the bumper zone. As pointed out above those fasteners in the BUMPER ZONE that project outside the FRAME PERIMETER are permitted. Similar fasteners projecting the same amount beyond the FRAME PERIMETER but outside the BUMPER ZONE are not permitted.

Al, the rules allow you to pocket the bumper to allow for bolts, etc sticking out of the frame perimeter, but is it REQUIRED or just allowed? I thought that by being excluded from the frame perimeter, bolts, tie straps, etc can stick slightly out of the perimeter and the bumper sit flush (with the exception of the fasteners) without being pocketed.

For our case, we just have tie straps wraping around the frame in the bumper zone. Will we be required to have 10 vertical and horizontal notches on our bumper to allocate for these tie straps to allow the bumper to be perfectly flush? Or is it okay to just slap the bumper on the tie straps? The tie straps being used are small (similar to the vex ones).

[eugenebrooks]

Here is a QandA that does not address this question directly,
but is quite close.

Join Date: Jan 2010
Posts: 1
Warped Bumpers
We manufactured two sets of bumpers early in the build, to the specifications of <R07>. Since then, we have mounted the bumpers on the robot and found the 3/4" plywood has warped, making them slightly convex. Do the bumpers have to be in contact with the frame through the entire length of the robot?
#2
02-15-2010, 11:35 AM
GDC
Game Design Committee

Join Date: Jan 2006
Posts: 2,401
Re: Warped Bumpers
Yes. Please refer to Rule <R07-M>. The BUMPERS have to be supported along their entire length.

[Vikesrock]

Thanks for posting that Eugene, I had managed to skip over or miss that one.

I'm going to guess that at least 50% of robots and potentially many, many more will not be in compliance with that response when they come out of the crate.

I hope the inspectors show some common sense and let small gaps (less than 1/8"), due to slight warping of the plywood or parts of the frame that aren't perfectly square, pass.

I may be heavily arguing for a piece of foam as a frame member if inspectors don't take it into their hands to be reasonable with this one.