Encoders : Quadrature or not? and other Questions

[Rebelgium]

I'm planning to make optical IR encoders for my new (object avoiding, mapping, ...) robot, but I have some questions about that.


I'm making the encoder disks myself, what gives the best results?
- encoder discs printed on transparant sheets
- or encoder discs printed on normal paper
I know how to make both of them, but I can't seem to find what kind is the least prune to noise/to weak signals...



I'm using the PIC18F4431, this PIC has a QEI (Quadrature Encoder Interface). I know Quadrature encoders give you the speed AND the direction of rotation.
But this PIC only has ONE QEI... :/  And ofcourse I want to monitor my two wheels.
So what's my best option here?
- Use the QEI and use two other pins on the PIC to program my own QEI (I know how to program it)
- Or use the two QEI pins as two INPUT CAPTURE pins (another function of these pins).
  This way I'll use two normal encoders (with just one IR LED and receiver pair per encoder) and connect the two receivers to the two INPUT CAPTURE pins.
  Ofcourse then I'll only know the speed and not the direction of rotation... But is this such a problem?
  Do I really need direction info on my robot? How would you go about programming a PID or PD controller without directional info?



I'm not completely sure what the INPUT CAPTURE interface is for, and what you can do with this. Can anyone with some experience clarify this for me?
Also, what's the "QE index pin" for?


Thanks in advance

[Rebelgium]

can't anyone answer any of my questions?

[paulstreats]

Using quadrature encoders requires 2 inputs each. So maybe a way to go about it is to wire 1 output from an encoder to an interrupt port and the other output to a normal port. This way when an interrupt occurs, you can read the value on the other pin. PICs usually have more than 1 interrupt so you can easily do it like this (i think that a lot of work will need to happen with the whole remembering the last sequence and comparing it to the new).

A better way is if you have 4 interrupt ports to use.

Failing that, use 1 pic for each motor encoder and amalgamate their data

Ignoring the above, i think that you might have misunderstood the way the qei system works. 1 of the outputs from 1 encoder goes onto QEIA the other output from that same encoder goes onto a capture port (say CAPA) (you must set the latches in code). So you can ask the QEIA port to capture on either high or low (high has more options). So if its set to capture high, when it registers a high signal then its obviously captured the speed, by reading the CAP1 pin it can determine the direction by wether that pin is high or low(or black or white from the encoder disk).
This leaves the other QEI pin free for the other motor encoder.

You will have to make sure that if you are using ir receivers that they are placed correctly otherwise the system just wont work. (they have to be set so that when 1 is only just on a black edge, the other is halfway between white or halfway between black).

Remember that the qei system is timer based and so can only register data by checking for it which means that if you develope a superfast system then it is going to fail you but for normal application then it should be fine

[ALZ]

Hi:  I never felt a need for "Quadrature  encoder" on a robot. You are the one who is turning on the motor with your program so you better know what direction they are going in.

I just put a hole or 4 holes (depands on the speed of the motor) thru a piece of cardboard  for my encoder wheel.  The outputs can be wired thru a cap (you just want the AC) to the comparator pins on the PIC.

[JesseWelling]

What if your robot thinks it's going up hill but it's actually rolling down the hill because it's not giving the motor enough 'juice' ? Also what happens if your AI commands the robot to go from full forward to full backward? You would loose a lot of encoder counts....

In an open loop system it would be fine. But in a closed loop system it could mean death and decapitation depending on how big your robot is....

[ALZ]

"Also what happens if your AI commands the robot to go from full forward to full backward? "

You don't loose any counts. You may loose a gearbox.

"What if your robot thinks it's going up hill but it's actually rolling down the hill because it's not giving the motor enough 'juice' ?"

There are many ways to take care of that problem without using an quadrature encoder.

1) If you have a current sensor on the motors, you would know something is wrong.

2) The count would slow down to zero before the wheels went backwards. again you would know something is wrong.

[JesseWelling]

I've never lost a gearbox because of that... But I do use speed controls that have regenerative braking.
But more to the point, You will loose counts because of the mechanical system doesn't react as fast as a step command across 0. So while you think your counts are going in reverse, they are actually still going forward. If you are closing the loop on speed, this can throw off a PID system because of the non-linearity around 0. Maybe not so much of a problem for Ackerman steering, but a real problem for differential steering.

