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.

For this project (as opposed to the porting of my existing motion-control code to PIC32, which is the current goal) there's also the possibility of multi-turn R/C servos (typically used for winches on R/C sailboats, apparently). They would lend themselves well to this system, because they wouldn't require a "homing" routine nor limit-switches, which would be nice.

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

Anyways, here's the video: