Random Signal

[CRLS97]

Hey CD,

When I enable our robot,

every 15-20seconds or so (its random), our Drive motor controllers (victors) receive a signal and the robot makes a click noise (from the motor getting that tiny signal). Sometimes it happens when I slow down our shooter and bring it to a stop and for some reason the drive motors get a signal. I've looked through the code many times and there is nothing controlling PWM 1 and 2 where are drive controllers are connected to but Teleop.vi where the default arcade drive is. Any idea why these victors would detect some itsy signal every now and then?

I put a probe while running it labview on the joystick axis values and even sometimes when its 0, it'll still do a jerk without actually moving the robot from its place.

Any help appreciated!

[slijin]

Can you describe what exactly this signal is? (i.e. how do the Victors respond, what color does the LED turn)

I assume you've checked your DB37 for proper assembly, but if not, check that immediately. Make sure to check for shorts - is your cRIO (and camera, if you have one) electrically isolated from the frame?

[CRLS97]

^ yes, everything is electrically isolated from the frame. I checked this a few times and also did the ground test on the robot frame (in as segments as I could).

Also regarding the DB37 cable, we decided to use the round one from previous years.

I don't remember the exact patter the LED signal gives since I won't have access to the bot til tomorrow, but from what I do remember, the blink pattern changes to exactly how it would be if I was to actually drive the robot with the joystick.

[slijin]

Originally Posted by CRLS97

Also regarding the DB37 cable, we decided to use the round one from previous years.

Bizarrely, FRC has managed to find ribbon cables that violate the laws of physics; some people have noted differences in performance between the old cable and the new one. While I can't imagine why this happens, you might want to try swapping out the cable with the new one to see if that solves your problem.

Originally Posted by CRLS97

I don't remember the exact patter the LED signal gives since I won't have access to the bot til tomorrow, but from what I do remember, the blink pattern changes to exactly how it would be if I was to actually drive the robot with the joystick.

There should be no "blinking" whatsoever if you're providing a signal to your controller; I assume you mean the color response. Check to see if it's consistently red, consistently green, or a mix of the both. (or does it turn the LED off?)

[Joe Ross]

Are there any errors reported in the diagnostics tab of the driver station?

[CRLS97]

Thanks to everyone who has responded. I will try the new DB37 cable tomorrow and check if the problem persists (already fixed the cable).

@Joe Ross, the only error we are receiving in the DS is the -44061 re: the loop containing robotdrive not running fast enough/being starved

[Tom Line]

Originally Posted by CRLS97

Thanks to everyone who has responded. I will try the new DB37 cable tomorrow and check if the problem persists (already fixed the cable).

@Joe Ross, the only error we are receiving in the DS is the -44061 re: the loop containing robotdrive not running fast enough/being starved

That exact error has caused us to have the symptoms you are seeing. Try to determine why you are getting it. Are you developing on the driver station? Running on a busy network? Not deploying your code permanently?

[CRLS97]

Originally Posted by Tom Line

That exact error has caused us to have the symptoms you are seeing. Try to determine why you are getting it. Are you developing on the driver station? Running on a busy network? Not deploying your code permanently?

The developing is being done on the same computer as the driver station being used to control, but it's not the classmate-PC from KOP. The network has only the robot and computer connected to it and the problem occurs when the code is run from labview for debugging AND when it is permanently built and deployed.

Could it be that the lag gives it that quick little signal?

I'm also thinking it could be the default camera Vision code. I'll try disabling vision tomorrow and see if the error goes away. If it does, does anyone think it would be worth disabling the vision loop overall, except when I deliberately want to use it (ie. case structure w/ joystick button; it's being used for auto-alignment w/ hoop)?

[slijin]

Originally Posted by CRLS97

I'm also thinking it could be the default camera Vision code. I'll try disabling vision tomorrow and see if the error goes away. If it does, does anyone think it would be worth disabling the vision loop overall, except when I deliberately want to use it (ie. case structure w/ joystick button; it's being used for auto-alignment w/ hoop)?

Just to toss this out there (I'm not positive if this is pertinent to the issue at hand), but we recently ran into memory leak issues, despite that we use Java, whilst running camera code. We eventually determined that the reason was because the NIvision libraries are written in C++, not Java, so we had to account for that.

[flargen507]

First off, are you using PWM?
If so, our team had a similar issue where, when enabled and recieving no signal from the joystick, it will randomly move the motors a little bit. It looks like the robot is twitching. If this is what is happening to you, go into your code and make sure there are no slots on the Digital Sidecar that are not hooked up (e.g. if you are trying to send values to PWM 7, which has nothing plugged into it.) When you get an active pin with no wire, it builds up a small charge on the Digital Sidecar, which then randomly discharges, and is interpreted by the motor controller as a very small signal.