Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Ethics 101: To re-use or not to re-use? (http://www.chiefdelphi.com/forums/showthread.php?t=50240)

Pavan Dave 06-12-2006 12:07

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by Steve W
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.

One of my I was gonna post. FIRST stands for a little more than you are giving credit for and help spread Gracious professionalism along with other skills you need to suceed in the real world.

Although some rules seem pointless they are rules none the less and you MUST follow them. But than again programming is often very simlar. What are you going to do? But I believe that the point of this rule is so that the rookies learn how the program itself works and get to work on it and learn something about programming rather than just cut and paste.


Pavan.
118 - Controls

seanwitte 06-12-2006 12:15

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by Pavan
One of my I was gonna post. FIRST stands for a little more than you are giving credit for and help spread Gracious professionalism along with other skills you need to suceed in the real world.

Although some rules seem pointless they are rules none the less and you MUST follow them. But than again programming is often very simlar. What are you going to do? But I believe that the point of this rule is so that the rookies learn how the program itself works and get to work on it and learn something about programming rather than just cut and paste.

It's the difference between building up a body of expertise from year to year and starting from scratch. Do you want to start next season where are are now or where you were last December? If you're rebuilding the codebase every season there will be limited opportunities for innovation because a large percentage of the time will be spent rebuilding basic components. It's like writing a GUI library every time you write a windows app. You'll get better at it, but you still have to DO it every time. That time should be spent doing something useful, but that's just my opinion.

ewankoff 06-12-2006 12:43

Re: Ethics 101: To re-use or not to re-use?
 
Yes it may waste time to re build a code base but the rule does not out law reusing code it only states that that code must be adapted for that years robot. The adapting of the code is what makes students learn from last years code. If each year students can understands all the code you are using from previous years and adapted it to work on the new robot it is acceptable to the rule.

Steve W 06-12-2006 14:32

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by seanwitte
It's the difference between building up a body of expertise from year to year and starting from scratch. Do you want to start next season where are are now or where you were last December? If you're rebuilding the codebase every season there will be limited opportunities for innovation because a large percentage of the time will be spent rebuilding basic components. It's like writing a GUI library every time you write a windows app. You'll get better at it, but you still have to DO it every time. That time should be spent doing something useful, but that's just my opinion.

Could you please explain the differences in your statement between hardware and software. As I see it the argument holds equally true with either.

aaeamdar 06-12-2006 15:36

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by Steve W
Could you please explain the differences in your statement between hardware and software. As I see it the argument holds equally true with either.

With hardware, teams can take a CAD drawing (or whatever you guys call them), send them off to a machinist, and get the parts back in a few days. Thus, if a team has settled on a certain drive train/gear box/whatever, all they must do to get a new Part X is send it off to a shop. Thus, while teams are encouraged to spend time thinking about ways they could improve their Part X, they're not forced to reinvent Part X from scratch each year (as some interpretations of R71 seem to say).

If you basically take the rule (as some have suggested) to mean that you have to start from scratch (i.e. you can use a pseudo-code/code outline or similar, but no actual code), you're forced to redo each year the simple things. Imagine if every year, teams were forced to do CAD drawings for every part of their robot, even if the drawings were the exact same as a previous year. This is the real parallel we're talking about.

Paul

mgreenley 06-12-2006 15:46

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by Steve W
Could you please explain the differences in your statement between hardware and software. As I see it the argument holds equally true with either.

Please correct me if I'm off the mark, but I believe that Seanwitte is saying that by having code that can be built off of previous implementations, programmers can work on adding to the code rather than re-working it.

After reading the thread, I think that the machine part v. code is a faulty analogy because of the information they hold. Rather, I suggest that a source file is closer to the working-drawings that are used to build components. I say this because working drawings are a very information-dense format of representing the idea of a part; In my design class, I wouldn't throw out my drawings at the beginning of every project, rather, I re-work them to speed up the next project to allow me to work on something new. In the same way, the source code is a very information dense format of representing an idea of behavior. I think Seanwitte is saying that by having code modules already developed, instead of re-writing them, they can be tweaked to fit a new situation and then new code and new implementations can be built from them.

The analogy breaks down at the implementation stage, because machining a part takes more time than compiling a program; the information-dense idea to information-diffuse implementation divide is blurred.

However, consider a team that has a CAD file for a part. To make the part, they can enter this into a CNC, go to (Wawa/7-11/Subway/etc...), and retrieve their part. By having this, a team can plan new implementations without worrying about the base every year. Maybe they want to add a turret on their already developed frame? The programming analog here is adding a new function. By having a code base for managing joystick input to drive motor output (lets say the team wrote a piece of code to linearize the input to output and also added a deadzone on the joystick). This year, the team plans to implement the already-debugged code block, but also to add functionality for using the gear-tooth sensor and an accelerometer.

I think that this difference is key to why I am behind the conclusions Mr. Scheck draws in post #62

seanwitte 06-12-2006 17:17

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by Steve W
Could you please explain the differences in your statement between hardware and software. As I see it the argument holds equally true with either.

This has already been stated in this thread, but there is a common misconception that you can "design" software in preparation for "manufacturing", similar to hardware. Taking a CAD drawing and turning it into a physical part is a well known process. Taking an algorithm and producing working code is completely different. The only true way to fully define a piece of software is with the source code. People can argue but that is a fact.

Say for any artifact, hardware or software, there is 80% planning and 20% implementation. For a piece of hardware you create this year you get to save 80% next year. You don't get the same scaling for software because you can't fully define it without the source. Since the software is by far the weakest discipline in FIRST, acknowledge the difference and relax that particular rule.

Marc P. 06-12-2006 17:34

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by Dave Scheck
Marc

I agree that then end result has to benefit the students. However, there is a hole in your argument.

What do students learn from Kevin Watson's serial port code? That code is so complex that it has the potential to baffle even people that write software for a living. I would never expect a high school student to be able to understand it. Yes they can be taught how it works, but isn't the allocated time better spent teaching them how to use the interface? In this case, I believe that's where the real learning comes from. How many high school students are exposed to serial communication outside of this program? How many have even heard of it? So much can be learned in simply writing a protocol to talk serially between two endpoints. In theory, nothing about the guts of the serial code needs to be known other than "when I call this function, these bits get sent to the other end".

By the same logic, how many students know anything about embedded processors and microelectronics? What do students learn from Innovation First's robot controller designs? Should teams be expected to build their own operator interfaces/robot controllers/radio modems?

There are pieces of hardware and software provided to all teams by the governing organization to use as a starting point in building a robot's functionality, separate from custom team-generated programming. The same idea as IFI providing the hardware applies to Kevin Watson's code- it's provided as a basis for obtaining functionality provided to all teams. I doubt any team simply compiled unmodified camera code and downloaded it to the RC without adding some sort of custom input/output or autonomous code. It's understood overall there are some pieces of code that are necessary to use from year to year, e.g. the default code provided from IFI. But to preserve complete customized team modules from year to year in a copy-paste fashion seems to defeat the purpose of having a programming team for each year. All it would take is one original team to write the code, then hand the flash drive down from season to season.

Quote:

Originally Posted by aaeamdar
Marc, as a previous poster said, there are some holes in your logic. I'm not sure how much knowledge you have of the programming process, but in your first example, a robot that simply pushes other robots around, there is (programmatically speaking) nothing for the programming team to do. The default code that you are required to use takes care of this already. R71 would have no effect here, since you would be using the default code each year (which I'm sure doesn't violate the rule).

While I'm not a programmer by profession, I grew up with BASIC, and wrote PBASIC code for FIRST robots for a number of years ago. I didn't start learning C until the IFI controllers switched a few years back, but I'm well aware of the differences between BASIC and C development, enough so to understand the programming process.

My example was a hypothetical extreme, and yes, the default code would suffice for that function. My point was to show how boring life is for the programmers on the team if they didn't have anything to do. The default code is provided for the purpose of having something that "just works" for all teams to use if necessary. Customization is the prerogative of the team, and generally necessary to achieve proper robot function. Handing completed modules down from one programmer to another is similar to handing them the default code. The only difference is one happens to be more functional, which is great for getting a working robot out the door, but not so great for the students trying to learn what programming entails. To each their own I guess.

Quote:

In your second example, you seem to be out of touch with the way that the camera code was implemented last year. I'm sure some teams last year wrote their own camera code, but the vast majority of teams (including mine) took advantage of the code graciously provided by Mr. Kevin Watson. So in effect you have the mentor saying this: "Sorry guys, we have code already for the camera. Just copy and paste it and call it a day." Maybe you would argue that such code should not be provided?
As I responded to Dave, the camera code provided by Mr. Watson was available to all teams, in the same sense that the IFI hardware was made available to all teams. Of course students would benefit in some way by learning how serial protocols work in rewriting the camera code, just as they could learn how embedded electronics work by dissecting the IFI controllers, but I believe that falls outside the scope of what FIRST is trying to accomplish. I wouldn't expect a programming team to rewrite stdio.h, as it's a standard library available to everyone. But you can't honestly compare custom robot code to globally standard library files or universally accessible code in terms of carrying over from year to year. One is team generated, the other is available anywhere. The team generated code is what the rule is attempting to keep in check. I understand the similarities in terms of the real world application of having pre-written libraries ready to serve common purposes, that's not what this debate is about. This thread was meant to question the reasoning behind this particular rule, which is what my original point was, semantics aside. The purpose of the rule is to prevent teams from maintaining the same code base from year to year, thus putting programming groups out of a job.

Dave Scheck 06-12-2006 18:05

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by Marc P.
By the same logic, how many students know anything about embedded processors and microelectronics? What do students learn from Innovation First's robot controller designs? Should teams be expected to build their own operator interfaces/robot controllers/radio modems?

I think you may have misinterpreted what I was saying. My point was that if the interfaces are defined well enough, the internals of the module don't necessarily need to be known in order to incorporate it into the system. With the RC example, in the typical case, you don't need to know the exact details of what's going on inside in order to program it. Obviously there are reasons for wanting to learn, but every detail isn't required. The nice thing about reusing code (not binaries) is that you have access to what's going on under the hood if you need to know more than what the interface provides.


Quote:

But to preserve complete customized team modules from year to year in a copy-paste fashion seems to defeat the purpose of having a programming team for each year. All it would take is one original team to write the code, then hand the flash drive down from season to season.
I disagree. The chance that the entire codeset will be used from year to year is extremely slim, but the chance that a team will need to count wheel ticks from year to year is more feasible. There will always be customization that needs to be made, but the internals of the low level building blocks could stay the same.

Quote:

But you can't honestly compare custom robot code to globally standard library files or universally accessible code in terms of carrying over from year to year.
Why not? If a team writes a library that will simplify the interaction with a sensor, I see nothing wrong with using it from year to year. Instead of interacting directly with the sensor, future programmers would interact with the library (to which they would have the source code for reference).

Quote:

The purpose of the rule is to prevent teams from maintaining the same code base from year to year, thus putting programming groups out of a job.
Your statement would also be an argument for not releasing default code because it would put teams that only need the default functionality out of a job.

EricH 06-12-2006 22:33

Re: Ethics 101: To re-use or not to re-use?
 
Guys, this thread is off-topic (I think.) What Paul was originally asking was, A. What is your interpretation and what does the rule mean? and B. What is a violation (of letter or spirit) and what violations are acceptable? The thread has now gone from answers to the questions to "This is my analogy and why the rule shouldn't apply" and "You're wrong, this analogy is better and why" and "You're both wrong", and generally being a big confusing mess. (At least, confusing to a non-programmer who doesn't know much about programming and isn't sure he wants to know.)

Now, to answer:
A. The rule is that you can't re-use unaltered modules from year to year, but algorithms and designs may be re-used. Also, the specific lines must be new. Now, what this means (to me) is that you must alter the modules every time you use them. If you have changed a hardware drive module for a different encoder/wheel/gearing, you practically have to change the software module, right? So, seeing as the robots are different each year, there shouldn't be too much of a problem for most teams.

B. The letter is as Paul quoted. The spirit is that you must change the code between years. For me, a violation is when a team used the exact code that they used the year before. Doesn't matter if they retyped it or not (and that discussion was over a rule that applied to Fix-it windows and similar things, if I remember correctly.) What violations are acceptable? For me personally, none. I prefer not to do anything that might be perceived as against the rules.

There is another point that I wish to bring up, however. This rendering of <R71> is from last year's manual. We don't know what the corresponding rule in this year's manual will be, or even if there will be one. So this whole discussion could be a moot point on January 6th.

Alexa Stott 07-12-2006 15:48

Re: Ethics 101: To re-use or not to re-use?
 
So does that mean that Kevin Watson has broken the rule? Most of his code is the same from year to year.

trilogism 07-12-2006 18:21

Re: Ethics 101: To re-use or not to re-use?
 
Hypothetically speaking:
If a team has used the same drive train 4 years in a row, and plans on using it again for a fifth year, but each year they build a new one (so they are using a design but not the pre-made structure), does the programmer still have to completely rewrite the drive code, even though it would most likely be nearly or completely identical to the code from the previous four years?

Alexa Stott 07-12-2006 19:10

Re: Ethics 101: To re-use or not to re-use?
 
Quote:

Originally Posted by trilogism
Hypothetically speaking:
If a team has used the same drive train 4 years in a row, and plans on using it again for a fifth year, but each year they build a new one (so they are using a design but not the pre-made structure), does the programmer still have to completely rewrite the drive code, even though it would most likely be nearly or completely identical to the code from the previous four years?

According to the current rule, you can't, because then some of the lines of code would be <gasp!> identical! :ahh:

But you brought up a good point. According to some people in this thread, no line of code could be the same from year to year. Now, if that is what the rule is actually saying, that means the simplest things, such as pwm01 = 127; would be illegal. Also, as it has been stated before, this rule would make using Kevin Watson's default code illegal, since there are few changes from year to year.


All times are GMT -5. The time now is 13:49.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi