Labview code overwhelming cRIO

[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?

[Mark McLeod]

You should design your code to probably use no greater than 80% of the available cRIO CPU.
That leaves a little room for future code modifications and we really shouldn't be pushing the maximum. Operating systems need some space too, to be efficent.

We noticed our cRIO CPU utilization getting up towards 100% too and purposely drove it back down to around 55%. It takes a little attention and sometimes measurements of individual loops.

We designed our code to hit the motors and other actuators only when they need changing, and choose to disable the Safety VIs to eliminate those unnecessary repetitive actions.

Another common issue I've seen is unrestricted loops.
By now most of us know that loops, especially infinite ones, need to be throttled down a bit by a Wait vi just to allow other parallel tasks time to run.
What many don't realize is that the Wait should be as long as practical. I've seen quite a few dutiful Waits that in use actually take less time than the execution of complicated code inside the loop itself. What that means is the loop is really unconstrained and will proceed to suck the life out of your cRIO.

Any errors displayed on the Diagnostics tab should be quickly dealt with as well.
Error processing drastically consumes available CPU and slows our programs.
Eliminate any and all errors as soon as possible.

[theprgramerdude]

Do you know if these CPU-spiking actions are unique to the Labview code, or do similar functions in C++/Java also cause huge CPU spikes? Personally, I have never measured usage with the utilities, so I have no background knowledge.

[JohnGilb]

Mark,

Out of curiosity, what sort of delay do you have on your main drive system? We've been using 20ms (50Hz), as we were concerned that longer delays would reduce the effectiveness of a PID system.

[Mark McLeod]

For the main drive motors we use the same as everyone should, 50Hz, to match the packet rate from the Driver Station. So the robot responds and makes changes when commands can change, as quickly as it should. If your Telop is quick and light, and you aren't pushing the cRIO limits elsewhere, then the Safety vi's are probably okay.
For most drive systems, especially at the low average speeds we tend to experience and the inertia in the system, applying the PID results any faster probably isn't necessary.
Take advantage of the high speed FPGA capabilities to accumulate sensor readings and just sample them when necessary. That kind of stuff.

Where we save the most is probably in processing sequenced actions or revisiting sensor readings.
Or matching the revisit time of actions to the real motor or mechanism response. There are a lot of actions that really don't happen that quickly. Window motors don't tend to get away from you. For instance, calculate how far a window motor powered mechanism will travel in 10ms and decide if you really need to know that fast or if you can slack off a bit in favor of a higher revisit rate for your 2000rpm CIM-powered flywheel.

Do you need to react to the push of a button within 10ms or is 100ms enough to match human responses?
Limit switches you probably want to be quicker on, but a button that makes LEDs on your robot flash can usually wait half a second to be checked.
A lot of cRIO time can get wasted just constantly checking a control that gets used maybe twice in two minutes.

Think in terms of software design tradeoffs.
Some things have to be 50Hz, for others 10Hz is plenty.

[JohnGilb]

Thanks Mark - after implementing your changes, our resting load was reduced to ~65-70%. This is a huge improvement, and gives us some breathing room to including some vision processing.

Thanks again!

[gnunes]

Originally Posted by JohnGilb

This is a huge improvement, and gives us some breathing room to including some vision processing.

With the D-Link radio, you can move all your image processing to the PC (unless maybe you are sticking with the Classmate...). We plug the camera directly into the D-Link, obtain and process the images on our laptop, and just sent a few numbers back to the cRIO via UDP port 1130. Works great!