Hi, I’m the lead programmer of Team 2976, same team as DaveL. I have never experimented with velocity calculations with an encoder since I have always used the premade one in the encoder library. Normally I find the change in position in a constant time period…say 100 milliseconds. This usually works well for regular encoders that return 360 ticks per revolution. However, in the hardware setup we have, as DaveL explained we only have 6 spokes and 6 ticks per revolutions. Reading through your suggestions I have found namely 3 solutions:
1) Measure the change in position with constant time (100ms). However, as phurley67 pointed out this only gives us +- 100 rpm and the uncertainty increases with smaller sample times
2) Measure the change in time between 2 successive pulses or ticks. Although I haven’t tried this I calculate about 3 ms change in time and I feel this will give lots of noise. Furthermore, I also am worried about CPU usage when throwing interrupts ever 3 ms.
3) Use an encoder. This is a good solution, except, our team wants it to be done using a beam break. Nevertheless, it will be interesting to work with this.
My solution is using a tracking loop, similar to a Kalman filter. The principle behind this is our knowledge of the relationship between position and velocity—I.e. integrate position to get velocity—can allow us to estimate the velocity with less noise.
Here is the outline of a tracking loop:
Basic physics tells us that integrating velocity results in displacement, or position. So I do that and integrate a variable I call velocity_estimated. The result of this integration will be the estimated position.
I feed this into a PI controller as the input and set its setpoint to the measured position and the controller will try to minimize the error by giving me more accurate values of velocity_estimated.
In a way this is recursive. I first calculate the estimated position by integrating the estimated velocity. I compare this value to the measured position and using a feedback loop get a more accurate estimate for velocity which I integrate once again…and the cycle continues.
Even though this is a roundabout way to get at the velocity, this is good. By integrating position, we absorb error and hope that it will cancel.
See for yourself here is a link to my github page where I created a simulation of a spinning wheel with the extra time I have since school is out for winter break.
https://github.com/neilhazra/Simulat.../Simulate.java
If you run it, you will notice estimated position is almost always closer to the hypothetical position_exact than measured position is. And that velocity_estimated is more precise and consistent (with much less noise) than delta position/ delta time.
This is not a perfect simulation, I assumed our error would be randomly distributed which it will definitely not be. I will need to test it on a real robot soon.