Here's a summary of the situation:
- I have the intention of making a hobby 4 wheels proto to move at a controlled speed and/or turn a certain -prefixed- angle: the goal is to control the movement through the encoder (a feedback loop) so that you don't have to guess the amount of space made by multiplying speed by time (without any idea of what the speed was in fact).
- The very first feat is to read the encoder in "real time" basis: you have to connect it to an interrupt and, then, write a software that makes whatever you need every teeth of the encoder: the simplest is to store the "millis" so that, next time, everything you have to do is to subtract to have the "period" ("T"; the inverse -1/T- is the speed). If everything goes well, you should have a series of smooth readings (Serial.print). A few days ago I posted a piece of software that did that.
- Sometimes it worked, sometimes it didn't. It did (work well) at slow speeds but when you speeded it up, the readings started being a bit random (not exactly random; it looked that the controller read 2, 3, . . . tooth instead of just one -not every time: it could start making good readings for a while and, suddenly, again failing).
- As we say in Spanish, "sabe más el diablo por viejo que por diablo" (devil is sage not because he's clever, but for he is old): I had the impression that it was impossible to keep on going without a tool to see what happens in "real time". Even for this simple project things happen at 25 Hz (25 times a second. The maximum speed of the motor is about 150 rpm and the encoder has 10 teeth: 150 * 10 / 60 = 25), so an oscilloscope is mandatory. Fortunately, what costed 30 years ago 2.000 $ now costs 60 $: I bought a "Hantek" (a chinese made that is quite well aspected and works reasonably well). Here are the results:
** The very first image I got was the #1 I attach. It corresponds to the interrupt pin I'm using: it looks fine, specially the neat rising and falling edges; there are some spikes coming up and down from the flat parts but they don't look so big (as to interrupt the controller), so further investigation was needed.
** I added two lines of code to the interrupt (code) to send to a(nother) pin a HIGH signal while the interrupt itself is executing: I got the figure #2: Green lines (spikes) are the interrupt executing itself: a complete disaster.
** 1st, the interrupt should occur JUST in the RISING edge (as coded): in the image you can see that it happens when rising and when falling. In addition to this (2nd), there are additional executions of the interrupt that appear here and there. A disaster. (Or not?. Well, at least it corresponds with that the code makes: more interrupts than the correct ones means a bigger speed than the real one).
** These kind of problems are associated wiht "noise". It is a kind of "noise" you can't (normally) hear. In the images I enclose you can see the noise on the bottom and on the top. (I can't explain the basics of the -general- problem; sure you can find excellent papers in the net).
** I do have some experience on suppressing noise: 1) some coming from power supply and some "noisy" parts (the motor itself in this case) is diminished easily by connecting small capacitors in parallel. 2) The signal coming from the encoder (by the way: is an optically coupled one. A led that makes an "opto"transistor to conduct by lighting it) itself can carry noise too: another cap in parallel (to earth: see below).
[BE AWARE: Noise suppression has some of sorcery: you can't use any cap (even worse: some kinds of them make noise themselves). For this purpose small ceramic capacitors are the best. I have a beginners kit with a number of them (no idea of the value: a few uF)].
** So I used three of them. You can see the results in the figure #3. Falling edge interrupts have dissapeared completely: sure the encoder signal carried noise that has been (at least in part) removed.
The problem is, by no means, solved. You can see remaining (undesired) shootings (but I keep some bullets in my cartridge). I'm going to make the following.
1) Separate power supplies: up to now I've been using the same DC supply for both the arduino and the motor. I'm going to supply them from different DC sources.
2) Build a "solid" signal earth: whatever you might think, cables have resistance (i.e: they are not zero ohms), so there are minimal voltage drops in between points that are wired together (specially with those stacks of boards we use to make the prototipes). Sometimes these drops are big enough as to shoot the interrupt (this is not -only- a "noise" problem).
3) Shorten the cables: in addition to contribute to the last problem, cables act as antennas. Everyone wants to keep them as long as possible (just in case) but, some times, you have to cut.
I'll keep you informed.