NI releasing/designing new controller for FRC

[Jim Giacchi]

In 2001 as a (High School) Sophomore I decided to teach myself the control system. I took home the new system with a motor and a battery and withing an hour had everything setup using radios, to make the motor spin back and forth. Latter that season I wrote the code for the robot because no one else wanted to and did so by downloading and installing the several megabyte program (I'm pretty sure I may have even copied it on a floppy disk, yes I am that old, I also built my robots using candle light and hot wax burns!!!).

In 2009 - 2010 as a graduated and employed Mechanical Engineer who works everyday on robots I attempted, and I stress attempted to get the control system to work. I failed miserably, giving up in frustration and turning it back over to the electrical advisor telling him to fix it because I just didn't care anymore.

The funny thing is that our robots are the same complexity as what I did in 2001, they are no more complicated, but in order to get them up and running the control system is orders of magnitude more complicated and the compiler takes multiple DVDs (Thats gigabytes, with a big old capital G) God help us when our computer crashed last year halfway through the season, took the students and mentor over a week to get it back up and fully updated.

So basically what I am saying is Please.... Please I beg you and wholeheartedly agree with the others who have posted that it needs to be less complicated and easier to setup. The metric should be, can a student get this running on their own. I understand that they may not be, can the student get this to use a camera, pick out a shape and have the robot do a backflip frisbee throw into the top goal in autonomous, but a student should within an afterschool meeting get a robot to drive from start to finish. Right now the system is not even close to that.

Spending time troubleshooting something this complicated always eats away at the fun I have working on this and I have longed for the days of that beautiful black IFI box, oh how i miss thee (and it's not the IFI part, it's the simplicity)

Thanks for reading my book of a post,
Jim

[apalrd]

Originally Posted by Jim Giacchi

The funny thing is that our robots are the same complexity as what I did in 2001, they are no more complicated, but in order to get them up and running the control system is orders of magnitude more complicated

Interesting analogy.

Our 2001 robot ran two PI controllers, each had 2 potentiometers and a single motor (it actuated a complex cable/spring driven linkage so it switched sensor part way through the travel), plus an auto bridge balance program. All of this ran in 63 bytes of variable space on a BASIC Stamp, with code in PBASIC, in a 26ms task. (authors note: The linkage claws on the 2001 robot are some of the coolest things I have ever seen)

Our 2013 robot ran one PI controller, with one potentiometer, and several state machines. Autonomous has no closed-loop controls, just thresholds and sequences. Granted, we use interpolation tables (which include For loops, not entirely lightweight) and floating-point math, but we're running a 10ms task on a 400mhz PowerPC and using more than half of the bandwidth.

Both robots were world finalists. The 2013 robot still has more feedback controls than most of FRC. FRC does NOT need more processing power.

It takes our 2013 robot a long time to boot up and find the field, and builds take a minute or so. The 2001 control system would have booted and established a radio link in 5s, under 1s on tether (~200ms I've heard).

Speaking of boot times, I've worked on programs which mandate a 250ms boot time from power applied to ready to synchronize and start, and can do a soft reset (module stops executing code and starts from the beginning without powering down) without stalling the engine. These programs run over a million lines of C code on a processor that runs half as fast as the cRio, with control loops at 1khz, on a PowerPC core similar to the cRio.

I've heard VxWorks boots in a few seconds on the cRio, why does it take soo long for user code to come up and init? I know some of the init code is even more inefficient than the runtime code (Encoder4x does a typedef conversion of the three lines A/B/Index 12 times or more at init), but it's still 30s or so before user code even begins to init.

[apples000]

Does anybody know where the extra time is actually coming from?