Encoder Velocity: A Common Miscalculation
How to correctly calculate encoder velocity
by James
Introduction
Encoders are commonly used to track the position, velocity, and acceleration of motors and other mechanical objects. If you are new to the operation of encoders, please refer to the Phidgets Encoder Primer for information that may help in understanding this document.
When working with Phidget Encoders, a tempting method to calculate their velocity is to simply divide the number of pulses (or edges) by the elapsed time given by an event. However, problems arise with this method when the encoder starts and stops, or moves slowly enough that it’s hard to tell the difference.
Considerations
Phidget Encoder adapters report the elapsed time between the previously reported time and the latest recorded edge. This works well for calculating the speed of encoders moving quickly enough to make one or more edges per interval. However, if the encoder adapter reports a span of time without an edge, it will begin reporting time since the last interval. In this way, blindly dividing the number of edges by the elapsed time becomes a dangerous proposition, as seen in the following diagram.
From this example, in the interval between 5-6s, the time reported by the event will only be 0.1s (the time between the start of the interval and the last edge in said interval). This results in a large spike in velocity if calculated as edges per reported time.
In order to mitigate the resulting spike in calculated velocity, it is advised to keep a record of the time since the last edge to calculate velocity, instead of directly using the elapsed time provided by the event. This can be done simply by adding the elapsed time of all intervals with zero counts to that of the first interval with a nonzero count.
As an example, the time change for velocity in the interval 5s-6s from the diagram could be
calculated as: 1.7s + 1s + 0.1s = 2.8s
which results
in a a calculated velocity of
Conclusion
While this method is still not perfect, it is safer than doing calculations with a velocity that is potentially many orders of magnitude too large.