Re: On the quality and complexity of software within FRC
 

Yeah...

For those who haven't noticed or cared (and... it's legitimate to be proud of not needing to notice or care ;)), I have noticed that 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 (business analytics, online shopping, social networking, searching, databases in clouds, intelligence/spying, etc. etc.), and it's now quite trendy.

It's become so trendy that I worry that folks are losing sight of the differences between efficiently operating on small datasets and efficiently operating on large datasets. For small datasets, low-overhead brute force will often beat the pants off of manipulating some fancy data structure that is appropriate for larger datasets. There is more to writing efficient code than learning the big O characteristics of various data structures and algorithms.

FRC has opportunities to for programmers to experience both sides of this fence.

Re: On the quality and complexity of software within FRC
 

The one thing people harping about code efficiency and big O functions need to hear is this:

The most important resource isn't CPU time, or even the money to run a team. It's time. There are only so many man hours a person can spend doing something. (obviously varying from person to person) Money can be acquired through time. (People can spend time fundraising) CPU time can be bought with money (Just buy another onboard computer for the second camera.)

If it's going to take 50 hours of work to get your vision tracking program optimally threaded for all 4 cores, for the sake of saving 200 dollars on an onboard computer, you are literally working for less than minimum wage.

Now if you're writing code for mass produced industrial equipment, you're no longer looking at 200 dollars, likely 200,000 dollars, or 2,000,000 dollars. Then it would be worth it.

You might also want to learn how to write threaded code well. In that case, it becomes worth it for the educational value.


FRC robots are not mass produced, and most FRC programmers are still worried about getting EVERYTHING working in the several hours they have with the robot.

Out of all the ways FRC programmers can spend their time, code efficiency is the least efficient way to spend it.

Re: On the quality and complexity of software within FRC
 

It took me less than 30 minutes to properly thread my vision code in 2013 on a quad core sbc....

But that's not the point. It's that frc ultimately fails at demonstrating what computer science really is.

Re: On the quality and complexity of software within FRC
 

Re: On the quality and complexity of software within FRC
 

That's also not its goal. Plain and simple. FRC is aimed at inspiration. Not at learning the reality. If demonstrating the reality were the goal, the mechanical students (remember, they're all in high school) would all need to be able to do at least basic stress analysis, geartrain stresses, fatigue-rating...

...and know the math behind all that, which can be worse than the math used to compute the various items I just mentioned.

Oh, and the electricals would need to be able to understand the guts of the electrical devices, which as I recall can get into Diff. Eq. As I recall, that's barely touched on in H.S. calculus.



Plain and simple: Part of any (and I do mean ANY) engineering project is to deliver a product that works, on time and on budget (and on weight). Comp Sci is very much an engineering field. If you have the time to go above and beyond, nobody is stopping you from going above and beyond, provided that the product (your code) works (read: runs the robot) properly. I think Randall puts it very nicely in 664...

Re: On the quality and complexity of software within FRC
 

OK, I'll bite.
How did you know it was properly threaded?
And,

What is computer science, really?

Re: On the quality and complexity of software within FRC
 

Let me rephrase that, it was threaded well enough that I couldn't make the program run any faster due to limitations on how many frames a second I could grab from the camera.

I do not have a firm definition of computer science, as I do not have one of mechanical engineering either. But I'll give it a shot by combining various definitions I've heard from my professors and read over the years.

Computer Science is concerned with information in much the same sense that physics is concerned with energy; it is devoted to the representation, storage, manipulation and presentation of information. Computer scientists deal mostly with software and software systems, which includes theory, design, development, and application.

Let's dissect this in terms of FRC:
Representation: An interesting survey would be to see what percentage of frc programmers know how various data types are stored in the computer (and the rough range of them)
Storage: Beyond the occasional class, data structures such as queues and trees are not used in FRC to my understanding
Manipulation: Manipulating ints is as trivial as tightening a bolt, manipulating complex data structures is another thing
Presentation: Besides graphs and printing to console, how are teams presenting the data they have when they want to?
Theory: Do teams take to the calculate the complexity of their problem before they solve it?
Design: (Serious question): Do teams take to the whiteboard and draw out their algorithm, like this famous one?
Development: There are many theories about software development so I won't touch this as to not anger people.
Application: Does it solve what it is suppose to? I feel in general this is the one area FRC meets.

Side note: For those who say why bother about efficiency if what is being done isn't complex to begin with. It's about learning and developing good habits. Programming habits are some of the hardest to break in my opinion and it takes self discipline to do things right, and not what is easy (Insert jfk speech). When you are constantly worried about optimization, you begin thinking like a computer scientist.

Re: On the quality and complexity of software within FRC
 

"The purpose of computation is insight, not numbers." -- Richard Hamming

Why this matters:


FRC "fails" to demonstrate what every field truly is -- but its true value is you can get exposure to the essence of almost ANY field.

Re: On the quality and complexity of software within FRC
 

We understand the coding exception:
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.

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.

My point exactly.

Yes!


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.

Re: On the quality and complexity of software within FRC
 

Well. It is applicable to software, and software being the topic of this discussion, maybe we ought not to digress, but it really applies to everything. There was a weekend during which the programmers here didn't touch the laptops at all, because there just weren't enough man hours being put into modifying the mechanical aspects of the robot, and there wasn't much good we could do editing code. We weren't very useful or good at it, but what we did accomplish was orders of magnitude better than what would have come out of another dozen hours of typing.

Re: On the quality and complexity of software within FRC
 

Oh man, this. Here is an entire semester of a highschool Java intro class (with many things done using much better/more advanced than the rest of the class including the teacher did). Even the most basic programming done in FRC would be A material in my school's programming class.

Re: On the quality and complexity of software within FRC
 

Can attest to this. High school CS was a joke compared to what I see the Electrical division coding.

Re: On the quality and complexity of software within FRC
 

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

Re: On the quality and complexity of software within FRC
 

On top of a lot (probably most) teams not having a programming mentor of some sort, I would venture to say that most of the programming mentors out there have no formal training in controls.

Re: On the quality and complexity of software within FRC
 

That's actually a good point. I suppose there are a couple of ways to look at FRC robots. One is as a control system problem. I'm not sure many teams take the approach to look at their robots in that light. I think that has a lot to do with why LabView is often shunned by some. LabView is an absolutely amazing tool for programming control systems...

All this talk of optimization is great but I haven't seen anyone in this thread talk about profiling. It's been a while since I took the compiler optimization class that I took in college but as I recall, there were some choice readings by Donald Knuth that pointed out that pre-mature optimization is the root of all evil or something similar. Profiling helps to determine where to optimize systems and with FRC robots containing a physical component, profiling would entail looking at the code as well as the robots output and the speed/efficiency of motors and gearboxes... which as others have pointed out, is more likely to provide substantial efficiency gains.