Optical Encoder Algorithm...Dedicated Motor Controller

Width of the Magnets affecting the Hall Sensor?

Hi Rick, you've got yourself a real real time problem here.

Either may work. Both will change with speed. The time in-between will likely be more stable, because it is longer. The pulses may tend to fall off in ratio'd width at higher or lower speed, depending on our sensors, so either could be off a bit.

The real answer is "none of the above". For accurate rate, you should take leading edge (or trailing edge) to leading edge (or trailing edge) and then you are reading a whole cycle.

________|``````|________|``````|___________ **************** (That may not look right in non ps font, but the intention is to cover the whole cycle, narrow part plus wide part.)

And here's where the real time problem comes in. And maybe some state programming.

The short answer is, without hardware help, you can't measure both wheels accurately. You will always be off sometimes when both edges occur at the same time. You'll have to service one stream, the first you detect needs service, and not the other. Your second reading will be off by the latency of your processing system, or in other words, how long it takes to finish one process before doing the other.

I don't know the PIC's well, but often micros can latch their timers on edges. If you had two timer inputs, you might be able to do this, and let the hardware in the timers pick up the timer count, and hold it until the micro could process the result. If the micro could service both channels before the next edge could come along, you'd have it.

The classic PIC approach might be to use two PIC's one for each channel. But this only obscures the problem, because you now have the information in two processors instead of one, and getting the information into a single one is yet another real time task, and you can loose data just as easily by trying to send and recieve data when your other task occurs as having the original two tasks.

I did a job like this recently with the IsoPod(TM) where I read six channels of quadrature and also obtained the velocity of each channel by measuring the length of the pulses with a single processor. (It also had two real time serial streams and floating point positioning calcs going on.) If you've got good hardware timer channels, it's quite possible.

Call it a 'Rotation Sensor' perhaps ?

6 'steps' per wheel revolution is a bit coarse for any kind of precision navigation

Not a good idea - the apparent width of the pulses will vary with different magnet strengths etc

Not a good idea, for the same reason.

Measure the times between successive rising (falling) edges instead

The PIC is zillions of times faster than your wheels ! For something like this, make a fast counter that runs continuously, then either use interrupts to 'grab' the counter readings, or just a polling loop. Even if the PIC is ten or twenty microseconds late reading, you'll never notice the tiny error that results - you do not need to know the speed exactly.

Of course you still need to do the arithmetic on successive counter values to get speed etc. Don't forget to do unsigned arithmetic when needed, and think about how to cope with low speeds (= big counter values) and change of direction.

If you only have a single sensor per wheel, you don't get the wheel direction, which makes odometry considerable more interesting ... (Read up on quadrature sensors - usually optical, but hall effect ought to be possible)

Have Fun !

Dave

I have to disagree on this one. Using hall effect sensors is a perfectly valid means of obtaining good, accurate pulses out of a rotating element. Just about every automobile made today does it, with the anti-lock wheel rotation sensors.

Allegro makes some nice hall effects, and even makes some quadrature based devices as well, at a specific pitch.

I do feel that your resolution for odometry purposes is a bit low.

Something I have been meaning to do is to use refridgerator magnets for this purpose. With linear hall effects, and an a/d, you could possibly make a very high resolution sine/cosine encoder.

'Fridge magnets have alternating north south domains, and if you could cut them accurately on a domain boundry, and glue them together on a diameter, you would have much more resolution.

just my $0.02

Mike

6 pulses per rotation is too low? The Wheel diameter is 3 1/4" That means I'll get a tick about every 1.7" using 6 magnets. I'll get a tick about every .85" using 12 magnets. I'll get a tick about every .425" using 24 magnets. I'll get a tick about every .284" using 36 magnets.

Well I understand that the higher resolution will always be more accurate, but what would be a truly usefull number of ticks per rotation then?

12?..36?

Thanks, Rick-

Rather than use lots of magnets, what is usually done is to use a steel toothed wheel (gearwheel perhaps). The Hall sensor sits so that it just misses the edge of the teeth, and it is backed up by a (single) magnet. As the teeth of the wheel move past, the magnetic flux through the hall sensor varies. Depending on the geometry and resulting field strength etc, you can either use an analog Hall sensor and the A/D of the PIC, or a schmitt trigger - threshold type sensor. A pair of analogue Hall sensors will give you a nice quadrature system.

Gaps need to be small to get reasonable magnetic fields, and you may need to build a flux concentrator (same idea as pole piece on a magnet).

As for how many steps per rev - it all depends on what you expect to do. For any kind of precision positioning etc then an odometer tick of perhaps 5 to

10mm sounds reasonable. Remember that the tick size, combined with your wheel geometry tells you (very roughly) what sort of angular misalignment will result when you try to turn through any given angle.

Dave

Consider that odometry is used for two general purposes: speed control of the motor, and distance measurement. On most robot platforms, the distance measurement is terribly inaccurate over time (inches, even feet), especially over carpet and uneven surfaces. The error is "unbounded," meaning that it grows progressively, especially at each turn.

In order to ensure accuracy for distance measurement you need to be really careful about all the facets of the robot's construction -- even little differences like minor variations in motor mounting and wheel diameter can greatly affect accuracy. Most homebrew robots lack this type of accuracy in construction.

So, depending on the application, eight or 10 "ticks" per revolution may be perfectly acceptable given the overall accuracy you're trying to achieve. Six ticks may be a little low if you use a single-channel encoder, but that's up to you to decide. And, if what you're after is speed control, then even a low resolution is usually sufficient, because you're looking for an average.

