Go Down

Topic: Problem with rotary encoder (Read 1 time) previous topic - next topic

robtillaart

You could use the holes in the chain as encoder, put a led above it and an LDR/photoresistor below and it will give you speed info. Counting teeth on the gear at the back will give the pulses per rotation. Double the hardware (a bit shifted) and you can detect direction of the chain too.

just thinking out loud. ;)
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Jabberwock

@retrolefty
The wheel is easy - it's what I'm trying out right now (it would be even easier if the rubber on the mouse wheel did not peel off due to age!). However, it's a freewheel (obviously) so only one direction is registered, and I'd like to have both. Also, the inertia is too high for my purposes - I will not win Split/Second season without delicate control of the throttle and brake ;)

@robtillaart
I have thought of this, but did not know I could detect the direction... Could you explain that in more detail?

robtillaart


one led/ldr combination gives a square wave OK.

if we place the second one not exactly in sync with the first but a few mm further

       +-------+           +-------+
       | LED1  |           | LED2  |
       +-------+           +-------+

+-----+       +------+       +------+       +-------+

       +-------+           +-------+
       | PHR1  |           | PHR2  |
       +-------+           +-------+


If the chain moves to the right PHR1 sees the hole a small fraction earlier than PHR2 sees its hole
If the chain moves to the left PHR1 sees the hole a small fraction later than PHR2 sees its hole

connect  PHR1  to an IRQ routine (RISING) and use something like this.
Code: [Select]

volatile int direction;

void IRQ()
{
  if (digitatalRead(PHR2) == LOW) direction = RIGHT;  // or CW
  else direction = LEFT;  // CCW;

  count++; // for the speed
}

Practical problem might be dirt, => do the photoresistors above the chain so gravity works with you...; The leds are needed so it will also work at night ;)

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Jabberwock

I am not sure if I follow - is the difference due to the fact that due to delay between IRQ and readout of the second sensor it has been either covered or opened?

Anyway, it is not possible this way...

For this to work tension must be applied to the chain around the place the sensor is located (otherwise sagging of the chain will confuse the sensor). The problem is that with the forward movement the tension is on the lower part of the chain and with the backward movement on the top part... Of course, this in itself could be an indication of the direction of movement, now just to couple it with the speed reading...

Oh: the sprocket! The wheel itself is free, but the sprocket is not! No problem with the tension, either.

I guess I will have to sleep it over!

P.S. One more thing I forgot to mention - the advantage of hooking the mouse wheel to the chain (or, rather a small sprocket attached to it) instead of the main wheel is that the gear ratio is much more palatable... The sprocket I've got is somewhat smaller than the bike sprocket (did not get around to count the teeth), but not below 1:2 - the wheel speed is typically around 4 rotations per second, so I guess it should work out OK.

Jabberwock

Unfortunately, I have failed miserably... I cannot construct a mechanism which would transfer the rotation reliably.

Therefore, I am reconsidering using Hall sensors or LED sensors. However, I have a problem with grasping the principle of the rotary encoding. I have looked at the diagram and the explanation above, I have read through the wiki several times and I still don't get it... For example, how does the code relates to the diagram here? If I read the PHR2 at the situation given in the diagram, I get... an indeterminate (between) state? Does Arduino wait till the sensor has a discrete value?

Go Up