So, I'm working on an interesting problem. It's somewhat self-assigned, but it'll make it's way into some customer equipment. It's not quite DSP, not quite circuits, but I'm posting it to these groups anyway. The application is an optical encoder -- shine light through a disk at some photosensors, look at the result, and tell the processor where the disk is. There are some tried-and-true methods, but I want to do better. I want to be able to use an encoder to rapidly -- but not immediately -- figure out the absolute position of a wheel. Sort of a hybrid absolute/ relative encoder, that's not as expensive as using N strips to get the 2^N precision of an absolute encoder, but that gets you an absolute position quicker than the "go around until you see an index pulse" that you get from a pure relative encoder. My thought is to use a quadrature encoder in the usual way to figure out the relative motion of the wheel, and then back that up by a strip that is encoded in binary (dark = 0, light = 1) with some scheme such that any consecutive string of N positions is unique. And I figured out one such scheme! Take the output of an N-bit LFSR, and lay it down in order. If the idea of having 2^N - 1 bits bothers you, then augment the LFSR such that it has one string of N zeros on its output, giving you a nice even 2^N positions. Then, to figure out the absolute position of the wheel, use the quadrature encoder to to run by N bits in either direction. Use the looked-up bits to determine the position (which you can, because they're unique), and voila! You have the absolute position and can now just use the relative encoder. So my question is: has anyone seen this done? Are there better variations? Is there anyone who makes some sort of off-the-shelf solution that does all that, but cheaper than I could ever roll my own from individual components? My ideal would be a sensor that I could buy off the shelf, and specify to my customer how their code disk would have to be made, and have everything just work. (Note that if you had the freedom to roll your own silicon you could make a system that would register a code word, look it up for the absolute position, then figure out its offset within the sensor. This would give you oodles of precision and an immediate answer -- but it'd be ridiculously expensive to roll one from scratch). Thanks in advance. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Position Encoding.
Started by ●December 21, 2011
Reply by ●December 21, 20112011-12-21
Tim Wescott wrote:> > And I figured out one such scheme! Take the output of an N-bit LFSR, and > lay it down in order. If the idea of having 2^N - 1 bits bothers you, > then augment the LFSR such that it has one string of N zeros on its > output, giving you a nice even 2^N positions. > > Then, to figure out the absolute position of the wheel, use the > quadrature encoder to to run by N bits in either direction. Use the > looked-up bits to determine the position (which you can, because they're > unique), and voila! You have the absolute position and can now just use > the relative encoder.This still requires the encoder to move a small amount before the position is known. But, it does require only a very SMALL amount of movement. I would not be astonished to find out somebody already does this, there are a RAFT of absolute or pseudo-absolute encoder schemes out there that use the relationship between several tracks to provide absolute position with just a small movement. Jon
Reply by ●December 21, 20112011-12-21
There's a Hardware Hacker on this -- Don? As long as direction is known (I suppose you could use something like Manchester encoding, so it always produces a direction on top of the serial bit pattern you're computing against), you should be able to up/down shift it into a register and predict the next step, or compare, or etc. I know LFSRs can be used as counters (modulo 2^N-1, kind of inconvienient, solvable as you note), but it's my recollection that, for obvious reasons, decoding them is nontrivial, so converting that to a positional count is hard (i.e., just look it up in RAM, instead of synthesizing logic to do it from scratch). Tim -- Deep Friar: a very philosophical monk. Website: http://webpages.charter.net/dawill/tmoranwms "Tim Wescott" <tim@seemywebsite.com> wrote in message news:Ha-dnZCw_aKf9W_TnZ2dnUVZ_omdnZ2d@web-ster.com...> So, I'm working on an interesting problem. It's somewhat self-assigned, > but it'll make it's way into some customer equipment. It's not quite > DSP, > not quite circuits, but I'm posting it to these groups anyway. > > The application is an optical encoder -- shine light through a disk at > some photosensors, look at the result, and tell the processor where the > disk is. There are some tried-and-true methods, but I want to do > better. > > I want to be able to use an encoder to rapidly -- but not immediately -- > figure out the absolute position of a wheel. Sort of a hybrid absolute/ > relative encoder, that's not as expensive as using N strips to get the > 2^N precision of an absolute encoder, but that gets you an absolute > position quicker than the "go around until you see an index pulse" that > you get from a pure relative encoder. > > My thought is to use a quadrature encoder in the usual way to figure out > the relative motion of the wheel, and then back that up by a strip that > is encoded in binary (dark = 0, light = 1) with some scheme such that > any > consecutive string of N positions is unique. > > And I figured out one such scheme! Take the output of an N-bit LFSR, > and > lay it down in order. If the idea of having 2^N - 1 bits bothers you, > then augment the LFSR such that it has one string of N zeros on its > output, giving you a nice even 2^N positions. > > Then, to figure out the absolute position of the wheel, use the > quadrature encoder to to run by N bits in either direction. Use the > looked-up bits to determine the position (which you can, because they're > unique), and voila! You have the absolute position and can now just use > the relative encoder. > > So my question is: has anyone seen this done? Are there better > variations? Is there anyone who makes some sort of off-the-shelf > solution that does all that, but cheaper than I could ever roll my own > from individual components? My ideal would be a sensor that I could buy > off the shelf, and specify to my customer how their code disk would have > to be made, and have everything just work. > > (Note that if you had the freedom to roll your own silicon you could > make > a system that would register a code word, look it up for the absolute > position, then figure out its offset within the sensor. This would give > you oodles of precision and an immediate answer -- but it'd be > ridiculously expensive to roll one from scratch). > > Thanks in advance. > > -- > My liberal friends think I'm a conservative kook. > My conservative friends think I'm a liberal kook. > Why am I not happy that they have found common ground? > > Tim Wescott, Communications, Control, Circuits & Software > http://www.wescottdesign.com
Reply by ●December 21, 20112011-12-21
On Dec 22, 12:13�am, Tim Wescott <t...@seemywebsite.com> wrote:> So, I'm working on an interesting problem. �It's somewhat self-assigned, > but it'll make it's way into some customer equipment. �It's not quite DSP, > not quite circuits, but I'm posting it to these groups anyway. > > The application is an optical encoder -- shine light through a disk at > some photosensors, look at the result, and tell the processor where the > disk is. �There are some tried-and-true methods, but I want to do better. > > I want to be able to use an encoder to rapidly -- but not immediately -- > figure out the absolute position of a wheel. �Sort of a hybrid absolute/ > relative encoder, that's not as expensive as using N strips to get the > 2^N precision of an absolute encoder, but that gets you an absolute > position quicker than the "go around until you see an index pulse" that > you get from a pure relative encoder. > > My thought is to use a quadrature encoder in the usual way to figure out > the relative motion of the wheel, and then back that up by a strip that > is encoded in binary (dark = 0, light = 1) with some scheme such that any > consecutive string of N positions is unique. > > And I figured out one such scheme! �Take the output of an N-bit LFSR, and > lay it down in order. �If the idea of having 2^N - 1 bits bothers you, > then augment the LFSR such that it has one string of N zeros on its > output, giving you a nice even 2^N positions.What's so special about a linear feed-back shift register?> Then, to figure out the absolute position of the wheel, use the > quadrature encoder to to run by N bits in either direction. �Use the > looked-up bits to determine the position (which you can, because they're > unique), and voila! �You have the absolute position and can now just use > the relative encoder.They aren't actually unique. Look at the example here http://en.wikipedia.org/wiki/Linear_feedback_shift_register amd note that 0001 reappears - in the the overlap of 0100 and 0010, which you can rewrite as 010 0001 0 - a couple of cycles later. You need more than N bits of context before you can determine an absolute position. Serial communications codes deal with this problem by including unique framing synch sequences which you can use to identify how to break up the serial bit stream into multi-bit chunks, which is exactly equivalent to your "index pulse". http://en.wikipedia.org/wiki/Bit_stuffing The HDLC-style solution - where N+1 successive zeros is always and only a frame synch sequence - could let you synchronise after reading only 2N+1 bits if you alternated the 2^N-1 possible n-bit numbers (excludng N zeros) between frame synch sequences, or you could use 2N-1 index pulses to do the frame synch job, but that would require two extra parallel tracks and two extra detectors. -- Bill Sloman, Nijmegen
Reply by ●December 21, 20112011-12-21
piling on... On 12/21/11 6:13 PM, Tim Wescott wrote:> So, I'm working on an interesting problem. It's somewhat self-assigned, > but it'll make it's way into some customer equipment. It's not quite DSP, > not quite circuits, but I'm posting it to these groups anyway. > > The application is an optical encoder -- shine light through a disk at > some photosensors, look at the result, and tell the processor where the > disk is. There are some tried-and-true methods, but I want to do better. > > I want to be able to use an encoder to rapidly -- but not immediately -- > figure out the absolute position of a wheel. Sort of a hybrid absolute/ > relative encoder, that's not as expensive as using N strips to get the > 2^N precision of an absolute encoder, but that gets you an absolute > position quicker than the "go around until you see an index pulse" that > you get from a pure relative encoder. > > My thought is to use a quadrature encoder in the usual way to figure out > the relative motion of the wheel, and then back that up by a strip that > is encoded in binary (dark = 0, light = 1) with some scheme such that any > consecutive string of N positions is unique. > > And I figured out one such scheme! Take the output of an N-bit LFSR, and > lay it down in order. If the idea of having 2^N - 1 bits bothers you, > then augment the LFSR such that it has one string of N zeros on its > output, giving you a nice even 2^N positions. >so what's the advantage of this over gray code? i can think of a serious disadvantage. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●December 21, 20112011-12-21
On 22 Dec., 00:32, "Tim Williams" <tmoran...@charter.net> wrote:> There's a Hardware Hacker on this -- Don? > > As long as direction is known (I suppose you could use something like > Manchester encoding, so it always produces a direction on top of the > serial bit pattern you're computing against), you should be able to > up/down shift it into a register and predict the next step, or compare, or > etc. �I know LFSRs can be used as counters (modulo 2^N-1, kind of > inconvienient, solvable as you note), but it's my recollection that, for > obvious reasons, decoding them is nontrivial, so converting that to a > positional count is hard (i.e., just look it up in RAM, instead of > synthesizing logic to do it from scratch). > > Tim >I guess the brute force approach is to put N bits in an identical lfsr and count how many steps it takes to get to a known value a quadrature decoder done right is pretty robust with regards to noise and contact bounce, I think you'd lose that if you do it in other ways -Lasse
Reply by ●December 21, 20112011-12-21
On Wed, 21 Dec 2011 16:56:13 -0800, Bill Sloman wrote:>> Then, to figure out the absolute position of the wheel, use the >> quadrature encoder to to run by N bits in either direction. Use the >> looked-up bits to determine the position (which you can, because >> they're unique), and voila! You have the absolute position and can now >> just use the relative encoder. > > They aren't actually unique. Look at the example here > > http://en.wikipedia.org/wiki/Linear_feedback_shift_register > > amd note that 0001 reappears - in the the overlap of 0100 and 0010, > which you can rewrite as 010 0001 0 - a couple of cycles later. You need > more than N bits of context before you can determine an absolute > position.I said the _output_, which goes 000100110101111 and then repeats, or if you insert the zero, 0000100110101111. Not the _state_. Please show me the repeat in the above. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●December 21, 20112011-12-21
On Wed, 21 Dec 2011 20:13:54 -0500, robert bristow-johnson wrote:> piling on... > > On 12/21/11 6:13 PM, Tim Wescott wrote: >> So, I'm working on an interesting problem. It's somewhat >> self-assigned, but it'll make it's way into some customer equipment. >> It's not quite DSP, not quite circuits, but I'm posting it to these >> groups anyway. >> >> The application is an optical encoder -- shine light through a disk at >> some photosensors, look at the result, and tell the processor where the >> disk is. There are some tried-and-true methods, but I want to do >> better. >> >> I want to be able to use an encoder to rapidly -- but not immediately >> -- figure out the absolute position of a wheel. Sort of a hybrid >> absolute/ relative encoder, that's not as expensive as using N strips >> to get the 2^N precision of an absolute encoder, but that gets you an >> absolute position quicker than the "go around until you see an index >> pulse" that you get from a pure relative encoder. >> >> My thought is to use a quadrature encoder in the usual way to figure >> out the relative motion of the wheel, and then back that up by a strip >> that is encoded in binary (dark = 0, light = 1) with some scheme such >> that any consecutive string of N positions is unique. >> >> And I figured out one such scheme! Take the output of an N-bit LFSR, >> and lay it down in order. If the idea of having 2^N - 1 bits bothers >> you, then augment the LFSR such that it has one string of N zeros on >> its output, giving you a nice even 2^N positions. >> >> > so what's the advantage of this over gray code? i can think of a > serious disadvantage.Assuming you're getting differential from a quadrature (2-bit gray code) it means that you only need three tracks for any resolution of encoder. An N-bit absolute encoder with gray code still needs N tracks. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●December 21, 20112011-12-21
On Wed, 21 Dec 2011 20:13:54 -0500, robert bristow-johnson <rbj@audioimagination.com> wrote:> >piling on... > >On 12/21/11 6:13 PM, Tim Wescott wrote: >> So, I'm working on an interesting problem. It's somewhat self-assigned, >> but it'll make it's way into some customer equipment. It's not quite DSP, >> not quite circuits, but I'm posting it to these groups anyway. >> >> The application is an optical encoder -- shine light through a disk at >> some photosensors, look at the result, and tell the processor where the >> disk is. There are some tried-and-true methods, but I want to do better. >> >> I want to be able to use an encoder to rapidly -- but not immediately -- >> figure out the absolute position of a wheel. Sort of a hybrid absolute/ >> relative encoder, that's not as expensive as using N strips to get the >> 2^N precision of an absolute encoder, but that gets you an absolute >> position quicker than the "go around until you see an index pulse" that >> you get from a pure relative encoder. >> >> My thought is to use a quadrature encoder in the usual way to figure out >> the relative motion of the wheel, and then back that up by a strip that >> is encoded in binary (dark = 0, light = 1) with some scheme such that any >> consecutive string of N positions is unique. >> >> And I figured out one such scheme! Take the output of an N-bit LFSR, and >> lay it down in order. If the idea of having 2^N - 1 bits bothers you, >> then augment the LFSR such that it has one string of N zeros on its >> output, giving you a nice even 2^N positions. >> > >so what's the advantage of this over gray code? i can think of a >serious disadvantage.He'd only need three tracks, the quadratures and the PRBS one. The PRBS would replace the index track, but find the absolute position in a much smaller rotation. Cute idea. John
Reply by ●December 21, 20112011-12-21
On Dec 21, 6:13�pm, Tim Wescott <t...@seemywebsite.com> wrote:> So, I'm working on an interesting problem. �It's somewhat self-assigned, > but it'll make it's way into some customer equipment. �It's not quite DSP, > not quite circuits, but I'm posting it to these groups anyway. > > The application is an optical encoder -- shine light through a disk at > some photosensors, look at the result, and tell the processor where the > disk is. �There are some tried-and-true methods, but I want to do better. > > I want to be able to use an encoder to rapidly -- but not immediately -- > figure out the absolute position of a wheel. �Sort of a hybrid absolute/ > relative encoder, that's not as expensive as using N strips to get the > 2^N precision of an absolute encoder, but that gets you an absolute > position quicker than the "go around until you see an index pulse" that > you get from a pure relative encoder. > > My thought is to use a quadrature encoder in the usual way to figure out > the relative motion of the wheel, and then back that up by a strip that > is encoded in binary (dark = 0, light = 1) with some scheme such that any > consecutive string of N positions is unique. > > And I figured out one such scheme! �Take the output of an N-bit LFSR, and > lay it down in order. �If the idea of having 2^N - 1 bits bothers you, > then augment the LFSR such that it has one string of N zeros on its > output, giving you a nice even 2^N positions. > > Then, to figure out the absolute position of the wheel, use the > quadrature encoder to to run by N bits in either direction. �Use the > looked-up bits to determine the position (which you can, because they're > unique), and voila! �You have the absolute position and can now just use > the relative encoder. > > So my question is: has anyone seen this done? �Are there better > variations? �Is there anyone who makes some sort of off-the-shelf > solution that does all that, but cheaper than I could ever roll my own > from individual components? �My ideal would be a sensor that I could buy > off the shelf, and specify to my customer how their code disk would have > to be made, and have everything just work. > > (Note that if you had the freedom to roll your own silicon you could make > a system that would register a code word, look it up for the absolute > position, then figure out its offset within the sensor. �This would give > you oodles of precision and an immediate answer -- but it'd be > ridiculously expensive to roll one from scratch). > > Thanks in advance.You've described a single-track encoder (or code+clock track) where the position track is coded with a non-repeating sequence, and absolute position can be known, for example, in m bits for a 2^m-1 maximal length sequence. http://www.freepatentsonline.com/4628298.html http://www.freepatentsonline.com/4947166.html http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.132.6922 Older tech was a conductive Gray-coded track, with multiple pickup contacts spaced one bit's distance apart. -- Cheers, James Arthur
