Post-ship S/W (& H/W) development restrictions

[Donut]

Originally Posted by KenWittlief

thats the thing. Are you allowed to draw mechanical things on a piece of paper before your first day at regionals? to figure out measurements? to make scale drawings? To make a prototype at home to see if it works, then fabricate it over again at the regional?

the problem with SW is that once you write it down (type the code out) you are mostly done.

I dont know about anyone else, but if I have a problem to solve it simmers on the back burner of my brain all the time, and when an answer bubbles to the surface I have to stop what Im doing and write it down. For SW that means writing down an alogrithm, or a bubble diagram, or a flow chart.

The rules forbid this?! you would have to heavily sedate me!

I believe you can come up with all the "ideas" that you want. However I don't believe you can actually test them on a robot, and testing is the most time consuming part usually.

I know last year, we wrote notes down on things to come up with for the Regional, however we did not test anything or load it onto any previous robots. At Regionals, we retyped all the code on site, then loaded it there and tested it. I think half of it ended up not working anyway, but we still managed to get some accomplished.

[David Brinza]

This question came up last year and was addressed in the official FIRST Q&A:

See:

http://www.chiefdelphi.com/forums/sh...6&postcount=16

Basically, most teams interpret this to mean you have to type in new source code into the version that was used at the time of ship or the prior competition.

[Rickertsen2]

Originally Posted by David Brinza

This question came up last year and was addressed in the official FIRST Q&A:

See:

http://www.chiefdelphi.com/forums/sh...6&postcount=16

Basically, most teams interpret this to mean you have to type in new source code into the version that was used at the time of ship or the prior competition.

Is copy+paste legal?

Honestly, This is a pretty ludacris rule IMHO.

[Rohan_DHS]

Originally Posted by Rickertsen2

Honestly, This is a pretty ludacris rule IMHO.

I agree with you here...this might be a problem for a bunch of teams

[dlavery]

Originally Posted by David Brinza

This question came up last year and was addressed in the official FIRST Q&A:

See:

http://www.chiefdelphi.com/forums/sh...6&postcount=16

Basically, most teams interpret this to mean you have to type in new source code into the version that was used at the time of ship or the prior competition.

That was an answer to a question about the 2005 rules. It does not apply to the 2006 rules.

[David Brinza]

Originally Posted by dlavery

That was an answer to a question about the 2005 rules. It does not apply to the 2006 rules.

Here is the 2005 rule:

<R14> Prior to the competitions: After the close of the “FIX-IT WINDOW” and prior to the competition, the team must put down their tools, cease fabrication of robot parts, and cease all software development. Take this opportunity to rest, recover from the build season, and relax. Teams may scout other teams, gather and exchange information, develop game-playing strategies, collect raw materials, prepare tool kits, plan how to make repairs, etc. in preparation for the upcoming competitions. But no construction or fabrication is allowed.

Compare with the 2006 rule:

<R18> Prior to the competitions: After the close of the “FIX-IT WINDOWS” and prior to the competition, the
team must put down their tools, cease fabrication of robot parts, and cease all software development. Take
this opportunity to rest, recover from the build season, and relax. Teams may scout other teams, gather and
exchange information, develop game-playing strategies, collect raw materials, prepare tool kits, plan how to
make repairs, etc. in preparation for the upcoming competitions. But no construction or fabrication of any
hardware, or development of any software, is allowed.

The difference is in the last sentence, where the phrase "or development of any software" now appears.

So, as was discussed last year, there needs to be some clarification about what constitutes software development (i.e. conceptual design, flowchart, algorithm, coding, test, any or all of these). Since "any software" is stated, dashboard code may also be subject to this restriction.


Time for a new Q&A post!

[kevinw]

Originally Posted by David Brinza

Here is the 2005 rule:

<R14> Prior to the competitions: After the close of the “FIX-IT WINDOW” and prior to the competition, the team must put down their tools, cease fabrication of robot parts, and cease all software development. Take this opportunity to rest, recover from the build season, and relax. Teams may scout other teams, gather and exchange information, develop game-playing strategies, collect raw materials, prepare tool kits, plan how to make repairs, etc. in preparation for the upcoming competitions. But no construction or fabrication is allowed.

Compare with the 2006 rule:

