Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Electrical (http://www.chiefdelphi.com/forums/forumdisplay.php?f=53)
-   -   Walking Encoder Values (http://www.chiefdelphi.com/forums/showthread.php?t=93989)

JoeyPass 24-03-2011 19:09

Walking Encoder Values
 
We have two active Encoders on our robot that read the positions of our arm and wrist. After a couple of movements and bringing the arm and wrist back to starting position we are getting increasing values. It should be reading near zero each time we return to the initial positions but on the arm we get increasing or "walking values" in increments of about 4 - 6 per iteration. Has any one encountered this and do you have any suggestions.

Thanks,

MagiChau 24-03-2011 19:10

Re: Walking Encoder Values
 
I would have limit switches that when hit, reset the encoder.

Chris27 24-03-2011 19:21

Re: Walking Encoder Values
 
A properly working encoder shouldn't drift very much. Are you sure that the encoder isn't slipping?

JoeyPass 24-03-2011 19:27

Re: Walking Encoder Values
 
Absolutely positive that it is not slipping. This encoder (the hat) is set on very tightly.

DonRotolo 24-03-2011 19:52

Re: Walking Encoder Values
 
What kind of encoder?

JoeyPass 24-03-2011 19:54

Re: Walking Encoder Values
 
Optical encoder.

Teched3 24-03-2011 20:03

Re: Walking Encoder Values
 
Is the encoder connected directly to an axle? If that is the case, then possibly the axle is slipping. We use reinforced rubber fuel line between our encoders and axles, and then tighten safety wire around each shaft, us well as file a flat on the axle to ensure no radial creep occurs between them. Enlighten us further on how it is set up and maybe we can help you solve the problem.:) :)

plnyyanks 24-03-2011 21:00

Re: Walking Encoder Values
 
Is there the possibility of any EMI with the encoder. We had a bad motor interfering with an encoder, causing the values to be dramatically different than what they should be

DonRotolo 24-03-2011 21:04

Re: Walking Encoder Values
 
Two common reasons for an optical encoder to slip are:

Mechanical: There is mechanical slippage. Check this carefully, don't assume anything.

Computational: Your input circuit is missing some of the encoder's output pulses. If you are using a hardware interrupt, then your encoder resolution (pulses per revolution) may be higher than the hardware can manage. If you are not using a hardware interrupt, that could be your problem.

apalrd 24-03-2011 21:15

Re: Walking Encoder Values
 
Quote:

Originally Posted by DonRotolo (Post 1044867)
Computational: Your input circuit is missing some of the encoder's output pulses. If you are using a hardware interrupt, then your encoder resolution (pulses per revolution) may be higher than the hardware can manage. If you are not using a hardware interrupt, that could be your problem.


If you are using the cRio's Encoder or Counter modules, they are handled with dedicated hardware in the FPGA, and should never drop counts in any reasonable encoder.

Teched3 24-03-2011 21:34

Re: Walking Encoder Values
 
what is your encoder pulse rate/ rev? When we First starting using them years ago, the pulse rate was too high for the software/computer to keep up. As Don noted earlier, eliminate mechanical slip, and then triple check software code. Have you marked the connector, encoder, and axle to visually see if it creeps?:) :)

pfreivald 24-03-2011 21:46

Re: Walking Encoder Values
 
We had exactly this problem, and found that the encoder was getting scratched because someone had seated the disc too tightly. It took us a while to figure out that this was the problem.

I suggest popping the encoder open and looking at the disc!

Teched3 24-03-2011 22:09

Re: Walking Encoder Values
 
I wouldn't advise using that encoder after doing that. Just replace it with another to see if that corrects the problem (substitution). Then consider that one, (if you open it up) for destructive analysis. Good encoders aren't inexpensive. :) :)

Gdeaver 24-03-2011 22:33

Re: Walking Encoder Values
 
To measure the arm position, I prefer an absolute angular position sensor. Such as a potentiometer. There are some problems with pots since they are a mechanical device. We prefer to use magnetic absolute encoders. Last year we used a Cherry AN8 series 360 non-contact absolute encoder. This year we are using Vishay 981HE encoders for our pivot modules and arm. They give an analog voltage output from .5 to 4.5 volts 0-360 degrees. Both of these devices are rugged and automotive qualified.

techhelpbb 24-03-2011 22:39

Re: Walking Encoder Values
 
This may not help you at a competition...

However, I found the most definitive way we have to check our U.S. Digital optical encoders was to connect them to a motor moving at a relatively fixed RPM (you don't really need to know the RPM...just as long as it's relatively fixed) and observe the output channels with an oscilloscope. This assumes you can rotate the encoder completely around...over and over...so doing this with an arm probably won't work out.

If you're seriously missing pulses from the encoder itself you'll see it rapidly as you'll get a very unstable waveform from the 2 channels on the oscilloscope display.

You should see a nice stable waveform from both sides of the encoder.
It should be roughly 50% duty cycle for the U.S. Digital optical encoders, keeping in mind that the frequency of the waveform will depend on the RPM.

We had a lovely pile of bad encoder wheels...and bad encoders...and this was how a student and myself finally sorted them.

Our encoders were put on the drive train, with just one motor in the gear box and we ran the drive train with %VBUS. I then checked each encoder on there. Some had one bad channel. Some had no output. Some just produced a mess...and if carefully adjusting the height of the disk over the sensor assembly didn't fix it...we put it in a big bag marked *BAD*.

The only difficulty you'll find with the U.S. Digital optical encoders is that you'll need to find a way to hook up the oscilloscope to the encoder. The simplest way is probably to use a tail with the Molex PicoBlade for the encoder on one side, soldered to the wire to whatever it normally goes to and simply expose the junction of the wires to grab the ones you need with the oscilloscope probes (you need ground, and the 2 channels).

As others have pointed out, your software can cause you issues, and if you doubt the hardware's ability to 'decode' the encoder you might spend quite some time chasing ghosts. With the oscilloscope you might still have some random missing pulses occasionally...but for the most part you'll actually see any often missing pulses. If you can manage to hook up the oscilloscope while using the encoder as a sensor on a device as well, you can also get a good feel for how responsive that device is to the input from the encoder because you'll be able to see what the encoder is doing...and if you do it right...what the thing looking at the encoder thinks is going on.

A step up from using the oscilloscope might be to use a logic analyzer which would let you record the output of the encoder channels over a greater stretch of time.


All times are GMT -5. The time now is 18:57.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi