Believe it or not:

From the pictures/vids--wonky breadboarding, using a mouse for an encoder, the old Lego system, surely more--one might think this dude's motion-control software to be as flakey as his setups... There may be truth in this.

Indeed, the motion-control software I've written over the years is entirely self-taught. I tried taking a controls class a while back and dropped out in the first week; all that math, all at once, and so much theory... too much for me. But, I have been working on this software for quite some time, and it has worked quite well in systems I didn't build.

So, yeah, this setup appears a bit ridiculous. That's part of what's making it "fun"-ish, this time 'round, rather than just the bore of getting a previously-working system working on a new chip.

In the process I'm working first-hand with much lower-quality parts than before... (quality, at least, in regards to the purpose they're being applied to).

We'll start with the motor (wherein I begin to ramble):

The motor connected to the mouse-encoder is, I think, from an old [cassette] tape-deck. It was never intended to do anything other than run at two speeds in each direction, and was intended to be gear-reduced a bit. This presents an interesting learning-experience... Applying a small voltage (or low-power modulation) to get a slow speed results in something I haven't experienced first-hand... At slow speeds this motor speeds up and slows down at different points in the rotation. It makes sense, from a physics-sense, something to do with the pull-strength of the magnets' based on their alignment. Nevermind the brushes... (@davedarko once fell-victim to much hypothesizing on these matters). But, anyways, now I'm seeing it first-hand, and it's quite apparent.

At one (small) power-level, I can get the motor to rotate at roughly one [mouse] encoder-count per second... that's *really slow* and in fact almost impossible to see. It'll run like that for several seconds, several encoder-counts, then suddenly go really quick for a fraction of a second, and return to slow... It's actually quite interesting to look at on the 'scope in "roll" mode. (I should insert a picture, or maybe a vid). It definitely seems to have a specific periodicity which I assume is related to the poles of the motor.

Again, I haven't really experienced this effect before, as I'd been using DC-motors which were designed for positional control via feedback-loops... They may have had similar effects, but much smaller. And, of course, since they've been running *with* feedback-loops, in my code, these effects would be accounted-for by adjusting the power accordingly. I have no idea, however, whether this tape-deck motor could be driven with such (positional) precision even with a/my feedback-loop. Also, again, these are designed to run at much higher RPM than the positional-controllable-motors, so rotating at only a few degrees per second, or attempting to rotate just a few encoder "ticks," is expecting a lot from them. This'll be an interesting experiment. Albeit, a little bit ridiculous, as surely they'll need gear-reduction before they can drive anything, with any strength...(?) (If nothing else, what kind of shaft-attachment is there for such tiny shafts? Most any set-screw would be bigger than the shaft itself! And most of the pulleys/gears I've seen attached to these motors are merely press-fit nylon, which surely would slip under much load).

As far as the encoders: I haven't counted, but it looks like these mouse-encoders have somewhere on the order of 50-100 slots... That's not much when compared to most of the motors-with-encoders I've worked with. It's not so much that you need that much *positioning* resolution, but more that the extra ticks allow for easier math(?).

E.G. Say I want the motor to be positioned at one of four positions, 90 degrees apart, and there's 4 encoder slots... With four slots (as-implemented), the computer only knows if it's ~90, ~180, or ~-90 degrees away from where it should be... so then how much power should it apply to get to the right position? Apply enough power to move from 90degrees to 0degrees, when really the motor's located at 47degrees... and the motor will most-likely overshoot by quite a bit. It might be stuck at -43 degrees... Or possibly enough power would've been applied to go two encoder-ticks, which would then look like -90 degrees, and then the reverse would happen, causing oscillation *around* 0 degrees.

Whereas if I still only cared about 90degree-positioning, but there're 16 encoder slots, then I can say something like "power = desiredSlot - measuredSlot" and power would have 4 values between each of the four desired-positions. The power would reduce as it gets closer to 0degrees. Here we can also apply a "dead-zone", where if the motor's say only one tick away, then it won't apply any power, thus helping reduce the potential for oscillation. And, in my experience, adding a dead-zone isn't really necessary; since most motors won't actually spin when the applied-power is too low, they have an inherent dead-zone.

In either example, we're assuming no load. But say a rubber-band was attached to the shaft, pulling it away from the desired-position... the only way (in this system) that the computer would know this is to look at the difference between the desiredSlot and the measuredSlot (and possibly compare how much power is already being applied to keep it there). Thus, typically, at least in my self-taught system, the motor's always going to be a few "ticks" away from where you really want it.

Note, again, that e.g. some power-levels won't actually result in rotation at all, e.g. 1/256th power may be way too weak to overcome friction in the motor's bearings (the inherent dead-zone, mentioned earlier)... This also affects how many "ticks" away from the desired position the motor actually stops at..