[apalrd]

I don't think I've ever done anything in FRC that I couldn't do on a Vex Cortex, aside from stream video back to the driver station laptop. In fact, I've run Cortex code has run as fast as 100hz without complaining about CPU loading, and under RobotC (a terrible bytecode language with all the inefficiencies of Java and none of the benefits that dosn't even support the C language really at all) I was able to run all of my code in 2ms (measuring the time it took the task to execute).

I did come a bit short on IO (granted I used 5 LED's with individual GPIO pins), but I managed to live with the 12 DIO and 8 analog and 10 PWM. I think an extra two of each would be nice for FRC, but it's perfect for Vex robots. It's also got I2C and two UART ports.

I would agree that, the peak performance of the roboRIO vs the Cortex provides more cost efficiency. But for 99% of teams, the Cortex would be just fine (in fact, way better because it's so easy to setup and dosen't require default code), so the doubled cost dosn't provide doubled benefit, or even any benefit to them. And then there are the 5% who insist vision procesing is important (it has not been important to me yet), and the 1% who might utilize the full benefits of the roboRIO and implement a good onboard vision system without compromizing their RT controls.

We're still not doing anything controls-wise that we couldn't have done on the 2008 IFI controller. We now use floating point math, and LabVIEW, and other useful code features to do it, but we haven't found a challange which we simply couldn't do previously. Our development times have stayed about the same, our calibration efficiency is up a bit during online calibration-heavy activity but way way down for short between-match changes. We've also spent a lot more money on system components (cRios, more cRios, tons of digital sidecars, analog modules, solenoid modules, radios, more radios, more radios, ...) than with that system.

In fact, I would argue that our code has gotten more complicated because of all the stuff we've had to do to get development and calibration times down. We wrote Beescript because it took too long to write new autonomous code and deploy it, especially in competition, and would never have done so (and possibly had more flexible autonomous modes using real programming features like math and if statements) if the compile and download times were short, or we could modify calibrations without rebuilding.

We've thought a lot about implementing a calibration system that reads cal files and such, but we can't get the design to a point where we can retain the current online debugging, cal storage, and efficiency. And the more code we write, the longer the compile times get. I know I can't get a system with the flexibility I want and expect, while retaining all of the performance I expect, and it's incredibly frustrating to see systems in the real world operate on far lower resources running far more application code (running way faster) with good development and calibration tools that try hard to streamline and optimize the process as much as possible, and can do it efficiently with such little overhead, while we're running throwing more CPU speed and libraries at the problem and still nowhere near the performance (on all fronts - RT performance, boot times, development times and overhead, calibration efficiency, etc.).