Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

DIY Quadrature Decoder/Counter Interface

Status
Not open for further replies.

AllanBertelsen

New Member
I need some quadrature wheel encoders for my robot.
I want to use encoder wheels and ID LEDs and detectors from a pc-mouse.
The inspiration came from

I have been looking for Quadrature Decoder/Counter Interface ICs. They are quite expensive.
I was thinking of making one myself by logical circuits. Now my MCU is a PICAXE. My concern is if it is fast enough. So my idea is to use up and down counters for the counting part. I don’t want to miss counts. So I will use registers for keeping the counted values. The loading of the counted values and the resetting of the counters can happen in parallel. Then the mcu can read the data in serial and do its odometry/PID things without missing counts.

But I'm not an engineer, so I could sure use a second opinion.

Take a look at the attached gif please.
 

Attachments

  • Quad encoder.GIF
    Quad encoder.GIF
    6.8 KB · Views: 5,936
Thank you for the link. It just don't answer any of my questions. I have been reading tons of sites that tell how to hack a mouse. What I am asking about is a way to store the counted values outside my MCU while it is doing other things. The schematic is just conceptual – I know. It's more the idea behind that is in question.
 
hi allan,
I understand, I thought you were looking for alternative ways of getting a quad signal.

Regarding your logic drawing, I have used a similar method on a 360.0 degree horizontal and vertical laser bearing unit.

I generated a quad signal and direction bit, using a 900 counts/rev optical encoder, gave 3600 counts/rev.

The up/down counts were clocked into separate 16 bit binary counters, the cpu read them to determine the angular movement. The only difference I can see between our two systems, is my optical encoder give me an index pulse at 0.0 degrees
as I required an absolute angle.

Your circuit should be fast enough, what sort of count rate are you expecting?
 
Last edited:
Hi Eric
My motor has a rated speed at 5900 rpm. The encoder wheel has 64 slots. So my max count would be 6290 pulse per sec. 8 bit counter would be filled in 0,04 seconds. I think I will add a counter more per wheel and 74HC165 more to make it 12 bit counters. Then it will be filled in 0,65 seconds.
 
Diagram

To be more specific. Here is a diagram of what I had in mind.
 

Attachments

  • Quad encoder 2.GIF
    Quad encoder 2.GIF
    11.9 KB · Views: 8,577
hi Allan,

Just for interest, what PIC and xtal clock are you using ?.

I am not a robotist, but I imagine that some of the technical problems you have to solve are challenging.

As a side issue, you could, if required in a later project, increase the resolution of the quad wheel output,
by creating a count pulse on the leading and trailing edges of the quad pulses.

Lets know how it goes.
Regards
 
Hi Eric,


The PICAXE 18X is running at 4Mz. I think the PICAXE 18X is based on PIC16F88-I/P. It can be over clocked to 8Mz. RevEd estimates that it's 10,000 basic commands per second (double if over clocked). Loading data to registers, resetting the counters and reading the registers would take approximately 150 basic command executions. I would use register IC's for feeding speed commands to MCU (16 bit of data) and for sending commands to two PIC12F683-I/P's that are going to provide the PWM-signals for the motors (that’s 16 bit of data to). That should sum up to 400 basic command executions including PID calculations. With 10,000 commands per second it should be able to do the whole operation 25 times in a second.
What technical problems do you see?
I read about doubling resolution or even making four times better by using both leading and trailing edges for both encoder channels.
With the gearing and wheel size I'm using. One pulse is 0,02 cm. So to travel 1 cm it gives 46 pulses.
 
hi Allan,

The 16F88 PIC using the internal clock will run at 8MHz, INTOSC.

I cannot see any problems with the draft circuit are you going to test the quad, counters and SR's 'off line' [not PIC driven] using a test setup?
 
ericgibbs said:
The 16F88 PIC using the internal clock will run at 8MHz, INTOSC.

The trouble is a PICAXE runs a BASIC interpreter, reading tokenized code from the internal data EEPROM - so it runs a HUGE amount slower than a naitive PIC. It may be slightly faster than a BASIC STAMP (because it's not reading an external EEPROM), but it won't be much faster.
 
hi,
>> PICAXE runs a BASIC interpreter, reading tokenized code from the internal data EEPROM.

I would agree, basic interpreters are slooow.

I'm not upto speed myself regarding these robotic projects, hope Allan is aware of these limitations.

Enjoy the Easter break.
 
picaxes are actually pretty fast. Yes they are 10 times slower than pic, but this is still fast ;).
now that there are picaxe X1 released and X2 on the horizon it gets even faster.
X1 is 20MHz and X2 is 40MHz. Ps X1 can be overclocked to 30MHz...
 
