On 1 November 2010 05:13, Jon Elson <el...@pico-systems.com> wrote: > One quirk, which I think is inherent in the way that HAL component > encoder.c works, > and which I copied, > is that a dithering encoder gets the wrong velocity. The first count of > the dither gets > the right velocity, as there was no movement for some time before. The > second count, > if immediately following the first one, cancels out the movement, but it > gets twice the > velocity,
This sounds like a problem related to the one I am having with my resolver converter, and one possible solution would be a tracking filter (as used by PCW on his resolver converter, apparently). I have not started on it yet, but I think the concept is to model the output like a physical system, with a position, virtual velocity and virtual acceleration, and to have quite heavy filtering on the acceleration. This is vaguely related to an algorithm I have used to extract velocity data from noisy position data in the past: i) create a least-squares fit polynomial to a patch of the data- x = a + bt + ct^2 + d t^3 .... ii) calculate the derivative explicitly for the current value of t: V = b + 2ct + 3d^2 ..... This might be a bit computationally expensive for a real-time application though. It has the advantage over simpler smoothing algorithms of not losing detail. -- atp ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