And while the two options you suggested for the hill problem will work and have worked in the industry in a pinch, they aren't considered optimal solutions compared to the simplicity of an encoder... Not to mention they will take more time to develop than an encoder when it comes to software.

But to each their own

[bens]

1) If you have a current sensor on the motors, you would know something is wrong.

2) The count would slow down to zero before the wheels went backwards. again you would know something is wrong.

The issue usually isn't knowing something is wrong but rather keeping accurate track of your position and orientation over variable terrain and potentially rapidly changing accelerations.  If you go from full forward to full reverse, your count will become inaccurate if you don't have quadrature.  Can you deal with the inaccuracy?  It depends on how crucial accuracy is to your particular application.

- Ben

[ALZ]

"I've never lost a gearbox because of that... But I do use speed controls that have regenerative braking."

"Also what happens if your AI commands the robot to go from full forward to full backward? You would loose a lot of encoder counts...."

Then you are not going "from full forward to full backward?" you are slowing down to zero then slowly going to full speed backwards.  

You do not loose counts. You write the program to only go backwards once the motors have stop. You know the robot has stop when it doesn't count anymore pulses from the encoder. Now the program tells the motors to go backwards. Now the program knows the count is for backwards. There is nothing hard about it.

[bens]

You do not loose counts. You write the program to only go backwards once the motors have stop. You know the robot has stop when it doesn't count anymore pulses from the encoder. Now the program tells the motors to go backwards. Now the program knows the count is for backwards. There is nothing hard about it.

No one said it was hard, but I think you are neglecting that one is often trying to optimize many different facets of a robot.  It is not always an option to make your robot so slow as to wait for it to fully stop before accelerating in another direction.  If speed and responsiveness is an important characteristic, or if accuracy of your counts is paramount, then quadrature encoding is the preferential way to go.  If you don't care so much about accurate position/orientation tracking or if you can afford to go at a slow, leisurely pace, you can get by just fine without quadrature.  From your posts it seems as if you want to universally write off the usefulness of quadrature, and, if so, that's what I'm objecting to.  Quadrature definitely has its place in robotics.


- Ben

[Rebelgium]

You do not loose counts. You write the program to only go backwards once the motors have stop. You know the robot has stop when it doesn't count anymore pulses from the encoder. Now the program tells the motors to go backwards. Now the program knows the count is for backwards. There is nothing hard about it.

No one said it was hard, but I think you are neglecting that one is often trying to optimize many different facets of a robot.  It is not always an option to make your robot so slow as to wait for it to fully stop before accelerating in another direction.  If speed and responsiveness is an important characteristic, or if accuracy of your counts is paramount, then quadrature encoding is the preferential way to go.  If you don't care so much about accurate position/orientation tracking or if you can afford to go at a slow, leisurely pace, you can get by just fine without quadrature.  From your posts it seems as if you want to universally write off the usefulness of quadrature, and, if so, that's what I'm objecting to.  Quadrature definitely has its place in robotics.


- Ben

If I'd want to go from full forward to full reverse with normal encoders, i'd program this:

go full forward;
short the leads of the DC motor; //this causes braking
wait untill the encoder doesn't count anything anymore; //standstill
go full backwards;

But ofcourse, as bens said, for more professional robots which are heavier and where accuracy is important, or on rough terrain, quadrature encoders would be neccesairy.
But in my case it isn't essential. I'd use quadrature encoders, but in my case it's just easier to use normal encoders (with the Input Capture interface of the PIC)

[ALZ]

Quadrature encoders will tell you what direction you are going in but they will not give you anymore accuracy over rough terrain than a plain encoder wheel. I don't care if the robot stops fast or slow, it is still easy to write the program so that it doesn't loose any counts.

I don't know why anyone would reverse voltage on a DC motor when it is going a full speed other than to blowout your gearbox !  I have stop a 60 lbs robot on a dime just by shorting the leads of the DC motor. I learned never to do that again.

"universally write off the usefulness of quadrature,"

I am not writing off the usefulness of quadrature encoders. They are fine if you have no idea the way something is turning.  Maybe something that is being turn by the wind.

[JesseWelling]

Well, to each their own then.

But you forgot the added benefit of twice the resolution with quadrature as well

