Worried about high CPU usage in CRIO

[DominickC]

Originally Posted by Greg McKaskle

I think what you are trying to do is set the output, then wait 500ms, and then restore the output. Consider using a sequence structure. Put the delay in the center frame and have the outer two update the outputs.

Greg McKaskle

Exactly. I'll throw something together and post an image of it.

EDIT - Here's what I've got. How can I clean this up to run smoother, if at all possible?

[Ether]

Originally Posted by DominickC

I did not intend for my loops to be blocking (at least not in this situation). How could I write a value (such as a motor output) then rewrite a value 500ms later without it becoming a blocking loop?

blocking and busy waiting (spinning) jargon explained:

http://en.wikipedia.org/wiki/Busy_waiting

http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf

[Greg McKaskle]

That is a very minimal way to update the I/O twice with a delay in between. As mentioned earlier, the only issue is that if you start that in a loop that runs at 10Hz, this will pause it and may interfere with other operations you want the same loop to control.

Greg McKaskle

[DominickC]

@Ether - Excuse my misuse of the terminology; running on little sleep while trying to do tasks which require thought is not the best combination! I intend for the majority of my code to be blocking.

@Greg - Great to know I'm now able to strip my code down to the bear essentials to make it run the way I want it.

[DominickC]

If this code is located within Periodic Tasks and runs with a 100ms or even a 50ms delay, will any problems be caused if the code is not finished within 100 or 50ms? This code, along with other stuff, helps the second driver aim and shoot. Everything is tested and is working save the first frame of the Sequence Structure. Sorry for the messy coding in there! It basically squares the bot up with the nearest wall and seeing if the distances fall within an acceptable difference.

[wireties]

Originally Posted by DominickC

I did not intend for my loops to be blocking (at least not in this situation). How could I write a value (such as a motor output) then rewrite a value 500ms later without it becoming a blocking loop?

#include "taskLib.h"
#include "sysLib.h"
....
taskDelay(sysClkRateGet()/2); // wait 0.50 seconds

The WPILib has a delay function in it also, taskDelay is the native vxWorks function.

We send messages from one task to another and block waiting on the messages. For example the task receiving data from the DS sends a message to the motor task telling it the desired velocity. The motor task calculates the PID setpoints then blocks again waiting for another message, consuming no bandwidth. The PID callbacks are running off a timer of course but that is all in the PID classes. It is relatively simple and efficient.

[SuperS_5]

I finally got some time to look into this. My original numbers seem to be off slightly. The graph of my driver station has an extended scale below 0. (I hope that the scale matches the graph.) Disabling various things and even modifying the framework to control the loops, allowed me to bring the CPU utilization down to well below 10%. I tested the default framework, acquiring but not processing images, sending data to the default data to the dashboard, and a bit of extra code only hit 25% CPU utilization on the first frc-cRIO. I did manage to confirm that the dashboard compiling and sending VI was a significant portion of that 25%.

There seems to be a fair amount of CPU left for vision processing.

[Greg McKaskle]

About the scale on the chart. The graph plots are plotted against the scale, so 0 is not the bottom of the black chart area. If you see your red plot go to the bottom of the black plot area, that would be negative, and I'm not sure if that is a good thing for your CPU.

The reason the scales are lifted off the bottom was to leave room for the instrumentation dots. There are four plots below the 0 on the scale, one for the robot mode that the field or DS gave to the robot, and one each for any calls by the code to declare what was run. At least for LV, the framework has VI calls in it to place a dot on the chart each time the teleop code is run, each time the disabled code is run, and each 20ms while the auto is running. This should help identify when robot code doesn't leave auto, or runs auto and tele or other odd combinations during the event, as well as noting when the code doesn't run anything for extended periods (typically caused by large delays inserted into teleop).

Anyway, thanks for verifying.

I looked into why the autonomous is by default higher than the others, and it is caused by RobotDrive not being updated. Not updating for 100ms causes the robot safety override to kick in. No big deal, but it uses the uncaught error mechanism to print the message to the DS. This adds the extra overhead. Next year, we'll hopefully be able to redo the uncaught error stuff to be cheaper, and/or explicitly send the safety message. A properly written auto should never go into safety, at least not until it has run to completion and stops sending motor commands.

Does anyone else seem to see excessive CPU usage in simple code? Is this one still causing anyone issues?

Greg McKaskle

[DominickC]

I did a bit of testing today. I ran some pretty heavy code (2 camera's and gimble control on both, two Gyro's, potentiometer, and three rangefinders, all sensors giving output to the dashboard and being used in automated actions within Autonomous). We were getting about 60% CPU usage in Teleop, and about 75% in Autonomous.

[Chris_Elston]

Originally Posted by Greg McKaskle

Does anyone else seem to see excessive CPU usage in simple code? Is this one still causing anyone issues?

Greg McKaskle

Yes, we still have high CPU usage when we download the "DEFAULT" framework code into a CRIO-I (2009) and a CRIO-I (2010). I ordered a CRIO-II today, I hope to get it next week and see if that helps at all.

I am lost in this thread at this point.

[Greg McKaskle]

The cRIO and cRIO-II are not that different in performance. Kinda like comparing a 2008 and 2010 models of small Toyota pickups.

It is time to debug this specific to your system. I'll be in touch.

Greg McKaskle