<R18> Prior to the competitions: After the close of the “FIX-IT WINDOWS” and prior to the competition, the
team must put down their tools, cease fabrication of robot parts, and cease all software development. Take
this opportunity to rest, recover from the build season, and relax. Teams may scout other teams, gather and
exchange information, develop game-playing strategies, collect raw materials, prepare tool kits, plan how to
make repairs, etc. in preparation for the upcoming competitions. But no construction or fabrication of any
hardware, or development of any software, is allowed.

The difference is in the last sentence, where the phrase "or development of any software" now appears.

So, as was discussed last year, there needs to be some clarification about what constitutes software development (i.e. conceptual design, flowchart, algorithm, coding, test, any or all of these). Since "any software" is stated, dashboard code may also be subject to this restriction.


Time for a new Q&A post!

Both state you must cease all software development. Perhaps FIRST will interpret the rules differently this year, but to me it appears to be the same rule which FIRST clarified last year. I'd be interested in seeing additional clarification this year, but it seemed pretty clear to me after the Q and A last year.

[dlavery]

Originally Posted by David Brinza

Here is the 2005 rule:

<R14> Prior to the competitions: After the close of the “FIX-IT WINDOW” and prior to the competition, the team must put down their tools, cease fabrication of robot parts, and cease all software development. Take this opportunity to rest, recover from the build season, and relax. Teams may scout other teams, gather and exchange information, develop game-playing strategies, collect raw materials, prepare tool kits, plan how to make repairs, etc. in preparation for the upcoming competitions. But no construction or fabrication is allowed.

Compare with the 2006 rule:

<R18> Prior to the competitions: After the close of the “FIX-IT WINDOWS” and prior to the competition, the
team must put down their tools, cease fabrication of robot parts, and cease all software development. Take
this opportunity to rest, recover from the build season, and relax. Teams may scout other teams, gather and
exchange information, develop game-playing strategies, collect raw materials, prepare tool kits, plan how to
make repairs, etc. in preparation for the upcoming competitions. But no construction or fabrication of any
hardware, or development of any software, is allowed.

The difference is in the last sentence, where the phrase "or development of any software" now appears.

So, as was discussed last year, there needs to be some clarification about what constitutes software development (i.e. conceptual design, flowchart, algorithm, coding, test, any or all of these). Since "any software" is stated, dashboard code may also be subject to this restriction.

Time for a new Q&A post!

