FIX-IT WINDOW Proposal

[ChuckDickerson]

Man-hours. X number of man hours to use however you want between ship date and your regional(s). For example: Say FIRST allows each team 100 man hours. The team can allow 10 people to work 10 hours, or 25 people 4 hours each, or 2 people 50 hours each, or even 5 people 10 hours each and another 2 people 25 hours each, etc. Sure it isn't enforcable but neither are the current fix-it windows. The number of man hours is debatable.

[AdamHeard]

Originally Posted by DeepWater

Man-hours. X number of man hours to use however you want between ship date and your regional(s). For example: Say FIRST allows each team 100 man hours. The team can allow 10 people to work 10 hours, or 25 people 4 hours each, or 2 people 50 hours each, or even 5 people 10 hours each and another 2 people 25 hours each, etc. Sure it isn't enforcable but neither are the current fix-it windows. The number of man hours is debatable.

Hmmmmm I think that might be a bad idea. Teams with CNCs could have 2 people work for 50 man hours and get a lot done.

[Madison]

Originally Posted by AdamHeard

Hmmmmm I think that might be a bad idea. Teams with CNCs could have 2 people work for 50 man hours and get a lot done.

Though, to be fair, that's true of the current fix-it window rules as well. As with all things, resources dictate how much we can accomplish in six weeks, ten hours or at a regional.

[Raul]

David,

I like your idea. I just still have a problem with the 10 hour limit for software work. I believe, as many of you probably also figured out, that the two 5 hour sessions are meant to simulate roughly 5 hours that teams get to work on their robots on Thursday and Friday. But in reallity, I know that many teams, including us, work well more than 10 hours on the robot at a competition. This is even more pronounced for SW since you do not need access to the actual robot to write SW. You only need occasional access to the robot to test the SW. You could theoretically work about 30+ hours on SW during the competition (equal to the hours that the pits are open).

[ChuckDickerson]

Originally Posted by AdamHeard

Teams with CNCs could have 2 people work for 50 man hours and get a lot done.

Very true but how is that any different in the regular build season? This is exactly my point. What is the purpose of 1 or 2 or 3 or whatever 5 hour or 10 hour or whatever fix-it windows. Teams with limited resources (fewer members, only hand tools, etc) are placed at a disadvantage to those with more resources (100 team membersm zillion dollar CNC shops, etc.). By FIRST limiting the fix-it windows by clock time it in no way levels the field. At least with man hours you can't just have more people working in the time period to get more done.

[meaubry]

My vote is "other" -
10 hrs accumulated total - allocated any way you'd like.

For example,
1 team might choose to use all 10 at one time, and be done with it,
while some may choose to allocate equal portions over X days,
and others may choose to split it up in unequal time allotments

So, depending on each teams dynamics (size of team, available equipment, and workspace, time availability of mentors and students) it would best allow all teams the capability of using the fix-it window as they wish to.

Mike

[johnr]

just wondering if it would be better to drop the fix-it-window and go to something like ,"you can't change more then 25 percent of your robot ". better minds could figure out how to divide robot and/or percentage based on game. would it be for each event or whole season? maybe one official picture at first event uncrating.
the only reason i bring this up, it seemed that i saw a few teams carrying in alot of the robot at the comps. mainly ramps.it seemed to me that should be in crate already.
or would this to be a rule that you couldn't enforce? i do believe that writing code should be unrestricted and not part of the above idea.

[galewind]

The problem that I have, personally, with the fix-it window is that the programming is supposed to be done simultaneously with the manufacturing of parts, and the coordination of that is sometimes near impossible, and quite frankly, unrealistic. Noting that the coding of specific features of the machine and the autonomous testing cannot be done until after specific components of the machine are built, I would propose that FIRST do something along the spirit of these two ideas:

1) Make separate fix-it windows for programming
2) Make the "put the computer down" deadline X amount of days after the ship deadline in order to compensate for not being realistic in coding until after the design of the robot is laid out.

As it stands, those teams who build separate identical robot bases or full robots stand to benefit from the fix-it windows because they have a full machine to work on coding with while the manufacturing crew has the ability to work on assembling the spare parts. Additionally, if a prototype base is designed before build, teams can learn to work with sensors on this prototype base so that code is already written BEFORE build starts.

When teams don't have these resources, during build, the programming crew often gets pushed by the wayside when it comes to testing because, after all, if you don't have a finished robot, you can't test it.

