On the quality and complexity of software within FRC

[notmattlythgoe]

Originally Posted by marshall

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.

The Software industry is really starting to move towards the Agile process of development. Over-engineering is one of the wastes of time that the Agile process tries to avoid. Why engineer to a future problem that might never happen. On the topic of this thread, why over engineer your optimization unless it is actually going to be a problem. Outside of vision, optimization isn't going to be an issue.

[Alan Anderson]

Originally Posted by notmattlythgoe

The Software industry is really starting to move towards the Agile process of development. Over-engineering is one of the wastes of time tat the Agile process tries to avoid. Why engineer to a future problem that might never happen.

I try to stay away from the trap of unnecessary generalization and superfluous creation of flexible frameworks. My two favorite Patterns are 1) Do the simplest thing that could possibly work, and 2) You aren't going to need it.

[notmattlythgoe]

Originally Posted by Alan Anderson

I try to stay away from the trap of unnecessary generalization and superfluous creation of flexible frameworks. My two favorite Patterns are 1) Do the simplest thing that could possibly work, and 2) You aren't going to need it.

Exactly.

[Ether]

Originally Posted by notmattlythgoe

Why engineer to a future problem that might never happen.

This is a great motto for FRC.

For passenger airplanes, spacecraft, nuclear plants and warheads, and medical equipment... not so much.

[notmattlythgoe]

Originally Posted by Ether

This is a great motto for FRC.

For passenger airplanes, spacecraft, nuclear plants and warheads, and medical equipment... not so much.

Well you obviously have to engineer to the project requirements, and in those cases the requirements include redundancies. My point is don't engineer past the scope of the project.

[GeeTwo]

Originally Posted by notmattlythgoe

Well you obviously have to engineer to the project requirements, and in those cases the requirements include redundancies. My point is don't engineer past the scope of the project.

Or to paraphrase from the legal community, engineer to the requirements, the whole requirements, and nothing but the requirements.

[efoote868]

Originally Posted by GeeTwo

Or to paraphrase from the legal community, engineer to the requirements, the whole requirements, and nothing but the requirements.

I've had a few instances professionally where a more senior person has told me not to worry about designing for something in the future, only to find that a little bit of effort in the past would have saved a whole lot of trouble later.

"That'll never happen" has become an inside joke.

[Ether]

Originally Posted by GeeTwo

engineer to ... nothing but the requirements.

Originally Posted by notmattlythgoe

don't engineer past the scope of the project.

And my point was that I agreed with you for FRC.

But I sure hope you guys aren't suggesting that should be the "hear no evil, see no evil" attitude of the lead project engineer of a project where human life hangs in the balance.

It's certainly not the way I ran my projects.

[notmattlythgoe]

Originally Posted by Ether

And my point was that I agreed with you for FRC.

But I sure hope you guys aren't suggesting that should be the "hear no evil, see no evil" attitude of the lead project engineer of a project where human life hangs in the balance.

It's certainly not the way I ran my projects.

I'm absolutely not suggesting that Ether. If you run your projects that way even when human lives don't hang in the balance you'll end up with unhappy customers.

I'm saying that you shouldn't be spending a bunch of extra time optimizing loops and building adaptable code with the assumption that you'll need that optimization or need to adapt it in the future. In most (not all) cases it will be a wast of time and money.

[GeeTwo]

Originally Posted by Ether

And my point was that I agreed with you for FRC.

But I sure hope you guys aren't suggesting that should be the "hear no evil, see no evil" attitude of the lead project engineer of a project where human life hangs in the balance.

It's certainly not the way I ran my projects.

Of course I'm suggesting that a vehicle designed and built on a $4000 budget in six weeks to last about an hour of actual operation should be operated on the open highway ...

... never.

[Ari423]

Originally Posted by GeeTwo

Of course I'm suggesting that a vehicle designed and built on a $4000 budget in six weeks to last about an hour of actual operation should be operated on the open highway ...

... never.

Been there done that! Our wheelchair/go-cart test bot breaks the speed limit.

[evanperryg]

FIRST gives us restrictions on weight and height. The only software restriction we have is the ports we can use and the hardware limitations. I don't think many of us are concerned about the efficiency of our code with the hardware in the roboRIO. A 120 lb limit is a much harder limitation to work with.