The question is not if it is fast or not. The question is: can it do the job? Would 25 or 50 PID cycles per second be fast enough for a rover travelling 1 meter per second. Some of the very advanced projects I have seen on the internet do not use that many cycles.
 
AllanBertelsen said:
The question is not if it is fast or not. The question is: can it do the job? Would 25 or 50 PID cycles per second be fast enough for a rover travelling 1 meter per second. Some of the very advanced projects I have seen on the internet do not use that many cycles.

Is this why you're talking about counters?, rather than reading the encoders directly with the PIC - I would have thought a PICAXE would be fast enough for that, because there's nothing speed critical. Probably be different without the counters though?.
 
The counters are 4-bit up/down binary counters. So the counting is happening outside the MCU.
Three cascading counters would give me 4096 counts. Now it can count both up and down so I got to read the counters before they have reached 2048 counts up or down. That would be done in 0.33 seconds at my motors max speed. The loop speed has to be better than 3Hz.
This page https://www.societyofrobots.com/programming_PID.shtml tells that at least 20Hz is to desire.
With this setup two motors can be controlled at once at 25Hz. I don't think PICAXE can do it directly at this speed.
 
I'm sure I've missed something, but why do you need to calculate the rotation direction on a robot?
Isn't there a simpler way of determining direction based on the direction of current going to the motors? Then all you have to do is count the wheel rotations, easy. I assume your robot uses some form of H-Bridge.

On my Mongoose design I use RB4 & RB5 (PORTB 4,5) as they support interrupt on change. The maximum is about 100Hz per motor.
 
Last edited:
Isn't there a simpler way of determining direction based on the direction of current going to the motors?
That'd be hard to do if you used a motor braking system as I've described in Omar's Motor Controller thread. Also, I don't know if it's good form for feedback control to read signals/power and to use that value to inform your process, rather you should be doing your best to read what's actually physically happening as directly as possible. Otherwise, your feedback gets introverted with circular, self-verifying proof (e.g., send a signal, read the signal, the signal is verified therefore what is expected to happen must be happening - not a good idea). Just saying.

As an example of good and better feedback in a particular situation, supposing you have an encoder reading how far your robot has moved. For the robot's application, you want it to move from where it is across ten feet of floor and stopping just before it hits the wall. Reading the motor current will tell you that your robot is heading towards the wall, but not how far it's travelled. Reading an encoder can tell you whether or not the robot is heading towards the wall, and can speculate on how far away the wall is based on how much the wheels have rotated. But suppose the wheels didn't get good traction, so they spun a bit before the robot started moving? The robot would stop short of its desired position, while presuming it's in the right place. An even better feedback method for this application would be to have a sensor on the front of the robot "seeing" if there is something, like the wall, in front of it.

When I went to an university engineering projects conference last spring, the top guys were all about drilling the students on feedback control. It's one thing to create a process that does something, it's another altogether to build autonomous control so the process works better. Where you draw the line is ultimately subjective, which is why I like the signature someone has on this forum (can't remember who) of "Close enough is perfect."
 
Last edited:
My robot is going to be rather big 10-15 kg. It will drive around in my garden. I got to get as much precision via odometry as possible. It has to travel 15-20 meters without any landmarks for navigation. Quadrature Decoder/Counter is state of the art. The point about quadrature is the 90 degrees out of phase signals that make it possible to detect direction. I bought some robot books: One mention the technique but nothing about implementing it. If you want to know exactly what your motor does, you put a quadrature encoder wheel on its shaft.
And guess what, the quadrature encoder wheel and the IR led and the detector are so cheap. I took my from an old computer mouse. I made a test on my breadboard yesterday. The only things you got to add is a d-type flip-flop, two resistors and maybe two caps.
Yesterday I finally found some support for my idea.
Look at the bottom of this page:
 
Last edited:
If you want to know exactly what your motor does, you put a quadrature encoder wheel on its shaft.
Sure, but what your motor is doing and where your robot actually is are two different things. I'd find some way to reset the encoder info a few times during the course of a mow (if that's what your doing).

Did you look into the advantages of taking the mouse encoders versus leaving them on the mouse and just reading the ps/2 signal?
 
Last edited:
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top