Jeff Epler wrote: > It's been mentioned many times, most recently by Jon Elson, that it > would be nice if pid could take a better velocity estimate than the one > it gets by performing a two-point numeric differentiation of the error > term. > > I got around to implementing this and testing it very lightly on > servo-sim. It looks promising! > > > > Without the new feedback-deriv pin hooked up, following is terrible and > feedback derivative estimate is all over the place: > http://emergent.unpy.net/files/sandbox/pid-trad.png > (green/cyan trace: cmd, fb; purple trace: feedback-deriv estimated from > feedback position; tan trace: pid error) > > With the new feedback-deriv pin hooked up to the velocity estimate, > following is much better thanks to the high-quality velocity estimate > http://emergent.unpy.net/files/sandbox/pid-bettervel.png > (green/cyan trace: cmd, fb; purple trace: feedback-deriv from encoder > based on timestamps; tan trace: pid error; scales all the same as before) > > Note that with encoder.0.scale=6000, a 1-count error is 166u, so the > following went from "all over the map" to "+-2 counts". > > Both screenshots use the same pid tuning parameters. Only the source of > the feedback derivative (velocity) differs. > I am a bit confused as to why the following error goes from about .0015" (off scale) to .0002". The change in the feedback-deriv is exactly as expected, and what I was looking for, all those nasty sampling time induced spikes are gone. At the particular velocity Jeff tested this at, the spikes are about equal to the velocity, for a signal-noise ratio of 1:1, which is certainly a BAD situation for a control loop. In the second trace, there is still (I think) some position quantization, which is unavoidable, but it is VASTLY better than without the correction. So, I think this proves that this is something that I should continue on.
Thanks Jeff, for resurrecting this variant of PID. I wonder if we could get this committed to the development head? It could either be a different component, or a command-line option to the standard PID component. If I don't make it out to Wichita, I definitely intend to try to put the velocity estimate into the hal_ppmc driver shortly. The UPC firmware has what I believe are the requisite functions. There is a 16-bit timestamp running at 1 MHz, and a 16-bit latch that records the timestamp at each encoder transition. If I can get this working, I will then add the function to the UPC and PPMC boards. Jon ------------------------------------------------------------------------------ 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
