![]() |
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
Quote:
I should have been more specific with my examples. I also should have said that these details need to be listed when they matter to the design. Some more detailed examples: Last year for our shooter release we used a COTS dog gear with the stock screw. We wanted to stay as COTS as possible but kept shearing screws. We tried plain carbon, 300 series CRES, titanium and finally A286 CRES screws before they stopped failing. If I only had a STEP of the screw you would have no idea you need a specialty fastener. I have rarely been designed into a corner where I want to use a COTS screw but need to make sure there is 3 full threads engagement worst case. If the next size screw is too long and will hit something I have had to go from an easy to find UNC thread to UNF, UNEF or UN threaded screws. Look at the STEP for the Vex 3 CIM ball shifter and tell me if there is any retaining compound and if so where/what it is. Overall I would say if it is non-standard, vendor specific or failed once and you had to replace it, disclose that in addition to your STEP. Bonus points for telling folks where to get the parts cheap and easy. Let us use what you have learned. My favorite example of this is 3/16" red spade terminals - every year I bring an extra box to competition because many rookie teams get the more common 1/4" wide spades and they fall off their RS??? motor and make problems. -matto- |
Re: FRC Blog - Some Tidbits Before Kickoff
If we're being pedantic, I'd argue that there's no requirement here that a shared design be useful or that it work at all. The absence of fasteners, thread counts, retaining rings, assembly instruction or GD&T limit the usefulness of the design, perhaps, but don't necessarily represent an incomplete design.
Further, there's no requirement that teams using design information shared before kick-off cede any right to refine or modify that design. Consider, then, that adding the missing fasteners could be considered a design revision and that there's nothing that prohibits any such scenario. More interesting than this particular rule, in my mind, is that FIRST has rewritten some or all of the manual itself. With any luck, the language will be clear, concise and straightforward, but based on the discussion happening here already, I'm not getting my hopes up. |
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
Quote:
Further, what a team does in the off season other teams/inspectors don't generally know about unless you actually post something about it. So, it's largely up to the teams to self-enforce this rule. The intent here is, I think, two-fold. First, it's intended to help level the playing field - a 20 year old team can't have an advantage by having a large library of designs that a rookie doesn't have. Second, it's a chance for less experienced/knowledgeable teams to learn from the designs of those teams with more experience. At the bottom of the inspection checklist, right above where we have both a mentor and captain sign, is a statement that says "We, the Team Mentor and Team Captain, attest by our signing below, that our team's robot was built [...] in accordance with all of the 2014 FRC rules, including all Fabrication Schedule rules. [...]". We trust the teams to do what they feel is within accordance with the rules, and that statement is them telling us that they did. Draw the line where your conscious and common sense tells you it needs to be drawn. |
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
Heck, if a team really wanted to, they could minify/obfuscate all the software they want and it would still follow the rule if they released it. As long as you can compile the code or manufacture the part from the source given, hence (complete information sufficient to produce the design), then it should be good. Is it necessarily within the spirit? Maybe not, but it sure does comply with the rule. |
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
Of course, this is a stupid argument to be having because no inspector has ever checked to see if a design was published prior to build. And even if it wasn't, no inspector should ever force a team to rebuild a subsystem at an event just to force compliance with this rule. It would be against the goals of the program. |
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
Publishing just enough of an design to make it "legal" & not useful is really against GP & the intent of the rule. While there are individuals that might think that way I hope that is not a general philosophy on any team. If I can across it, I would use my mentoring skills (such as they are) to change the attitude. :) |
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
Which is why I've always thought this was a pointless rule. Who cares if I use the same velocity control code I developed in the off season, the domain knowledge I gained from doing it means that it's mostly a matter of rewriting it anyway. Same with mechanisms, at some point designing an elevator becomes a function of doing the same thing then tuning it to meet your specific design requirements. And I don't see FIRST mandating that we can't use knowledge gained in the off season, I don't view designs or code as any different than knowledge. |
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
Re: FRC Blog - Some Tidbits Before Kickoff
Quote:
|
| All times are GMT -5. The time now is 18:42. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi