My thoughts of how to read an encoder wheel
I use this little fellow:
It's a TCRT50000. It consists of an IR LED and an IR phototransistor. It's the central element in sensors used in line following robot cars, like the KY-033 sensor. In my case I wanted to use just the tiny TCRT50000. What I have is this:
A planetary gear, where the ring gear is fixed to a bottom plate, the planet gears hold to a machine rotating, and the sun gear is on a motor axis, the motor being fixed on the rotating machine. Everything works nicely. When I read the phototransistor with analogRead(A6), I get nice readings:
This is a very rough curve, where I have a long delay between the readings. With shorter delays and maybe with some filtering, I get a smoother curve. The top of the curve occurs, when the TCRT50000 is above a white sector. The bottom relates to the black sector.
To count steps, I need to count the waves. I need an algo, where I can clearly distinguish these waves from each other and not mix them with maybe smaller waves, which are caused by ambient light or noise.
I want to count all white and all black sectors, which gives me 16 counts per revolution. The whole planetary system will rotate some 9 degrees per sector.
So I need to count the tops and the bottoms of the wave. The average value of the wave in the image is somewhere about 450. If we think of this value as the X axis, we have a sign change when the curve passes 450 in either direction. I want to use this sign change as the significant step to count, but I want to use the tops and the bottoms as the actual position to stop at. The sign change should be easy to detect, with proper filtering one can't miss it, or there won't be multiple sign changes in a narrow interval, due to the large rate of change. But at the tops and bottoms, the rate of change goes to zero and will have its own sign change. Moreover, there might be several sign changes of the rate of change at the tops and bottoms, even after heavy filtering.
The machine will rotate back and forth a number of step. If at a top, one step in either direction takes it to a bottom. Each step is about 9 degrees. A 90 degree rotation means 10 steps.
The algo for one step goes like this:
- Start rotation
- Wait for a pass of the 450 value ("sign change")
- Start monitoring the increase or decrease rate
- Wait for the rate to reach 0 and make a sign change
- One step is completed. Stop the rotation. Or jump to 2, if more steps are needed.
The exact mean value (450 in the example) is not very important, as long as it's a clear value, where the rate of change is about the largest.
Likewise, the exact point where the rate of change changes the sign is not important, as long as it clearly happens between two points passing 450. Despite using filtering, I could still have some ripples causing several sign changes of the rate of change at a top or at a bottom. I only care for detecting the first sign change. It might be a few degrees off the midpoint of the sector, but it's more important for me to count the sectors passing by, than to stop in the middle of one sector. If I want the system to rotate 90 degrees, I count 10 sectors and stop. I can go back and forth 10 sectors how many times I want and never be more off than a few degrees.
I have built everything already. But I haven't implemented this logic yet. I hope to get feedback on the idea itself. Did I once again reinvent the wheel? (I'm the founder of WRIS, Wheel Re-Inventers' Society. Sorry, but you can't join the Society. Everyone has to found their own WRIS.)
