<R14> and Software Development

[Joe Johnson]

<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.

I bolded the last bit for emphasis.

What do folks think about this rule?

I think that it is a good thing. It is a mercy rule: It saves us from ourselves.

Evenso, I am going to encourage Chief Delphi to get cracking on the coding NOW, TODAY so that they can avoid the long tough slog we usually go through getting the software in shape by the Championships.


Personally, I hope the teams honor the rule. Gracious Professionalism is the only way to enforce this kind of a thing. Here's to GP.

As always, your thoughts are welcome...

Joe J.

[Matt Adams]

I think that it is a good thing. It is a mercy rule: It saves us from ourselves.I'm going to agree with you on this one. Whenever you have no limit on something (money, time, type of material) people are going to indulge themselves 100% to utilize it. Having several more weeks of software development just widens the gaps between the haves and have-nots, especially those teams who have built a second robot in the past specifically for software tweaking in addition to driver practice.

I think that mentors of this program have been telling FIRST for a while now, "Can we please make this just a 6 week competition? I have a family." This rule change definitely helps this out.

Matt

[sanddrag]

Thanks for the heads up but NOOOOOOOOOOOOO. Aww man. We were all set to build an identical practice bot, but now the only benefit would to drivers, not programmers.

[Dave Flowerday]

What do folks think about this rule?
On one hand, I'm relieved, but at the same time, I'm worried. Again, I think this is a rule to attempt to level the playing field, but really I think it just helps more experienced teams that are better equipped to get their robot done early to allow software testing.

I also want to know more details: are we allowed to tweak our "practice" software then show up at competition and "redevelop" those same changes on our "competition" software? How does this compare to the mechanical side? Mechanical groups are allowed to design new components, build and test them, even though they can't bring them to the event. I hope the same would apply to software, although it's more of a fuzzy line. Is thinking up a new algorithm without implementing it considered "software development"? I know it is as far as my employer is concerned.

[Deltafrog]

I think it just helps more experienced teams that are better equipped to get their robot done early to allow software testing.

No matter how hard we try, our software is usually still in the testing process when we get to the 1st competition. Last year we didn't really finish our software untill the nationals and even then it wasn't great! I think this benefits the bigger teams more then it does the smaller teams. :mad:

[Matt Leese]

I would think that whatever the intent of the rule, it will "level the playing field" quite a bit. Simply, there was a huge advantage for the autonomous portion of competition if you built a second non-competition robot. You could spend all the inbetween portion finalizing your code on the second robot.

That said, I think that to be fair, and analogous with the mechanical portion of the robot, that the only thing that can be developed outside of the legal build periods would be design documents. It'd be legal to develop a state machine or flow chart. It'd be illegal to actually write the code to implement it. And if you wrote proof of concept code, I'd think you'd have to leave it at home and rewrite it from scratch at the actual competition.

Matt

[Marc P.]

I think this rule is a good thing. In previous years, it was up to the team to develop their own tools/code to perform required functions. This year, with the majority of the more difficult code already written and available in non-complex forms (scripting language), there's no reason coding basic to intermediate functions should take longer than the 6 weeks. The tools are there to help both rookies and veteran teams produce functions that were out of reach of many teams last year. However, the controllers are still essentially the same, and the basic software can still be written in C. More advanced teams interested in complete customization can still do so, while all others can still rapidly develop with the avaliable tools. If it comes down to the last 2-3 days of the build season, or even during the service window at a competition, and the software still has bugs and/or isn't working, these tools are still avaliable, and can provide emergency relief should the need arise. Heck, any team capable of writing complete custom code should have no problem integrating provided functions and hammer out some working code within hours. Because the coding can be so easy this year, it's good to limit the time things can be coded, just as the mechanical and electrical teams have to follow the limits of the competition, so should it be with software.

[Damian Manda]

We have usually had to stop software development with the robot ship in previous years, because we made no practice bot, and the only thing not finished in the code has been autonomous, which is not practical to program without testing on the actual robot. This year we may actually build a second robot, but I still think this rule is a good idea, as it may just keep me from spending more time than I should on programming after the build season. I'm not sure how much this will actually level the playing field, but at least it does not give an advantage to those teams with second, practice bot.

[Bharat Nain]

I personally don't like the rule because I write up a lot of code inbetween competitions and test it out during competitions. I guess I can't anymore. However, I do see how this rule came into effect. Writing new code could be compared to building new spare parts. If we should not build spare parts outside the fix-it-window, then we shouldnt make new software programs either.

[russell]

This is only my teams second year and the size of our team is still somewhat unclear, but last year we had seven people and while the programmers "programmed" the rest of us built the robot. Then when we finished the robot on the ship date we found out that the programmers had been too busy watching us build the bot to actually get anything done. The fun part of this came when I realised that this meant I could try programming too, so I spent the next few weeks learning programming. Personally though I think this rule does level the playing field for rookie teams because they dont have a second bot to program on after the ship date.

[jimfortytwo]

Does this mean that taking your laptop home to the hotel during the competition is illegal?

[russell]

you cannot program on it at the hotel. If you are just going to play counterstrike its ok though :D

[David Brinza]

On one hand, I'm relieved, but at the same time, I'm worried. Again, I think this is a rule to attempt to level the playing field, but really I think it just helps more experienced teams that are better equipped to get their robot done early to allow software testing.

I also want to know more details: are we allowed to tweak our "practice" software then show up at competition and "redevelop" those same changes on our "competition" software? How does this compare to the mechanical side? Mechanical groups are allowed to design new components, build and test them, even though they can't bring them to the event. I hope the same would apply to software, although it's more of a fuzzy line. Is thinking up a new algorithm without implementing it considered "software development"? I know it is as far as my employer is concerned.

I think FIRST is going to have a hard time defining "software development" - especially with an English-like scripting language available to the teams. The gamut for software development runs from defining software requirements or problem-statements (just thinking about what the new software will need to do), to writing a "psuedo-script" (documenting the solution to the problem statement) ,to actual coding and compiling (performed in the IDE), to test/validation (running it on a robot).

There's no way that FIRST members aren't going to spend time in the first phase of software development (can you really NOT think about how the robot will be more effective in autonomous mode after shipment or between competitions??) If you write down your thoughts on how to run your robot in autonomous mode (and English is your choice of language) - you've developed a pseudo-script. The actual coding and compiling are now just a stone's throw away. Finally, there is testing...the part of software that seemingly never gets done well enough because there isn't enough time.

There's one aspect about testing autonomous mode software that really needs to be considered - safety. There's a need for a really safe environment for teams to test new code. The practice field and other space at regional competitions aren't as easy for a team to control as their own robot development space. If a robot makes a wrong turn with a tetra in its grip, someone near the field might get whacked (if they're not paying attention).

Teams like ours that have built code from scratch have learned the hard way how dramatic the result of a minor bug can be. That's why we built second robots for driving practice and software testing and everyone pays attention the first time new code is executed.

It will be interesting to see how this topic evolves...