> > http://emergent.unpy.net/files/sandbox/pid-trad.png > > 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. > > On Tue, Oct 26, 2010 at 08:29:52PM -0500, Jon Elson wrote: > I am a bit confused as to why the following error goes from about > .0015" (off scale) to .0002".
I'm not sure why myself. I am nearly certain the only thing I changed between the two captures was the use of the software encoder's velocity output. I suspect that under the traditional pid setup and with a real machine this is the kind of tuning that is simply *so* bad that you'd immediately e-stop it and lower something (namely the Dgain). Why it behaves specifically like you see in the graph, I'd be reluctant to speculate. > 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. Indeed. I chose the velocity to be well under 2 counts per servo cycle (but still in the realm where velocity estimation is very good) in the hopes of making the old code look as *BAD* as possible. > 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. Actually, the modified pid is intended to be entirely compatible with the original pid without any ini/hal changes. The way I accomplish this is a little bit gross (it treads on a hal implementation detail, the "dummysig") but it means less disruption or duplication of code (at_pid, I'm looking at you!). > 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. Cool! I recall that with hostmot2 it took a number of iterations on the driver side to deal fully with direction reversals and counter overflows in all the corner cases, but the timestamp is the basic building block that makes the high-quality velocity estimae possible. Jeff ------------------------------------------------------------------------------ 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
