Quote:
Originally Posted by AlexanderTheOK
It's a good idea to have two programmers on one laptop in a coding pair to fix bugs quicker, but more than that you end up having too many laptops and people in the pits.
|
We understand the coding exception:
Quote:
|
Originally Posted by Recycle Rush 2015 Manual, R15
D. After Kickoff, there are no restrictions on when software may be developed.
|
as meaning that we can develop code in the stands or the lobby or even off site. However, as I noted above, the lack of connectivity pretty much limits us to a single laptop.
Quote:
Originally Posted by Jared Russell
Code:
Jared's Hierarchy of FRC Needs for Repeatable, On-Field Success
HIGHER LEVEL NEEDS
Software
Mechanical design and construction
Construction fundamentals (batteries, wiring, pneumatics, fasteners, etc.)
Sponsorship, equipment, and space
Mentorship and team organization
FUNDAMENTAL NEEDS
|
Excellent point. I would add "strategy" between Mechanical design and construction and Construction fundamentals, but the bottom line is that even great software can't redeem a robot that is built poorly or is built to do the wrong things.
Quote:
Originally Posted by artK
A connection of some sort is always going to be necessary in any distributed work.  |
My point exactly.
Quote:
Originally Posted by artK
Does this work? <IMG/>
|
Yes!
Quote:
Originally Posted by gblake
Yeah... the buzzworthiness of knowing and discussing the big O characteristics of various data structures and algorithms for various operations (insert, sort, etc.) has been on the rise for a while because of the money to be made in big data.
|
Quote:
Originally Posted by AlexanderTheOK
The most important resource isn't CPU time, or even the money to run a team. It's [software development] time....Out of all the ways FRC programmers can spend their time, code efficiency is the least efficient way to spend it.
|
Yes and Yes!
Using a red/black tree to sort a list if ten numbers is less efficient than bubble. Coding it is only more efficient if you're regularly going to sort hundreds or thousands of numbers.
When we started the team, Gixxy (our first program lead, now a CSCI major, and fascinated with computers since before he was two) was planning to write this big code base to carry from year to year. However, most of the FRC reusable code is already in WPIlib or LabView. Unless you reuse hardware (or at least hardware design), the software is also going to be a fresh start. In four years, I believe that we have reused vision processing code (running on a raspberry pi), the threaded connection to the pi, and an xBox controller front end. We have borrowed old drive system and manipulator code to build new, but we followed up with such massive modifications that I wonder whether we saved more time by reusing than we spent in fixing "old code" problems. That is, the main reason most programmers practice good coding (that is, someone will have to maintain it ten or more years from now, maybe me) is not a valid concern for deck plate FRC programming.