Absolute Encoder Rollover

crgwbr

For one application, I am useing a 10bit absolute encoder as an HID device. I need absolute positioning, but I need to figure out someway to stop the rollover. For example, when the user turns the encoder clockwise from pos1024 to pos0, I need the prop to read it as pos1025 instead of being back at pos0. I can't seem to figure out the math behind this. Anyone know how?

Thanks,
Craig

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My system: 1.6 GHz AMD Turion64 X2, 4GB DDR2, 256MB ATI Radeon Graphics card, 15.4" Widescreen HD Screen

I have a duel boot of Ubuntu Linux and Windows Vista. Vista, because it came with the PC, Ubuntu because I like software that works.

"Failure is not an option -- it comes bundled with Windows."

Use The Best...
Linux for Servers
Mac for Graphics
Palm for Mobility
Windows for Solitaire

Graham Stabler

I don't think it is maths so much as code. You need to track it and when it crosses then take appropriate action (totalposition:= pos + 1024) etc.

The encoder just gives an angle output there is no way to tell if the encoder wrapped around or jumped back to zero mathematically. In practice however when reading the encoder quickly and with human input the latter is very unlikely.

Graham

Phil Pilgrim (PhiPi)

Here's an untested code fragment that might help:

Position := ReadEncoder
pEncoder := Position
repeat
  Encoder := ReadEncoder
  if (||(Encoder - pEncoder) < 512)
    Position := Position & $fffffc00 + Encoder    'Normal: no rollover or rollunder.
  elseif (Encoder < pEncoder)
    Position := Position & $fffffc00 + $400 + Encoder    'Rollover
  else
    Position := Position & $fffffc00 - $400 + Encoder    'Rollunder
  pEncoder := Encoder

-Phil

whicker

The correct way this is handled is to treat even an absolute encoder as a relative device.

Basically you have a loop constantly reading the position and then comparing it (subtraction) to the previous read position.
From that subtraction you get a delta position.

To handle the wraparound, you play halves: Is the absolute value of the delta-position greater than or equal to half that of the highest possible absolute position count? If so, you know it wrapped around and find out the "correct" delta position (a number of ways to perform the subtraction).

If your read loop is occurring at a regular interval (or you know delta time), then the position delta divided by time delta is obviously Velocity.

Also you've got a Running Count somewhere where every loop you add the delta position. This Running Count is your position value, and feel free to just wrap that too as you please, regardless of how the actual encoder wraps.

Obviously when you start out, your running count gets either pulled from nonvolatile memory, or otherwise you just set your running count to the present encoder value if you don't care when powering up. Also obviously, if you are using nonvolatile storage of the encoder count, you either need to keep writing the running count to it, or be sure when the system loses power to write the count.

Phil's algorithm above has basically the same idea, but suffers from premature optimization. What if the encoder count is 1000? You're not going to be able to do bitfield operations then.


Oh, and I forgot the Velocity aspect from above... basically you can use this to plan for events that happen sometime in the future (that have a reaction time). Current position + Velocity * Reaction time = Lookahead Position. Again you need to wrap the lookahead.

Phil Pilgrim (PhiPi)

whicker said...
Phil's algorithm above has basically the same idea, but suffers from premature optimization. What if the encoder count is 1000? You're not going to be able to do bitfield operations then.

Why not?

-Phil

Update: I may have misunderstood your comment. Originally, I thought you meant what if the reading were 1000, not the total count. Since the encoder in question has a total count of 0 - 1023 (not 1024, I assume, despite the original post), the bitfiled operations will work fine. For non-power-of-two total counts (rare among absolute encoders, I think), the bitfield ops can be replaced with modulo operations which, because they involve division, are much slower on the Prop.

Another wrinkle that would render my algorithm ineffective would be if the encoder output Gray code, rather than plain binary. Without an internal processor of its own, it would almost have to. Craig didn't mention Gray code, so I assume such a processor is present.

-P.

Post Edited (Phil Pilgrim (PhiPi)) : 4/8/2008 3:08:31 PM GMT