Re: Please read R17
 

As is having to ship the RC, when we can legally buy another one and program on that.

Re: Please read R17
 

Or change out a few libraries and just program on the older (minus the PBASICs) controllers.

So now my views on R17, from a programmers perspective. With all due respect, I don't think that the people (person?) who wrote R17 have ever had to program during the six weeks. I know the FIRST standard for programmers is that a couple days is lucky. This year I was given about two full days and a couple hours worth of "Hey, mechanical team has to change this piece. You can have twenty minutes with the bot." This is definetly not enough time to program anything more than a medium complexity robot.

I will bet money that if you ask the majority of programmers what they want during the six weeks, the answer will not be a new compiler. Nor will it be a new language, or a different IDE or a faster processor. It will be either more time with the bot or a second bot for testing. The former is not feasible on most teams (six weeks is already a strain) and the latter is not feasible due to financial complications. The only options that a programmer has is write all his code during the first five and a half weeks and testing at the last couple of days. This leads into my next thought...

Programming is not merely writing code. To successfully program a FRC bot, you need to design the code framework, read up on the datasheets of the sensors you are using, write the actual code, debug the actual code (syntax and whatnot), load the program and finally... TEST. Testing is by far the most time consuming thing out of the entire process. Lets take a PID loop, for example. Someone who is familiar with PID can write the actual code in under half an hour. However, after it has been loaded onto the robot it will most certainly take them at least half an hour of tuning. Testing is not possible after the six weeks (lack of a robot, unless you can afford to build a second) so I don't think writing raw code should count towards "software development." If a programmer knows how to write a certain function, they should not have to take time out of their testing time at competitions to write it.

So if you've been following all that, congratulations. It's probably a tad hard to understand, I tend to jump from topic to topic. What I've said basically amounts to...

• I don't believe that R17 should apply to programming. There simply is not enough time given to programmers.
• The most beneficial thing to a programmer would be more time with the robot or a second robot purely for programming. The first option is hard due to time constraints, and the second due to financial constraints.
• Writing raw code is only a part of the software development process. Testing code is much harder on the complex systems that most programmers wish to design.
• Programmers shouldn't need to take precious testing time to write code.

Re: Please read R17
 

Do in part to my stupidity we also missed the window. I had miss read and thought that we had 10 hours after ship, before the next regional. We decided to take a break till Monday and then start our fix it window. I am in agreement with the 10 hour window. I would also like to see the teams manage that time in the way that it best suits the team and it would have to end Wednesday 12 PM before the first regional. This would be fair to all teams, easier on mentors and students and probably followed by most teams.

Re: Please read R17
 

Whether or not a rule makes sense does matter. A rule with a high likelihood of being broken needs to be examined from a few perspectives:
1. What was the intent of the rule
2. Does it achieve its intended purpose
3. Might there be a better way to accomplish the same goal

Intent of the rule
With respect to the fix it window rule, I can only surmise the intent was to:
1. Create a finite period of work for teams and corporate mentors
2. Put teams "with" and "without" abundant resources on equal footing
3. Not give teams playing their first competition later in the season a longer time to get ready

Does the rule achieve this?

Creating a finite period of commitment
As FIRST is a mentoring program, FIRST anticipated they would have to have to ask corporations to lend their engineers/technicians to teams. They also anticipated having to answer the question "How much time are you asking for?" In an effort to entice rather than scare away potential mentors, FIRST believed by imposing a ship date and then limiting work time beyond the ship date, it increased the chance of finding and keeping mentors to work with teams. Did it work?

I think the answer is no. It did limit the time they can work, but not without putting an undue burden on the mentors who must now eat, sleep and breathe FIRST during this finite period to get the robot done. It is not uncommon for team members, mentors included, to literally give up their families, friends and school during the 6 week build period. If we are honest with those we solicit for help, it certainly doesn't make selling participation any easier. And if we are not honest about the sacrifice they must make, we set the teams up for hardship when the mentors seldom come. The finite period also creates a situation where time is so short, mentors must hijack the project to finish on time, leaving everyone else to watch. This problem is magnified when you consider the mentor feels a responsibility to the corporate sponsor to produce a robot the company will be proud of.

Another point to consider is whether we have undermined our efforts for longevity of teams by putting too much pressure on them to finish within a finite period. The mentor (and even the student) who has sacrificed everything during the FIRST season, may not have the support of his family, friends and school administration next year or two years down the road when he/she chooses to participate again.


Leveling the field based on differences in resources:
Does providing a fix-it window close the gap between the teams with and without abundant resources? It seems to me teams with the most resources (manpower, money and access to machines and engineers) have a far better chance of finishing their robot during the six weeks and accomplishing what is needed during the fix-it window. Therefore the rule actually increases the disparity between the teams with and without abundant resources.

If it takes some teams longer than others to produce a great result, why should FIRST or any other team care? Think of it this way: If it takes one person 20 hours of studying to get an A, but it takes another only 5, should everyone have to stop at 5? Don't we want to teach that you have to work hard to compensate for your weaknesses, not give in to them? The time is there, why not let teams decide how they want to use it? The benefit to FIRST is that the competitions should be more exciting and inspirational when all the robots function better.

