2.5-3D thing

I've said it before, and I'll say it again... most of my projects tend to feed into each other.

So, this time, we've got #CD/DVD mechanisms and cartesian thinggie[s?]

which has taken-on some of the porting of my motion-control code that started here (the porting of the code, not the code itself. started here.).

Here're some logs from that project which are related to this project:

• ramblings on precision and non-steppers
• DC Motor Revisited + Another one [laser] bites the dust [beam-focussing]

Here's an image from the second link... Managed to attach another mouse-encoder to a CD mechanism. This motor is *definitely* smoother than the "hobby"/"toy" motor I used earlier.

Update (9-19-15):

Adding another pseudo-related hypothesis to the end...

Update (9-8-15):

@RoGeorge has a great project-page dedicated to comparing PWM and PDM aka "Delta-Sigma Modulation." #Delta-Sigma versus PWM. His project-page discusses the differences, and has some excellent graphics.

And Thanks to @Al Williams (or is it @Al Williams, 'if that is your real name...') for the writeup on the HaD Blog! http://hackaday.com/2015/09/08/pulse-density-modulation/

Update (9-8-15 2.0):

Adding a groovy image and description at the bottom...

Update (9-9-15):

Another, in ascii-art, at the bottom.

Adding a different fraction to the drawings, where cyclical nature is more evident.

A few TODOs added in the original text...

Adding disclaimer at the top... (right below the line, below...)

Update (9-9-15 2.0):

Adding a summary of and link to the hfModulation code

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

NOTE: I'm no expert on Pulse-Density Modulation, Pulse-Frequency Modulation, nor Delta-Sigma Modulation. In fact, I have a difficult time understanding their wikipedia articles. AS FAR AS I'M AWARE, these are all the same, or very similar. My so-called "High[est]-Frequency Modulation" (hfM) is something I came up with on my own, and used for years before discovering these terms for it (PDM, PFM, DSM). It's my [minimal] understanding, again, that these are all pretty much the same thing, and I've slowly (after years of using and improving hfM) started referring to it as PDM. THAT MAY BE A MISTAKE. Again, I don't fully understand the wikipedia articles on these things. It has been my intent, ever since I discovered the terms, to eventually figure out their differences and possibly rename hfM appropriately. In Other Words: TAKE THE INFORMATION HERE as nothing more than *my understanding* of PDM... Where I say "PDM" below, I'm referring, specifically, and plausibly mistakenly, to my hfM implementation....

NEW VIDEO:

Here, for this project, I have a motor rated for 3-6V... I'm using a 12V power-supply with PWM (or PDM).

At full-power (PWM = 100%, should be 12V) the motor draws more current than the power-supply can supply. The supply drops-down to 6V.

BUT: There's a big-ass capacitor where the power-supply enters the circuit.

PWM and PDM recap:
(I call my implementation of PDM "HFM",
 "highest-frequency modulation")

PWM: (cycle period = 6 counts)      >| |<--- one PWM "count"
 _._         _._          _._._       _._._
|   |_._._._|   |_...    |     |_._._|     |_...
^-----------^            ^-----------^
one PWM cycle            one PWM cycle
 33% power                50% power
     = 2 counts               = 3 counts

HFM: (max power = 6 counts):      >| |<--- one "HFM" "count"
 _     _     _            _   _   _   _
| |_._| |_._| |_...      | |_| |_| |_| |....
^-----------^            ^-----------^
one HFM "cycle"          one HFM "cycle"
power = 2 (33%)          power = 3 (50%)


UPDATE 9-9-15: Adding a different fraction, e.g. 2/5 and 3/5, 
      where cyclical nature is more evident

PWM: (cycle period = 5 counts)    >| |<--- one PWM "count"
 _._       _._          _._._     _._._
|   |_._._|   |_...    |     |_._|     |_...
^---------^            ^---------^
one PWM cycle            one PWM cycle
 40% power                60% power
     = 2 counts               = 3 counts

HFM: (max power = 5 counts):      >| |<--- one "HFM" "count"
 _   _     _            _._   _   _._   _
| |_| |_._| |_...      |   |_| |_|   |_| |....
^---------^            ^---------^
one HFM "cycle"          one HFM "cycle"
power = 2 (40%)          power = 3 (60%)

Where was I going with this, again...? Hmm, big-ass capacitor...

So, I intend to run the motor at no more than 33% power, using 12V and one of these modulation-schemes. That's roughly the equivalent of running the motor off 4V...

