View Single Post
  #27   Spotlight this post!  
Unread 15-06-2013, 13:00
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: NI releasing/designing new controller for FRC

CPU Usage:
I am good friends with the programming leaders from three local teams (51, 1718, 2337). All three use LabVIEW and felt severely limited by the compile/download cycle time, especially when making changes between matches, and CPU utilization. I believe all tree hit 100% CPU at some point, all asked me for advice on reducing CPU utilization and were forced to run control loops slower than they wanted, and at least one was unable to run even a single control loop faster than 15ms. To my knowledge, none were using any sort of vision processing on-robot. I do not directly talk to other software team leaders who use LabVIEW, but I've seen similar sentiments on ChiefDelphi over the past two years. The fact that most teams are under 50% shows that most teams aren't doing anything reasonably advanced or using a lot of IO.

Default code:
IFI provided the source for their default code, as well as binaries, and pre-imaged controllers as shipped with it. You could use it as-is or modify it to your needs. Every test chassis we have built using an IFI control system has run default code, and we sometimes modify it to suit the specific chassis (e.g. when we built the DualDrive pre-2011, we implemented a C version of the auto-lift control, but we only modified the lines where relay1 was set to command it from something different). Source-only default code is better than nothing, but the current source-only default code is nowhere near the IFI default code in functionality. With the IFI default code, there was a table that maps all joystick inputs to motors, and all buttons to relays, and one relay and DIO pair were used for the compressor. You could wire it up and test it. The current default source only provides for a tank or arcade drive, even the compressor control isn't enabled by default.

WPIlib:
In 2012, I was able to reduce CPU usage on a 10-PWM robot by ~20% by rewriting a single VI and dependencies (this created Motor Set Simple), out of the hundreds of VI's in the WPIlib only ~10 were touched. Many team programmers personally thanked me at the Championships and via CD that year, as the 20% CPU utilization was significant to their robot. I do not believe that high CPU usage is limited to only a few teams. I think it's quite rampant with teams who control their robot using feedback controls, especially those who don't know how to optimize code to the LabVIEW execution system.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack