R71: Can't re-use code that you've written before?

[Dave Flowerday]

Originally Posted by R71

Unaltered software modules developed during prior competitions may not be directly re-used. Just as designs for hardware COMPONENTS may be reused from one year to the next, software algorithms and designs may be reused. However, the specific lines of code must be customized for each robot each year.

I haven't seen any discussion on this one yet (please correct me if I missed it). The way I read this you are not allowed to reuse code that you've written for past competitions without "customizing" it. I'm not entirely clear what is meant by "customized" in this rule, but our team's initial impression was that this meant that it would have to be re-typed to be usable. Is that how others interpret it?

[Joel J]

It seems you can just modify the code. In practice, you'll probably end up re-copying software components you want to reuse simply because it is general and stable, so there would be nothing that needed modification.

Sometimes FIRST makes some oddball rules when attempting to "level" the playing field.. this might be one of them.

Eh..

[Andrew Blair]

Hmmm... Seems like their saying you can't cut and paste. Not really an enforcable or practical rule.

[Tom Bottiglieri]

Is

y=mx+b;

the same as

y = b + (m * x); ?


You Decide.

[Joe Johnson]

Wow, this is a change. It seems pretty clear. But I am sure it will get murky by the time we are done.

It seems to require retyping of last year's code to read encoder pulses or to navigate using the encoders or whatever.

As others have asked, does changing variable names count as altering?

I understand some of the concerns the rule is trying to address but I don't know how this rule will work out in practice.

Joe J.

[Joel J]

AND a retype of Kevin Watson's code. I mean, unless they further their attempt to be fair and make him a COTS vendor. Fair market value: $0.00.

I'm thinking if I change a line or two, then I have modified the code to be used for this game. I think if they are trying to make rules the same between programmers and mechanical engineers, then they have to introduce the other "mechanical" rules to allow everything to balance out and make sense.

[Hutch]

I think this is just something designed to make you do the right thing; I wouldn't worry about it. Just respect fix it windows and the such and don't do anything really dishonest.

[kc8nod]

Originally Posted by Hutch

...our team's initial impression was that this meant that it would have to be re-typed to be usable.

The way I read it, if you just re-typed it, you would still be reusing the exact same code and therefore violating the rule.
It doesn't make a whole lot of sense, but that's the way it reads to me.

Why do they want to prevent code re-use?

[eugenebrooks]

*****
<R71> Unaltered software modules developed during prior competitions may not be directly re-used. Just as designs for hardware COMPONENTS may be reused from one year to the next, software algorithms and designs may be reused. However, the specific lines of code must be customized for each robot each year.
*****

Last year, we had to cease work on code "actually used in the robot" except for the build period, the fix-it windows, and the competitions. Module re-use from prior years was allowed. Questions were asked about this and it came down to re-typing any code what had been written outside of the appropriate time window, during an appropriate time window. The customization rule is new and has a potential downside impact depending on how you interpret it.

Re-use of code is more similar to re-use of a hardware design than it is to re-use of a hardware component, for example within the current rules it is perfectly fine for you to re-use a CNC program to produce a custom hardware component from year to year. The CNC program is in fact, software. You are taking advantage of software developed during a prior year to make the part, just as is the case when using a module from a prior year, our an outside source, when building your robot program.

The clear intent of FIRST is that work on custom robot code is performed during the appropriate time windows, but I do not think that FIRST intends to keep teams from using the code that is provided by Kevin Watson, or others who labor to provide FIRST teams with useful software modules. It can be quite unsafe to customize some of this code.

I spend quite a bit of effort documenting programming methods useful on FIRST robots. I have also provided code modules that are useful to enable teams to safely deal with the hazards involved for functionality that uses interrupts, the protections against these hazards being carefully tucked away in interface routines for wheel counters, gyro integrals, and so forth.

I hope that the customization rule does not cause programmers to customize the posted code in a manner that might get caught up in some of these hazards. Re-writing some of this code using expressions that seem to be equivalent can, in fact, run afoul of interrupt hazards and this could lead to unsafe robots, the code of which needs to trust the values returned by the access routines.

Perhaps the solution is to declare these code modules "standard software parts" for competition robots, and offer them for sale as software vendor. If that is the case, I'll offer them for the princely fee of $0. It is clear that teams can get as many copies as they want, as often as they want, whenever they want.

Yes, I think that we all should do that and rejoice in our efforts to help level the playing field...

Eugene

[Astronouth7303]

I think this should be interpreted as the mechanical rules. You can cut & paste, but make sure you go through and change something.

This does bring up a question. There are teams that think of a strategy, and their sponsor come up with chasis that would fit it.

If a team develops a library of software that is reusable from year to year, would this not be the same thing?

[geeknerd99]

But what if copying and pasting produces the only code that will work or is satisfactory? For example, the dead zones on our joysticks were customized to my driving preferences, and there is a large possibility that I'll be driving again this year. Our design looks like it'll drive much like last year's, and I was anticipating using our modified 2-stick code again. Does this rule mean that I can't have the sticks set the way I had them set last year, even if I'm perfectly happy with it?

And really, how is FIRST or IFI going to enforce this? Not to sound like I'm purposely trying to reuse code (we don't have much code to reuse anyways), but if they can't enforce it, they might as well not include it. I'm expecting this rule to be clarified by the time ship date.

[Rickertsen2]

Umm WHAT? O well, I am doing a rewrite/refactoring of our code this year anyway. I think this rule is absurd.

[KenWittlief]

FIRST has no power to enforce any of its rules (well, maybe a handfull can be enforced).

It looks like the intention of this rule is that FIRST wants this years students to write the actual code that will be used in the robot. If you have some really great code from previous years that does PID loops, or tweaks the user interface inputs, what does a new student learn this year if you copy it?

This rule goes back to the age-old question that comes up every year: Do you want your team to have the absolutely most-competitive robot possible, or do you want your students to be involved in every aspect of its design and implementation?

Isnt this the same thing that happens in computer science classes? Every year students have to write code to solve some problem, and usually its the same sort of problem every year. But the teacher /professor doesnt give you code that some student wrote 8 years ago and say "here, run this". Right?

Most students already know what <CRTL><C> and <CTRL><V> do. Learning how to write the SW from scratch is more interesting.

My take on this is, if you wrote the code last year, teach a freshman the concepts and let them write the code this year.

[DonRotolo]

Originally Posted by geeknerd99

But what if copying and pasting produces the only code that will work or is satisfactory? For example, the dead zones on our joysticks were customized to my driving preferences, and there is a large possibility that I'll be driving again this year. Our design looks like it'll drive much like last year's, and I was anticipating using our modified 2-stick code again. Does this rule mean that I can't have the sticks set the way I had them set last year, even if I'm perfectly happy with it?

If you use the entire 2-stick code, verbatim, again then you've violated the rule. But, using the parameters you've determined, along with a line here and there, in a new piece of code (that may perform the same function), then, well, it;s a new piece of code, isn't it? Face it, this year's bot will not be exactly the same as last year's.

It comes down to this: You may certainly use components of previous code, but not a mechanism (which is a collection of components that perform a larger function) of code. A component might be joystick deadzone settings, or a compressor control routine - a line here or there. A mechanism would be a whole subroutine, or maybe even more.

I think Ken's point above is probably the best spirit of the rule.

Don

[Rick Thornbro]

Let's remember spirit of the rule. Let's use this time to teach new programmers the art of taking a hunk of metal and making it come alive. Taking code from a previous year and dumping it, is fast but doesn't teach anything.