[Greg McKaskle]

I didn't look at the code yet, but I'll try to answer some of your questions.

Normal for default code is somewhere around 15% to 25% depending on PWM or CAN, the number of sensors and actuators you are updating in teleOp or a fast periodic task, and how many variables you are publishing.

If you have panels open, they also take CPU to send the updates the debug panel.

The first thing I'd do is build an EXE, deploy and run as startup and use the DS to see what the numbers are as you use the robot in TeleOp and other modes. If you want to see more detail, you can connect to the roboRIO web page and scroll down the screen and you will see detailed CPU numbers.

If they seem high, slow down or disable vision to isolate it from the rest of the robot. Personally, I think vision on the roboRIO is not that bad, but running it on the dashboard is a fine solution too.

Global variables make it quite easy to have a race condition, but I wouldn't pin them as a common source of performance problems. They are atomic, meaning the a mutex is needed, but I wouldn't describe that as a windows call to set priorities. Again, once vision is removed, you can more clearly see what remains.

Common problems are ... running loops faster than needed (which includes no wait at all), calling CAN nodes inside the loop when they only need to be set once, setting a NT variable more often than needed, doing excessive logging or print message reporting in a loop, etc. Vision is typically slow because the image is too big.

Greg McKaskle