[JohnGilb]

Today I made use of a few LabVIEW utilities - the real time manager (which shows CPU and memory usage) and the profiler. This was because I noticed our robot running slowly when vision was enabled (runs smoothly and responsively unless we're doing image processing), and figured something was being pushed to a limit.

1) The cRIO, running the default competition code (out of the box), uses about 60% of it's available CPU time. Understandable - there's a lot of stuff going on just to get things running

2) Our code, which uses motors/sensors/relays/solenoids/servos/PID pushes this up to 100%. I can see why adding vision on top of that would slow things down.

I expected we might have to simplify some of our control code in order to accomodate more processing. However, I then ran the profiler. Keep in mind that the profiler itself has a pretty severe performance impact, so the following information isn't guaranteed to be 100% accurate.

After running the profiler, I examined the code running in Periodic Tasks - for our team, this vi contains all the logic related to sensing (except camera) or moving anything, so it's the workhorse of our code.

1) The robot spent 60% of its Periodic Tasks time in the WPI library VI's that set speed, do safety checks on motors, set the state of solenoids, do safety checks on solenoids, set relays, etc...

2) Even though we were running PID and other operations all over the place, these operations were chump change compared to setting a motor speed.

What is going on here? Are other teams seeing this as well? Is there a way to mitigate this?