Leveling the field based on when you play first event
This argument can cut either way. There are many factors teams consider in choosing which event to play in. Travel budget is one. Level of competition is another. The fix-it window cannot compensate for all of these factors. For instance, everyone knows competition on the field is the lowest at the beginning of the season. You could argue teams playing early that have mega resources which allow them to finish in plenty of time to test, are at a distinct advantage and have a far greater chance of winning earlier. The fix-it window actually helps them by limiting how ready their opponents will be. Similarly, those playing later for the first time will be up against repeat players who have already had the chance to learn what needs to be fixed, what strategies work better, etc.. Either way, teams have to weigh the advantages of playing early or late and decide this for themselves. The fix-it window won't eliminate these factors

Additional factors
Not only does FIRST dictate how many hours you can spend, but also when those hours may occur. Teams are tired after ship date, and equally tired after competitions. Often students and mentors have let other things in their lives slide and need to concentrate on getting those things back on track. Students need to catch up on missed school work, mentors need to catch up on work. Additionally, after a competition, it is often the case that parts need to be ordered and received before a replacement, spare or improvement can be fabricated. Telling us when we can work just doesn't make sense

A Better Way
FIRST should continue to level the playing field by limiting parts, motors, weight, size and overall costs allowed on the robot, but not on how hard teams can work. Let teams decide this for themselves.

I am a proponent of allowing teams to work as many hours as they choose, on whatever days they choose, to accomplish whatever they as a team choose to accomplish. I love to see robots evolve over the course of the season, even if that evolution is the result of imitating a concept from another team. This is how it is in the real world. This is what sharing info is all about. This should be what FIRST is about.

Re: Please read R17
 

I completely agree. Isn't the point that we work hard? Woodie Flowers mentioned at kickoff that he gave us a time frame too small, team too big, etc. Time frame too small is right. My team just barely finished our robot. We didn't have time to create spare parts. I agree that we shouldn't be able to create new parts, or completely redesign the robot, but, especially with this year, there will be A LOT of colliding, and new parts will be needed. Ten hours isn't very much time, especially for temas with limited machine shops.

I know at the NY regional, one team has their machine shop two blocks from the competition area, but what about teams from CT and the surrounding area? How can they get replacement parts?

Re: Please read R17
 

With this I agree. After the build season, nobody wants to do ANYthing for a few days, and so we did not do much of anything during the fix-it window. Trenton regional is this week, so we'll be making shields and drilling out sprockets Thursday - hopefully there will be someone kind enough to loan us the use of a drill press, and maybe a lathe. Not to mention that the mentors all work for a living, so spending just one more night from 5:30 to 10:30 is right out of the question.

I'd rather see "OK, you have 10 hours total between now and the regional, use them wisely."

Don

Re: Please read R17
 

This may seem crazy, but maybe they think that you should finish the robot during the build. Not 75%, but ready to rock out of the crate.

Re: Please read R17
 

I believe that is the premise of the rule. In theory, that would fix all of the problems FIRST has with boring matched by forcing teams to do all essential robot work before the build. But as you know, things get hectic, and as with any project, schedules fall behind, and the final details often get forgotten.

Re: Please read R17
 

Bottom line is that 6 weeks is not enough. It never has been enough. Now, with this year's rules you needed to be done in four weeks compared to six weeks in previous years.

Re: Please read R17
 

Maybe that's the point.
You need to be DONE in 6 weeks; then back to your kids and job.

It seems like FIRST is making a statement saying "Dragging this out into a 12 week process, is not what we intend to happen. 6 weeks, means 6 weeks."

Like Joe, I don't want to put words in FIRST's mouth, but this seems to me to be a pretty clear attempt to force engineers in FIRST to NOT work on FIRST. "Ok, robots have shipped, go do real work and wait for regionals."

I'm not saying I agree (in fact, I don't), but this could be a direction the powers-that-be want us to take.

-JV

Re: Please read R17
 

I also want to point out that over the past 11 years of doing FIRST - I have had some of the very best experiences while helping teams that were 75% or less completed and far from "ready to rock out of the crate".

I seriously do not think that this "fix it window" rule is to assure everyone finishes their robot during the build, but then again, I have been known to be wrong before.

My point was that robots that don't move are boring to watch - almost painful and if the team cannot schedule 2 - 5 hour long work sessions to make/repair replacement parts or debug programs - the overall level of FIRST participation doesn't get any better. If a team can only schedule the group for 2 - 4 hour sessions, 20% of the opportunity to improve things is wasted.

With Engineers and Mentors working during the day, 2 full evenings (5:30 to 10:30pm) now need to be scheduled instead of being able to spread that 10 hours out and find a balance between, work, FIRST, and seeing the family. This puts me in a tough spot -
a) Honey, I know we finished the build, but theres alot of things that still need to get done and we can ONLY get them done in these 2 - 5 hour windows
b) Team, I can't make this schedule so we'll just do what we can and we'll get done what we can get done, let me see when the other coaches can be here and if the school is open that late
c) What fixit window(s)? - if on one knows, no one gets upset

