Robot Twitch

[Greg McKaskle]

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.

Greg McKaskle

[Chris Hibner]

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:

1) 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.

2) 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.)

[Greg McKaskle]

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.

Greg McKaskle

[tipsmiller]

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.

[PAR_WIG1350]

Originally Posted by Chris Hibner

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:

1) 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.

2) 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.)

Assuming we don't use solenoids in the code, would not having the 24volt DIO module (the solenoid module) in the cRIO cause this issue?

[DominickC]

Originally Posted by PAR_WIG1350

Assuming we don't use solenoids in the code, would not having the 24volt DIO module (the solenoid module) in the cRIO cause this issue?

Nope. We've been flying without this module for a good two weeks with no issues.

[Chris Hibner]

Originally Posted by PAR_WIG1350

Assuming we don't use solenoids in the code, would not having the 24volt DIO module (the solenoid module) in the cRIO cause this issue?

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.

[PAR_WIG1350]

Originally Posted by Chris Hibner

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.

Will the imaging tool allow you to image the cRIO without the module in place? if so, that might be what happened.

[Greg McKaskle]

I am pretty sure the imaging tool just reminds you if a module is missing or in the wrong slot.

Greg McKaskle