Re-reading the rule book, I came across the following rule in the 2006 Manual, Section Five:
This rule seems to be saying that you can’t copy-paste sections of old code into your new robot’s brain. My first question is, is that the way everyone else sees it? What do you think this rule means?
My second question is this: what constitutes violation of the spirit of the rule versus the letter of the rule, and is such a violation acceptable to you? It seems to me that you could follow the letter of this rule while easily sidestepping the spirit. In general, is it acceptable to dodge around a rule you simply don’t like?
My team has used the same PID algorithm two years in a row. But, it was pretty much a standard one we got out of a book anyway. All the implementation and the gains were different, but that was still the same. I don’t see this as violating the rules because the only way around it would be to intentionally changing the algorithm just so we can use it.
Also, code that we used from someone else may have been used twice. I think we may have unintentionally violated this rule with Kevin W’s code, but I’m not sure if that counts.
Really, in most situations it wouldn’t even be possible to simply copy and paste previous years’ code.
This rule is written with no possible way to enforce it, so technical legal obligation are meaningless in this argument.
It seems that the spirit of the rule is to encourage learning and development by writing fresh software every year instead of having one good programmer write code that you can pretty much use every year.
My answer to the last question of “is it acceptable to dodge a rule you simply dont like” is yes. I do believe that too many people are into the cult of FIRST rather than the actual issue of the things they are supposed to teach, i.e. technical expertise, programming expertise, or actual robotics. Following this type of rule to the letter represents being too caught up with the organization of FIRST and not necessarily what it teaches.
Rule violations will always happen, unitentional and intentional. Things break, changes in the pit almost always leave with some type of violations, and some teams have to knowingly use a diffent gauge wire when they only have 3 minutes to fix it, but that not the point. The point of this program is not to pay incredible attention and respect the infallibility of FIRST, but to learn from it. When people are too caught up in the cult of FIRST, I feel that we miss the important parts of the program as in the actual robotics part of it.
Anyway, that was kind of off topic, but it is the observations of a person who was always into the team and into the robotics, but never really a huge fan of the FIRST cult.
p.s. I always copy and paste lines of code. Its quite annoying to have to write entire drive algorithms over again when you have the same drive train.
I see this as saying you can’t copy paste entire control systems from a previous year, not a section (since copying a section and then adding new stuff to it would be classified as “altering” it in my opinion).
If you were to say using any previous year’s code was against the rules, that would mean you really couldn’t even use past years as reference, since you would invariably end up having at least 1 line in common with it. I think they just want you to figure out how the program works from the past and add your own style to it, rather than importing whole files for drivetrain, arm control, etc.
I can agree with that one. Software engineering isnt exactly the same thing as hardware engineering. I also think its kind of hard to use the exact same code for every years robot so the rule is self surviving. Although, if you’re talking about simply mapping inputs to ports which is even done in the default code, copying and pasting isnt really a big deal.
I think the rule is geared towards more complex software. Maybe a personal software for camera? I don’t know. The rule doesnt entirely make sense right now but maybe it will in the future.
I think the rule is terrible, and the reasoning given for its creation is nice to listen to, but reaches a flawed conclusion.
:rolleyes:
Tangent about rules: the worst thing (in my opinion) about rules that have to be followed is the effect they have when they steer you to the edge of a cliff, and then tell you that you have to jump off. Absolutely painful to endure. This software reuse rule isn’t that bad, but with all the bad rules being enforced in my daily life, this tangent was a must-take for me.
If you have old useful code that you will have to rewrite from scratch, then please be careful! Its really easy to make a mistake…
Your answer reminds me of what an acquaintance said when asked what was his definition of a cult: “A cult is any religious group I don’t like.”
I see a serious problem with your answer, however. When people “dodge” a rule they “simply don’t like,” the results are often damaging to society. Political scandals, felonies, skyrocketing teen pregnancy rates, automobile fatalities–these are often consequences of people breaking rules they “simply don’t like.” Calling the party that sets the rules a “cult” (or any other label) does not justify breaking the rules–particularly if you participate in that group voluntarily. The only ethical grounds for deliberately breaking a rule is when the rule violates a higher standard.
People with long experience in FIRST know that sometimes the rules could be more clearly written, and there is often room for interpretation. But breaking rules merely for personal convenience is more than a failure in exercising Gracious Professionalism–it is an attitude that can lead to anarchy, a society in chaos.
There’s a difference between breaking a rule that you see as simply an inconvenience and breaking a rule that you know you shouldn’t break. For example, we all know it’s wrong to steal from people - massive violation of this rule would result in the anarchy you describe. But how would breaking this rule lead to anarchy?
Would you like to review your answer now that you see it in print? There is no way it is acceptable to violate a rule you don’t like or that you don’t believe. This one isn’t even that hard to implement. Just retype… One thing all team members must understand is that the rule book is what draws us all together by making us follow the same path. When we accomplish great things by following the same rules as everyone else we show everyone that it is possible. If you don’t like the rules then consider them a false set of real world constraints, like gravity. By avoiding the rules you are telling your students it is acceptable to violate any rule they don’t like. There is no ‘almost right’ in this question, there is no ‘it’s alright if I don’t like it’ to this question. And there is no ‘if no one knows then it’s alright’ to this question. A violation of the rules is a violation.
FIRST is not just about robotics. I believe that it has a higher standard. Gracious Professionalism is just part of it. There have been many threads about following rules. I will state again here that a rule is a rule. It is meant to be followed. It is there for a reason. It can be changed if the powers that be deem that you have a valid point. It is wrong to intentionally break a rule. It is a violation even if it is not intentional. If you break rules then you must live with the consequences.
It is also your responsibility to pay attention to all of the details. If you don’t in the real world then you won’t last long. As for people being caught up in the “cult” of FIRST, that is not a bad thing. Being caught up on ones self and putting them self above all others is.
I am glad to see that you admit breaking the rules. This will make it easier for the inspectors to find those who intentionally break the rules.
Is it a good rule? Probably not but it is still a rule. It holds the same intent and validity as only 4 CIM motors.
Note to 2007 inspectors: Be on the lookout for Poof Ball shooting robots!
Seriously, we need to follow the rules – even this one – in order to show respect and fair play toward the competition. If we succeeded in breaking a rule and later succeed in wining a match or three, then what have we won? None of us should want to cheat our way to hollow victory. It is way better, win or loose, to have played fair.
Acting up about this rule isn’t like the Founding Fathers tossing tea into Boston Harbor, or Rosa Parks sitting where she pleased. This is not about tyranny or oppression; it’s about honesty and fair play. Feel free to speak up against it, but respect us all enough to follow it.
Do you really think that simply re-typing the code would satisfy the rule? If so, that’s fine. I respect your interpretation of the rule; I’m just looking for some clarification. How would re-typing the same thing be better than copy-paste?
If the rule book is really what draws us together, then FIRST is a sad organization indeed. Thankfully, I don’t believe that our FIRST credo and over one-thousand teams can be summed up into one hundred pages of rules, from non-functional decoration to pneumatics. Is it possible you meant something different from this and I’m reading too much into what you said?
To all those who are saying that following this rule constitutes fair play (and there seem to be quite a few such people), imagine a rule saying that before every meeting, teams must do the chicken dance. Would you still make a “fair play” argument? I suppose that there’s some time gained or lost in not doing/doing the chicken dance (as there is in re-using old code directly or re-typing it, as Al S suggests), but is this really what the rule is about?
What do you guys see as the purpose of this rule, and what would be the purpose of a violation? Many people seem to think the intent of a violation is to cheat to get a leg up on hard-working teams following the rule. Is this the case?
The intent of the rule is obviously to try to put software on the same sort of footing as hardware. This is not an easy thing to do well, for a number of reasons, but prohibiting reuse of code developed before kickoff is pretty close to prohibiting reuse of mechanisms assembled before kickoff.
Copy and paste of last year’s code is too close to pulling a spare assembly from last year off the shelf. Retyping the code, line for line, is very much like fabricating an exact duplicate of a mechanism from last year’s plans. The code design can certainly be reused without breaking the rules, and I think running the actual code through a student’s eyes and fingers on the way to being compiled is a very good way to expose him or her to the design of the software.
I haven’t given it a great deal of thought yet, but there could well be a legitimate way to reuse the exact .c and .h files from a previous year’s software project. If you make it readily available to everyone, you could probably make a good case for treating it as an “off the shelf component”. That’s approximately what happens with the code so helpfully provided by Kevin Watson. But unless you’re also willing to support such code, I wouldn’t suggest making yourself a test case.
NO, I very strongly disagree with this. I understand the intent of the rule but I really feel that it is misguided. Code is not equivalent to an assembled part (I know, you only said “pretty close”, but I’m not even comfortable with that). Code for a project the size of a robot includes large portions of design as well. People are trying to make analogies between the code and a mechanical part and it really can’t be done (not accurately, at least). The mechanical team is allowed to reuse a design. This means they’re allowed to re-use a blueprint of the exact part they want, right? This means they’re allowed to even re-use a CAD design to generate the exact part on a CNC mill, right? As far as I know, there is no requirement to throw away all the blueprints and CAD designs each year and re-do them (by measuring a previous part, etc). Re-typing is not the same as building another copy of a previous robot part, because by retyping you’re repeating a lot of work that for the mechanical part would have been considered part of the “design” and would not have been repeated.
The rule is what it is, but I’d prefer to talk about WHY is it that way, and does it make sense? If we’re not allowed to re-use prior year’s code, then where does code from Kevin Watson and others fall? If we’re trying to equate the code to a physical, mechanical part then shouldn’t we require teams to purchase the code from Kevin (and require him to be an approved vendor, and require teams to re-purchase it each year)? Or, if it’s given away free, then the “fair market value” of it should be charged against a team’s budget. (You have any idea what his code is really worth and how fast THAT would chew through your $3500 limit?)
I wish people would stop trying to draw parallels between robot code and mechanical parts, and instead focus on making a different set of rules which really make sense for software. Requiring teams to re-type is stupid and represents tons of wasted busy-work - I contend that no one learns anything from blindly re-typing code. Re-building a mechanical design allows the builder to learn how to operate the machines, etc. necessary to build that part. However, the other extreme (re-use no code, no re-typing allowed) doesn’t make sense either, because then you’re throwing away valuable design work that is invariably tied to the code. What interest would it serve by requiring teams to completely start over on the software each year? Don’t give me any excuse about being fair to new teams (who wouldn’t have software from last year to re-use) because they also don’t have the library of mechanical designs that other teams have either, and no one is talking about taking that away.
I guess my opinion on this matter is that the change to the game each year necessitates enough code change on its own. It’s highly unlikely that a team could completely re-use code from a previous competition season without at least some modification, and if they can re-use it entirely then they’re likely pretty close to the default code anyway. I think the nature of the game changes each year already ensures enough changes are made to the code that there is no good reason to attempt to “legislate” that more be made.
Paul,
You started the thread with a reference to rule #71, the terms of which are clear and with which you find fault. What is generally accepted is that year to year, software must be treated as if it were a part for the robot. The statement “Just as designs for hardware COMPONENTS may be reused from one year to the next, software algorithms and designs may be reused” indicates teams will “reuse” software. But just as all parts for this season’s robot must be built during the build period, so shall software. It is not to put you or I on the same playing field but to put both of us on the same field as a rookie who has no code from last year from which to copy.
I don’t think FIRST is a sad organization because of the rule book. The rule book is the means to the end of building a robot for competition. This is much more than a competition, we are building (or trying to build) the next generation of scientists, engineers and other professionals to make this world better. We have to get people back into the mode of realizing rules and following them, automatically. We know what happens when people don’t follow rules. Lay, Skilling and others not only lined their own pockets they did so at our expense and the millions of people who depended on their retirement accounts to get them through their golden years. I know it is hard for a young person to imagine but many of those people are now well into their seventies and eighties and beyond their ability to work for themselves. They worked diligently when they could and sacrificed in order to not be a burden on anyone when they retired. Those people have watched as 40 years of their hard sork and sacrifice were flushed down the toilet by a couple of guys in Texas who didn’t follow the rules.
Generally accepted by whom? I see a lot of people who do not write software for a living who agree with it, but so far I haven’t seen too many who do write software professionally pipe up.
Consider this: right now (as I understand the rules), we are allowed to re-run a CAD design on a CNC mill to produces an EXACT DUPLICATE of a part from a previous year. The best software design document in the world will not allow you to write a brand new program that produces an EXACT DUPLICATE of the binary output of the compiler.
Dave, I infer from your posts that you consider the source code for a software module to be the equivalent of the blueprint for a hardware assembly, and the compiled bits to be the equivalent of the assembly itself. Is that a fair assessment of your opinion?
I draw the line between design and “fabrication” a little higher. The way I see it, the design is in the structure and the algorithms, rather than in the specific way those algorithms are embodied in actual lines of code. I think it’s the .h and .c files that correspond to the frame members and sprockets. Sure, there is usually a particularly obvious way to write a function to implement an algorithm, especially when the structure of the program is well-defined in advance, but that just means the next embodiment of the design will come out looking the same as the previous one most of the time.
The software rule from last year means you’re not allowed to pull a module out of the version control system and drop it into this year’s project unchanged; you’re required to re-implement it. That’s a perfectly reasonable rule in my worldview. It means someone has to actively do some programming in order for that functionality to be available. If you want to consider that wasted effort, fine, but I think it’s the same sort of effort required to assemble a KOP gearbox when you already have four assembled ones sitting on a shelf from the previous year.
I write software for a living, and I definitely consider software to be a part of the robot. Is your position otherwise?
