Truncated match.
PICList
Thread
'Encoder resolution?'
1997\03\03@234843
by
Jeff 'n Kristen Kroll
I have been reading the PICLIST for about a month and have seen several
methods of doing quadrature decoding on a PIC. One method, the one in the
Microchip Applications Handbook suggests monitoring one channel and when it
changes check the other channel to determine direction. Doesn't this reduce
the resolution of the encoder by half? This method would be great if it
didn't because the project I am working on, a six degree of freedom
trackball, needs to monitor three encoders, and the 16c65 chip I'm using
only has four interrupt on change pins. However I can't sacrifice
resolution.
BTW, I just wanted to comment on how impressed I am at the helpfulness(?
)
of everyone on the PICLIST. Keep up the good work!
Jeff Kroll
1997\03\04@001048
by
Jeff 'n Kristen Kroll
I have been reading the PICLIST for about a month and have seen several
methods of doing quadrature decoding on a PIC. One method, the one in the
Microchip Applications Handbook, suggests monitoring one channel and when
it
changes check the other channel to determine direction. Doesn't this reduce
the resolution of the encoder by half? This method would be great if it
didn't because the project I am working on, a six degree of freedom
trackball, needs to monitor three encoders, and the 16c65 chip I'm using
only has four interrupt on change pins. However I can't sacrifice
resolution.
BTW, I just wanted to comment on how impressed I am at the helpfulness(?
)
of everyone on the PICLIST. Keep up the good work!
Jeff Kroll
1997\03\04@005910
by
Bob Blick
|
Just poll the encoders. A trackball doesn't spin very fast, and it's
non-critical, so if it misses a count or two when busy, no big deal.
Pretend it's the mouse on a Macintosh :-)
I also hear that interrupt-on-change will miss interrupts. It's good for a
keyboard wakeup-from-sleep and not much else. Does Andrew Warren have
something on his "answers" page about this? I think so. If you read the
Microchip data sheets _very_carefully_ they actually say so, too.
-Bob
At 08:41 PM 3/3/97 -0800, you wrote:
> I have been reading the PICLIST for about a month and have seen
several
>methods of doing quadrature decoding on a PIC. One method, the one in the
>Microchip Applications Handbook suggests monitoring one channel and when it
>changes check the other channel to determine direction. Doesn't this reduce
>the resolution of the encoder by half? This method would be great if it
>didn't because the project I am working on, a six degree of freedom
>trackball, needs to monitor three encoders, and the 16c65 chip I'm using
>only has four interrupt on change pins. However I can't sacrifice
>resolution.
> BTW, I just wanted to comment on how impressed I am at the
helpfulness(?)
>of everyone on the PICLIST. Keep up the good work!
>
> Jeff Kroll
>
>
http://www.bobblick.com/
1997\03\04@011444
by
Steve Hardy
|
> From: "Jeff 'n Kristen Kroll" <spam_OUTjkkrollTakeThisOuT
JOSHUANET.COM>
>
> I have been reading the PICLIST for about a month and have seen
several
{Quote hidden}> methods of doing quadrature decoding on a PIC. One method, the one in the
> Microchip Applications Handbook suggests monitoring one channel and when it
> changes check the other channel to determine direction. Doesn't this reduce
> the resolution of the encoder by half? This method would be great if it
> didn't because the project I am working on, a six degree of freedom
> trackball, needs to monitor three encoders, and the 16c65 chip I'm using
> only has four interrupt on change pins. However I can't sacrifice
> resolution.
> BTW, I just wanted to comment on how impressed I am at the helpfulness(?)
> of everyone on the PICLIST. Keep up the good work!
You can feed both quadrature inputs into an XOR gate and apply the
XOR gate output to the interrupt-on-change pin. The output makes
a transition on each edge of either input. You can look at the
XOR gate output and one of the 'raw' inputs to determine direction
info.
BTW, just in case you are under a misapprehension, one degree of
freedom counts both the forward and reverse directions as the
one DOF. If you truly have a 6-DOF trackball, my mind is boggling
trying to imagine how one would drive such a beast, since you would
need X, Y and Z translation, plus pitch, roll and yaw! -- and 6
encoders, not 3.
Strap yourself in for a slight digression: did you know that you can
yaw (spin) a trackball using just pitch and roll? To demonstrate
this, take a ball and sit it on a table. Put your hand on the top of
the ball. You can pitch the ball by moving your hand back and forth,
and you can roll it using side to side motion. Now if you move your
hand in small circles, the ball yaws in the opposite direction to your
hand motion (albeit with some nutation). Mathematicians will tell you
that this is a result of group theory, but I think it just works anyway
in spite of that lot...
Regards,
SJH
Canberra, Australia
1997\03\04@012048
by
Andrew Warren
Bob Blick <.....PICLISTKILLspam
@spam@MITVMA.MIT.EDU> wrote:
> I also hear that interrupt-on-change will miss interrupts. It's good
> for a keyboard wakeup-from-sleep and not much else.
Yes, this is true for many of the 16Cxx parts... The newest ones
have allegedly been fixed, but I haven't verified this.
> Does Andrew Warren have something on his "answers" page about this?
> I think so.
Yeah, he does. It's the answer to Question #88, in the
"Microchip PIC" section of his "Answers" page.
> If you read the Microchip data sheets _very_carefully_ they
> actually say so, too.
In the newest data books, you don't even have to read
carefully... Microchip have been nice enough to put a shaded
block around the applicable paragraph.
-Andy
=== Andrew Warren - fastfwd
KILLspamix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== Custodian of the PICLIST Fund -- For more info, see:
=== www.geocities.com/SiliconValley/2499/fund.html
1997\03\04@022649
by
Walter Banks
Jeff 'n Kristen Kroll wrote:
>
> I have been reading the PICLIST for about a month and have seen
several
> methods of doing quadrature decoding on a PIC. One method, the one in the
> Microchip Applications Handbook suggests monitoring one channel and when it
> changes check the other channel to determine direction. Doesn't this reduce
> the resolution of the encoder by half?
Yes it does.
> This method would be great if it
> didn't because the project I am working on, a six degree of freedom
> trackball, needs to monitor three encoders, and the 16c65 chip I'm using
> only has four interrupt on change pins. However I can't sacrifice
> resolution.
Another way is to sample the port with a timer set to the fastest
expected quadrature speed it will have a lower interrupt overhead
and full resolution. The code on a PIC is quite abit shorter.
Walter Banks.
1997\03\04@030025
by
John Dammeyer
|
At 02:08 AM 04/03/1997 -0500, you wrote:
{Quote hidden}>Jeff 'n Kristen Kroll wrote:
>>
>> I have been reading the PICLIST for about a month and have seen
> several
>> methods of doing quadrature decoding on a PIC. One method, the one in the
>> Microchip Applications Handbook suggests monitoring one channel and when it
>> changes check the other channel to determine direction. Doesn't this reduce
>> the resolution of the encoder by half?
>Yes it does.
>
>> This method would be great if it
>> didn't because the project I am working on, a six degree of freedom
>> trackball, needs to monitor three encoders, and the 16c65 chip I'm using
>> only has four interrupt on change pins. However I can't sacrifice
>> resolution.
>
>Another way is to sample the port with a timer set to the fastest
>expected quadrature speed it will have a lower interrupt overhead
>and full resolution. The code on a PIC is quite abit shorter.
>
>Walter Banks.
>
That is somewhat similar to what I did more than a decade ago. I used a
couple of one-shots that were re-triggered by the encoder edges. Along with
a flip flop or two it prevented the false triggering as the encoder vibrated
back and forth around one edge. As I recall the time period of the oneshot
was set to less than the maximum encoder rate. The idea came out of EDN (I
think). This was in late 1983. I really do wish I still had that circuit.
Cheers,
John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc. Ph. 1-250-544-4950
PO Box 20002 Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9
1997\03\04@095520
by
Andy Kunz
At 08:41 PM 3/3/97 -0800, you wrote:
I did an encoder thingy by polling at high speed, keeping the previous value
read in in RAM, then XORing to find the deltas (a delta appears as a 1 bit).
You just need to poll fast enough to catch all the changes at the speed you
expect to move.
Kinda like below:
OldEnc ds 1 ; Holds previous value read from encoder
NewEnc ds 1 ; Holds current value
Deltas ds 1 ; Holds deltas
EncPort equ RB
ChkEnc movf EncPort,W
movwf NewEnc
xorwf OldEnc,W
movwf Deltas ; A "1" signifies a changed bit
btfsc Z
goto ChkEnc ; No changes, so loop, or go back to main
program
DoChg ... ; Process each bit change manually
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
1997\03\04@234654
by
Jeff 'n Kristen Kroll
|
----------
{Quote hidden}> From: Steve Hardy <
.....hardyKILLspam
.....SWENG.STORTEK.COM>
> To:
EraseMEPICLISTspam_OUT
TakeThisOuTMITVMA.MIT.EDU
> Subject: Re: Encoder resolution?
> Date: Tuesday, March 04, 1997 2:08 PM
>
> > From: "Jeff 'n Kristen Kroll" <
jkkroll
spam_OUTJOSHUANET.COM>
>>the project I am working on, a six degree of freedom
> > trackball
> BTW, just in case you are under a misapprehension, one degree of
> freedom counts both the forward and reverse directions as the
> one DOF. If you truly have a 6-DOF trackball, my mind is boggling
> trying to imagine how one would drive such a beast, since you would
> need X, Y and Z translation, plus pitch, roll and yaw! -- and 6
> encoders, not 3.
>
> Strap yourself in for a slight digression: did you know that you can
> yaw (spin) a trackball using just pitch and roll? To demonstrate
> this, take a ball and sit it on a table. Put your hand on the top of
> the ball. You can pitch the ball by moving your hand back and forth,
> and you can roll it using side to side motion. Now if you move your
> hand in small circles, the ball yaws in the opposite direction to your
> hand motion (albeit with some nutation). Mathematicians will tell you
> that this is a result of group theory, but I think it just works anyway
> in spite of that lot...
>
> Regards,
> SJH
> Canberra, Australia
Actually what I am working on is a 6DOF trackball. A coupla' months ago
I
moved next door to an inventor who has the patent on the whole arena of
6DOF trackballs( see http://gadgetland.com/globaldevices/trackball.html).
The guy is a mechanical genius and has a prototype that spins in all 3
directions and can translate in the other three. Fortunately for me he
didn't know alot about electronics and is supplying me with all of the
equipment I need (PICStart Plus, PC, chips, PC board design software, etc.)
in exchange for doing this project for him.
The three rotational axes will be done with encoders and the translation
al
axes will have proportional control, but have a much better "feel" than
controllers currently on the market. This thing will ROCK the game
controller world!
I didn't quite understand how you can get the yaw from just pitch and
roll. Does this mean I can do away with one of my encoders? If it does,
will I need to do intense computations? I would greatly appreciate any help
in finding out more about this (references, etc.).
Thanx,
Jeff Kroll
1997\03\05@180803
by
Steve Hardy
|
> From: "Jeff 'n Kristen Kroll" <@spam@jkkrollKILLspam
JOSHUANET.COM>
> Actually what I am working on is a 6DOF trackball. A coupla' months
ago I
> moved next door to an inventor who has the patent on the whole arena of
> 6DOF trackballs( see http://gadgetland.com/globaldevices/trackball.html).
> The guy is a mechanical genius and has a prototype that spins in all 3
> directions and can translate in the other three. Fortunately for me he
> didn't know alot about electronics and is supplying me with all of the
> equipment I need (PICStart Plus, PC, chips, PC board design software, etc.)
> in exchange for doing this project for him.
> The three rotational axes will be done with encoders and the
translational
{Quote hidden}> axes will have proportional control, but have a much better "feel" than
> controllers currently on the market. This thing will ROCK the game
> controller world!
> I didn't quite understand how you can get the yaw from just pitch and
> roll. Does this mean I can do away with one of my encoders? If it does,
> will I need to do intense computations? I would greatly appreciate any help
> in finding out more about this (references, etc.).
>
> Thanx,
> Jeff Kroll
>
It's not really suitable for your application - try rolling a ball as
described and you will see why. Also, it is counterintuitive for the
user of the device. Nevertheless, the principle has been applied to
CAD programs for 'rolling' 3-D objects around using a 2-D mouse or
trackball. E.g. the user clicks on a special roll-mode button. If the
mouse is then moved in the Y direction, the object rolls around the X
axis as if the mouse cursor is a 'hand' pushing on the top of the
object. Similarly for the other axis. Rolling the object around the Z
axis (pointing out of the screen) is performed by moving the mouse in
small circles. No additional computation is required for this, as it
is a natural mathematical consequence of keeping track of the 3-D
orientation of the object.
This is explained in 'Graphics Gems' which is a set of books relating
to tricks for computer graphics, which is where I got my info.
Regards,
SJH
Canberra, Australia
1997\03\05@200113
by
Prashant Bhandary
|
At 11:58 PM 3/03/97 -0800, you wrote:
>That is somewhat similar to what I did more than a decade ago. I used a
>couple of one-shots that were re-triggered by the encoder edges. Along with
>a flip flop or two it prevented the false triggering as the encoder vibrated
>back and forth around one edge. As I recall the time period of the oneshot
>was set to less than the maximum encoder rate. The idea came out of EDN (I
>think). This was in late 1983. I really do wish I still had that circuit.
I designed(but never implemented) something similar in software. I had to
sense a digital signal on a port B line with the change on Port B interrupt
enabled and have a timer going at the same time for PWM. Jitter on the digital
signal was not important but constant interrupts could disrupt the PWM. So
on each change of digital signal, I disabled the Port B interrupt and enabled
it on the next timer interrupt.
The application was a DCC decoder in a model train(yes, that's all I do) which
senses the DCC signal on the track and controls the motor speed at the same time
using PWM. A dirty track can produce jitter inside the loco. You may lose the
data packet but that's OK. It could disrupt the PWM which will manifest itself
as
the loco shuddering when it hits the dirty patch.
Something similar could probably be used for the encoders. Handle jitter by
shutting off the Port B interrupt for a while. This ensures that you have enough
quiet time to do other processing. You would not lose resolution as the change
is still sensed, only at a slower rate. You would not accumulate error because
this time period is not long enough to miss an actual step.
Regards
Prashant
--------------------------------+---------------------------------
Prashant Bhandary | Tel: +61-2-9662 5299
Spatial Information Solutions | Fax: +61-2-9662 5348
Roads and Traffic Authority | Email: KILLspamprashbKILLspam
rta.nsw.gov.au
Rosebery NSW 2018, AUSTRALIA | "2b|!2b" - William Shakespeare
--------------------------------+---------------------------------
1997\03\05@232246
by
John Payson
|
>
> At 11:58 PM 3/03/97 -0800, you wrote:
> >That is somewhat similar to what I did more than a decade ago. I used a
> >couple of one-shots that were re-triggered by the encoder edges. Along with
> >a flip flop or two it prevented the false triggering as the encoder vibrated
> >back and forth around one edge. As I recall the time period of the oneshot
> >was set to less than the maximum encoder rate. The idea came out of EDN (I
> >think). This was in late 1983. I really do wish I still had that circuit.
If you have two interrupt-on-change signals that can be enabled/disabled
seperately, it should be possible to design a jitter-resistant quadrature
decoder in software. The key is to recognize the four states as 0x, 1x,
x0, and x1; any time one of the input changes and triggers an interrupt,
disable the interrupt on that input and enable it on the other one. In
this way, you should be able to get excellent response while minimizing
overhead from contact jitter. You will add one count worth of slop to the
current position report, but in many cases you'd want to add a count of
hysteresis anyway so it's a non-issue.
More... (looser matching)
- Last day of these posts
- In 1997
, 1998 only
- Today
- New search...