Jon Elson wrote: > Sebastian Kuzminsky wrote: >> If the encoder counter can timestamp the arrival of the encoder edges >> with a temporal resolution that is high compared to the servo cycle >> period, then the velocity can be accurately and smoothly estimated at >> any (constant) velocity, from much less than one edge per servo cycle up >> to the max practical edge rate. >> >> > sampling jitter is not the problem. In some systems with relatively low > encoder resolution, there are just a couple counts per servo cycle. So, > the +1 / -1 nature of the sampling interval necessarily adds a "noise" > to the perceived velocity. "Estimating" means filtering, as far as I > can see.
If the encoder counter provides only the number of edges seen since startup (or since some reset event), then it's really hard to estimate velocity well - it'll be quantised and crunchy (though as you say, maybe filtering could help). But if the encoder counter has a fast clock (like the base period of the software encoder counter, or the Quadrature Timestamp Clock of the HostMot2 firmware), then it's possible to do better. In this setup, the data sent from the encoder counter to the driver takes the form "X edges seen since reset, most recent edge seen at time T". By remembering the last time this "timestamped edge count" datapoint changed, the driver can estimate velocity as V = dX/dT. If the datapoint has not changed (no edges seen) since the previous time through the servo loop, then things get a little more complicated. We know an upper bound on the velocity - it's *not* so fast that we *just* saw an edge. If this upper bound is *greater* than the previous velocity estimate, then stay with the previous estimate. If the upper bound is *smaller* than the current velocity, then use the upper bound. So, the "one edge every other servo period" example above would look like this. "Ts" is the time that the servo loop runs, "X" is the total number of edges seen, and "Te" is the timestamp of the most recent edge. Ts=0.000000 X=0 Te=0.000000 Starting condition, first time through the loop. Report V = 0. Ts=0.001000 X=1 Te=0.000456 New datapoint! This informs the position, but we dont have enough data to estimate velocity yet. Ts=0.002000 X=1 Te=0.000456 No new edge this time. The fastest possible (average) speed since the last time through the loop would result in an edge right after we checked, which would mean X=2, Te=0.002001. *If* that edge arrived, we would see V = (2-1)/(0.002001-0.000456) = 647 edges/second. This is greater than the previous (initial) V of 0, so report that V = 0 still. Ts=0.003000 X=2 Te=0.002456 New datapoint! V = (2-1)/(0.002456-0.000456) = 1/0.002 = 500 edges/second. New datapoints (unlike upper bound estimates) force updating V, so report V = 500, which is the correct value for this thought experiment. Ts=0.004000 X=2 Te=0.002456 No new datapoint. The upper-bound V would result in a datapoint X=3 Te=0.004001, for V = (3-2)/(0.004001-0.002456) = 647 edges/second. That's higher than the previously reported velocity, so report the previous velocity instead, V = 500. Ts=0.005000 X=3 Te=0.004456 New datapoint! V = (3-2)/(0.004456-0.002456) = 1/0.002 = 500. New datapoints force updating V, so report (again) the correct value of 500 edges/second. Things could go on like above indefinately, and it would always report V=500. Let's say instead that the encoder stops moving at this time. True V is now 0. All future readings of the encoder counter will have the current datapoint of X=3 and Te=0.004456 Ts=0.00600 X=3 Te=0.004456 No new edge, estimate upper bound V = 647 edges, report old V = 500. Ts=0.00700 X=3 Te=0.004456 No new edge, upper bound V = (4-3)/(0.007001-0.004456) = 393. Report V = 393. Ts=0.008000 X=3 Te=0.004456 No new edge, report V = (4-3)/(0.008001-0.004456) = 282. I'll stop there, but the reported velocity decays towards zero, until you hit some timeout and give up and report V = 0. In hm2, this timeout is controlled by the encoder.XX.vel-timeout parameter. I think you can see how this system works well with both slower and faster encoder velocities across a great range, and how it reacts quickly to changes in velocity. Without the encoder counter reporting Te, the driver has to use Ts for the delta-T in the velocity estimation (just like the "ddt" HAL component does). The golden nugget of insight here is: The edge timestamping done by the encoder counter removes the servo period from the velocity estimation, replacing it with more information from the actual encoder hardware, and that removes the greatest source of quantisation error. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