As you said, a big reason programming restrictions may be so small is that school programming courses are very low-caliber. the most advanced programming taught in my school is very, very simple VBA, or a little RobotC. The "programming class" is literally just a semester of ALICE, the biggest joke in the programming world. However, most other technical aspects have some sort of advanced class. Physics, autos, woods, any technical class will teach you some amount of mechanical engineering. Schools with PLTW have a rigorous electronics course that goes as far as to explain the workings of FPGAs and other highly integrated digital systems, and most schools have an introduction to electrical class that will get into basic digital logic. Programming? Not so much. The "problem," if you can even consider there to be a problem here, is that most students already have some kind of base for other technical aspects of the robot, but none for programming.

Originally Posted by faust1706

Studies suggest that roughly 40 percent of people aren't even capable of learning to program. Just look at the fizz bizz test. Really good read.

Seems like another reason why FRC programming is generally very rough. If it's inherent that only a limited number of people can program at all, then the fact that FRC is getting lots of people to make code that even works is pretty impressive.

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.

FRC scouting in a nutshell.

Originally Posted by EricH

That's also not its goal. Plain and simple. FRC is aimed at inspiration.

Inspiration through science and technology. OP's prerogative seems to be making the science and technology in FRC more advanced, thereby advancing the inspiration. Advancing programming in students is certainly in line with FIRST's goals, but it has diminishing returns and is much more difficult to implement than other modes of FRC-related inspiration.

Originally Posted by connor.worley

IMO once your code works, you get more diminished returns improving it than you do improving your mechanisms. Efficiency doesn't really matter because there's no requirement to scale.

We've begun to encounter the issue that WPIlib for Java is poorly coded itself. The libraries relating to vision code are particularly messy. This may be why so many teams opt to build their own libraries entirely. Sometimes, optimization is good. But, usually, it isn't all that necessary for FRC because we have a magical beast of processing power called the roboRIO. Since there's no real limit on how inefficient your code can be (unless you try vision code, then good luck) there's usually no reason to optimize your code. Outside of FRC? Yeah, optimization is important. In FRC? Not really, because 2 minutes out of your 2:15 match, your robot is an RC stacking machine, not an autonomous robot.

[Thad House]

Originally Posted by evanperryg

We've begun to encounter the issue that WPIlib for Java is poorly coded itself. The libraries relating to vision code are particularly messy. This may be why so many teams opt to build their own libraries entirely. Sometimes, optimization is good. But, usually, it isn't all that necessary for FRC because we have a magical beast of processing power called the roboRIO. Since there's no real limit on how inefficient your code can be (unless you try vision code, then good luck) there's usually no reason to optimize your code. Outside of FRC? Yeah, optimization is important. In FRC? Not really, because 2 minutes out of your 2:15 match, your robot is an RC stacking machine, not an autonomous robot.

This is a very true fact. You can tell the Java libraries for this year were rushed to get finished in time. Also, some of the hacks needed to interface with the native c++ code for the FPGA just look like they could cause more issues. This is the same thing that causes the vision libraries to be slow. It wastes alot of time marshalling the structs between java and c++, and this looks to be what is so slow. We've been trying to alleviate alot of these issues in the DotNet port, and its easier since working with native code is easier, but its still a challenge trying clean up the code to make it faster, yet keeping it running the same code.

[connor.worley]

Originally Posted by Thad House

This is a very true fact. You can tell the Java libraries for this year were rushed to get finished in time. Also, some of the hacks needed to interface with the native c++ code for the FPGA just look like they could cause more issues. This is the same thing that causes the vision libraries to be slow. It wastes alot of time marshalling the structs between java and c++, and this looks to be what is so slow. We've been trying to alleviate alot of these issues in the DotNet port, and its easier since working with native code is easier, but its still a challenge trying clean up the code to make it faster, yet keeping it running the same code.

I wish there was a middle ground, something that could run natively like C++ but be like Java in the sense that it lacks a lot of the pitfalls C++ learners fall into.

[Thad House]

Originally Posted by connor.worley

I wish there was a middle ground, something that could run natively like C++ but be like Java in the sense that it lacks a lot of the pitfalls C++ learners fall into.

Too bad having a garbage collector and running natively don't work together super nice, without a lot of work. Because that's basically what that would be. I think later this summer, I want to do a runtime shootoff between LV, C++, C#, Java and Python (all the currently working languages) and see how much performance you gain or lose with each one.