If you're careful about placement, you can construct a quadrature Hall effect odometer, using the same number of magnets, but a second sensor (can be located on the opposite side of the wheel, but 90 degrees out of phase -- with respect to the magnets - of the first sensor). You then quadruple the resolution -- six magnets yields 24 distinct phases per revolution. You need a quadrature decoder for this setup, but if you don't want to buy a ready-made chip for the job these can be constructed using simple gates. Or, using something like Randy's product, you can interface multiple quad encoders to one microcontroller, and be done with it.

With quadrature encoding you can also detect wheel direction, but this is usually something of a bonus for gear-reduced motors, where the output wheel doesn't readily turn when not powered. It can be useful in "set-and-forget" hardware counters, where the encoder can count up and down automatically, without you telling it to count up (going forward) or count down (going backward).

-- Gordon Author: Constructing Robot Bases (Forthcoming) Robot Builder's Sourcebook, Robot Builder's Bonanza

Rick Cassidy wrote:

[Zagan] I've had some experience designing "hall effect" sensors as used in pneumatics (fluid power cylinders, etc.) for position sensing. Actually we were using magnetoresistive sensors (which are more sensitive than hall effect devices) but the principle is similar. One of the problems you'll run into is that different sensors will have varying "sensitivity" and the magnets you use will vary in flux density. This will affect the "on" and "off" response from magnet to magnet and per wheel. Plus, the equidistance spacing of the magnets around the wheels with be a problem.

Unless the accuracy you require is low, I expect you will have problems "calibrating" your wheels to match. Although such devices are used in applications requiring significant accuracy, this accuracy is obtained using precise machining and magnetization of magnets and matching sensors. Unless you have the ability to provide such precision (if required), I expect you may run into problems.

If your application works as you intend, I would suggest using the rising or falling edges of the sensor output for your calculations.

Another thing to consider is that motors of the same type don't necessarily match in rotation for a given applied voltage (or PWM). This is one of the reasons optical feedback is preferred. In the design I'm working on, I will be using optical feedback on initialization to determine if a "bias" needs to be applied to one of the motors so that "straight" travel as well as differential turns, etc., needs to be applied to one of the motors.

All this might be overkill for your application; it depends on the accuracy you need. although I have extensive experience in mechanical, programming, and electrical design, I still consider myself to be a newbie to robotics. I will be interested in the results of your efforts, so please post what you learn.

Best Regards,

// Jim

Actually Allegro makes a hall effect gear tooth sensor that can count the gear teeth, It's really cool, you get as many ticks per revoultion as you have gear teeth. I've noticed a lot of auto manufacturers use them on the flywheel starter ring gear now.

This is also the sort of thing used in wheel speed detectors for anti-lock brakes.

misalignment

Actually, speed control with a low resolution sensor is a bit of a nightmare - the problem is that the speed updates just don't arrive rapidly enough to derive a useful value for 'average', and this is usually a good way to get a feedback loop to overshoot or worse.

Have fun !

Dave

Define "rapid." That's in the eye of the process control, and is a subjective value. I used to think more was better until I played around with a Big Trak motor on some early bots I built. The motor included a low resolution (8-10 hole) optical encoder on one of its output gears. Milton-Bradley used a microcontroller for speed and distance control on the toy, but I used a simple discrete circuit based around a one-shot set with a fairly slow delay. Certainly not perfect, but reasonably effective.

I agree that if one has the choice, go for more resolution, as it makes other parts of the design esier. That's not always a possible choice, though.

-- Gordon Author: Constructing Robot Bases (Forthcoming) Robot Builder's Sourcebook, Robot Builder's Bonanza

The wheel encoders I used produce 64 ticks per revolution and that's counting the rising and falling edges of the pulses. What others have said about the pulses varying in width is true which is why I decided to count edges. I'm using optical devices though which produce pulses from a black and white striped encoder disc. The system works well. There's an article on it here, I did something similiar to this.

I have to agree with others that your resolution is a bit on the low side and you may not get the kind of results you're after.

I used a pulse input co-processor to handle the wheel encoder input. Got it here. Nice device.

Best regards,

Sorry the link I gave you for the pulse input processor was wrong. It's actually here:

-Dave

Again, 1 notch on a disk an provide very high speed resolution, if you count clock pulses between wheel pulses.

Another interesting thing about encoder resolution, as far as PID is concerned is having too many pulses, which can saturate things.

Mike

Not only neat but a terrific idea someone should "re-invent."

-- Gordon Author: Constructing Robot Bases (Forthcoming) Robot Builder's Sourcebook, Robot Builder's Bonanza

"> If your application works as you intend, I would suggest using the rising or

necessarily

This is also something that will be achieved. I sure will post the results. Thanks,

Rick-

Not really sure what you mean there. But I suppose at high speed it would be okay, at low speeds though, I don't see how one count could give good resolution.

Agreed. Even with the 64 ticks per revolution on my robot wheels I find that I actually get better results by taking samplings of the number of ticks every 1/8 turn or even 1/4 turn rather than continuously. Waiting a longer period of time to sample gives you a better picture of the speed differential between wheels, at least at low speeds anyway. Best regards.

-Dave

>

>

If you set up a counter to count pulses on a crystal driven clock for instance, and count those clocks between transitions of your wheel encoder, you will end up with very high resolution velocity information.

Mike