Menu
▾
▴
emc-developers
|
From: Peter C. W. <pc...@me...> - 2010-11-01 14:34:27
|
On Mon, 1 Nov 2010, Jon Elson wrote: > Date: Mon, 01 Nov 2010 00:13:36 -0500 > From: Jon Elson <el...@pi...> > Reply-To: EMC developers <emc...@li...> > To: EMC developers <emc...@li...> > Subject: Re: [Emc-developers] pid with derivative inputs > > Well, after an AMAZING amount of fooling around with barely one page of > code, I finally > have MOST of the velocity estimation working in the ppmc driver. I'm > still not sure it is right, though. > > One quirk, which I think is inherent in the way that HAL component > encoder.c works, > and which I copied, > is that a dithering encoder gets the wrong velocity. The first count of > the dither gets > the right velocity, as there was no movement for some time before. The > second count, > if immediately following the first one, cancels out the movement, but it > gets twice the > velocity, as these are seen as two counts in a short period of time. I > suppose you could look > back two servo periods, and if the position delta between now and n-2 is > zero, then velocity > should be zero in that case. > > Maybe I implemented the code wrong. Under some conditions it seems like > it might be an > improvement, but it is not as smooth as I had hoped for. Now, maybe the > problem is the > servo I am using for tuning is so jittery (as it does not yet use the > velocity info) that it creates > a lot of these dithery counts. > > Jon One good sanity check on the velocity output is to setup your hardware step generator for quadrature mode and set a constant velocity but randomly changing directions(and ~infinite acceleration). Another good test is just a slow velocity ramp. The advantage is the the hardware doesnt have the quirks of a real encoder/motor. For example, quadrature phase error (signals not at exact 90 degrees) will limit the improvement that a simple, all edge time stamp can bring. > > ------------------------------------------------------------------------------ > 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...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. |
|
From: Peter C. W. <pc...@me...> - 2010-11-01 16:53:46
|
On Mon, 1 Nov 2010, Jon Elson wrote: > Date: Mon, 01 Nov 2010 11:18:06 -0500 > From: Jon Elson <el...@pi...> > Reply-To: EMC developers <emc...@li...> > To: EMC developers <emc...@li...> > Subject: Re: [Emc-developers] pid with derivative inputs > > Peter C. Wallace wrote: >> >> >> One good sanity check on the velocity output is to setup your hardware step >> generator for quadrature mode and set a constant velocity but randomly >> changing directions(and ~infinite acceleration). Another good test is just a >> slow velocity ramp. The advantage is the the hardware doesnt have the quirks >> of a real encoder/motor. For example, quadrature phase error (signals not at >> exact 90 degrees) will limit the improvement that a simple, all edge time >> stamp can bring. >> > But, I WANT to see how it responds to all the vagaries of real encoders, > especially dither > and the quantizing noise. I was comparing against the software encoder > component reading > my MPG, with detents. I observed the phase error effect as the detents > in the MPG severely > affected the quadrature phasing. By gripping the knob tightly in my > clenched fist I got most > of the detent effect to disappear. That was an interesting effect to > observe. Sure, ultimately you want to test with real world signals but when debugging its good to reduce the number of variables or at least have good control of them... Peter Wallace Mesa Electronics |
|
From: Jon E. <el...@pi...> - 2010-11-02 01:56:04
|
Peter C. Wallace wrote: > Sure, ultimately you want to test with real world signals but when debugging > its good to reduce the number of variables or at least have good control of > them... > I added a number of internal variables to the exported pins so I could Halscope them, this made deciphering what was going on easier. Jon |
|
From: Jeff E. <je...@un...> - 2010-10-27 01:30:35
|
I tried this on my little circuit board milling machine and it can make
a difference there as well.
I retuned with the hostmot2 high-quality velocity estimate, and then ran
with and without it. The new tuning parameters I ended up with were
Component Pins:
Owner Type Dir Value Name
10 float I/O 5 pid.0.Dgain
10 float I/O 0 pid.0.FF0
10 float I/O 0.615 pid.0.FF1
10 float I/O 0.0045 pid.0.FF2
10 float I/O 0.01 pid.0.Igain
10 float I/O 150 pid.0.Pgain
in the old tuning, Dgain was 2.
http://emergent.unpy.net/files/sandbox/pid-old-zenbot.png
http://emergent.unpy.net/files/sandbox/pid-new-zenbot.png
red: axis.0.joint-pos-cmd
purple: Xpwm-cmd
cyan: pid.0.error
cream: pid.0.feedback-deriv (note change in scale: 10m vs 50m)
what you don't see in the picture is the difference in the noise.
Without the improved velocity estimate, there's a sickly hum or honk
coming from some part of the machine resonating -- actually, you can see
it in all those reversals of the purple trace, Xpwm-cmd. The overall
following during a cruise isn't much different, but I'd sure rather have
it without the noise! (lowering Dgain also gets rid of it).
It's also interesting to note that the pattern of lead/lag is nearly the
same in both traces. That variation seems to be something physical
about the machine, and can't be cured by PID tuning. Of course, it's
also tiny compared to all the other kinds of slop in this flimsy little
machine...
Jeff
|
|
From: Jon E. <el...@pi...> - 2010-10-27 05:24:52
|
Jeff Epler wrote: > > what you don't see in the picture is the difference in the noise. > Without the improved velocity estimate, there's a sickly hum or honk > coming from some part of the machine resonating Yes, the Y axis of my minimill has a Japan Servo disc motor, and it produces a very annoying sound almost like it has sand in the bearings. I know, from tuning, that this is the quantization noise coming through the D term. If I get to Wichita, I can demo this noise. I may not bring the minimill, but I definitely will bring one of those motors, I can clamp it to a table for a sounding board. This noise is exactly the symptom of what I want to get rid of. Jon |
|
From: EBo <eb...@sa...> - 2010-10-27 05:45:16
|
> Jeff Epler wrote: > > what you don't see in the picture is the difference in the noise. > Without the improved velocity estimate, there's a sickly hum or honk > coming from some part of the machine resonating Why not post some sound clips? |
|
From: Jon E. <el...@pi...> - 2010-10-27 05:34:34
|
Jeff Epler wrote: >>> > On Tue, Oct 26, 2010 at 08:29:52PM -0500, Jon Elson wrote: > > 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!). > Ah, very good! >> 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. > Yes, I'm expecting some of the same difficulty. I've been looking at the encoder hal component, but I couldn't really see any code to handle those cases, so I was wondering how the heck it worked. It seems a direction reversal shouldn't actually be a special case, except in some kind of crazy case where there were several counts in the minus direction and the last count was in the + direction, all in the same servo period. That seems like it shouldn't happen, except maybe due to encoder dither. The counter overflow would be rare on the hal component, it uses a 32-bit integer, and whatever the BASE_THREAD is running at, so that's maybe every 85000 seconds or just about once a day. I'm using a 16-bit counter and a 1 MHz clock, so it overflows every 65 milliseconds. I may have to look at the hostmot2 code to see how they do it there. Jon |
|
From: Andy P. <an...@an...> - 2010-10-27 10:40:15
|
On 27 October 2010 06:34, Jon Elson <el...@pi...> wrote: > I may have to look at the hostmot2 code to see how > they do it there. I made a patch to add velocity to the Motenc driver, but there is no timestamping there so it is just as brain-dead as the one built-in to PID. (Also the patch has never been tried on actual Motenc hardware, I sent it to Don Stanley and then forgot about it for several months. Motenc were going to send me a card, but I think I told them not to bother) -- atp |
|
From: Stephen W. P. <sp...@so...> - 2010-10-30 16:54:42
|
Jeff Epler wrote: > On Wed, Oct 27, 2010 at 05:38:24PM +0100, Andy Pugh wrote: > >> On 27 October 2010 17:09, Jeff Epler<je...@un...> wrote: >> >> >>> It's a dirty trick and I'd rather see it get as little use as possible.. >>> >> Is there an easy, elegant way to make it less dirty? I can see many >> uses for it (encoders going automatically into counter-mode, bldc >> drivers knowing whether to use encoder or hall-sensor feedback spring >> to mind) >> > You're right. Either I shouldn't use the trick here, or other > components should feel free to use the trick. Which do we want to do? > > First, let me summarise what the trick *is*. After hal_pin_new returns, > the pin points at the internal "dummysig". The dummysig exists so that > it's always permitted to dereference a pin, regardless of whether a pin > is connected. > > When a pin is connected to any signal, the address it points to is some > other address than the dummysig. > > If the dummysig address is stored just after hal_pin_new, this enables: > * test in constant time and from a RT thread whether the pin is > connected to any signal > * generate a value internally onto the dummysig that is later read as > the pin's value when the pin is not connected to any signal > > There are some reasons to *not* use this trick in hal components: > * In the future we might see a way to change the design in a way that > makes the trick unusable (for instance, something that doesn't > require the dummysig at all) > * The hal lock is held during the time between hal_pin_new and the copy > I think this is supposed to say that the HAL lock is *not* held ... > of the dummysig address. Instead, the assumption that makes this > safe is that the only possible pin-linker is the same halcmd that is > waiting for this component to be ready. We might want to violate > this assumption sometime in the future (and you can probably violate > it now just by running two halcmds at the same time) > * The trick depends on whether a signal is connected, not whether a > signal with a writer is connected. So for instance, connecting a > signal and then scoping the signal will modify the component's > behavior. (thanks to SWP for identifying this problem) > > What other considerations (uses or problems) are there than the ones > I've identified? Shall we decide to use this trick freely, or to use it > not at all? If we decide to use it freely, should we create some kind > of API to make its use more explicit? > It seems reasonable to me to create an API for this. Something like pin_is_connected(something). At the moment, that can be a #define macro that tests for (something==&((halpin)something->dummysig)) (or whatever the correct spelling is). If it turns into an actual function call, or we add a flag to the pin struct that tells whether it's connected, has a writer, etc, the function can change. In fact, a full set of functions might as well be defined: pin_has_reader() pin_has_writer() pin_is_connected() (has_writer() and has_reader() also imply is_connected()==true) Similar API functions for signals may be useful. Maybe not in RT components, but certainly in userland utilities. There may be an argument that these functions shouldn't exist - an IC doesn't know whether a pin is being used, or what it's being used for. It's just supposed to do its function(s) anyway. If there's a need for this knowledge inside a component (the equivalent of an IC in the HAL model), then maybe the design of the component is wrong. I guess my opinion is that we should add a full API or nothing at all :) - Steve |
|
From: Jon E. <el...@pi...> - 2010-10-31 04:51:22
|
Stephen Wille Padnos wrote: > There may be an argument that these functions shouldn't exist - an IC > doesn't know whether a pin is being used, That's not completely true. There are things like weak holders and resistive pull-ups/ pull-downs and such tricks to get more than plain high/low logic level functionality. Some of this stuff is used on FPGAs for various tricks before and during configuration. Jon |
|
From: Jeff E. <je...@un...> - 2010-10-31 15:53:14
|
On Sat, Oct 30, 2010 at 12:55:13PM -0400, Stephen Wille Padnos wrote: > In fact, a full set of functions might as well be defined: > pin_has_reader() > pin_has_writer() > pin_is_connected() > (has_writer() and has_reader() also imply is_connected()==true) Of these, only the last can be determined with the dummysig trick; the other two presently require taking the HAL lock and traversal of a linked list. Jeff |
|
From: Jon E. <el...@pi...> - 2010-11-01 16:18:21
|
Peter C. Wallace wrote: > > > One good sanity check on the velocity output is to setup your hardware step > generator for quadrature mode and set a constant velocity but randomly > changing directions(and ~infinite acceleration). Another good test is just a > slow velocity ramp. The advantage is the the hardware doesnt have the quirks > of a real encoder/motor. For example, quadrature phase error (signals not at > exact 90 degrees) will limit the improvement that a simple, all edge time > stamp can bring. > But, I WANT to see how it responds to all the vagaries of real encoders, especially dither and the quantizing noise. I was comparing against the software encoder component reading my MPG, with detents. I observed the phase error effect as the detents in the MPG severely affected the quadrature phasing. By gripping the knob tightly in my clenched fist I got most of the detent effect to disappear. That was an interesting effect to observe. The software scheme that I copied has different modes depending on whether a count was recorded in the last servo cycle or not. I'm not convinced the code I produced is correctly blending between the two. I THINK I have checked all the scaling factors on paper and they seem to be right. But, at certain speeds, the velocity estimate seems to be jumpier than it should be. This could be the effect of the servo that is driving the encoder, I will have to back off on the servo tuning and see if it looks better. Jon |
|
From: andy p. <bod...@gm...> - 2018-06-14 12:45:33
|
On 31 October 2010 at 15:53, Jeff Epler <je...@un...> wrote: > > On Sat, Oct 30, 2010 at 12:55:13PM -0400, Stephen Wille Padnos wrote: >> In fact, a full set of functions might as well be defined: >> pin_has_reader() >> pin_has_writer() >> pin_is_connected() >> (has_writer() and has_reader() also imply is_connected()==true) > > Of these, only the last can be determined with the dummysig trick; the > other two presently require taking the HAL lock and traversal of a > linked list. I have no recollection of an API being added. So, before I go ahead and use the dummysig trick in a component, did we reach consensus about whether it is to be encouraged, deprecated or abhorred? -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1916 |
|
From: Chris M. <chr...@ho...> - 2018-06-19 15:09:47
|
________________________________ From: andy pugh <bod...@gm...> Sent: June 14, 2018 12:44 PM To: EMC developers Subject: Re: [Emc-developers] using the dummysig trick (was Re: pid with derivative inputs) I have no recollection of an API being added. So, before I go ahead and use the dummysig trick in a component, did we reach consensus about whether it is to be encouraged, deprecated or abhorred? My 2 cents: I would not encourage the dummysig trick (meaning behavior is different based on whether a signal is connected or not) This is black magic voodoo. - brilliant but - unintuitive, hard to recognize the error, easy to create the error. In fact pncconf connects signal names to components and doesn't necessarily connect them to anything. When PID added this trick I was unaware - and pncconf created the error - Peter eventually noticed while diagnosing a user's problem. Wouldn't a pin created to set the behavior be safer? In fact isn't that was what param's were made for? (not that I would use params for anything today, since you can't connect to them) Chris M |
|
From: Jeff E. <je...@un...> - 2018-06-14 21:15:10
|
I think there's little use for the functions SWP proposed, assuming his analysis that they have to take a HAL lock is true. The functions aren't useful at component-init time, because it's expected for there to be no connections yet; but they're not usable at runtime, which is when the dummysig trick is useful. Is there another use case to consider? Go ahead and use dummysig if it's appropriate, and wrap it in an API if you like, but don't add these other functions without a good motivation. Jeff |
|
From: John K. <jmk...@fa...> - 2018-06-17 21:06:17
|
On Thu, Jun 14, 2018, at 4:31 PM, Jeff Epler wrote: > I think there's little use for the functions SWP proposed, assuming his > analysis that they have to take a HAL lock is true. The functions > aren't useful at component-init time, because it's expected for there to > be no connections yet; but they're not usable at runtime, which is when > the dummysig trick is useful. Is there another use case to consider? > Why are they not usable at runtime? Nothing precludes taking the HAL lock at runtime. The lock prevents changes to the HAL topology, but does not prevent execution of HAL functions and components. > Go ahead and use dummysig if it's appropriate, and wrap it in an API if > you like, but don't add these other functions without a good motivation. > > Jeff > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-developers mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-developers -- John Kasunich jmk...@fa... |