[Rebelgium]

Quadrature encoders will tell you what direction you are going in but they will not give you anymore accuracy over rough terrain than a plain encoder wheel.

I didn't say QE give you more accuracy over rough terrain, I said they are better.
For instance if your bot is standing still on a slope, and it needs to go forward so you give it some juice, but because of the slope it will rol backwards etc... If you don't have QE in this case you wouldn't know you're running backwards and think you're fine.

[paulstreats]

Lets face it, if youre going to go to the effort of adding encoders. Then you might aswell put in the extra work and add quadrature encoders.

I guarantee that a couple of weeks after adding encoders youll think, only f i put in the extra effort....... Theres so much more my robot could do........

 

[Rebelgium]

true, but the PIC18F4431 only has one QE interface... How hard do you think it'd be to add another one?

[paulstreats]

There is another way of doing it using interrupts aswell.....

jusrt for arguments sake, say that pin b0 is an interrupt pin and pin b1 is a normal i/o pin.

if b0 is wired up to the first ir sensor and b1 is wired up to the other. set the interrupt on n0 to interrupt on change (this will give you the frequency therefore speed). once the interrupt happens, you just get your code to read b1 and it value should give you the direction.

Most pics have more than 1 interrupt port. This is the way I would implement a quadrature encoder. The only problem is that the faster your robot goes, the more frequent your interrupts get and therefore less time is spent in the actual programming. It might be a case where you want to dedicate an mcu for reading the encoders (dont worry it can be used for other things too such as controlling the motors). This is a good way of doing it - have a dedicated motor mcu where you can send commands through i2c to move and also receive speed data back through i2c. It means that it frees your main processor from having to do pwm to motors + be interrupted by encoders letting it get on with what really matters.

[Rebelgium]

Most pics have more than 1 interrupt port. This is the way I would implement a quadrature encoder. The only problem is that the faster your robot goes, the more frequent your interrupts get and therefore less time is spent in the actual programming. It might be a case where you want to dedicate an mcu for reading the encoders (dont worry it can be used for other things too such as controlling the motors). This is a good way of doing it - have a dedicated motor mcu where you can send commands through i2c to move and also receive speed data back through i2c. It means that it frees your main processor from having to do pwm to motors + be interrupted by encoders letting it get on with what really matters.

That's exactly what I'm doing
Dedicated PIC , I²C, ... exactly the same :p

[Tom2000]

Lets face it, if youre going to go to the effort of adding encoders. Then you might aswell put in the extra work and add quadrature encoders.

I guarantee that a couple of weeks after adding encoders youll think, only f i put in the extra effort....... Theres so much more my robot could do........

 

Sorry to butt in, but I just released a freeware program that might be pertinent to this discussion.

My program generates codewheels that you can print on your home inkjet or laser printer.

I designed the program because I want to build a quadrature encoder to control an RF synthesizer.  And since I'm fairly ham-handed mechanically, I included a two-track quadrature encoder wheel in the design that would let me arrange my photodetectors vertically, masked by a couple of vertically-aligned pinholes.   I think that will be much simpler than trying to align two photodetectors horizontally, spaced in quadrature to each other, with narrow cell widths.

I haven't had a chance to try this design out yet, but I have high hopes that even someone as mechanically inept as me can pull this off.

I've posted a sketch of my idea on my Codewheel page (where you can also download the software):

http://www.mindspring.com/~tom2000/Delphi/Codewheel.html

Good luck!

Tom Lackamp

[Rebelgium]

I already read your topic in the misc forum, it's already in my bookmarks

[Tom2000]

I already read your topic in the misc forum, it's already in my bookmarks

Rebelgium, if you like the program, there's one favor I'd like to ask of you.

I'm an electronic experimenter and, as I mentioned above, am not great with
mechanical design and assembly.  So, for me, amateur robotics would be a
frustrating pursuit.    As a result, I have no contacts within the robotic
experimenter fraternity.

If you like the program, could you please spread the word to your friends
and to the robotics sites you frequent?  I'd appreciate it.

I have nothing to gain by wide distribution of my program.  Since I don't have
any ads on my web site, I don't even gain from page hits. 

When I wanted to build my own encoder, I looked for a program like mine.  I
thought lots of folks would have invented ways of printing codewheels.  I was
very surprised to find nothing that I could use. 