But (as I discovered late in the game) the power-supply drops-out at the current required by this motor at 12V. And, using one of these modulation schemes, the motor is *actually* given 12V quite regularly... So why isn't the power-supply dropping-out (to 6V) on every pulse of 12V? Well, in part, because of that big-ass capacitor.

And, in part, because my first attempts with this motor were done using "HFM"/PDM.

I didn't notice the effects of the power-supply dropping-out until experimenting with output powers >50%. With output powers >50%, the output pulses seemed to be drooping strangely. Weird, but not a problem, since I don't plan to use it at >33%.

Eventually I switched to PWM, just for the heck of it... (In this case, my PWM "counts" are the same duration as my HFM "counts"--their complete "cycles" occur at the same frequency). And, right off the bat, I noticed the output drooping strangely, again... even at really low power-output levels... It became noticeable at just 2 counts out of 256/cycle, less than 1% duty-cycle, less than 1% power output to the motor.

A little hunting, and sure-nough discovered it wasn't that the output-power was drooping, the power-supply was. It seems the "big-ass capacitor" happened to be just about the right size to keep the 12V supply pretty stable for one high PWM/HFM "count," but little more. At 2 "counts" the capacitor charge depletes noticeably, at 3-4 counts, the power-supply drops-out to a pretty steady 6V.

Guess it's just luck the capacitor I chose randomly weeks ago just happened to have been doing its job fine for so long, despite running *right* at its limit!

So, what's this all mean...? I dunno, exactly... This is a *really* odd setup, in my experience.

Usually the PWM frequency can be *much higher* than my software-based HFM implementation, since there are often dedicated PWM peripherals, and I've yet to see a dedicated PDM peripheral. In this case, however, the playing-field has been leveled due to the motor-driver's slow response-characteristics; the switching-speeds are plenty slow-enough to be handled by bit-banging in software, PWM or HFM.

Also odd about this setup is the fact that I don't intend on using output power >50%. That particular factor is what makes this discovery interesting... Since I'm using <50%, with HFM, there will be no pulses that are two "counts" wide. The capacitor sags *slightly* during a single high pulse and gets "recharged" in the following (low) pulse(s). If I stick with HFM then I don't need to increase the size of that "big-ass capacitor" nor upgrade the power-supply. Both of which would be necessary if I switched-over to PWM (in this setup).

Usually one would prefer a high enough PWM frequency that it wouldn't be audible, >20KHz is preferable. But that's not an option here. And, in general, there's always an upper-limit to the PWM frequency due to switching-speeds of the motor-driver... Even motor-drivers that are significantly faster than the one I'm using.

In this era of MOSFET-based H-Bridges, most of the heat generated is actually generated during the time it takes to switch a MOSFET from full-on to full-off, or vice-versa. This is the time where the MOSFET is actually acting like a (large/varying) resistor, thus generating heat. Usually that transition is so quick most people won't even notice it, but when switching *a lot* it becomes a concern. Note, because of that, HFM/PDM(?) is generally a *bad* option, because its main purpose is to switch at the highest frequency possible. Lots of (sloped) edges = lots of heat. OTOH, switching-times of MOSFETs are improving every day... easily-acquirable Class-D (switching) subwoofer-amplifiers can run at 250KHz switching-frequencies... maybe PDM has a place.

(TODO: Comments in the blog-entry suggest that PDM is actually used for audio encoding... should look into this)

Note, in this case, I could use PWM and a much-larger capacitor where the power-supply enters the circuit... It would have to be something like nearly 100 times larger. As-implemented: 1 count works, I want 33% power-output, 33% * 256 counts =~100! And, actually, I'm unsure as to whether the longer-duration discharge could be recharged quickly-enough without causing the power-supply to sag merely from the recharging-action... Here's where my hypothesizing gets a bit [more] iffy.

Anyways, PDM/HFM seems like the best-choice right now... at least with regards to the power-supply and "big-ass capacitor."

Update (9-9-15 2.0):

Here's a snippet of the 'hfModulation' code:

if(modulator->desiredSum > 0)
{
	(modulator->desiredSum) -= (modulator->maxPower); //0xff;
	toReturn = TRUE;
}
else //avg == desired is handled at the start... (except 0-case which works here too)
{
	toReturn = FALSE;
}

(modulator->desiredSum) += (modulator->power);

I think we have determined with little doubt that this is in fact "first-order delta-sigma modulation" whatever that means!

Update (9-8-15 2.0):

This image is of my implementation of Pulse-Density Modulation on a graphical display...

(from my avr-lvds-lcd project)

