'Fix It Window' and Programming....
 

I'm looking for a little discussion on how the "Fix It Window" applies to programming. Now, right off the bat, I know that no one is to compose programming outside of the Fix It Window to download to the robot at competition. This is straight forward and clear.

My question lies in some grey area. Drivers are allowed to practice on an old robot. One can test new ideas on an old robot to see if they'll work, so long as nothing is built and brought to competition outside of the fix it window. I'm kind of new at programming, so am I allowed to test out code, learn more about it, and create the actual code during the Fix It Window after our first competition? I want to be safe and follow the rules, G.P. and all that, but I also want to take advantage of any appropriate use of the code i can.

I'll probably post this question on the FRC Q&A at some point, but I wanted to hear some discussion on what everyone thought about this. Thanks!

Re: 'Fix It Window' and Programming....
 

Inside the FIX-IT-WINDOW, software dev is still permitted, though I got the impression that you were implying the time frame following the conclusion of the FIX-IT-WINDOW.

That issue is raised in <R14> stating, "After the close of the "FIX-IT-WINDOW" and prior to the competition...and cease all software development..." This becomes a question of semantics, what defines software development. If, for instance, a team builds a practice robot and uploads a copy of the software thatis on the competition bot to the practice robot, modifies it, perfects it, then uses the knowledge and experience gained by testing and debuging to refine the functions in the competition code, does this constitute as software development? Some would say it most definately does, and I would not neccesarily be willing to disagree.

However, there is another side to this coin. The rule also states, "Teams may scout...plan to make repairs, etc..." One could argue that working on code using a testbed, making notes to modify the code, then re-inventing the wheel, would constitute as "planning ot make repairs." Getting technical, I'm more inclined to agree with the second argument, however I don't know if this question has yet come up on the FIRST Q&A and if so, what, if any, official statement has been made.

The problem becomes even more confusing with FIRST's overt encouragement of practice robots. This stance leads me to believe that FIRST encourages testing with the robot, including the software, to your hearts content, as long as you re-invent the wheel so to speak at competion. Ultimately, it comes down to what is the gracious professional action. Use common sense.

Re: 'Fix It Window' and Programming....
 

Sounds like a good YMTC question.

It really is a tough issue. For example, many robots incorperate autonomous funtions in driving (such as a button to automatically put your arm in a position to grab a tetra). If you have a practice robot, are you allowed to tweak that code to give your drivers an accurate training experience?

Re: 'Fix It Window' and Programming....
 

stupid question time.... what does "YMTC" mean?

Re: 'Fix It Window' and Programming....
 

YMTC stands for "You Make The Call". See also YMTC: Your Thoughts

Re: 'Fix It Window' and Programming....
 

Nope. Software development is software development. We can draw the line on what constitutes development wherever we want (i.e., whether or not algorithm design, flow charting, pseudo-code, or punch lists constitute software development), but wherever that line is drawn, downloading new code is on the wrong side.

I don't think the recent ruling that R14 doesn't prohibit practice robots is anywhere near an "overt encouragement". Rule R14 was clearly written (ok, maybe "clearly" is a stretch) to discourage them, but did not go to the point of forbidding them.

Why a rule would be written like that is beyond me. Any rule writers wanna help out here?

Re: 'Fix It Window' and Programming....
 

So are you suggesting that I cannot continue to develop software for my job at Motorola? I imagine not. I think it's safe to say that FIRST did not mean to imply that you cannot do ANY software development, but rather software development for your robot. I would argue that they even meant your competition robot, but that may not be quite as clear. Personally I think changing the software for your practice robot would be fine, just as you could modify it mechanically, as long as you did not bring that updated software with you to the competition (just like you could not bring your updated mechanical piece to the competition). I also think that developing a scouting program would be perfectly legal, as would developing a web-based application for your team, etc.

It seems like a lot of people are trying to read a lot more into that rule than is necessary.

Re: 'Fix It Window' and Programming....
 

Especially since it's enforced by your team signing a form. If you can, in good conscience, sign the form, then I guess it's legal.

But I understand why there is concern. I personally call "developement" when you change the logic of a program or debug said logic. But I would not call tweaking constants "developement", since that depends on the exact bot and preference, but does not really change the program itself; the program just opperates on slightly different data.

But as I said, it's all what you think.

Re: 'Fix It Window' and Programming....
 

No, I'm not. Allow me to elucidate my point:

Software development for one robot is software development for all similar robots.

Call it Verdeyen's law. Or the transitive property of code, whatever floats your goat.

