Symptoms: Every once and a while (especially after the robot has been running for a while) the robot (usually the drivetrain) will twitch. The drivetrain doesn’t really go anywhere but this freaks some people out.
I first though that this was some sort of drivetrain code problem but I couldn’t find anything that might cause this?
My current diagnosis is that the cRIO is being bogged down with processing tasks (we are running encoder PID in periodic tasks in a 50ms Timed Loop). I would have initially suspected that the cRIO could handle this OK, but when I put the loop in a diagram disabled structure, the problem stops.
Another symptom is that we sometimes have laggy controls. Generally, at the beginning of build sessions, the robot performs fine (no latency problems), but then as we progress throughout the day, the delay gets greater and greater until everyone gets frustrated and leaves). Why does this happen?
On your driver station, when you go to charts, what is your CPU percent when teleop is enabled? Is it 100%? Then yes, you probabilistic are getting a left and right drive loop not running fast enough error in your messages window. recently we went through a bunch of this.
If you say no to your CPU percent, then double check your I/O cable between your CRIO and digital side card. (we had a badly crimped one).
And finally, we have had bad PWM cables. (we make our own) but discovered that they needed to be made little better that caused glitchy controls on the drive speed controllers.
we have seen the same thing one our issues is a lot of motors running at the same time we have found if the load hits 100% for to long it will twitch. Change up your code so the stuff isnt running all the time
To get a better idea about what sort of twitch, let’s break it down. Is it A we are talking about, or B?
A.) When sitting still, the motors twitch – tighten the chain for a fraction of a second, then relax again.
B.) When driving at a constant speed, the motors stutter – the robot slows or stops, or the robot has a twitch as if the motors dropped to zero or went in reverse for a fraction of a second.
As for the delay, is this wireless, wired, or both? Is the lag more than a second or less?
When the lag is present, try reboot just one of the elements to see if goes away. For instance, just stop and restart the driver station and see it goes away. Then reboot the entire driver station computer. Test it. Reboot the router, test. Reboot the cRIO, test.
One iteration through the test doesn’t necessarily identify the issue, but it will often eliminate a good number of elements, and the next round of tests can get closer to finding a solution or workaround.
Additionally, flip to the Charts tab to see the round-trip time and lost packets and compare a laggy and nonlaggy chart to see if it correlates.
If you have code that seems to drive the cpu to 100%, post it or a picture of it and we can give suggestions.
We had a similar issue where the robot twitched every now and then (sitting still - type A) and there seemed to be a time delay from all of the operator inputs to when the robot would start moving.
We put ElapsedTimes.vi into the PeriodTasks loops and in Teleop. We found out that our fast loop and teleop were taking about 250 ms to complete!
At first, we couldn’t figure out what the problem was. Our code was bigger than previous years, but we didn’t think by THAT much. We don’t use sub-loops. We had no idea what could be blocking the code and taking up so much time.
Then we figured it out - we had an analog input that was configured for an incorrect channel. That caused an error, which for some reason bogs down the entire system. We allocated it to the right channel and voila, our loop times bacame exactly what they should be. I’ve since confirmed this behavior with a missing solenoid card. It seems that any misallocation causes the system to slow to a near crawl.
So, there are 2 things to take from this:
Coming out of Begin.vi, check your error output (assuming you have all of the errors from the Open blocks going into a “MergeErrors” vi). Make sure you have no errors. If so, fix them - it just might solve your problem.
Greg: can NI do anything about this? It seems like bad failure mode that if a piece of hardware becomes dislodged or someone fat-fingers a channel number, it causes all of the code to become blocked for 200+ ms. Please don’t take this as me being a big complainer - I think NI has done a fantastic job and much kudos to all of you for always being helpful.
(BTW: when it happened to us, we had two analog devices allocated to the same channel (copy and paste - forgot to change the channel #). I noticed it again when we were doing some code development on a second cRIO: our code uses solenoids but the second cRIO did not have a solenoid card installed.)
I don’t mind good complaints – especially when I agree with you.
The issue is that we are using an uncommonly used hook to catch unwired errors and routing them to the DS. This doesn’t take the full 200ms, but I think it takes 15 or 20ms, ruining your control rate.
We tracked down the issue a few years ago and I didn’t have the foresight to get it fixed for 2011. I looked again this year for a workaround and couldn’t find one. Fortunately, I know the guy who can fix it and he is now on the FRC team, so I think it will get fixed.
For more details on the issue, before LV can run code it has to reserve it. It visits all called subVIs and other resources that it needs, reserves them, and ensures that everything is actually able to run. Then it runs the handler once, then it unreserved it, which unreserves all of the subVIs. The algorithm is typicall run once when the app starts up, but the hook for catching errors does this each time the error occurs – not really the right hook for what we are doing. The hook was intended to log to disk or put up a dialog and we are using it in a situation where it keeps going, so the performance is more important.
My team was having the same issue. Our programmers had written code and initialized sensors which were not yet connected on the robot. What we saw happening was that the digital sidecar would poll the pins that the sensor was supposed to be attached to. When the sensors weren’t there, it was releasing the charge it had built up through the other ports.
It won’t be an issue if you don’t image your cRIO without the solenoid module in place.
Also, I don’t think it will be an issue as long as you don’t OPEN a solenoid. The issue appears to be if you OPEN an input or output, and either the input/output hardware doesn’t exist, OR you double allocate something.