I believe that building and coding are two separate beasts that COULD have rules created around them that are separate (but don't necessarily have to if you have strong enough project management skills).

I'm not really... convinced that we would have to do either of these things, but i'm just throwing it out.

[David Brinza]

Originally Posted by johnr

just wondering if it would be better to drop the fix-it-window and go to something like ,"you can't change more then 25 percent of your robot ". better minds could figure out how to divide robot and/or percentage based on game. would it be for each event or whole season? maybe one official picture at first event uncrating.
the only reason i bring this up, it seemed that i saw a few teams carrying in alot of the robot at the comps. mainly ramps.it seemed to me that should be in crate already.
or would this to be a rule that you couldn't enforce? i do believe that writing code should be unrestricted and not part of the above idea.

There is already a rule that limits the total weight (25 lb) of parts that can be brought to the competition, so that satisifies the hardware part.

FIX-IT WINDOW software development restrictions have been contentious since inception. Writing "practice" code for a practice robot seemed acceptable to some teams and totally contrary to the intent of the rule by others. The 2006 "cease software development" CD thread here.

I also favor unrestricted software development after ship.

[Jonathan Norris]

Eliminate the Fix-it window. Or allow teams a much longer fix-it window.

Every year on Thursdays at every regional you see a large portion of the teams making major changes, building major components, and programing as quickly as they can. If allowing more time between regionals to give teams and opportunity to design improvements, test them, and build them and improve the quality of their robot why not. If we want a true competitive balance in FIRST, why not give a team every opportunity to improve the performance of their robot.

I know in my teams case last year we had to use the fix-it windows to make major changed to our robot, and I know how much more time would have helped us improve the quality of our robot. During the BAE regional we determined that how we had designed our arm it was going to be too difficult to score (think of 1251 last year, but harder to control...). So we stopped using our arm and played some mean defense. But every minute between matches we spent changing the design of our arm and manipulator system. We came up with a new design of the arm, with a single main joint, an extension, and a new roller-claw manipulator. We were not able to finnish the construction of the manipulator by the end of the competition (and we needed new banebots gearbox's anyway) so we decided to use our fix-it windows between BAE and Waterloo.

Back at the school we built the new manipulator and were able to do some crude testing, but truthfully what we had time to build was more of a prototype then a final product, if we had the time we would have rebuilt it after testing to make it more robust. We brought our new manipulator to waterloo on thursday, we fixed our turret in place cut off a joint for the old manipulator and cut down our extension and attached the new roller-claw. The design was great, it immediately made us a top scorer at the regional even with our major problem with consistency. The manipulator was great at sucking in the tubes, and could rotate them about 300 degrees on to the legs. Because the new manipulator was built under such time constraints we made sacrifices that came back to haunt us, it broke in some fashion during almost every match. During the quarter and semi-finals it consistently failed us. (edit: it did win us design awards at both Waterloo and GTR)

So the moral of my little story here is that I know that if we had more time between regionals we could have been even more effective and more successful at the Waterloo Regional (maybe even get to challenge 1114 in the finals again). I understand why the fix-it window is in place to stop teams from rebuilding the majority of their robot between regionals, but in reality all that team wants is to spend extra time and work to improve their robot why not let them?

[Bharat Nain]

For reasons stated above, I am all for eliminating fix-it window's.

[Pavan Dave]

I'd say eliminate the "fix-it" window but submit a copy of your code to FIRST. What FIRST would do with this code is they would check its file size, and check it to make sure you don't write jibberish in some files to get away with more room. Than you could make as many parts anything up to 25 lbs, and 50-100kb limit mod to the code or something. You would have to submit it wednesday night and you would be okayed to use it for the competition. Than when you get your 25 lbs weighed in, you must show your code to the same person who checks weight and you will be required to show that FIRST has approved your "post season" code modifications.

[Mr.G]

Originally Posted by Pavan

I'd say eliminate the "fix-it" window but submit a copy of your code to FIRST. What FIRST would do with this code is they would check its file size, and check it to make sure you don't write jibberish in some files to get away with more room. Than you could make as many parts anything up to 25 lbs, and 50-100kb limit mod to the code or something. You would have to submit it wednesday night and you would be okayed to use it for the competition. Than when you get your 25 lbs weighed in, you must show your code to the same person who checks weight and you will be required to show that FIRST has approved your "post season" code modifications.

Why limit learning.

The parts weight rule has been in for a couple years and never enforced. I don't agree with it. I do believe the assembly’s that are brought in should be completely disassembled though. I agree greatly with that rule, and it is easy to enforce.