I figured that being able to generate good codewheels for free would give
all types of electronic hobbyists new capabilities.  They could include optical
encoders in projects now, when doing so before would have cost too much.

I'd like to spread the word, and give all experimenters this capability.

So, I would appreciate it very much if you could let folks know that this
program exists.

Thanks very much!

Tom Lackamp

[Rebelgium]

I already read your topic in the misc forum, it's already in my bookmarks

Rebelgium, if you like the program, there's one favor I'd like to ask of you.

I'm an electronic experimenter and, as I mentioned above, am not great with
mechanical design and assembly.  So, for me, amateur robotics would be a
frustrating pursuit.    As a result, I have no contacts within the robotic
experimenter fraternity.

If you like the program, could you please spread the word to your friends
and to the robotics sites you frequent?  I'd appreciate it.

I have nothing to gain by wide distribution of my program.  Since I don't have
any ads on my web site, I don't even gain from page hits. 

When I wanted to build my own encoder, I looked for a program like mine.  I
thought lots of folks would have invented ways of printing codewheels.  I was
very surprised to find nothing that I could use. 

I figured that being able to generate good codewheels for free would give
all types of electronic hobbyists new capabilities.  They could include optical
encoders in projects now, when doing so before would have cost too much.

I'd like to spread the word, and give all experimenters this capability.

So, I would appreciate it very much if you could let folks know that this
program exists.

Thanks very much!

Tom Lackamp

There's not much I can do really...
All I can do is tell someone about your program when someone asks, I think your topic is a good start (people that search the forum for encoders will stumble upon it).
The best thing you can do is contact Admin and ask him to put a link to your site on his wheel encoder tutorial (or the most relevant tutorial).

That would be ideal.

[Tom2000]

There's not much I can do really...
All I can do is tell someone about your program when someone asks, I think your topic is a good start (people that search the forum for encoders will stumble upon it).
The best thing you can do is contact Admin and ask him to put a link to your site on his wheel encoder tutorial (or the most relevant tutorial).

That would be ideal.

Thank you!

Tom

[Admin]

Quadrature encoders will tell you what direction you are going in but they will not give you anymore accuracy over rough terrain than a plain encoder wheel.

By going to quadrature, you can increase accuracy by 2x. And if you are clever with the algorithms, in theory up to 3x to 4x.

[Tom2000]

Quadrature encoders will tell you what direction you are going in but they will not give you anymore accuracy over rough terrain than a plain encoder wheel.

By going to quadrature, you can increase accuracy by 2x. And if you are clever with the algorithms, in theory up to 3x to 4x.

Let me expound on this, since I recently figured it out.   

Your decoded resolution depends upon the number of quadrature transitions your decoder captures.

Let's use the example of a 100 cell codewheel with two sensors configured in quadrature. 

As you rotate the wheel, each quadrature phase output will produce 50 cycles per revolution.  (This is the usual term you'll find to represent a quad encoder's resolution:  CPR.)

Each quad phase will produce 100 transitions per revolution - the positive-going transition, and the negative-going transition. 

But you have two phase signals available to you, one offset by 90 degrees to the other.  So your 100 cell wheel (or 50 CPR wheel) will produce 200 transitions per revolution.

If your hardware or micro is configured to capture, say, just the positive-going transition from one of the two phases, your decoded output will produce 50 pulses for a 100 cell (50 CPR) wheel.

If you capture two of the four available transitions, say the positive-going transitions from each phase or the positive and negative-going pulses from just one phase, you'll double your decoded output to 100 pulses per revolution for a 100 cell (50 CPR) wheel.

If you capture all four possible transitions, such as you would if your configured your micro for interrupt-on-change for both phases, you'd capture all possible information, and produce 200 pulses per revolution for that 100 cell (50 CPR) wheel.

So, in summary: 

If you capture a single transition on just one of the two phases, your output will be equivalent to the number of cycles per revolution.

If you capture two of the four available transitions, your output will be double the number of cycles per revolution.

If you capture all four possible transitions, your output will be four times the number of cycles per revolution.

So, it behooves you to scour your microcontroller data sheets to figure out how to implement interrupt-on-change for the pins you'll use for your quadrature encoder inputs.

HTH,

   Tom