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.