It might sound hackneyed, but in software, unlike mechanical parts, the process is the product. Say your team troubleshoots drive code on your practice robot, and spends 100 hours trying different things that just... won't... work. Until, sometime around hour 110, someone sees the light, and realizes that you need to use Newtons instead of pounds, they already know the answer. So next week, when you go to competition, you're already 111 hours into the software development process, and you have the answer in your pocket. That's outside of both the spirit and the letter of the rule.

If you still think that's legal, then tell me where you would draw the line. Can the programmers bring the new code to the competition on a laptop, or does the code need to be on a disk? Or would it be better if they just had a printout of the code, and re-typed it? Maybe not the actual code, what if it was just a flowchart that showed them what they needed to write, and they re-wrote the actual functions from scratch?

If you don't draw the line at no robot software development, you have nowhere else to draw the line.

It seems to me that a lot of people are trying to read a lot less into the rule than what it says.

Re: 'Fix It Window' and Programming....
 

So, say we build a seperate bot for practice. Something happens, we discover a single line of code is preventing us from using the entire thing (its disabling drive motors..).. We aren't allowed to fix that then? We have to sit there, knowing that we just wasted money, time, and effort building a 2nd bot, only to have it not be functional, and us not be able to fix it. I would hardly call that fair.

I don't like these new rules.. I'm wondering how many teams will have a sucessful auto mode at the first competition they have.. by the time you get there its too late to debug+test your code. (Well, maybe not too late, but where exactly would you be testing?) It doesn't make sense to me. Either allow practice robots, and modifying the code, or don't. This in-between stuff just seems to be causing more problems.

Re: 'Fix It Window' and Programming....
 

You think this is unlike mechanical parts? Try this:
Do you think it would illegal for a team to troubleshoot a mechanical design and show up at competition knowing how to fix their competition robot? I don't.

Since the rules about the physical parts of the robot have been around longer, I guess I look to them for inspiration. As I said, I think you need to leave any new software you've written at home. But if you brought notes on how to change your software, I think that's fine, just like you could bring blueprints of a new design to build at competition or a list of modifications you need to make to your robot's frame or whatever. To me the line is very clear - don't bring new code. Notes, ideas, thoughts in your head are fine.

Re: 'Fix It Window' and Programming....
 

Neither do I, but then, the rules don't say (anymore) that you have to cease mechanical development. They say that you can't bring new parts to the competition. They do say, however, that software development outside of the FIW is illegal. I would say that, the way <R14> was originally written - "...put down their tools..." - they were trying to hold mechanical parts to the stricter standard as well, but Q/A 1026's answer nullified that part of the rule. Still, the rest of the rule, the part that says "...cease all software development..." is still in effect.

At least until Q/A 1226 gets answered.

The rub here is that the rules governing mechanical parts and software are different. You're trying to find analogues where they simply don't exist.

Re: 'Fix It Window' and Programming....
 

"FIX-IT-WINDOWS – The 48-hour period following the deadline for shipping the robot, or following the close of a regional competition, in which parts may be manufactured in preparation for future competitions. During the FIX-IT WINDOWS, software for either the robot or operator interface may be developed without restriction" -- 5.1.4 Conventions: Page 5 of Section 5 - The Robot

Re: 'Fix It Window' and Programming....
 

If you consider flowcharting and algorithm design to be part of software development, then I am curious why you don't consider design of a mechanical part to be part of "fabrication of robot parts". Fabricating a part involves designing that part, just as developing software involves designing that software. In my opinion, software development and parts fabrication are equivalent concepts. As part of that opinion, I believe FIRST intended to prevent teams from bringing the implemented result to the competition (that belief seems to be confirmed by their response to question 1026). Designing software and designing mechanical parts, to me, are the same thing and I believe them to still be legal. Bringing an implementation of a software design, just like bringing an implementation of a mechanical design, is not.

I may, of course, be wrong in my opinion, but to date I have not seen anything concrete that convinces me of that.

Re: 'Fix It Window' and Programming....
 

I do, but it's less cut and dried, since the rule says "fabrication" for mech stuff, and "development" for software, and "fabrication" seems like cutting metal, while "development" is more like knowing what metal to cut.

That's why I feel like the decision rendered on QA1026 is wrong.

We'll have to wait and see what the response is on QA 1226.

Or we could ask for someone who actually knows the answer to post what they meant by "teams must put down their tools". Certainly, someone who was present at the (undoubtedly complicated) birth of <R14> reads this board. If anyone reading this had a hand in writing that seemingly innocuous rule, break your silence! Tell us the answer, so that Dave and I can sleep. And if you wanted to frame your response to let us sleep a little more after Feb 22nd, I'm sure we'd both be able to use the nap.