Project Logs

Collapse

• project crossover, again...

  Eric Hertz • 09/15/2015 at 08:07 • 0 comments

  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.

• PWM vs Pulse-Density Modulation: Power Supply

  Eric Hertz • 09/02/2015 at 13:30 • 12 comments

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

  Read more »

• life-size

  Eric Hertz • 08/27/2015 at 02:57 • 9 comments

  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.
  

• BEWARE THE ALI-EXPRESS, ETC!

  Eric Hertz • 08/25/2015 at 12:14 • 0 comments

  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!
  

• Gear Cutting

  Eric Hertz • 08/25/2015 at 04:49 • 9 comments

  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:

  (Of course, this is the cutout-piece that will be subtracted from a cylinder)

  
  

• Crazy Motor Driver and Crazy Motors Revisited

  Eric Hertz • 08/23/2015 at 12:10 • 0 comments

  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.
  

• a bit ridiculous...

  Eric Hertz • 08/19/2015 at 12:24 • 0 comments

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

  Read more »

• Vids! Ball-Mice! Crazy Motor Drivers!

  Eric Hertz • 08/18/2015 at 12:36 • 0 comments

  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:

• This is getting confusing!

  Eric Hertz • 08/17/2015 at 16:48 • 0 comments

  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

• motion-control, here we come!

  Eric Hertz • 08/11/2015 at 14:37 • 0 comments

  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

  See more about the PIC32 porting-process at: https://hackaday.io/project/6450/log/22496-finally and #operation: Learn The MIPS (PIC32MX1xx/2xx)

View all 17 project logs