Seriously, look at @RoGeorge's #Delta-Sigma versus PWM page for a much more intuitive explanation...

But here's plausibly an interesting visualization.

I don't know why I left the screen rotated sideways for this picture...

The left column of (really large) "pixels" displays a power of 0/64(?), the next column displays a power of 1/64 (notice the one red pixel at the bottom, and the rest of the column is blue). The third column has a power of 2/64 (notice the red pixel at the bottom, and another in the middle). And so-on. At 50% power, 32/64, the column in the middle of the screen, the pulses alternate between red and blue...

(Update 9-9-15)

The following is the output of the 'hfModulation' test-application...

The first two graphics show hfm at various power-levels, (0-100% = 0/5 to 5/5).

Pulses which are on are indicated with '#'

There are two methods of changing the power-level, one is to start a new hfm_setup where you can set both the power-level and the maximum power (5 = 100%, here). The other is to use hfm_setPower, which does not allow changing of the maximum power, but is intended to be used for realtime changes in power, e.g. when fading an LED or simulating a sine-wave.

Using hfm_setup on each change:
0/5:|                                                                          |
1/5:| #    #    #    #    #    #    #    #    #    #    #    #    #    #    #  |
2/5:| # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #|
3/5:| ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## |
4/5:| #### #### #### #### #### #### #### #### #### #### #### #### #### #### ###|
5/5:| #########################################################################|
4/5:| #### #### #### #### #### #### #### #### #### #### #### #### #### #### ###|
3/5:| ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## |
2/5:| # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #|
1/5:| #    #    #    #    #    #    #    #    #    #    #    #    #    #    #  |
0/5:|                                                                          |
Using hfm_setPower on each change:
0/5:|                                                                          |
1/5:| #    #    #    #    #    #    #    #    #    #    #    #    #    #    #  |
2/5:| #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  |
3/5:|# ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ##|
4/5:| ### #### #### #### #### #### #### #### #### #### #### #### #### #### ####|
5/5:| #########################################################################|
4/5:|##### #### #### #### #### #### #### #### #### #### #### #### #### #### ###|
3/5:|# # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # ## # |
2/5:|# # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # #  # |
1/5:|#    #    #    #    #    #    #    #    #    #    #    #    #    #    #   |
0/5:|                                                                          |

Attempting a gradient with realtime hfm_setPower() calls
  #           #    #   #  #  #  # #  # # # # ## # ## ## ## ### #### ########### 

Update (9-19-15): Hypothesizing on matters not really related to the log-title:

While this wasn't the intent, exactly, it just occurred to me that hfM lends itself well to varying the modulation power *during* a "cycle"... E.G. The "gradient" above, as a simple example. That portion of hfM was designed with the original intent of trying to keep smooth transitions while fading an LED between different power levels, without having to align a change-in-power with any particular position in the cycle. It was later improved explicitly for the purpose of creating gradients, wherein the "power" increases or decreases incrementally numerous times within a "cycle".

Now, extend that to something like motor-control, with a feedback loop... The hfM "cycle" duration might be significantly longer than a sensor/feedback-loop update. There might, in fact, be a hundred or more feedback-loop updates during an hfM cycle, or there may be hundreds of hfM cycles per feedback-loop update. It really just depends on the system. But for a simple system, this needn't really be taken into account! An hfM cycle might have 255 counts, initially it's set to 50% power, after 5 counts it's set to 75% power, after 10 counts its set to 31%... doesn't really matter if the set-power varies wildly during a cycle, as that cycle might just as well have been made up of 1 pulse in 256, or 75... Since the system's smoothed enough to handle 1 in 256, then surely it'd smooth whatever completely arbitrary pattern may occur in that 256. (excepting maybe unintended resonance, EMI, etc.?). In a PWM system, however, the power-change is generally only effective after the cycle completes... so, really, there's no reason to have a feedback-loop that updates faster than the PWM frequency (right?). Or, rather, it might be necessary to design the feedback loop to take into account the fact that it can't update the output faster than the PWM frequency (e.g. averaging, interpolation, maybe even extrapolation?).

ah.

So this is roughly life-size...

The teeth, then, are like... *maybe* 1mm at their widest. and, unless I do everything *just* right (yeah, right... especially not from a [low-resolution] photograph) it seems most-likely I'll only really have one tooth making contact at a time... starting to seem a little bit ridiculous.

I am proud, however; I used a different technique to get real-world measurements from the image for the motor-assembly than for the gear/tooth-spacing, and they seem to align.

