Encoder trouble

[flameout]

We have not been able to get our kit encoders (mounted to the Toughboxes) to work correctly. I thought at least one worked last night, but I didn't have enough sleep to detect if anything was amiss.

Sometimes, all we get are 0 results. Othertimes, the count continually goes up or down.

Does anyone have any idea what causes this? Thank you for any help.

[apalrd]

Did you check the wiring? Code? Power to PD board? Metal shavings in PD board? fingerprints on optical disc?

If the robot is moving the slightest bit, it will count up or down. It has +-1 degree acuracy, so moving its shaft 1 degree will trigger 1 count in 1x decoding. If you are intermittent, check the soldering of the wires and fingerprints on optical disc.

[flameout]

We checked everything we can think of -- we would like an idea of what could cause this in the first place. The wiring, code, replaced an encoder, swapped between the encoders. Nothing seems to solve this.

I do know they change, but after five minutes, the robot hasn't gone 90,000 feet! I do have feet scaled correctly.

Thank you for the help.

[JewishDan18]

Does the distance change suddenly, or very rapidly?

[apalrd]

Wiring review:
both encoders are getting +5 from the center pin (red wire on PWM cable)?
both encoders are getting gnd from the outer pin (black wire on PWM cable)?
both encoders are outputting two digital channels (A and B) to two inner pins (white wires)?
DSC has power and all three lights are on?
37-pin cable connected well?
Other things on DSC work? Other things that need 5v power (relays or some digital sensors) work?

Programming language:
In LabVIEW, you need to open two digital channels (A and B) then use ToDigitalSource, then feed that to the Open Encoder. Make sure you have them set right, as well as the scaling. The scaling should be a low decimal, on my robot that is .03 for inches with an AM Shifter 3:1 to the wheels, 1x decoding.

Graph the speed and distance output in LabVIEW. That helps to see what is happening.

Got an Oscilliscope? Try looking at the A or B output of one encoder and see what is happening. Or, create a LabVIEW program that has its own loop (like PeriodicTasks.vi or another loop in Robot Main) and graph the output of the digital line as fast as possible.

Maybe something is shorted somewhere - flipping your robot over and shaking it out usually fixes that.

The encoder software is interrupt-driven. It will only add to the counter when the value of the input changes. IF you have 1x decoding, that is only when the A phase goes high. If you have 2x decoding, that is either on both edges of the A phase or the rising edge of each phase, I don't know which. If you have 4x decoding, it is on both edges of both phases. If something shorts the pin high, then it won't count because the value won't change.

[PHSRobotics]

Hi from Team 2135,
How might one check to see if there are indeed fingerprints on the optical lens? Are the visible or should one just clean them off? How would one clean them?

[apalrd]

To get to the disc, pull off the plastic housing on the back. It is the silver disc pressed on to the output shaft, mounted close to the circuit board. If you turn it on with the back off, a red light should light up the disc. Pull it off, and check to see if there is anything on it. Make sure the side with 360 lines is facing in, that could be a problem if it isn't. Clean it off, and put it back on it without touching the side with the lines.

Assuming you are using 3:1 off a toughbox with kit wheels, your scaling should be set to 0.00166666666666666... go get to feet. I would recommend using 0.02 to get to inches in your scaling, because you will primarily be using them in Autonomous for distance calculations its much nicer to type in whole inches instead of fractions of feet. All of this assumes 1x decoding, divide that by the decoding type to get your scaling. You shouldn't need more than 1x decoding.

[Alan Anderson]

Maybe there's nothing wrong with the encoders or wiring. How are you reading them? If you show us your code, we might see something that you've overlooked.

[flameout]

Here's the code, it is attached.

We have the kit chassis, with the kit encoders mounted to the output shaft of the Toughboxes. There is a 15 to 22 reduction beyond that to the 8" kit wheels.

Here is the wiring:
Browns: (-)
Oranges: power
yellows: 5 and 8
Blues: 4 and 7

I believe our programming/electronics mentor added in some of the display code for debugging.

The distance is increasing or decreasing at a seemingly constant rate (I may/may not be able to run some checks or watch it closer.) This rate is very high, on the order of 200 ft/sec.

Thank you for your help, I hope this gets resolved.

[Alan Anderson]

Originally Posted by flameout

Here's the code, it is attached....

The distance is increasing or decreasing at a seemingly constant rate (I may/may not be able to run some checks or watch it closer.) This rate is very high, on the order of 200 ft/sec.

I don't understand the second picture you posted. What are you looking at to see what the distance is doing? I see what looks like a while loop -- where is this code? What is it intended to do?

[flameout]

The second picture is a screenshot of our dead-reckoning navigation code. To keep the image size down, I clipped it to just the portion involving the encoders. We are watching the distance by clicking on the wires from the "distance" output from the encoder palette's get routine.

Also, we added in something like "initialize timer," and it may or may not be working right.

Thank you for your help.

[Integral]

Flameouts Mentor here,

Our wiring is correct and sound, as is the condition and installation of the encoders themselves.

We currently appear to have a good reading from the right encoder and for the left we get a flat 0. Perhaps more of an error condition? I have not been able to find any sign of an error thrown by any of the encoder vis.

I note in the first block (from the begin vi) of code flameout posted that neither of the encoders are set for reverse. Could this cause an error?

It really does not matter how we are viewing the output of the encoders, the posted code shows how we first initialise the encoders then how we read them. Can someone comment on the correctness of this code?

[apalrd]

I'm looking at how you calculated the scaling...
8*pi = circumference of wheel
divided by encoder counts (360)
divided by feet
multiplied by gear ratio (15/22)
The result of that calculation is 0.00379
My math says 0.05 inches - same as yours except yours is in feet.

Scaling is correct.

Which brings us back to - Where is this get code. It is in a while loop. Is it in Teleop.vi? Is it in Autonomous Independent.vi? You can call Encoder:Reset before you enter the while loop if you are doing this in Autonomous.


EDIT - after looking at that get code, I see a possible problem. You are feeding the difference from this get and the last get (speed) and using that to determine your position with the help of the gyro. It would be much simpler to just reset the encoders at each turn, and add the position change in each segment of your journey, assuming you never turn and drive straight at the same time.

[Alan Anderson]

Originally Posted by Integral

It really does not matter how we are viewing the output of the encoders, the posted code shows how we first initialise the encoders then how we read them. Can someone comment on the correctness of this code?

It might not much matter how, but it certainly makes a difference when and where you read them. The while loop worries me, but I can't comment on whether the code is correct without knowing the context. My earlier question remains: where is it?

[flameout]

This is in a VI that is in Periodic Tasks.vi (we use our own loops, not the built-in loops.) This is a timed loop, which I believe is set with a delay of 20 milliseconds.

We now have one working, and one not. The one that's not may or may not be plugged in (I don't recall for sure.)

Thank you.