“FIRST will allow you to keep all of your robot controls (Operator Interface, OI power supply, joysticks, etc.) and not ship them with your robot on Tuesday, 2/21/2006. This will allow you to continue to work on your programming. If you decide not to ship controls with your robot, please remember to bring your controls to your initial competition. FIRST does not have replacement controls.”
Also in section 5, the Robot, Page 4
“During the FIX-IT WINDOWS, software for either the robot or operator interface may be developed without restriction.”
From the latest update, Feb. 17:
“After the robot has shipped, and outside of the FIX-IT WINDOWS, software development is prohibited.”, in response to:
“To what extent are teams allowed to do any software work (planning, design, coding, parameter adjustments, and/or testing) with their practice robots or dashboards outside of the Fix-It windows?”
So what’s the deal. Can I, or can I not, program after shipping? I have no “practice robot\dashboards”, so… ?
You can, during the FIX-IT WINDOWS. Per the Q&A, you can plan your programming during other times (just like you could think about hardware updates), but can’t do any coding.
Without a practice robot, it’s really tough to see whether the code you write will work. Perhaps you might create different versions of everything, so you can use different routines at practice on Thursday of competition.
Fix-It Windows, software development, and second robots
Suppose we build two robots that are functionally identical. During the time between ship date and a competition, we work on the second robot (which wouldn’t even darken the doorway of a competition). Due to their identicalness, software development for the second robot would seem to be functionally the same as software development for the competition robot. Should programming for the second robot be considered open season, or does it fall under the control of a Fix-It Window?
Yesterday, 05:22 PM GDC
Senior Member
Re: Fix-It Windows, software development, and second robots
You may develop all the software that you want for your second robot. There are no restrictions on developing practice code for practice robots. However, if even one line of the code is developed after the primary robot has shippped and outside of the Fix-It-Window, then none of the code may be used on the competition robot. All software used on the competition robot (whether it was developed on a practice robot or not) must be developed during the build season, during the Fix-It-Windows, or at the competition site.
Now all I need is a clear definition of practice code and how to distinguish it from competition code. If I code and test an algorithm on my practice bot and then change variable names for the code used in the competition robot, is that OK?
I think not - wouldn’t this violate the intent of a related Q&A response? See:
Its very clear and I think you’re doing a disservice to the rest of the community by debating this. Whether you agree with the rule or not (and I don’t) you cannot work on code related to the competition robot outside of the build season, fix-it windows, and competition events. There is no way to police this so you’re on your honor not to cheat. If you work with a practice robot and modify code with the intent of replicating those changes at the event then you are violating the rules. If you’re testing and tracking bugs with the necessary fixes outside of the fix-it window then you’re cheating. I don’t think its good for the program, but those are the rules.
David, you know the answer, don’t you? If you are developing code for the purpose of making this year’s robot perform better, you are violating the spirit of the rules. We are all supposed to be engineers, not lawyers. The intent of the rules is clear: the robot is done – stop working. Changing variable or function names is the worst sort of robot lawyering – using cheap tricks to get around the spirit of the game. Go ahead and obsess about the robot all you want, but if you are writing code that you think will make this year’s robot more successful, you are (IMO) in clear violation of gracious professionalism.
Perhaps we should borrow from something the Boy Scouts: a FIRSTer is trustworthy, loyal, helpful, friendly, courteous, kind, obedient, and cheerful. (I’ll let you off the hook for thrifty, brave, clean, and reverent.)
I had asked a rhetorical question - sorry that you misunderstood my intent. I fully agree with what you say and had hoped that someone would come out and make a strong statement. This forum has been relatively silent with regard to the Q&A response to the question I had submitted over a week ago regarding software work outside of the FIX-IT WINDOWS. I thought the response from FIRST was very clear. It is our intention to do software development only during FIX-IT WINDOWS and at competitions.
I was taken by surprise with the response to the more recent Q&A regarding software for the practice robot. We have a practice robot, but we will only write and test code for it during FIX-IT WINDOWS. I think the response to that question can create more confusion amongst teams.
I do indeed know the right answer. The last thing I’d want to do would be violate not only the letter, but also the spirit of the rules. Please understand why I asked the question in the earlier the way I did.
I had posted the original Q&A question regarding software work outside of FIX-IT WINDOWS and competitions after Dave Lavery suggested that the interpretation this year might be different than last year. Indeed, it is different. Last year, you could write code until the twinkie supply was depleted in town and test it on the practice robot then recreate the changes at the competition. Not so this year. As I stated in my response to seanwitte, we intend to write and test code ONLY in FIX-IT WINDOWS and competitions.
I think the recent Q&A response to the question regarding “practice” software for the practice robot serves only to cloud the issue.