Misbehaving encoders

[nathanww]

Hey guys,
We've been trying to retrofit our Lunacy bot with quadrature encoders so that we can use it for some off-season projects. Unfortunately, the encoders are not cooperating with our plans. Disconnected from the robot, we can apparently read the shift in values from the encoder--but the robot's program doesn't seem capable of reading them(we checked to make sure we were using the right ports, actually starting the encoders, etc)

So, basically what we have is a situation where the robot's digital inputs are not reading the shifts. Our theory is that both the encoder HIGH and the encoder LOW signals are falling on the same side of the HIGH/LOW division when the robot reads it, so it can't pick up the pulse modulation. Does this make sense? Or is there something else that could cause this?

[Jared Russell]

Hey guys,
We've been trying to retrofit our Lunacy bot with quadrature encoders so that we can use it for some off-season projects. Unfortunately, the encoders are not cooperating with our plans. Disconnected from the robot, we can apparently read the shift in values from the encoder--but the robot's program doesn't seem capable of reading them(we checked to make sure we were using the right ports, actually starting the encoders, etc)

So, basically what we have is a situation where the robot's digital inputs are not reading the shifts. Our theory is that both the encoder HIGH and the encoder LOW signals are falling on the same side of the HIGH/LOW division when the robot reads it, so it can't pick up the pulse modulation. Does this make sense? Or is there something else that could cause this?

The theory you are describing (that you aren't reading the encoders fast enough and that they are going HIGH->LOW->HIGH so fast you don't see the "LOW" part) is known as aliasing. The Shannon-Nyquist Theorem basically states that you need to sample at least twice as fast as the highest frequency in your input in order not to miss anything. However, I don't think that's the case here, as the cRIO reads the encoder signal at many tens of KHz; you'd have to be spinning your encoder at a blazing speed to hit that.

It's more likely that it's a wiring or programming problem.

What kind of encoder are you using?

How is it currently wired?

Are you using LabView or C++, and what encoder code are you using?

[Eugene Fang]

The theory you are describing (that you aren't reading the encoders fast enough and that they are going HIGH->LOW->HIGH so fast you don't see the "LOW" part) is known as aliasing. The Shannon-Nyquist Theorem basically states that you need to sample at least twice as fast as the highest frequency in your input in order not to miss anything. However, I don't think that's the case here, as the cRIO reads the encoder signal at many tens of KHz; you'd have to be spinning your encoder at a blazing speed to hit that.