If they wanted the project completed in 6 weeks - than JUST SAY IT - the fix it window rule allows teams to extend the build cycle for repair and replacement parts - as well as, and more importantly - for programming/debugging. Giving control to the teams for when the 10 hours is to be scheduled, isn't gonna hurt anyone.

Re: Please read R17
 

The bottom line is this: they GAVE teams a working robot chassis that can be built by the end of the day of the kickoff presentation. They GAVE teams code that can find and track the target. You now have 6 weeks to build something that can pick up and throw the balls. Teams that build a functional robot in six weeks should not be penalized by allowing other teams to keep working after the ship date. Of course you could build a better robot in 8 weeks, but you only have six. Thats the point. If that means you need two weeks to practice then the build season is four.

Re: Please read R17
 

I understand that this rule is partially intended to level the playing field, but I think that certain teams will always have an advantage (due to financial or machining resources) that will not be able to be restricted. Instead, rules like this penalize the rookie teams that may need more time just to get to the level that a more advanced team can within the 6 weeks.

My main complaint about R17 is from the standpoint of programming. While I understand that there are often constraints on mechanical development in business situations, the software development often continues. Firmware updates correct major issues in electronics (I know my current PDA would be useless if not for post manufacture updates), operating systems and computer software are patched constantly due to new discoveries and games are updated to ensure stability and compatibility. Last year FIRST said that it was OK to fix problems in the code as long as the changes were retyped at a competition. Now there is the ruling below:

This seems unreasonable to me due to the fact that any code that is necessary to run a second robot (which we have for driver practice) would have to be duplicated on the competition one. Therefore, I understand this rule to say that no improvements could ever be used on the main robot. If I were to develop a better autonomous or shooter control, I could not in any way use this in competition, as a recreated code would surely use the same structure and statements. This ruling discourages improvement and makes me reluctant to change any code to better the control of our practice robot, because if I did anything more than think about it, it could not be used. Then, I probably will not have enough time to debug at the competition, or remember what needed to be implemented.

This total restriction therefore does not make sense if FIRST would like to see the best robots possible from all teams, because code is one area where all teams should be somewhat equal. We can all retain the control system and work with something to refine our code. This ruling only gives an advantage to those teams who had the ability to finish their robots more than a day before ship. While I will follow this and not continue coding, I believe FIRST should rethink this restriction in the spirit of innovation and gracious professionalism to the less privileged teams.

Just my opinion from a member of a team who has gone from building one robot to two during my participation. I have experience both ways, and believe banning after-ship coding only hurts both types of teams.

Re: Please read R17
 

just a fewthings to say:

Everyone here seems to be focussing on the fix-it window IMMEDIATELY after ship. there are duplicate windows following each regional competition per <R20>.

that said
1) I agree with everyone who thinks the first fix-it window should be more flexible than just two 5-hour work periods. Alternatively, give teams a break and move the post-ship fix-it window to the two days immediately preceding the first regional event.

2) I see no reason that they have to limit programming to that period alone. Why not let teams experiment with new controls (ie. steering wheels)? As it is, teams attending multiple regionals have MORE programming time than everyone else. I know our programmers would KILL for more time, because they know they're not going to get very much at the events.

3) If a team gets their spare parts made by a machine shop, does that shop have to complete the parts within the fix-it window?

Re: Please read R17
 

I'm not going to let Steve take all of the blame. I misinterpreted it too, despite having read and understood that rule, long, long ago. We were under the wholly mistaken impression that it worked like the other fix-it windows, that is, it could be taken until 5:00 on the thursday of the next event. (This is why everyone needs to read all of the rules; even the guys who are well-versed in them can make mistakes.)

On the other hand, I wasn't planning to admit it to the world that we'd botched our timing.... ;)

This is something that isn't specifically addressed in the rules, for the case where the machine shop is paid for its services as a non-sponsor (sponsors' employees are considered team members by 5.3.4.4, and are therefore apparently bound by competition rules). However, I think that it's implicit in 5.3.3 (<R15> to <R20>) that teams are not permitted to allow their agents (i.e. the non-sponsor machinists) to perform work outside of the legal periods, because the rules hinge upon the team's intent to use such parts in competition. While a non-competing entity can't violate a rule on its own, it is incumbent upon the team to ensure that if the intended purpose of the part is to be used in competition, that the part is fabricated during legal periods. For a contractor to work on the robot (or a part thereof) after the build season would require that it be uncrated, which violates <R16>. Even during a fix-it window, only teams are allowed to manufacture parts—a contractor working on fabricated items (primary/spare/replacement/upgrade) destined for the robot during this period would violate <R16>.

It would be nice of FIRST to slip a paragraph into the rules next year describing the permitted scope of the contractor-team relationship in more detail. It isn't urgent, because I don't think that the intentions of the rule-writers are really that unclear—it's just that actually proving it through the rules requires a little bit of careful examination.