00:13:59 rayh has quit 02:38:40 hey jmk_away, are you around? 02:38:52 no, he's not here 02:38:57 ;-) 02:39:01 ok - let me know when he returns :) 02:39:21 hey - a question on the time delay component 02:39:45 this is a simple one - I assume that a single update function is preferable to a zillion separate ones? 02:39:46 shoot 02:39:50 shot 02:40:06 you mean one that updates all delays, vs one per delay? 02:40:10 yes 02:40:12 that is a dilemma 02:40:22 heh - flexibility vs simplicity 02:40:29 exactly 02:40:34 I can do the group thing like you did with the debounces 02:40:45 (which is what I'm basing the code on) 02:40:57 nah, that smacks of cluge 02:40:57 kluge 02:41:08 yash, kinda 02:41:11 teah 02:41:13 yeah 02:41:15 heh 02:41:21 do all in one 02:41:22 too much grasshopper pie ;) 02:41:24 o0k 02:41:27 ok 02:41:51 if I ever get that "automatic dependency checker and addf generator" working, then I'd want one per component 02:41:54 but that is in the future 02:42:05 emc3.5 02:42:16 not that far, I was thinking emc2.4 maybe 02:42:34 that would be cool 02:42:48 however... (there's always a however) 02:42:48 I really want to do the hal refactor, just need to make the time 02:42:59 yep - time is always a problem 02:43:13 whats the "however" 02:43:43 well - I suppose it doesn't really matter at this point, since you can't change functions while threads are running 02:43:57 actually you can 02:44:10 you can do addf while its running 02:44:21 (I think) 02:44:26 does it actually add the function? 02:44:30 yes 02:44:31 I thought it wouldn't do that 02:44:44 maybe I'm misremembering 02:44:48 lemme check 02:44:55 but I guess it must - you can add scope_rt to a running emc 02:45:27 I want to double check that I did it in a thread safe way 02:45:29 hal threads are started during the initialization of emc, right? 02:45:31 heh 02:49:47 yeah, its thread safe, the next and previous links in the new funct struct are set before any of the links in the original list point to the new entry 02:50:34 the RT code follows the list in one direction only, so it either arrives before the new entry is linked (and doesn't run that funct) or after (and does run it, and then safely moves on to the next one) 02:51:08 is the struct protected by a semaphore or the like? 02:51:42 by a mutex, but that is to prevent simultaneous access for things like "show", "addf", etc 02:51:55 the RT code can run even tho halcmd holds the mutex 02:52:13 ok - so multiple halcmds simultaneously doing addf will fail or block? 02:52:25 but the insert operation itself is atomic 02:52:35 block, until the first one finishes 02:52:42 true - it should be one next pointer modification 02:53:06 see hal_lib.c line 1669 02:53:07 though you'd have unpredictable function ordering ;) 02:53:09 ok 02:53:26 if you had two addfs at the same time, yes 02:54:24 anyway - that was the "however" - if threads are running, you may need to swap the execution order due to any pin connection 02:54:29 that could be a real PITA 02:54:50 yes, it could 02:55:37 actually, it doesn't matter if threads are running, you still need to reorder (or run the ordering algorithm) for every pin connection made 02:55:58 unless you delay all that until "start" 02:56:31 if you have a signal chain like A->B->C->D->E, and B and D were both delay blocks, that adds a delay of one period 02:57:09 yes, if there is an auto-sequencer, it would have to re-evaluate after any signal-pin connection 02:57:38 that would depend on whether B and D are in ascending order or descending order in the delay list 02:57:42 in that case, to avoid messiness with relinking on the fly, I'd probably have two lists of functions, one active, one scratch 02:57:56 ok - in the scenario where they have independent update functions 02:58:31 with C inbetween, it doesn't matter what order they are within the one big function, there is no way for C to run after B and before D 02:58:45 ah - right 02:58:51 duh 02:59:26 anyway, for now we probably want to do "all in one", or do the group kluge, to keep the user from going batty with addfs 02:59:44 in the future when addfs are automagic, then one function per block 02:59:48 I'll do them all at once - this is a ladder like thing 03:00:03 yes 03:00:04 so they'd expect everything to be read, then operated on, then written 03:00:42 petev has joined #emc-devel 03:00:47 * jmk_away hides 03:01:05 hi Pete 03:01:09 hi pete 03:01:17 always joining after bedtime in the east ;) 03:01:35 yep 03:03:20 hi 03:03:33 yeah, I was busy this weekend 03:06:26 do you guys beleive it's possible to express a kinematics transform with a matrix? 03:06:48 certainly in some cases, but not all 03:06:58 yeah, that's what I thought 03:07:01 as long as the matrix is of arbitrary size, probably 03:07:05 some kins transforms don't have any closed form solution, and need iterative approaches 03:07:13 yes 03:07:24 along with initial guesses to tell it which side of a discontinuity it is on 03:07:41 fenn is trying to do some generic kinematics stuff, but I think he is going to spend a lot of time for not much results 03:08:09 hmm, I wonder if the line between close form and open form kins is serial vs. parallel 03:08:14 do you have any recommended reading on this stuff? 03:08:42 now that I think about it, I suspect that any series structure can use a transformation matrix (closed form) 03:08:52 as long as you do a separate transform for each joint, you can probably get a closed form solution for any physically realizable machine 03:09:15 what about the hexapod case? 03:09:25 ok - maybe not ;) 03:09:26 here you have several joints that limit each other 03:09:38 that may be the serial vs parallel think jmk is talking about 03:09:40 seems like multiple equations 03:09:44 yeah 03:09:48 there are even series configs that have discontinuities 03:09:58 like the scara robot 03:10:03 yeah, maybe elbow up/down type stuff 03:10:06 yes 03:10:09 is there a photo of the scara somewhere? 03:10:25 yeah, I think fenn is barking up the wrong tree, but I don't want to discourage him 03:10:35 did you see the cybaman thing soemone (tomp?) posted earlier? 03:10:41 no 03:10:47 http://www.cybamantech.co.uk/cyba/?page=cybaman 03:11:02 http://www.20sim.com/webhelp4/gettingstarted/Scara2.gif 03:11:06 (scara) 03:11:14 that thing is cool (the tomp one) 03:11:19 yep 03:11:29 yeah, pretty crazy 03:11:35 scara has two rotary and one linear joint 03:11:35 ok - the discontinuity is due to a physical limitation (no slipring), right? 03:11:52 look at the pic 03:11:54 and the tool will bind if you try to spin the second rotary joint too far 03:12:09 suppose you want the tool to centerpost distance to be less than the maximum 03:12:22 or the minimum ;) 03:12:40 that means the middle joint needs to be bent (elbow, sort of, but at 90 deg to a normal elbow) 03:12:47 so which way do you bend it? 03:13:04 answer (probably) the same way it was bent 1mS ago 03:13:08 it's not that there's a discontinuity, you calculate the middle joint angle to make the hypoteneuse the desired length 03:13:30 but the middle joint could be bent into or out of the paper 03:13:40 you run into a problem if the base rotation joint reaches a limit 03:14:37 do you guys see much value in generalized arbitray kinematics (if it can even be done)?? 03:14:44 no 03:14:50 me either 03:15:12 hey, we're not discouraging what you are doing (too much), so let Fenn have his fun 03:15:15 ;-) 03:15:16 I suspect that the mathematics knowledge needed to get a generalized matrix (if it's even possible) is way greater than the fairly simple polar / cartesian math needed now 03:15:44 yeah, I'm going to let him try, but I don't think he's going anywhere 03:15:50 I could write a kins module for the SCARA, but damned if I could figure out some closed form matrix transform for it 03:16:29 fenn wants to build data structures that represent the joints and links between them 03:16:32 I could probably do a matrix that given joint angles would give you end effector position and orientation, but not the other way around 03:16:43 then he wants to traverse it and build the matrix 03:16:48 right - and not all matrices are invertible 03:17:02 (if that would even give you the reverse transform) 03:17:19 yeah, this isn't easy 03:17:48 the matrices I was thinking of transform from end effector coords to world coords, and are invertable (world to end effector) 03:17:55 I helped him with data structs, but I don't know the math well enough, my gut says it's going to be very difficult if not impossible 03:18:03 but the joint angles are used to generate the matrix 03:18:26 so the matrix changes with every pose - ick 03:18:34 not bad 03:18:54 sound ick to me 03:19:02 sines and cosines - the video game and 3D graphics boys do that in their sleep 03:19:03 I could hand off the problem to my mother, but I'm not sure we'd get an "engineering" answer ;) 03:19:18 what good is the matrix if you need a new one for each pose? 03:19:34 I've got a library of 3D transform math tucked away somewhere 03:19:43 and posemath has some of that already 03:19:58 petev: the matrix isn't very attractive for this 03:20:04 right 03:20:07 tell fenn that 03:20:30 in 3D graphics, you generate one matrix for an object, then convert many points from object space to world space to render the object 03:20:48 then you move the object (modify the matrix) and repeat for the next frame 03:20:55 maybe we should be using Cg or the like ;) 03:20:58 here we only care about 1 point really, the end of the tool 03:21:08 right 03:21:14 (maybe 3 points, if you wnat to capture tool orientation as well as position) 03:21:41 right - so making a matrix (which basically means calculating the end point), so you can run it through matrix math to get the real answer, seems a bit wasteful 03:22:16 though with tool shape and obstacle avoidance, it may prove useful 03:22:18 what do you guys think of the joint accel/velocity limits for rotary robots? 03:22:20 there are advantages 03:22:42 you can generate a matrix for each joint, then contcatenate them 03:22:44 seems like they vary a lot in world space depending on joint position 03:22:58 jmk: that's what fenn wants to do 03:23:08 sorry pete, was responding to SWP 03:23:11 no - the limits are the same (at the moment), but the end effector speed varies 03:23:26 depending on position 03:23:36 swp: seems like on a rotary, the limits in world space would be sin/cos related 03:23:42 to do the limits, you need to be able to compute derivatives of the kins transforms 03:24:08 hmm, for TP seems like you need small cubes of limits in cartesian world space, no? 03:24:10 well - the ini file isn't really clear on joint vs. world corrdinates 03:24:34 heh - +_EMC_+ isn't really clear on joint vs. world coords 03:24:35 you put an axis_0 accel or vel limit there, does it apply to the axis or the joint? 03:24:40 swp: the TP seems to use them as world 03:24:40 right ;) 03:24:50 yep 03:25:11 so do we want EMC to handle non-trivkins correctly? 03:25:34 sure, but we need to prioritize that with all the other things we want it to do 03:25:40 I would say yes ;) 03:25:56 (one of which is not confuse the living hell out of the 95% of users who have trivkins) 03:25:58 then we really need to think about the whole TP and kins stuff 03:26:42 how else can you make the TP generic, other than to give it a cartesian map of joint limits? 03:27:12 are you talking about position, velocity, or accel limits? 03:27:30 yeah, cutting cartesian space into cubes and assigning them 03:28:01 no matter what size cube you choose, it will be too small, and too big (at the same time) 03:28:11 figuring out world-based limits is harder for non-trivkins machines, I'm not sure there's any way around that 03:28:27 why do you say that? it may not be optimal, but it seems like it would work 03:28:33 the cubes would depend on the kins 03:28:46 consider a rotary table 03:28:46 for trivkins, one big cube 03:29:00 motorized, of course 03:29:03 sure 03:29:25 too small as in you've got 20 bajillion of them and have RAM/speed issues, too big as in your work envelope is a jagged approximation of the real thing 03:29:30 the effective cutting load varies depending on the radius 03:29:46 radius from center of table to tool 03:30:09 jmk: a semi jagged approx may not be bad with conservative limits 03:30:38 also, it severely depends on the mass of the object, and its shape 03:30:53 there are more than just position limits 03:31:07 swp: mass is out, we're talking kins, not dynamics 03:31:11 assume the rotary table with a radial linear axis above it, and another linear for Z 03:31:24 so kin limits need to be conservative to account for mass changes 03:31:39 to cut a straight line thru the center of the table, the rotary needs to go to infinite speed as you pass thru center 03:31:53 lines near the center need high but not infinite speeds 03:32:15 net result, the velocity limit in world coords varies based on where you are 03:32:33 right, that's why cubes with limits 03:32:52 and you have to check the limits in every cube your path passes thru 03:33:02 yes, but that's not hard 03:33:12 you can use the graphics clipping algos 03:33:34 even better - you may not know what cube you're in until you've done the inverse kins 03:33:46 huh? 03:33:55 we are assuming we start in world space 03:33:59 sure 03:34:01 and the cubes are in world space 03:34:02 I think the problem will just be size of the cube data - this isn't a n^2 problem (which is bad enough) it is n^3 03:34:06 ah 03:34:37 and 99% of the cubes will have uninteresting data in them 03:34:49 jmk: agreed, but given how loose kins are compared to dynamics, do you really think we would need that many? 03:35:19 there are algos (again from graphics) for subdividing, so you use big cubes where things change slowly, and little ones where they change quiclky 03:35:26 (google voxels) 03:35:37 what other approaches are there that could work with arbitrary kins? 03:36:21 if the kins can be put in the form of polynomials, then they have closed form derivatives 03:37:01 so you can evaluate joint position, velocity, and accell over the entire path 03:37:20 isn't that going to be really slow and repetitive solution? 03:37:30 (solve for min and max values of the derivatives)] 03:37:39 if you step along the path, yes 03:38:04 but if you solve for the zeros of the accel equation, that gives you the points with the max and min velocity 03:38:31 solve for the zeros of velocity, gives you max and min positio 03:38:33 n 03:38:43 solve for the zeros of jerk, and get min and max accel 03:38:58 all closed form 03:39:26 ok, so you know where the min/max are, but how does that help with the rest of the path? 03:40:10 you can calc the min and max, if acceptable, go, if not, either scale down the overall velocity, or subdivide the path and repeat, scaling down the sections that exceed limits 03:40:45 I think I'm missing something 03:40:58 I thought u were solving hte kins for min/max 03:41:10 sounds like you're solving somethig path related 03:41:11 of course all of this assumes that you can represent the path in joint space as polynomials in t 03:41:31 assume a path in world space is a straight line 03:41:31 ahh, that's what I was missing 03:41:48 I wasn't assuming path representation in joint space 03:41:49 with non-triv kins, the path in joint space probably isn't 03:43:02 dammit pete, you've done it again... quarter to 11 on a work night, and I'm talking about future TP issues instead of coding something that is needed for the release we want to do in the next couple weeks. ;-) 03:43:18 ok, I gotta go pick my sister up anyhow 03:43:35 at least u got somthing to think about now ;-) 03:44:37 he 03:44:39 h 03:44:57 "with visions of matrices dancing thru their heads" 03:45:04 glaaaarggghhhh 03:45:12 (that was death by matrix) 03:45:44 how about quaterions? 03:45:47 "the castle Aaaahhhhhh - perhaps he was dictating" 03:46:11 What's a quaternion? 03:46:21 a way to represent rotations 03:46:27 fsck them 03:46:31 in some ways nicer than matrices 03:46:41 rotations in a plane? 03:46:45 (fewer nasty things like "gimbal lock") 03:46:51 or in 3-space? 03:47:02 rotations in 3-space (or higher, if your brain can handle that without exploding) 03:47:18 I have a klein bottle, and my brain hasn't exploded yet ;) 03:47:56 I used a mix of matrices and quaternions back in the day when I was playing with 3d graphics 03:48:30 I could read my "Computer Graphics" book (from way back when I took the class), but I often get bogged down in the math 03:48:44 there's a lot of it, and though I like math, I don't always like slogging through it 03:48:48 it is definitely boggy 03:49:09 (I took the Putnam exam in college, and I don't think I even knew what the questions were, let alone how to get the answers) 03:49:33 I worked out the various transformations (quat to mat, mat to quat, etc) and built a library way back in the mid 90's 03:49:51 I don't feel too bad about it - of the 4 students and two professors who took it at my university, I don't think there was a single correct answer 03:49:55 then I promptly forgot all the math and just used the lib 03:49:59 heh 03:50:00 wow 03:50:03 the engineer's way 03:51:02 at one time I was working on a modeling tool, that could model for instance a human body - you tell it all about the joints, and give it mesh points attached to the various bones 03:51:15 cool 03:51:22 then it would render the mesh (skin), and you could move the joints 03:52:01 the last time I did any 3D programming was using GL on the SGI Personal IRIS (for the graphics class) 03:52:28 it was a speedy 25MHz (or if you were lucky, you cuold use on eof the 33MHz ones) R3000 03:52:32 I did this stuff on the PC, using a Matrox graphics card with hardware z-buffering and such 03:52:50 it was totally non-portable 03:53:04 heh - from back when they actually released chip programming specs? 03:53:08 (the rendering that is - the math should be pretty portable) 03:53:35 I got a couple hundred pages from Matrox somehow, ftp site or something 03:53:48 yep - they used to be pretty ood that way 03:53:51 good 03:54:02 but I was doing this kind of stuff in DOS, just as windows was taking over 03:54:20 so it got pointless after a whil 03:54:20 while 03:54:39 yep 03:54:50 once Microshaft decided to stomp all ovber OpenGL 03:55:22 I remember the days when you had to instal Windows, then the DirectX package, just to get certain video and sound updates 03:55:30 I was aware of things like direct-draw and direct-3d, but couldn't get excited about them 03:55:34 some cards just didn't work right unless you used the DriectX driver 03:55:52 they were total crap, until the 8th or 9th revision 03:59:58 hey - I think this is the test I took: 04:00:01 http://www.unl.edu/amc/a-activities/a7-problems/putnam/-pdf/2001.pdf 04:01:23 ahhhh, my eyes 04:01:30 { 04:01:35 yeah - you should have smelled the smoke 04:01:42 sorry, that's tcl.. 04:01:47 ah 04:02:04 well - tcl gets the brain a bit smoky as well ;) 04:03:56 heh, you can tell that it isn't used for math much 04:04:06 tcl? 04:04:21 what - 1+2 = "12" ;) 04:04:25 "c = a + b" is written as "set c [expr$a + $b ] 04:04:32 heh 04:04:35 "c = a + b" is written as "set c [expr $a + $b ] 04:04:55 that's because ... they're strings 04:05:03 right, else it would be expr[whatever a is] + $b 04:05:16 jmk: what were the 4x4 matrices (the ones that let you do translation) in graphics called? 04:05:26 tranformation matrices? 04:05:52 there wasn't another name for the 4x4 vs 3x3? 04:06:03 I think 4x4 gives you perspective 04:06:06 the math types use 4x4, I used 3x4 when I was doing it, because all non-wierd transforms leave the last row all zeros 04:06:57 "weird" = perspective 04:07:27 non-weird = translation and rotation - I was doing 3d graphics, flight simulator stuff and/or solid object modeling 04:07:55 I used differnent math for the actual projection from 3D space to flat screen 04:08:11 cradek: I was test running some stuff with axis today and noticed a couple of things 04:08:22 the g-code display was 2 lines behind emc 04:08:37 and I couldn't find any control for the optional stop (M1) 04:09:29 can you reproduce that 2-lines-off thing? 04:09:46 it did the same thing everytime with the file I was running 04:09:58 it was really noticable when an M1 was hit 04:10:10 EMC would stop and the display would be 2 lines before the M1 04:10:46 I'm just trying it here and it seems to display the right line... 04:11:00 so it highlight the M1 when yours stops? 04:11:01 maybe something is odd baout M1 04:11:13 no, I didn't try an M1 04:11:23 I just ran a program and watched the cone 04:11:28 oh 04:12:25 well it shows the line before the M1 04:12:36 hmm, mine was 2 before every time 04:12:39 and then I can unpause 04:12:41 I wonder what's going on 04:12:54 yeah, S worked to continue 04:12:56 what did you mean you couldn't find the control? 04:13:18 there was nothing to control whether optional stop stopped or not 04:13:28 it's usually a switch on a real control 04:13:36 oh is that in the other guis? 04:13:42 I though there would be a radio button or something on the GUI 04:13:47 not sure 04:13:57 just noticed it cause I ran a prog with M1s 04:13:57 there would have to be an nml message to go with it 04:14:01 don't think I've seen that 04:14:05 it might be in the ini? 04:14:30 hmm, the interp handles it, I'll look at the details of what happens and send you an email 04:14:39 I suspect your program had a very quickly-executed line before the M1 04:14:49 let me check 04:14:57 since the gui polls for position and line, it probably just missed. 04:16:26 there was some coord setting, coolant, a Z move, then an X Y move before the M1 04:16:35 I'll email you the file 04:16:45 dcc it if you can 04:17:02 I'm on a doze boz 04:17:04 box 04:17:08 how about zip? 04:17:44 I mean transfer it with dcc 04:17:48 forget it, whatever is fine 04:17:54 ok 04:18:03 I don't see anything about optional stop in tkemc 04:18:49 may not be there, but it should be 04:19:29 I'll dig a bit and see what I can find 04:19:39 gotta go pick up my sister now 04:21:20 emc does not currently do optional stop - it always stops 04:21:26 but it's marked as FIXME 04:21:58 at least it's marked ;) 04:23:11 I wonder if that's a bug report or feature request... 04:23:40 feature request - it's not a misbehaving function, but something new (sort of, at least) 04:23:59 well, it's in the interp and canon API, but it doesn't "work" 04:24:06 i.e. it's not optional 04:24:07 true 04:24:23 though it's an optional stop - the user can decide, or the machine can decide 04:24:31 in this case, emc always decides to stop 04:24:51 (it's not incorrect, just not user-controllable) 04:25:07 you'd make a good politician 04:25:12 same to you 04:25:15 :) 04:25:19 haha 04:25:51 I swear too much to be a politician (plus I'm honest and stuff) 04:26:16 being honest gets in the way of a lot of jobs and money-making opportunities 04:26:29 then I'll be poor 04:26:39 same here 04:26:56 it's working well so far 04:27:00 yep ;) 04:27:03 actually I'm not poor, but neither am I rich 04:27:20 not totally poor either, but still have to think about purchases 04:27:22 and I think that's just fine 04:27:25 e 04:27:26 yep 04:27:42 the richest people have to think about purchases - just bigger ones 04:27:50 that probably never goes away 04:28:17 yeah - more than $100 for me, more than $100,000,000 for BillGatus 04:29:37 look on the bright side - we don't have to think about $100,000,000 purchases 04:29:52 but I *want* a 727-stretch 04:30:35 M1 is supposed to be optional stop, but currently EMC always stops. The interpreter and canon API have support for this, but the current emccanon always stops. 04:30:39