As far as material... I dunno what to think. I haven't worked with "modeller's plywood" before, but it's hard to imagine the grains crossing the teeth wouldn't be tempted to fall out at these tiny sizes. And, acrylic, well, that's known to be brittle, so probably all the force on a single tooth jutting out at nearly 90deg isn't such a great idea.

Been doing some measurements for the gear...

The seller claims:

"outside diameter of gear 8.7mm/ screw diameter 6.5mm length 19mm"

right...

Anyways, none of those measurements seemed to match anything in the photo. Finally looked up the specs on this otherwise standard-sized motor (and compared to one I have here) 20mm diameter. Judging by that, the *only* measurement that matches those listed is "screw diameter 6.5mm" which is actually the diameter of the flange. "length 19mm" *might* correspond to the total length of the screw to the body of the motor (including shaft and bearing), but that's more like 17-18mm... So... really not much to go on, here. 20mm diameter on the motor seems pretty standard, so I could try to base all measurements off that. Realistically, I guess I'd have to wait till I get these before I can design around 'em. :/

I think this is the answer: There seem to be several styles...

This page is *great* as it gives specs for one, but actually shows three entirely different styles in various pictures (including the style I based the gear on). This picture seems to show worm-gears that might actually match the measurements they claimed.

http://www.aliexpress.com/item/20pc-6V-4000rpm-12v-8000rpm-Standard-130-motor-Green-Micro-DC-motor-with-encoder/1698459475.html

The next image, again, is the one I based my gear on... different seller altogether, none of their products show the straight-worm-gear (seen above) which probably matches the measurements claimed by the seller showing this picture:

http://www.aliexpress.com/item/Great-10pcs-Speed-motor-MABUCHI-Standard-130-motor-encoder-photoelectric-encoder-DC-motor-high-quality/1903700249.html

Frankly, I think this worm-gear would be easier to mate with a gear (as opposed to, maybe, a linear glider, which the other seems well-suited for), as this has sloped-sides which would work with the rotation of a gear. But, I don't even know if these are the ones they're selling!

Found an image of the motors/worm-gear that seemed to be pretty much straight-on... so cropped and cleaned it a bit in gimp, then traced the bitmap into a path in inkscape, then output SCAD code via Make a 3D print from a 2D drawing...

Did some math... and I think I could actually cut a mating gear with a bit more math and measurements:

Interesting experiments this evening...

The other day I found these: http://www.aliexpress.com/item/Great-10pcs-Speed-motor-MABUCHI-Standard-130-motor-encoder-photoelectric-encoder-DC-motor-high-quality/1903700249.html

Actually, I was looking to see if prices had come down on the higher-quality motors with attached-encoders... I had no idea I'd basically find the wonky setup I've cobbled-together for extreme-worst-case-testing as a prebuilt item! OK, the higher-quality motors are running about $30 apiece, so that's not really an option. But these are only $1.50! They look to be darn-near identical to my setup, right down to the encoder-disk and quadrature detector which look pretty much identical to those found in old ball-mice. Kinda funny.

Actually, the motor I was using (described in detail in the last log) is a little bit better-suited for position-control than these, I think. My experience with these style of motors is that they're well-suited for high-speeds, but have very distinct snapping-action when rotated by hand.

So, I had to try it...

