Quote:
Originally Posted by dtengineering
While there are a few teams out there that will use every clock cycle that they are given, there are far, FAR more teams out there who are struggling to figure out how to get a limit switch to stop their arm from destroying itself, or how to get their robot to move forward for three seconds and stop in autonomous. "Simple and supported" is likely to benefit more teams than "sophisticated and speedy".
|
EXACTLY!
I've noticed over the years that the authors of the WPIlib seem to continuously pile on features with no concern for library cohesiveness or efficiency, while there are still issues (e.g. the execution cost of writing a motor value or especially a relay value) in the core IO access. We really don't need more features, we really need something that works reliably within the constraints of the 400mhz processor. This dosen't even include all the CAN issues, which I'm sure you've all heard me rant about.
I did some testing a few days before kickoff 2013 and found that the DEFAULT CODE from 2012 (without Network Tables) ran at about
40% CPU utilization on the 4-slot cRio (Back in 2011 I measured the default code to be about 65% CPU utilization on the 8-slot), running a single task that runs at something around 25ms iteration time (nowhere near consistent) and does nothing but set two motors to the values of two joysticks. By comparison, I got around 20-25% utilization running an early
PalLib in a 10ms RT task with <20us average jitter, reading and writing an entire analog and digital card of IO. The processor is capable of far more than is possible due to pure library inefficiency.
Some numbers for efficiency comparison: Our 2012 code ran at ~80% utilization running a 10ms RT task for gun speed control only and ~22ms non-RT task for everything else, while our 2013 code was able to run in a single 10ms RT task with extremely solid timing. Our 2012 code had a LOT of WPIlib mods to improve efficiency to get it to run at all (mid-build season we hit 100% continuous loading before we even merged in about half of the code), including a Set Motor Simple VI which we released on CD. Our 2013 code never encountered any issues using a totally new library, in fact we were under 50% CPU load for almost all of build season.
I talked to a friend of mine who is a programmer on another local team, and they struggled to get their (relatively simple) code to run under 100% CPU utilization, while getting the arm PID controller to run as fast as possible (they eventually got to 15ms by pushing some other tasks as slow as 100ms). 10hz control should never be considered an acceptable solution on a 400mhz system.
I also worked with several other teams with electronics or software issues during various events, and I was amazed how
s l o w the compile/download process STILL is, it's now quite a few minutes. I can do a full build of Chrysler PCM software (1.85 million lines, 1.3million of code) in under 20 minutes on my laptop and flash in under a minute on Nexus or ETK. If it takes 5 minutes to compile a team project with ~15 team VI's and another few minutes to download, on 100mbit Ethernet, we've got a
SERIOUS problem.
I see it all happening again with the new Athena controller. I really shouldn't say a lot about it, but IMHO NI/Athena team really don't know what's important to the vast majority of teams, and they keep focusing on the expansion possibilities that <5% of teams will think about using. CTRE gets it though, their solutions are fantastic, simple, efficient, and light.