next topic »

[Reply #15 on:]

Hi,

There is a very cheap and simple way of ensuring that the sample stops in exactly the same place every time if that will help. But the last turn or two will need to be slowish.

Would this be of any help?.

Mark

Hi Mark.  Yes, that would definitely be helpful.  I'm willing to have the last couple of turns be slower.  Thanks for any suggestions you may have.

[Reply #16 on:]

Make a card disk with a radius 2 or 3 times the length of your sample. Cut a small hole near the edge of the disk.

Fit the disk to the motor spindle so that it can't slip.

Now place a LED behind the disk so that it will be seen through the hole in the disk as the disk turns.

A Photo resistor(PR) is placed in front of the disk so that light from the LED will fall on the PR when the hole in the disk passes and the light is blocked the rest of the time.

Connect the PR via a voltage divider to an analog pin.

The value from the analog pin will be low when the light from the LED can pass through the disk and high when it can't.

Take the last few turns slowly and when get a low reading stop!.

You may find you need to fit some kind of "sunhat" to the PR to cut down on the effects of ambient light.

The PR also gives you a  rev counter.

Mark

[Reply #17 on:]

Great!  Can you point me to a good reference for coding a deceleration ramp?

I'm not aware of any reference off hand.  The basic gist is that you arbitrarily slow down the motor as you approach your target point.  There are a variety of ways to accomplish this.  A first pass crude approach would be to pick a couple points prior to your target stopping point and reduce the motor speed first to 2/3 speed, then to 1/3 speed.  The end goal is to have the motor come to a more controlled stop as it approaches it's target reducing overshoot and inaccuracies in where you stop.  By adjusting the points at which you reduce motor speed and the amount of speed reduction you can fine tune your specific setup for optimal performance.  You can also increase the number of deceleration points if you want to provide a smoother rate of deceleration, but that should have little affect on your end goal of stopping at a specific location.  That goal could very well be accomplished with a single deceleration point.

[Reply #18 on:]

I'd love to hear more about incorporating a bias - sounds cool!

No, it's not at all cool and nowhere near as elegant as the other solutions being suggested. Basically you arrange the motor so that it stops in a consistent position. Probably, being a DC motor it will already have several positions that it likes to settle in due to the position of the magnets, and which one it falls into is just a game of roulette. If you bias the motor, for example by putting an eccentric cam with a sprung follower, you can arrange for it to always stop in the same place.

[Reply #19 on:]

Thanks for all the help, folks. I'm getting closer...At the moment, my encoder pulse counter ("encPos" in my code above) appears to be giving me a HIGHER value than it should for a given number of motor rotations, even accounting for inertial overshoot. While this gives me hope that I'm not missing encoder transitions at this high rotation frequency (something I was originally worried about), I'm not sure what to make of it. Is it possible that I'm picking up "bounce" in my signal, causing the interrupt to trigger more frequently than it should?? I've seen references of bounce coming from hardware switches, although I'm unclear on whether it can happen in quadrature encoder signals as well?

In any event, If I can sort out the encoder signal to give me an accurate reading, then I'll use it to implement a crude deceleration ramp (thanks, jraskell.)  If I can't tame the encoder, then I'll revert to holmes4's photoresistor method, which sounds very promising. I'll come back to update with progress...

Again, many thanks for the assistance!

[Reply #20 on:]

I would not expect bounce but looking at the motor description it says it runs upto 1000 rpm with 480 pulses per revolution.

If you are running it at the speeds you indicated earlier it's possible that the encoder is working much faster than its designed spec and is not reliable.

[Reply #21 on:]

I would not expect bounce but looking at the motor description it says it runs upto 1000 rpm with 480 pulses per revolution.

I've removed the motor gearbox, though, so I'm down to 48 counts per revolution of the motor output shaft. And I'm only listening to one encoder channel, so 24 counts per revolution. If I rotate the motor at 230 Hz, then I'm triggering the interrupt every 181 microseconds. I dug up this thread, where someone states that the Arduino can distinguish between 64 and 68us:
http://arduino.cc/forum/index.php/topic,19671.0.html

Nevertheless, I hear your concerns. I'm definitely up there in frequency, which might produce an unreliable encoder signal.

[Reply #22 on:]

Sorry to dig up an old thread. But, I am curious, was this resolved?

I'm not familiar with the Pololu Simple Motor Controller you are using?

Have you tried DC Braking? It sounds like you are just coasting to stop.

http://ivan.blogs.chimerical.com.au/post/2008/04/You-spin-me-right-round2c-baby2c-right-round.aspx

Theory and schematic:
http://www.societyofrobots.com/schematics_dcmotorbraking.shtml

A high wattage resistor can be installed in the braking loop if it is a high inertia load or it just plain stops too fast. Of course your motor may not have enough residual energy to work well with braking but it may get the number of encoder changes down to a useable level. You may have to use a relay contact to disconnect the motor from the controller when the brake is applied. The same relay will work N.O. to the brake and N.C. to the controller.

Here is a nice brake controller without relays:

http://www.discovercircuits.com/H-Corner/dcbrake.htm

[Reply #23 on:]

Just found this:
http://store.iteadstudio.com/images/produce/Shield/MotaMama/MotomamaV1.0_DS.pdf

It has a Fast Motor Stop command.