(Clarification: I did this experiment with a similar-looking motor I had on-hand, and the mouse's encoder/disk, *not* with the motors shown in the picture, which I do not yet own).

The current setup is such that the motor attempts to resist any external force; tries to maintain its position. Sure-nough I can actually drive 'em with the feedback loop! There exists that distinct snapping action, which means the motor seems to snap between -10 and +10 encoder "ticks" away from where it's intended to be, when external force is applied. (The setup is kinda hard to describe... I'm rotating the motor while the encoder stays stationary, and the disk tries to stay stationary with the encoder. The motor's shaft/disk "snaps" as the motor is rotated, about 1/10th of a turn). But, really, that's minor, especially considering these have worm-drive. (I wonder if I could laser-cut a matching gear for that... maybe right on the drum-pulley?).

And on to the crazy motor driver (L9947, described in a previous log, as well)

So, the motor I've got seems to be working well at about 1/4 to 1/3rd power... which kinda makes sense... alot of these motors are designed to be used *in toys* which are usually powered by a couple AA's... (3V... and I'm using a 12V supply)

And then something hit me... If these things work fine at 1/3 power... then the "crazy motor driver" might actually be usable to its full-extent... It's designed to handle *3* motors, just that only one can be powered at a time. So, if I do some time-division-multiplexing *of* the (essentially) PWM signal... Then maybe I could actually run all three axes "simultaneously" from this one (crazy) motor-driver chip that appears to have not been designed for PWM nor simultaneous motion in the first place!

There're a few caveats to be considered... the motor-driver is heating up quite a bit with this style motor, despite running at only 30% power... I hear they've got nice inductive-spiking abilities, so maybe it's not because they draw a lot of current, but that the motor-driver's diodes are heating up... or maybe because of slow switching-times on its mosfets (though that would've been a problem with the other motor as well, right?). Possible it's the diodes, anyhow... and kinda preferable, because the "crazy motor-driver" is rated for 3A on one motor, but only 0.5A for the other two motors.

Regardless of the motor-driver, these cheap/small motors with attached-encoders (and worm-gear) could be quite handy for this "tiny" system, even if they tend to snap to 36.5-degree increments.

Not sure what to do about "homing", though... which was part of the reason I was considering those multi-turn servos, but those, too, seem to run about $30 apiece, which is way out of my budget. Don't *really* want to install limit-switches/opto-sensors on each axis of this tiny thing, but it may have to happen.

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..

Here's the video submitted for the 2015 quarterfinals, I decided to use it for #commonCode (not exclusively for AVRs)... (see the previous post, regarding how these projects all kinda feed into each other).

I decided to use a strange motor-driver for this project, the ST L9947. This motor driver uses a bus-interface, as in a microcontroller's multiplexed data-bus, as in it uses Data, Read/Write, and Strobe pins, rather than Direction and PWM (or similar) used on most "normal" H-bridges. As a result, it doesn't lend itself well to PWM. In fact, the highest rate it seems to be able to toggle the output is about 3kHz, which is pretty low, and would result in a really slow PWM frequency, if implemented the normal way. For now, iInstead of PWM, I'm using commonCode's 'hfModulation', (I think the official name is Pulse Density Modulation?) which toggles the output as quickly as possible, (3kHz, max) in order to achieve the desired power. This is the same code used for fading the 'heartbeat' LED. It seems to work, but as you can see in the above video, it is quite audible on some motors (especially when mounted to a 'resonating chamber' like a hollow tabletop!). I may try to push this chip's limits further, but before then I need some positional-feedback.

For positional-feedback, again, I decided to go a strange route... I do have DC-Motors with encoders built-in, but wanted to try something new... So I took out the box of old ball-mice (remember those?). I thought about a few other options. I have a beautiful old continuous-turn rheostat that's designed for the purpose, that will have to get used at some point! I also have a cool multi-turn inductor-tuner from an old radio that could be quite cool to implement at some point. But, for the sake of this project, I need something I can reproduce at least two, probably three times (for each axis), or more if I actually produce more than one of this thing...

Anyways, some initial experimenting with the mouse's encoder-disks and phototransistors looks promising. The most difficult part, I guess, will be attaching the disks to the shaft and still having enough shaft left-over to drive the drum pulleys (most-likely would need to be gear-reduced, as well... so we'll see. Thoughts on pulleying the cables directly around the shaft already attached to the encoder-disks, but I'm not sure about slippage...).

The output of the phototransistors is analog, of course... the signal is roughly sinusoidal. The obvious choice would be to feed this signal into comparators, and the PIC32 has several. There are also thoughts about using ADCs and trying to get more resolution that way. Interestingly, I've looked up the datasheet for the PIC16C57 used in the mouse, and it seems its inputs are TTL-level, not schmitt-triggered... So, I guess, I could maybe just treat the signals as digital. That analog-effect is accentuated by running the circuitry at 3.3V (PIC32) rather than the 5V of the original mouse, so maybe changing some resistor-values would help square things up.

The other thought was to use the mouse-circuitry as the decoder. Connect the PIC32 to it via the PS/2 protocol. This seems reasonable, except apparently PS/2 is limited to about 17kbps, at 3 bytes per packet, that'd be pretty slow. And, it seems, the fastest reporting-rate for mice is 200S/s, which isn't much, considering as I recall the AVR version updated the motion-control loop around 30,000 times per second.

OTOH, I don't know much about their precision.

Anyways, here's the video:

A summary of the "big three", no not the big-three commonThings, the big-three projects currently highly-involved in their development:

https://hackaday.io/project/3828/log/23266-this-is-getting-confusing-video

The 'main three' are finally running on PIC32: 'heartbeat', 'polled-uat' and 'polled-uar'...

so we have I/O, timers, and a bitbanged UART. Now, finally, on to motion-control: #2.5-3D thing