Quote:
Originally Posted by mikets
I am sorry if I don't understand. If the goal is to get velocity, wouldn't it be easier to do this instead:
Code:
vel = (currentDistance - previousDistance)/period;
This should work unless there is a problem with GetDistance() too. |
If the period is identical to the pulse period, then this is the same as GetRate() (less some filtering).
If the period is set by a periodic loop outside of encoder.c and not the actual pulse period, then vel is an average speed over that sample period. As I mentioned in the first post, if the sample period is much shorter than the actual pulse period, then this "vel" approaches an impulse train with zeros in between. These impulses can cause trouble if there are nonlinearities in the system such as limits or threshold detectors. So with very high sample rates, additional filtering is needed to negate these effects. The simplest way to filter the impulses is to increase the sample period over which you obtain the average rate, but this causes added delays is detecting speed changes.
So the GetRate() output is a nice compromise. It detects when a pulse has changed and then adjusts the rate and holds it in a register for whoever wants to use it. The averaging time varies with the pulse period and it has an artificial max period but it eliminates the impulses present with very high sample rates and minimizes the need for additional filtering.
I might add that encoder rate noise from other sources often dictates that even GetRate() be further filtered.