I understand that the 2006 rule is similar (albeit not identical) to the 2005 rule regarding software development after the ship date. However, my point is that the specific Q&A response you cited had to do with how the 2005 rule was to be interpreted. That interpretation is meaningless for 2006. It is a different game, a different rule (albeit only a small difference - but a significant one), a different set of referees, a different software environment, and a different membership on the GDC that wrote the rules. But perhaps most significantly, the FIRST "powers that be" now have a full year of experience with how teams complied (or didn't comply) with the software development rules from last year. That is sure to influence what they expect from the teams this year, and how they will enforce the rules. Based on that, I would not be willing to use a 2005 Q&A response to make any assumptions about 2006.

-dave

[David Brinza]

Originally Posted by dlavery

I understand that the 2006 rule is similar (albeit not identical) to the 2005 rule regarding software development after the ship date. However, my point is that the specific Q&A response you cited had to do with how the 2005 rule was to be interpreted. That interpretation is meaningless for 2006. It is a different game, a different rule (albeit only a small difference - but a significant one), a different set of referees, a different software environment, and a different membership on the GDC that wrote the rules. But perhaps most significantly, the FIRST "powers that be" now have a full year of experience with how teams complied (or didn't comply) with the software development rules from last year. That is sure to influence what they expect from the teams this year, and how they will enforce the rules. Based on that, I would not be willing to use a 2005 Q&A response to make any assumptions about 2006.

-dave

OK, I've submitted a question to the 2006 "powers that be".

[shamu1001]

Hmm well let's say we don't code after ship date, will they still let us upload code during the competition date? My team for one has a set of different codes, depending on which gate we want to go for and what position we start at. What we were thinking is to write like 6 different codes (all very similar but different constants, etc.) for every possible scenario and then upload the right one right before we compete. Is that allowed?

[David Brinza]

Originally Posted by shamu1001

Hmm well let's say we don't code after ship date, will they still let us upload code during the competition date? My team for one has a set of different codes, depending on which gate we want to go for and what position we start at. What we were thinking is to write like 6 different codes (all very similar but different constants, etc.) for every possible scenario and then upload the right one right before we compete. Is that allowed?

You are certainly allowed to develop new software during Fix-It Windows (See Section 5.3.3, <R17> and <R20>) and at the competitions (<R19>). Any software developed during the 2006 build season, Fix-It Windows and at competitions may be uploaded into your robot and, if you use one, the dashboard PC.

In this thread, we're trying to understand the limits of work that can be done on the software OUTSIDE of those times. The rules are pretty clear regarding hardware (you cannot use replacement, upgraded or spare robot hardware that was fabricated outside of those times, but you can plan how to fabricate that hardware at competitions or during Fix-It Windows during the competition season). It's somewhat ambiguous for software to define where the planning stops and building begins.

[KenWittlief]

yes, you can write all the SW and make as many mods to your code as you want at the events.

I would suggest you put a switch on your bot that is read at initialization, and use that to select your different modes of operation. If you make it to the finals you dont want to be loading different versions of code before every match.

Its also possble to read switch settings on the OI at powerup, to enable different auton functions or to set different parameters for your SW.

When the robot is disabled at the start of the match only the OUTPUTS are disabled. The inputs are all still active and readable.

[EStokely]

Well the thread was heading off into an area I was uncomfortable with.
To para phrase what I was reading
"Since its will be next to impossible to enforce how can FIRST enforce no software developement?"
And it was stated a few times GP is how.

Most of use could find dozens of ways to break dozens of rules and not get caught in this game. Does that mean we should? And then blame someone else because we could?
Or do we follow the rules, play the game as designed and hope we designed well?
I guess its ultimately a personnal decision but since we are trying to inspire the future here I would like to think we are helping towards working within the system, not looking for ways to cheat it.

As for the larger (and I hope point of the thread) question.

I can't see how you can't think about the robot, assy's, code or whatnot after shipping but there is a difference between jotting down a few notes and working with a duplicate robotic system to test code.
Having meetings specifically to work on the code after shipping is obviously outside of the rules (except for teh 5 hour build times allowed) but having one of my math students suddenly yell out in class "All I need to do is look at the DIFFERENCE between the encoders" two days after shipping is both OK and expected. He notes it down and takes the thought to competition to code.

[Don Wright]

If I were an outsider reading this rule, I would say the rule means just what it says. Put the pencils and laptops down and don't think about coding the robot until you see it again at the next event. Then code and test away...

However, as a participant, to me anyway, the worst thing about the "no software development" rule is that if a team doesn't have a good code going into ship day, it's going to be REALLY hard to get autonomous mode dialed in. How are teams going to be able to dial in their autonomous mode that tries to fire into the center goal at a regional? During their 2 or 3 practice rounds where they might get one or two shots at it? And then during the rounds when it counts? It's not like you can do it in the pits or there will be balls flying everywhere.

IMHO, this rule makes me sad and I think it leads to many autonomous modes where six robots sit there for 10 seconds at the beginning of a match...especially at the earlier tournaments.

I also understand what I believe the rule is trying to do...make it fair for the smaller, less funded teams who can't afford a second robot or RC. However, I think a lot of these teams are usually the ones who get things done during the last few days and have the least amount of time to program. So why not let the teams keep the controller boards to make it fair to everyone?

Of all the rules this year, this is the only one that I think is detrimental to the quality of the competitions... No offense...just my opinion...

[aaeamdar]

So if you are a programmer, are you allowed to think about code (outside of the five-hour window)? I would assume that the answer here is yes. Are you allowed to write pseudo-code? Are you allowed to scratch out actual code on a piece of paper? Are you allowed to use another IDE to test this code and use printf s to see how it works? This is such a slippery slope. I see not the point of this rule; it's not going to be enforced, and it's really up to each person to decide to what extent they wish to follow the rule.

Also (maybe I've gone off on a flight of fancy here, but...) it seems like this rule punishes those who follow it and helps those who are willing to ignore it. I must be wrong about this, it just doesn't seem right. Other than the moral satisfaction of doing it the right way, what is the incentive here? I don't know.


Confused,
Paul Dennis