| evanperryg |
16-06-2015 16:59 |
Re: On the quality and complexity of software within FRC
Quote:
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.
Quote:
Originally Posted by faust1706
(Post 1486630)
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.
Quote:
Originally Posted by gblake
(Post 1486885)
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.
Quote:
Originally Posted by EricH
(Post 1486898)
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.
Quote:
Originally Posted by connor.worley
(Post 1486573)
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. |
