Back
[00:21:37] <jepler> SWPadnos: if someone knew the pthreads api better than me I'm sure it could be switched back
[00:22:01] <jepler> rtai's userspace "looks like" pthreads, and I assume with the -rt kernels you also use a pthreads API
[00:22:25] <jepler> getting rid of the weird requirement of gnu pth would be a nice if small payoff too
[00:23:14] <SWPadnos> I think RTAI and linux (with or without the -rt patches) are both POSIX
[00:23:21] <SWPadnos> or at least have a POSIX-like interface
[00:46:33] <jepler> I found that there are bugs in the cvs->git conversion of the emc2 history -- at least one file existed when it shouldn't have (debian/emc2.files) and several didn't exist when they should have (debian/.../mumble.desktop)
[00:47:22] <jepler> on the other hand, I found it very convenient to make a whole bunch of changes in my private repository as a series of checkins, then convert them to cvs in a series of cvs commits
[00:50:52] <SWPadnos> CVS doesn't really have the concept of a "change set" does it?
[00:51:13] <SWPadnos> ie, when you checkin 100 files, it's 100 transactions, even if you did it with one command
[01:17:08] <jepler> SWPadnos: yes, but 'cvsps' tries to group them based on identical commit message and nearby timestamps
[01:17:13] <jepler> git uses cvsps
[01:17:38] <jepler> some of the stuff we have done with branches (like have only some files branched) seems to confuse either git or cvsps, I'm not sure which
[01:17:51] <SWPadnos> ah - I think I was thinking about the other direction - checking into CVS vs. git
[01:18:38] <jepler> oh
[01:19:31] <jepler> cvs-gitexport makes all the changes in the working tree and does the checkin with 'cvs commit'
[01:20:20] <SWPadnos> err - maybe I should have said "this is another area in which CVS doesn't seem to keep up with some other SCM tools"
[01:20:51] <jepler> oh -- yeah
[01:28:22] <jepler> jmkasunich_: so hypothetically, 'loadrt pid num_chan=3 velocity_input=1,0,1' could create 3 pids; pid.0.velocity-fb and pid.2.velocity-fb would be hal pins, and pid.1 would estimate velocity as now
[01:30:06] <jmkasunich_> yeah
[01:30:32] <jmkasunich_> s/estimate velocity as now/compute the D term as now/
[01:31:09] <SWPadnos> should that be in PID?
[01:31:22] <SWPadnos> ora separate componetn
[01:31:25] <SWPadnos> component
[01:31:55] <jmkasunich_> if it's 95% the same code as the existing PID, and if the default is to work just like the existing PID, I'd add it to the existing one
[01:32:05] <jmkasunich_> otherwise you have 95% of the code duplicated
[01:32:21] <jmkasunich_> and any bugs found in that 95% will need to be fixed in two places, etc
[01:33:21] <SWPadnos> I may not know what you're thinking of, but if it's in relation to the D term conversation with JonE, then I'm not sure how that can go in PID
[01:33:35] <jmkasunich_> just what jeff was saying
[01:34:04] <SWPadnos> ah - now I get it :)
[01:34:11] <jmkasunich_> if you specify "velocity_input" when loading the module, the PID will have an additional feedback pin for velocity (in addition to the position fb)
[01:34:23] <SWPadnos> so you'd have a velocity input pin - duh :)
[01:34:24] <jmkasunich_> and the "better" vel fb from the encoder would go to it
[01:34:26] <SWPadnos> I think I need a break :)
[01:34:30] <jepler> though I don't think that his boards have a provision for high-precision velocity reports...
[01:34:35] <jmkasunich_> in fact, there are other places where that would be usefull
[01:34:38] <SWPadnos> no, I don't believe so at the moment
[01:35:03] <jmkasunich_> for example, the folks who want to do linear scales - if they get vel fb from a motor encoder, they can get pos fb from the scale
[01:35:17] <SWPadnos> he could probably add a timestamp register, but there's not a whole lot of address space for moving the data back to the PC
[01:35:19] <jmkasunich_> likewise, analog tachs with A/D converters would work for vel fb
[01:35:44] <SWPadnos> * SWPadnos has tachs, and maybe a spare analog board or two ...
[01:35:51] <jmkasunich_> jon's boards can't provide good velocity feedback, so they're not relevant
[01:36:11] <fenn> can't you use a separate ADC card?
[01:36:22] <SWPadnos> could, but why bother when I have spares ;)
[01:36:40] <fenn> besides ppmc
[01:36:42] <SWPadnos> someone with a Motenc or similar could use one oftheir analog inputs (I think they have inputs anyway)
[01:36:52] <SWPadnos> oh, you only need analog if you have a tach
[01:36:58] <fenn> right
[01:36:59] <SWPadnos> for encoder feedback, you need something else
[01:37:08] <fenn> a lowpass :)
[01:37:12] <SWPadnos> heh
[01:37:23] <fenn> and a one-shot
[01:37:25] <SWPadnos> you'd always be at 50% velocity, unless the motor is stopped ;)
[01:37:29] <SWPadnos> heh
[01:37:45] <fenn> digital filters are cooler tho
[01:38:38] <jmkasunich_> for encoder feedback you need hardware with timestamping
[01:39:01] <jmkasunich_> or if the frequency is low enough, the software encoder counter, which has timestamping at the base period rate
[01:39:36] <SWPadnos> what sort of timestamp resolution do you think is needed?
[01:39:53] <SWPadnos> is 0.1 ms good enough or do you need it in the 0.01ms range?
[01:40:06] <jepler> I hate it when I look at source code and the understanding I thought I had of it or the algorithm it expresses suddenly evaporates
[01:40:27] <jepler> (which just happened when I went to look at pid)
[01:40:36] <jmkasunich_> SWPadnos: "good enough" is a hard question to answer
[01:40:48] <SWPadnos> heh - I know
[01:40:54] <SWPadnos> "it depends on what you're doing" ...
[01:41:08] <jmkasunich_> jepler: it's annoying that something so simple isn't actually simple
[01:41:56] <jmkasunich_> anything I can try to clarify?
[01:42:20] <jepler> no, I have the feeling it would fall on deaf ears
[01:43:02] <jmkasunich_> what are you trying to do? add the vel fb?
[01:43:14] <jepler> that's what was on my mind, yeah
[01:43:17] <fenn> i wrote this a while ago, anyone care to vouch/criticize it?
http://en.wikipedia.org/wiki/PID_controller#Pseudocode
[01:43:59] <jmkasunich_> jepler: I think the lines after the comment "calculate derivitave term" need to be revised and moved down
[01:45:27] <jmkasunich_> if moved after "calculate derivitave of command", then the error derivative can be "cmd vel - fb vel" instead of "derivative of (cmd pos - fb pos)"
[01:48:30] <jepler> if deadband wasn't applied, tmp1 * periodrecip would be "cmd vel (estimate)" right?
[01:48:47] <jepler> but after deadband is applied it's not...
[01:49:10] <jmkasunich_> I'm thinking that deadband isn't needed for the D term
[01:49:33] <jepler> hm is it deliberate that the I and D terms are computed using the "deadband applied" estimate?
[01:49:37] <jmkasunich_> deadband is mostly to prevent hunting when the commanded position is a float that falls between integral encoder counts
[01:50:05] <jmkasunich_> the I does need deadband, otherwise that fractional count will integrate and produce hunting
[01:50:18] <jmkasunich_> D uses the deadbanded error just because it's easy, and consistent
[01:52:26] <SWPadnos> I wonder if that's a problem
[01:52:40] <jmkasunich_> using the deadbanded error for D?
[01:52:45] <SWPadnos> yep
[01:52:53] <jmkasunich_> I doubt it
[01:53:02] <SWPadnos> you'll have 0, then it will snap to the deadband value
[01:53:17] <SWPadnos> or higher
[01:53:25] <jmkasunich_> nope, the deadband isn't implemented that way
[01:53:29] <SWPadnos> ok :)
[01:53:52] <jmkasunich_> if error > deadband, error -= deadband
[01:53:56] <jepler> /* apply the deadband */ if (tmp1 > pid->deadband) { tmp1 -= pid->deadband; } else if (tmp1 < -pid->deadband) { tmp1 += pid->deadband; } else { tmp1 = 0; }
[01:54:04] <jmkasunich_> if error < deadband, error += deadband
[01:54:14] <jmkasunich_> else error = 0
[01:54:32] <jmkasunich_> that was specifically chosen to prevent discontinutities
[01:54:42] <jmkasunich_> ignore my spelling
[01:54:51] <SWPadnos> ok
[01:55:10] <SWPadnos> it's a little off everywhere, but doesn't jump
[01:55:17] <jmkasunich_> right
[02:00:26] <jepler> * jepler finally figures out that what he was trying to sab about tmp1 was gibberish
[02:01:00] <jepler> "say about"
[02:01:02] <jepler> see, gibberish
[02:14:25] <jepler> now problem is that "feedback-vel" as a pin name breaks the fact that you can use pid on position or velocity (or maybe even acceleration)
[02:14:48] <jmkasunich_> feedback-D?
[02:15:00] <jmkasunich_> or feedback-derivative?
[02:15:05] <jmkasunich_> or derivative-feedback?
[02:19:30] <jepler> I don't love any of those but at least they aren't deceptive
[02:20:38] <jepler> unfortunately I don't have any hardware useful for testing this...
[02:24:16] <jepler> a patch in two parts:
http://emergent.unpy.net/index.cgi-files/sandbox/pid-deriv.patches
[02:25:22] <jmkasunich_> getting rid of "tmp" is a good idea
[02:26:22] <jepler> I understand that the way it was written was intended to optimize stack usage by manually finding that the lifetime of certain temporaries didn't overlap
[02:26:39] <jmkasunich_> IOW, it was prematurely optimized
[02:26:50] <jmkasunich_> (I'll admit to that)
[02:27:48] <jmkasunich_> + hal_float_t *feedback_d; /* pin: feedback derivative (or NULL) */
[02:27:55] <jmkasunich_> what's the bit about NULL mean?
[02:28:18] <jepler> If the pin is not created, the pointer is set to NULL; that's the test used in the pid function to decide whether to use derivative feedback or the old estimate
[02:28:35] <jmkasunich_> ah
[02:29:34] <jmkasunich_> prev_error is used ONLY to calc the error derivative?
[02:29:43] <jmkasunich_> (if in doubt it should be saved outside the conditional)
[02:30:14] <jepler> I didn't see any other use of it
[02:30:27] <jepler> float prev_error; /* previous error for differentiator */
[02:30:27] <jepler> pid->error_d = (error - pid->prev_error) * periodrecip;
[02:30:27] <jepler> pid->prev_error = error;
[02:30:27] <jepler> addr->prev_error = 0.0;
[02:30:33] <jepler> only 4 lines with prev_error in them
[02:30:54] <jmkasunich_> and it's not a hal_float, so not exported as a param or anything like that
[02:31:38] <jmkasunich_> those patches look good to me
[02:31:49] <jmkasunich_> I didn't examine every single line of the first one
[02:32:09] <jmkasunich_> that one only changes the temp var names, and reorders a couple calculations, right?
[02:34:59] <jepler> right
[02:35:04] <jepler> it shouldn't be a substantive change
[02:36:30] <jepler> Issuing EMC_TRAJ_CIRCULAR_MOVE -- (+221,+168, +0,0.000000,0.000167,0.000167,-469857228255643185479934995862687054436782682189354950646292292749495407340299812337449399124738493328162347427480493091058003966304970205506689528750485815651053165046385356181149555805423820469970853059141928594616237253990801995370135368532687323136.000000,-46985744206480235946010509325051057984141013926424568142017714795088882695519653960234864319779422213263
[02:36:37] <jepler> well here's an interesting debug message ..
[02:36:45] <jmkasunich_> have a few digits
[02:38:53] <jepler> the patch must be wrong because pid better before I hooked up net Xvel-fb encoder.0.velocity => pid.0.feedback-derivative
[02:39:03] <jepler> in servo-sim
[02:39:52] <jmkasunich_> not sure I follow that
[02:39:56] <jmkasunich_> "pid better"?
[02:40:12] <jepler> I'm running servo-sim with the pids in the new "derivative feedback" mode
[02:40:17] <jmkasunich_> right
[02:40:25] <jmkasunich_> the old PIDs worked better?
[02:41:04] <jepler> with pid.0.feedback-derivative not hooked up (but presumably in use), it has lower and more regular error, and more steady output, than with it hooked up to what should be the right feedback velocity
[02:41:29] <jmkasunich_> hmm
[02:41:37] <jepler> I expected to get bad behavior with pid.0.feedback-derivative stuck at 0 than with it hooked up to the encoder velocity value
[02:41:43] <jmkasunich_> with it not hooked up, dgain should have no effect
[02:42:02] <jmkasunich_> with it hooked up, dgain = 0 should give the same result as not hooked up at all
[02:42:43] <jepler> huh -- there's a short disturbance in the error (halscope on 'roll') when I change Dgain with feedbac-derivative unhooked
[02:43:32] <jmkasunich_> oh, I lied
[02:43:50] <jmkasunich_> with feedback-d unhooked, the D term is "cmd-d"
[02:44:03] <jmkasunich_> with dgain at zero, the D term is zero
[02:45:05] <jepler> I'm going to put this aside for now
[02:45:10] <jmkasunich_> ok
[02:45:31] <jepler> goodnight
[02:45:54] <jmkasunich_> goodnight
[02:46:01] <jmkasunich_> that sounds like a good plan (sleeping)
[12:41:52] <jepler> hi skunkgibbin
[12:42:00] <jepler> you could also consider calling yourself 'gutsworks'
[12:42:22] <skunkworks> heh
[12:42:33] <skunkworks> morning
[13:10:01] <jepler> con
[13:10:02] <jepler> argh
[13:10:10] <jepler> :%d :wqa!
[13:14:41] <Guest139> umm - yah
[13:15:02] <Guest139> Guest139 is now known as skunkworks
[22:26:46] <Roguish_> Roguish_ is now known as Roguish
[22:47:14] <cradek> * cradek grumbles about arc centers
[22:47:41] <cradek> I want G999: use irritating absolute arc centers
[23:15:47] <cradek> MOTION: rtapi_shmem_new failed, returned -4
[23:16:15] <cradek> anyone else getting this? I even make cleaned
[23:19:13] <cradek> hm reboot fixed it