Misbehaving encoders

[Jared Russell]

Originally Posted by nathanww

"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]

Originally Posted by nathanww

"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]

Originally Posted by nathanww

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]

Originally Posted by nathanww

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]

Originally Posted by nathanww

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]

Originally Posted by nathanww

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.p...5&postcount=34 (but I can't remember if that affected labview only, or C++ also).