Speed Encoder
hank van buren
Posts: 57
This program shows the use of any stepper motor can be converted for the use of a wheelencoder or a speed controller simply by driving the stepper motor, it will make a perfect magnetic encoder, with one exception instead of getting 8 pulses per revolutions you will get 48 and it is more economical. This system is currently used on www.gpscontrolledvehicle.net to maintaine a constant speed.
Post Edited (hank van buren) : 11/11/2007 5:21:16 PM GMT
bs2
1K
Comments
Is there a way to make it understand and the direction of turning also?
Thanos
Presuming you have two wheel encoders, you are always turning in the direction of the lagging or slower wheel, presuming there is no spinning or slippage of either wheel.
Regards,
Bruce Bates
The above code uses only 1 pin of the four that a stepper, what if I use the rest in conbination to intepret if its turning one way or another like the some encoders with two outputs do? I think that it can be done.
I tried to implement it but stuck on the programming side. For this I connected the common of the stepper to the ground and the rest four pins of the stepper on four ports of the stamp thru 470 resistors.
Thanos
·
I would imagine it would work just like the single wire stepper mode, but you will need to constantly scan all wires quite fast. In sequence.
I do this to determine if certain switches are pressed on a matrix keypad. I would imagine the same technique could be used to scan the stepper wires to see which of the 4 are giving pulses. You would have to scan the inputs pretty fast.
I would personally just start with scanning all stepper wires as fast as the stamp could in a repeating loop, and pump the output to the debuger, let each stepper line change a variable to 1 or 0, then display that variable in the debuger, this will let you see how fast your variables change, and also the pattern that results from the stepper motor rotating backwards or forwards.
But the debug might slow your loop down, so it may mess with the results. But its a start? I would think that rotating the stepper motor a bit slower would help you determine a directional pattern using debug.
http://www.parallax.com/dl/docs/cols/nv/vol1/col/nv8.pdf
If you don't get this to work, or no one else can help you, I might have some free time in a few days, and can help you out. I own two stepper motors, mine also have 4 "signal" wires, and a 5th common.
My apologies for misunderstanding your question the first time around. It DID seem too simple at the face of it. I didn't realize you were trying to determine the MOTOR (encoder) direction, since neither the of those words appeared in your original question.
Generally speaking those encoders whose dual output can be used to determine both speed and direction are emitting quadrature signals. In truth, the signals need not be true quadrature to be usable, but simply consistantly out of phase with one another by a sufficiently large angle that it can be detected. I suspect with a bit of empirical testing, you can find 2 pairs of windings on your stepper motor/encoder, that will provide such a detectable phase angle difference.
Here are some applications notes, thanks to Dr. Tracy Allen, that are intended to be used for quadrature output, but which I suspect can be adapted for use on your setup:
http://www.emesystems.com/BS2fsm.htm#directional
The whole "trick" here is to determine whether the Phase A signal (one of the stepper windings) leads or lags the Phase B signal (a different winding). If it LEADS, it's going in one direction, and if it LAGS, it's going in the opposite direction. The designation of Phase A and Phase B is purely arbitrary, but must be consistant throughout.
As you read through the code, just remember that both signals, from one single source (one encoder, two signals), are merely out of phase with one another, and that's all you're detecting to ascertain direction. Please let us know how you make out with it.
Regards,
Bruce Bates
----> ----> ----> ----> CW
0 1 1 0 0 B
0 0 1 1 0 A
<---- <---- <---- <---- CCW
0 1 3 2 0 state
And·it gives enouph code examples. Cool!!!!
I'll give it a try tonight...
Thanks
Thanos
·
Again, I'm not sure I understand what you're trying to do here, but I hope the following will clarify it. I tried to make it clear in my last message, but I guess I didn't do a very good job of it.
There is NO 2-bit "signal" per say. You have two signal sources (two different windings) which we're calling Phase A and Phase B, just by convention. Just for the sake of reference, we'll call the first winding you choose (whichever it may be) as the Phase A signal. The second winding that you choose to use will be the Phase B signal. For each of these signals you need to know the last or past state (0 or 1) and the present state (0 or 1). Now, if you want to call that two bits that's fine, but for me that just adds to confusion. To my way of thinking those are two different states of the SAME signal. Since we need to know the past and current state of two DIFFERENT signals (Phase A and Phase
Why do we need 2 states and 2 signals. Here is the rationale:
First we need to know if the state (0 to 1 or 1 to 0) has changed for a given signal. We have no interrupt-on-change facility on the PBASIC Stamp, so this is a way to imitate that feature. Thus, we need to know its past and current state. Once we know that, we can detect (by comparison) if/when a single signal change occurs. We might be standing still, and in that case there will be no change at all.
Second, if/when a change HAS occurred in the state of the signals, we need to know WHICH signal changed first (Phase A or Phase
I'm not saying you can't "condense" those states, I've just never seen it done, and would have to set up a test jig to test out whether it would work as planned. My suspicion is that you may be in for trouble, and that the trouble may be in the non-moving case. That's just an off-the-top-of-my-head guess, quickly thinking about it.
Regards,
Bruce Bates
Post Edited (Bruce Bates) : 1/10/2006 3:20:07 PM GMT
This is good place if you are looking for some cheap stepper motors. http://www.allelectronics.com/cgi-bin/category/400600/Stepper_Motors.html·
I would be very interested in a copy of your program reading the direction of the stepper motor.
regards Hank van Buuren
BUT it was kind of jumpy or sometimes going the opposite direction from what it supposed to be.
The reason for this must be that the stepper outputs half step information:
1 2 3 4
1 0 0 0···<---
1 1 0 0
0 1 0 0·· <---
0 1 1 0··
0 0 1 0·· <---
0 0 1 1··
0 0 0 1·· <---
1 0 0 1··
That has·four states·more·on each winding·indecated above with arrows.
If I had a way to filter these extra states...·to a usefull one that could be:
1 1 0 0
0 1 1 0··
0 0 1 1··
1 0 0 1··
The code really needs modification for 4 ports reading so when a beta vesion is available I'll post it...
Thanos
·
If the encoder (motor) was positively driven (no slippage in either direction) the "cogging" you're seeing would probably disappear. True encoders use Grey code, which is inherently error proof, and you can toss out any errors which may be seen.
If you want to have fun continue on. If you want a true encoder that is durable, accurate and repeatable, without errors, may I suggest that you purchase one, and these problems will ALL disappear. One old adage is "You can't make a silk purse out of a sow's ear"!
Regards,
Bruce Bates
But if works out, it would a durable self powered encoder with nice turning feel for the end user (I like all these halfstep stops it makes·when I·turn it by hand)
One good application could be used is in a·force feedback joystick where the stepper can provide both the reading of the movement caused by the users hand and both the feedback·movement fron the computer program he plays on.
I know already there are better solutions to this (I own a Microsoft Sidewinder FF2)
but it would be fun to·use some devices in way never intended to be.
Thanos
·
···· I had an application awhile ago to use an encoder to measure lumber width on a moving conveyor.
···· In working that out, I was able to combine a signal processing textbook from France with an old N&V article (or maybe it was an early Parallax app note) and ended up with a very elegant way to read an encoder which also generated a signal to show direction.
···· The program is attached, use at your own risk!
·· Cheers
· Tom