On the quality and complexity of software within FRC

[gblake]

Originally Posted by GeeTwo

I hadn't either until a few months ago, and I minored in computer science (1984). Back then, we just called it "order of magnitude". It tells you how resources required by a process (usually time) scales as the amount of data being handled increases. For example, a bubble sort is of order n² where n is the number of items being sorted, so "n²" is the "big O" for the bubble sort, starting from an unsorted data set.

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.

[AlexanderTheOK]

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.

[faust1706]

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.

[MrRoboSteve]

Shipping is a feature.

[EricH]

Originally Posted by faust1706

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

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

[gblake]

OK, I'll bite.

Originally Posted by faust1706

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

How did you know it was properly threaded?

Originally Posted by faust1706

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

And,

What is computer science, really?

[faust1706]

Originally Posted by gblake

OK, I'll bite.

How did you know it was properly threaded?
And,

What is computer science, really?

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.

[Ian Curtis]

Originally Posted by gblake

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.

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

Why this matters:

Shortly before the first field test (you realize that no small scale experiment can be done—either you have a critical mass or you do not), a man asked me to check some arithmetic he had done, and I agreed, thinking to fob it off on some subordinate. When I asked what it was, he said, "It is the probability that the test bomb will ignite the whole atmosphere." I decided I would check it myself! The next day when he came for the answers I remarked to him, "The arithmetic was apparently correct but I do not know about the formulas for the capture cross sections for oxygen and nitrogen—after all, there could be no experiments at the needed energy levels." He replied, like a physicist talking to a mathematician, that he wanted me to check the arithmetic not the physics, and left. I said to myself, "What have you done, Hamming, you are involved in risking all of life that is known in the Universe, and you do not know much of an essential part?" I was pacing up and down the corridor when a friend asked me what was bothering me. I told him. His reply was, "Never mind, Hamming, no one will ever blame you."[5]

But that's not the point. It's that frc ultimately fails at demonstrating what [CHOOSE YOUR OWN FIELD] really is.

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.

[GeeTwo]

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:

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.

Originally Posted by Jared Russell

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.

Originally Posted by artK

A connection of some sort is always going to be necessary in any distributed work.

My point exactly.

Originally Posted by artK

Does this work? <IMG/>

Yes!

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.

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.

[AlexanderTheOK]

Originally Posted by GeeTwo

The most important resource isn't CPU time, or even the money to run a team. It's [software development] time...

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.

[floogulinc]

Originally Posted by faust1706

The vast majority of code would get a 'C' at best in an intro to programming class in a high school. So why is no one talking about this?

Originally Posted by Anupam Goli

You vastly overestimate the rigor of a high school programming class. If you saw the MATLAB code I wrote for my Computing for Engineers introductory college course, I'm sure you'd have a heart attack. When you're not graded on efficiency and don't have to time to make it efficient, why make it so?
there's a lot).

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.

[asid61]

Originally Posted by floogulinc

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.

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

[Ether]

Originally Posted by Ian Curtis

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

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

[notmattlythgoe]

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.

[marshall]

Originally Posted by notmattlythgoe

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.

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.