When we enable our robot the code seems to run fine for a couple of seconds then it becomes twitchy and/or laggy. What I mean by twitchy is the light on the motor controllers flicker periodically and the motors controlled by joystick buttons do not respond quickly. Also, the CPU usage on the DS graph changes from 65% to 100% at the same time that the robot seems to become twitchy. In previous years we have had much larger code without problem.
In addition, when I put probes in the teleop vi the probes indicate that the code is running perfectly. However, the motors on the robot do not.
I have included a picture of our teleop code. Any ideas?
I don’t think the behavior has much to do with the teleop code. To see how often it is being called, you may want to put the Elapsed Times VI into teleop. You can find it in the support folder in your project window.
I think the twitch is likely caused by the robot drive motors being updated less than every 100ms. The next issue is to find the code that runs so often or takes so long that it slows down teleop. One place to look is vision, the other is periodic tasks. Finally, Since I can’t see the code run in the other case of the button 5 switch, it could be that it is sleeping for a long time and causing the issue, but I suspect this isn’t the case.
Your problem could also be caused by unhandled errors within your code - this often takes up a lot of CPU resources (the watchpuppies are a good example of this). On your driver station, go to the “Diagnostics” tab and look at the errors. If it’s telling you about an error somewhere in your code, see how fixing it affects your robot response times.
Thanks for the help. I’m not at the shop to hook up to the test bot. I’ll run the teleop code with the Elapsed time VI tomorrow. What should I be looking for? If it is not calling the teleop vi fast/slow enough what else should I look for?
I’d check that all your refnums all match and are correct. That’s a common error. And I’d check that your safety isn’t tripping (like Greg suggested). Check for code that takes a long time to execute (one iteration of your Teleop VI should take ~20 ms, the amount of time it takes for a new DS packet to reach the robot).
And once you get access to your robot, if there’s an error, the error message should tell you exactly what is wrong and which VI it’s located in.
I don’t think your bridge manipulator motor is going to work the way you want it to. You’re setting it in two places, and the second one (on the right) is going to win.
Actually, we can’t know which one will win: They are not dependent on each other, since the motor ref branches before the set vis. In the purist analysis, either one can fire first and their firing order could be “randomly” re-chosen each iteration. In reality, the optimizer might clump those two commands in an arbitrary order determined at compile time. The “winning” set will still be “randomly” chosen as the fpga timing interacts with the CPU timing, though one will be heavily favored over the other.
Regardless, the result will be a twitchy bridge manipulator. It will toggle between the two set commands unpredictably.
My prediction is that you actually have two problems: The twitchiness is caused by the two set commands racing eachother, and your CPU is being pegged to 100% by a separate error (likely a while loop with no wait in it).
Oops, you’re right. I thought the device reference went from the output of one to the input of the other. I guess I was distracted by the odd placing of the functions, with a bunch of right-to-left wires running along with the left-to-right ones.