What if you're using VEX encoders, which, according to IFI's website, can only count properly up to 1000 rpm (it might be 1000 clicks per second, i can't remember off the top of my head. either way, there seems to be a limit)

[Jared Russell]

What if you're using VEX encoders, which, according to IFI's website, can only count properly up to 1000 rpm (it might be 1000 clicks per second, i can't remember off the top of my head. either way, there seems to be a limit)

That's a good point - many types of encoders (particularly those with bearings, and especially sleeve bearings) can fail mechanically long before they hit the Nyquist rate. Or an encoder might have additional filtering circuitry that rejects pulses that are too short (the wording of the Vex encoder Inventor's guide implies that this is the case).

But if hand-turning an encoder on the benchtop produces a square wave and hand-turning the encoder at a similar speed with the cRIO does not, this probably isn't the issue.

[nathanww]

The theory you are describing (that you aren't reading the encoders fast enough and that they are going HIGH->LOW->HIGH so fast you don't see the "LOW" part) is known as aliasing.

Actually, the theory that I was referring to was that there wasn't enough difference between the voltage that the encoder sends for HIGH and what it sends for LOW. When we looked at this, it didn't really seem to actually touch either extreme of max/min--so we thought that it might be possible that the control system wasn't seeing these small differences because both the HIGH and LOW fall into what it considers HIGH.



What kind of encoder are you using?

It's the US digital kit encoder


How is it currently wired?

Each encoder's A and B outputs are wired to the signal in on the digital sidecar. We also use the power and ground on one PWM for those connections on the encoder
[/quote]


Are you using LabView or C++, and what encoder code are you using?


We're using C++, which is



Encoder *encoder1;
***more declarations******
encoder1=new Encoder(2,3,false,Encoder::k4X);
*****more config stuff********
void RobotInit(void) {
encoder1->Start();
encoder1->SetDistancePerPulse(100); //values are completely arbitary
encoder1->SetMinRate(1);
*****the rest of the init, now in the teleop periodic*****

printf("encoder1=%d",encoder1->Get());
if (encoder1->GetStopped()) {
printf("encoder stopped");
}

[Jared Russell]

Do you remember the exact voltages you were seeing for high and low? They should be close (within a volt, for sure) to 5V and 0V, respectively. Are you sure you saw the change on *both* encoder outputs?

Your code looks good. You could try changing the decoding type to Encoder::k1X and seeing if that changes anything. Then try hot swapping DI 2 and 3 and seeing if you get anything (this forces the cRIO to only examine one channel at a time).

[AustinSchuh]

That's a good point - many types of encoders (particularly those with bearings, and especially sleeve bearings) can fail mechanically long before they hit the Nyquist rate.

I don't have the specs for the digital input module on me, but I seem to remember that a 256 count encoder attached directly to a CIM was about at the limit. 971 had a 64 count/rev encoder attached to the cim output shaft, and that worked fine. I think the cRIO module has a rated refresh rate of something around 7 us, which would translate to 14,290 samples/second. I ran the math ~6 months ago...

[Steve_Alaniz]

Actually, the theory that I was referring to was that there wasn't enough difference between the voltage that the encoder sends for HIGH and what it sends for LOW. When we looked at this, it didn't really seem to actually touch either extreme of max/min--so we thought that it might be possible that the control system wasn't seeing these small differences because both the HIGH and LOW fall into what it considers HIGH.



It's the US digital kit encoder


Each encoder's A and B outputs are wired to the signal in on the digital sidecar. We also use the power and ground on one PWM for those connections on the encoder




[/QUOTE]

First of all, the encoders will send a 0 - 5 V or NEARLY a 0-5V square wave from both A and B channels. So there's no way that theory could be correct... unless you made a mistake building the quad system or the US digital unit is defective. Since you didn't build it and US Digital is primo stuff, both are unlikely. Although I DID have my very first failed USDigital device this year.
You need an o'scope to properly look at the signals for A and B and as I said, they SHOULD be a square wave 90 degrees out of phase with each other. ( At VERY high speeds there might not be time for the signal to drop to 0 or rise to 5 but you didn't say anything that might make me think that is a possibility.)
You said you are using a PWM for power to the encoders? Do you have a jumper on the 6V enable pins for that PWM? Sorry if that seems rudimentary but it a simple mistake that even I... <ahem> .. could POSSIBLY make... in a bizarre set of circumstances... not actually admitting anything you understand.

Steve

[Tom Line]

"Why aren't the camera servo's moving?"

2 hours of trouble shooting later: "Guys.... we don't have 5 volt power to the servos. Anyone want to guess why?" :o

[NickE]

Each encoder's A and B outputs are wired to the signal in on the digital sidecar. We also use the power and ground on one PWM for those connections on the encoderThe A and B outputs are wired to two separate digital inputs, correct?

[Steve_Alaniz]

You said you are using a PWM for power to the encoders? Do you have a jumper on the 6V enable pins for that PWM?

Steve


Oh wait... scratch that... you said PWM but you probably meant GPIO ports. (I just remembered PWMs are output ports only.) GPIOs have 5V continuously available. So you should have 5V present and they have internal 5V pull up resistors, so the signal should be clean.
Unless you damaged the encoder wheel installing it, this suspiciously looks like a software glitch. Still before doing any software stuff, you really need to look at the "signal in" levels with an o'scope or in a pinch a multimeter will work ( just to prove you get level changes).
I need to read these posts with greater care.

Steve

[Jared Russell]

When you are powering your encoder from your cRIO you should see the red LED inside the encoder housing turn on. Make sure that this is the case.

[Alan Anderson]

Each encoder's A and B outputs are wired to the signal in on the digital sidecar. We also use the power and ground on one PWM for those connections on the encoder

The encoder has four connections. Can you detail precisely where each of those connections is going? I hope you aren't really using PWM outputs for power.

How do you know the robot isn't reading the encoder properly?


printf("encoder1=%d",encoder1->Get());


I didn't use C++ this season, and I don't have the documentation handy, so I don't know if %d is what you want. Doesn't the Get() method return a long integer?

[Jared Russell]

Yes, Get() returns an INT32.

[nathanww]

The encoder has four connections. Can you detail precisely where each of those connections is going? I hope you aren't really using PWM outputs for power.

How do you know the robot isn't reading the encoder properly?

"PWM" here is referring to the cable we've spliced to, not the output on the digital sidecar

I sketched out a diagram of eaxctly how it's set up and attached it.

We know the robot isn't reading the encoder because the value from Get() never changes, and the robot always reports that it is stopped, even when moving


When you are powering your encoder from your cRIO you should see the red LED inside the encoder housing turn on. Make sure that this is the case.
Yep--we saw this, and when we checked it with a multimeter(we don't have an o-scope), we saw fluctuation in values--it just seems that the robot isn't interpreting it correctly.

[Jared Russell]

"PWM" here is referring to the cable we've spliced to, not the output on the digital sidecar

I sketched out a diagram of eaxctly how it's set up and attached it.

We know the robot isn't reading the encoder because the value from Get() never changes, and the robot always reports that it is stopped, even when moving


Yep--we saw this, and when we checked it with a multimeter(we don't have an o-scope), we saw fluctuation in values--it just seems that the robot isn't interpreting it correctly.

That is a sweet MS Paint sketch :)

Everything looks correct to me. So the problem is either really obscure, or right under our noses.

More ideas:

1. Are you sure you are using the correct port on the cRIO for the sidecar? Are you sure the sidecar is fully powered (12V power from the main breaker is necessary)?

2. Try commenting out the encoder code and instead creating DigitalInputs on the same two DIO lines. Call Get() on that and turn the encoder to make sure that you can at least see the two lines fluctuating.

3. Since you have a multimeter, verify that you are getting (close to) 0V and 5V on the Ch A and Ch B outputs as you rotate the powered encoder.

[Steve_Alaniz]

"PWM" here is referring to the cable we've spliced to, not the output on the digital sidecar

I sketched out a diagram of eaxctly how it's set up and attached it.

We know the robot isn't reading the encoder because the value from Get() never changes, and the robot always reports that it is stopped, even when moving


Yep--we saw this, and when we checked it with a multimeter(we don't have an o-scope), we saw fluctuation in values--it just seems that the robot isn't interpreting it correctly.


Sounds right. Are you doing this in Autonomous mode? We couldn't read our sensors in autonomous. They act like they never change. I wasn't involved with the software but The sensors worked in teleop mode so we proved they were working. Not sure what the problem was. They may not have been set up as global variables ... something like that.

Steve

[Alan Anderson]

I sketched out a diagram of eaxctly how it's set up and attached it.

You've shown three wires going to one thing, and one wire going to another. The sketch doesn't show which pins on those "things" the wires go to. If your labeling of the wires on the left matches the order they're connected to the GPIO pins, I think you have +5 and ground reversed.

[nathanww]

You've shown three wires going to one thing, and one wire going to another. The sketch doesn't show which pins on those "things" the wires go to. If your labeling of the wires on the left matches the order they're connected to the GPIO pins, I think you have +5 and ground reversed.

I don't have the robot to look at, so I accidentally reversed them on the diagram. We know that the orientation is correct on the robot because the encoder LEDs are lighting, which wouldn't happen if they were getting reversed current, and we can get some variation as we turn the wheel, so it's not something weird like getting the ground and signal wires mixed up.


And yeah, we're running it in the teleop mode,and we have other sensors on the GPIO that work fine

[Alan Anderson]

I don't have the robot to look at, so I accidentally reversed them on the diagram.

Without accurate details, I can't help further. Sorry.

An actual photograph of your wiring would help a lot at this point. So would a good closeup of how you have the encoder disk attached. Your code looks fine to me (except for a nagging worry about using the %d format specifier with a long integer).

[Steve_Alaniz]

Just as a wild spitball...in your program, do you have to do anything to enable the interrupt for the encoders ?

Steve

[nathanww]

encoder1->Start();

As I understand it, this is what should tell the encoder system in the FPGA to actually start counting pulses.

And with the long-int %d--even if this was printing incorrectly, the encoder stopped flag should be changing, right?

[AustinSchuh]

And with the long-int %d--even if this was printing incorrectly, the encoder stopped flag should be changing, right?

The long-int printing question is easily fixed. I don't know if it is incorrect as previously written, but typecasting will get rid of all doubt and make sure it works as you think it should.


printf("encoder1=%d", (int)(encoder1->Get()));

[Joe Ross]

encoder1->Start();
And with the long-int %d--even if this was printing incorrectly, the encoder stopped flag should be changing, right?

The stopped flag may be affected by this bug: http://forums.usfirst.org/showpost.php?p=26395&postcount=34 (but I can't remember if that affected labview only, or C++ also).