Mappy (the mapbot)

Update: 1st truly succesful counter

It has been really hard to get the encoder to stop occasionally counting transitions more than once. But I just had a rather succesful run at that. My test setup is simple. I put a small piece of red sticky tape on the wheel so I can see when it has performed a full rotation. I then start counting steps and every time it made a full rotation I stop for ~2 secs. I let it run for some 10 minutes and it only got misplaced by a few millimeters. Best so far.

Here is the (rather ugly) code I used:

----------------------------------------------

int val;
int old_val;
int count = 0;
unsigned long int time;

void setup() {
Serial.begin(115200);
Serial.print(“START”); // sync with scope
pinMode(2, INPUT);
val = digitalRead(2);
old_val = val;
time = millis(); // initialize timer
}

void loop() {
analogWrite(5, 100); // move motor
val = digitalRead(2);
if(val == 1) val = 255; // max scope value
//Serial.println(val); // serial monitor
Serial.print(val, BYTE); // scope

if(val != old_val && millis() > time+5) {
if(count < 38) {
count++;
old_val = val;
}
else {
count = 0;
delay(5);
analogWrite(5, 0);
delay(2000);
}
time = millis(); // reset timer
}

delay(1);
}

----------------------------------------------

As you can see I had to make a rather nasty workaround to get it to stop counting some transitions several times. I only count a change if minimum 5 millisecs have past since the last change:

if(val != old_val && millis() > time+5)

Besides that it’s rather odd that I’m using an encoder wheel with 40 clicks per rotation BUT I seem to be only counting 39 clicks per rotation:

if(count < 38)

When I tried it with 39 as it SHOULD be it simply didn’t work?! Strange :confused:

I guess making your own encoder isn’t that easy at all. I still have some tweaking and fiddleing to do but it’s starting to look like something :smiley:

Aniss … Over and out

Counting Ticks with state

I’ve seen another discusssion about coding to read a rotary encoder, which suggested a few algorithms. One that was somewhat agreed upon was the use of state machine programming to keep track of counts. Essentially what was needed was to keep a small local memory of what the encoder was last time through the loop, a small "state variable. If the new value read was different than the current “state” variable, then the count could be incremented and the new “state” recorded.

The timer you’ve used seems worrisome, in that it would appear to skip counts if the robot got moving too fast. odd about the 39 thing.

Basically

Basically that’s what I do. Only my “state” variable is called “old_val” instead.

The timer is an ugly workaround indeed and I certainly don’t intend to keep it. I was just trying out different ways of making it stop counting some transitions more than once when I connect it to a digital input. I could off course use the analog input and use thresholds to detect the transitions, which would be infinately better than the current workaround. As you can see in the last scope screenshot the readings are good enough for that. But I would very much like to make it work with a digital input so I can use the hardware interrupts (on Arduino’s pin 2 and 3). That would be the optimal solucion because it would minimize the possibility of missing transitions when I start adding more code into the main loop.

And yeah the 39 vs. 38 is just plain weird as you say… :confused: