#emc-devel | Logs for 2007-02-05

[00:06:14] <alex_joni> config coming up
[00:09:34] <jmkasunich> http://pastebin.ca/340749
[00:09:41] <jmkasunich> I believe this matches the code
[00:09:51] <jmkasunich> I see no need for D4 at all
[00:10:08] <jmkasunich> actually, it doesn't perfectly match the code, but I'm gonna change the code
[00:10:27] <jmkasunich> D2 isn't in the code, but is usefull for generating a model
[00:10:56] <jmkasunich> there are a couple other values not used for the kins but usefull for the model
[00:11:02] <jmkasunich> like how much travel on the vertical slide
[00:11:11] <jmkasunich> oops, I forgot joint 3
[00:11:24] <jmkasunich> (which isn't used for machining, since its parallel to the tool
[00:12:22] <alex_joni> what's joint 3 ?
[00:12:41] <jmkasunich> the end effector can turn on its axis
[00:12:50] <jmkasunich> used for pic-n-place robots to orient the part
[00:13:00] <jmkasunich> not used for machineing, no need to orient a round endmill
[00:13:07] <alex_joni> ahh.. right
[00:13:11] <jmkasunich> or a plasma torch
[00:13:24] <alex_joni> unless it's tilted 45° for beveling :P
[00:13:31] <jmkasunich> good point
[00:14:27] <jmkasunich> heh, its implemented wrong in the kins
[00:14:35] <alex_joni> oh-oh
[00:14:43] <jmkasunich> the c angle isn't just joint3, its the sum of all three joints
[00:14:51] <jmkasunich> not that it matters for us
[00:14:54] <jmkasunich> I'll fix
[00:15:06] <alex_joni> hmm..
[00:15:19] <alex_joni> this is not good.. I see that it uses world->c
[00:15:36] <jmkasunich> whats wrong with that?
[00:15:53] <alex_joni> hmm.. think I'm not sure :D
[00:16:09] <alex_joni> if we have that on trivkins, it doesn't work without enabling a & b aswell
[00:16:14] <alex_joni> but here it might work..
[00:22:08] <jmkasunich> I really don't like the use of A for distances
[00:22:14] <jmkasunich> A should be angle
[00:22:58] <jmkasunich> I'm changing them, unless you say not to
[01:07:36] <alex_joni> jmkasunich: I think I'll head to bed..
[01:07:41] <alex_joni> getting late here :()
[01:07:54] <jmkasunich> ok
[01:08:05] <jmkasunich> just about to commit the rewritten kins, and start on the model
[01:08:08] <alex_joni> I'll read back in the morning..
[01:08:09] <jmkasunich> it will be a few hours
[01:08:16] <jmkasunich> (till the model is done)
[01:08:20] <alex_joni> I'll wait that long (on the rewritten kins)
[01:08:24] <jmkasunich> ok
[01:16:37] <alex_joni> the scara kins seem to be working OK
[01:17:08] <jmkasunich> cool
[01:17:22] <jmkasunich> I thought you were going to bed ;-)
[01:17:31] <jmkasunich> how do you do sqrt() in python?
[01:19:42] <cradek> math.sqrt
[01:19:55] <alex_joni> import math?
[01:19:57] <cradek> might have to "import math"
[01:20:07] <jmkasunich> yep, thanks
[01:20:19] <alex_joni> from math import sqrt print sqrt( 49 )
[01:29:56] <alex_joni> good night all
[01:30:02] <alex_joni> * alex_joni heads to bed
[01:30:04] <jmkasunich> night alex
[01:37:33] <jmkasunich> jepler: you around?
[01:37:49] <jmkasunich> had some questions about scaling the opengl stuff
[01:38:08] <jepler> jmkasunich: I'm here for a moment at least
[01:38:27] <jmkasunich> for the puma, I treated length units (rather arbitrarily) as meters, and chose numbers that kind of gave a smallish to typical machine
[01:38:35] <jmkasunich> scarakins has defaults that are in mm
[01:38:47] <jmkasunich> so the initial image will be huge
[01:39:12] <jmkasunich> (coords are hundreds of units, instead of fractions to single digit integers)
[01:39:39] <jepler> as you may have discovered already, "distance" gives the initial distance from the camera to the origin
[01:39:42] <jmkasunich> oh, is that what the distance parameter is for model?
[01:39:43] <jmkasunich> ;-)
[01:39:52] <jmkasunich> so I can pick that based on the model dimensions
[01:40:02] <jepler> there is also "self.near" and "self.far"
[01:40:19] <jepler> probably you need to arrange to increase "far" as well -- it defaults to 1000
[01:40:19] <jmkasunich> do I need to set those?
[01:40:56] <jmkasunich> where would I do that?
[01:41:10] <jmkasunich> seems like maybe the call to main() should accept those params?
[01:41:36] <jepler> yes, a new param to main, and then main assigns it just like distance
[01:41:53] <jmkasunich> I might go for convenience and have on arg called size
[01:42:02] <jepler> def main(model, distance=10, far=1000): ...
[01:42:15] <jepler> ... t.far = far ...
[01:42:21] <jmkasunich> distance = 5x size, near = 2.5x, far =7.5x
[01:42:58] <jepler> actually yo uwant "near" to be a small number
[01:43:01] <jmkasunich> near and far are measured from the camera position?
[01:43:09] <jepler> yes
[01:43:19] <jepler> nothing further than "near" or farther than "far" are visible
[01:43:46] <jmkasunich> so if size is 2 meters, then the camera will be 10 meters away, and everything between 5 and 15 meters from the camera will be visible
[01:44:10] <jmkasunich> which would certiainly include all of a model whose "size" is about 2 meters
[01:44:17] <jepler> yes -- but if you "zoom in" to be just 1 meter from some part of the machine, then you won't actually see it
[01:44:25] <jepler> it'll be clipped because it's now closer to the camera than a "near" of 5 meters
[01:44:33] <jmkasunich> hmm - does the zoom mouse function move the camera, or just tighten the field of view?
[01:44:37] <jmkasunich> I guess you answered that
[01:44:43] <jepler> it moves the camera in space
[01:45:01] <jmkasunich> ok, then near needs to be "small"
[01:45:04] <jmkasunich> is zero OK?
[01:45:13] <jepler> I'd suggest leaving 'near' unchanged no matter what, until that causes trouble
[01:45:32] <jmkasunich> do you know what the default is?
[01:45:44] <jepler> 0.1
[01:45:53] <jmkasunich> ok
[01:45:55] <jepler> zero is not permitted
[01:46:09] <jmkasunich> I'll leave it alone
[01:46:19] <jmkasunich> I saw that you added sphere to your lib
[01:46:43] <jepler> yes I went ahead and did that
[01:46:52] <jmkasunich> I'm gonna add a Sphere primitive then
[01:47:26] <jmkasunich> I'm a little confused - when I call gluSphere, am I calling the lib, or am I calling you and then you call the lib?
[01:47:55] <jepler> this page explains why near can't be zero: http://pyopengl.sourceforge.net/documentation/manual/gluPerspective.3G.html
[01:48:37] <jmkasunich> ah
[01:48:43] <jepler> jmkasunich: Python can't directly call general functions written in C or C++. for each opengl function that python uses, there's a wrapper function defined
[01:48:53] <jmkasunich> for things that are in mm, 0.1 is not going to be a good value, much lost precision
[01:49:02] <jmkasunich> ok, you added the wrapper
[01:49:04] <jmkasunich> got it
[01:49:45] <jmkasunich> if I run into trouble, I might make near = 0.01 * size
[01:50:15] <jepler> probably you want more like 1/1000 or 1/10000 as big
[01:50:41] <jepler> the defaults are 1000 : .1 and that has worked OK in axis so far
[01:51:24] <jepler> I do like the idea of getting far and distance from a "size", and I'm warming to the idea of getting "near" from it too
[01:51:39] <jmkasunich> is near also the granularity of the Z buffer? I would think that the buffer granularity = ( far - near ) / 2^number-of-bits
[01:52:41] <jepler> I don't think they're distributed linearly for perspective projections
[01:52:41] <jmkasunich> actually I think I read something in the GL docs about the Z buffer being logarithmic - better resolution close up and worse far away, so there is probably no single granularity number
[01:52:47] <jepler> bbl
[01:52:49] <jmkasunich> ok
[01:52:56] <jmkasunich> thanks
[02:51:32] <jepler> geez you'd think I would have tested gluSphere before committing it
[02:51:50] <jepler> but it's actually all a part of my plan -- now jmkasunich is a certified python hacker, and can no longer say he doesn't understand it
[02:52:01] <jepler> he even writes extension modules
[02:52:32] <jmkasunich> heh
[02:52:42] <jmkasunich> edits, not writes
[02:52:51] <jmkasunich> I've yet to start with a blank page
[02:53:29] <jmkasunich> I was having Z resolution issues (things would become transparent as I zoomed)
[02:53:35] <jmkasunich> so I did the size thing for distance, near, and far
[02:53:45] <jmkasunich> seems to work
[02:54:57] <jmkasunich> got two of 5 major chunks of the scara done
[02:55:08] <jmkasunich> tool, and the vertical arm, joints 2 and 3
[02:55:16] <jepler> the model you mean?
[02:55:20] <jmkasunich> yeah
[02:55:33] <jmkasunich> I'm making it parametric
[02:55:55] <jmkasunich> you enter the machine dims (length of arms, etc) and it calcs the rest
[02:56:01] <jepler> neat
[02:56:10] <jepler> "enter" via the commandline, ultimately?
[02:56:18] <jmkasunich> "enter" means "edit into the py file" at the momnet
[02:56:18] <jepler> or some other way?
[02:56:27] <jmkasunich> I don't know how to do IO in py
[02:57:00] <jepler> f = open("filename")
[02:57:10] <jepler> l = f.readline() # get one line with trailing \n
[02:57:19] <jmkasunich> s/I don't know how/don't want to spend the time/
[02:57:22] <jepler> m = f.readlines() # get whole file as list of lines
[02:57:24] <jepler> ok ok
[02:57:33] <jmkasunich> here's what I've got now:
[02:57:34] <jmkasunich> http://pastebin.ca/340877
[02:57:39] <jmkasunich> (for the parameters)
[02:58:30] <jmkasunich> ideally, both the kins file and the model would get the data from the same place in the config
[03:00:53] <jepler> loadusr scaragui --d1=[GEOMETRY]d1 --d2=[GEOMETRY]d2 ...
[03:01:06] <jmkasunich> yeah
[03:01:08] <jepler> and use the same items when doing loadrt scarakins or setp scarakins.
[03:01:24] <jepler> I'll happily write that if you want to leave it for me
[03:01:32] <jmkasunich> I was just about to ask...
[03:01:32] <jmkasunich> thanks
[03:53:10] <jepler> jmkasunich: http://pastebin.ca/340909
[03:53:30] <jepler> not useful, except to show the XML format for specifying the machine
[03:54:16] <jmkasunich> I think I like writing it in python better
[03:54:29] <jmkasunich> cradek made me realize something yesterday
[03:54:36] <jepler> what's that?
[03:54:56] <jmkasunich> because I always used compiled langages, the idea of letting a user write something in the actual programming language never occurred to me
[03:55:43] <jmkasunich> py with our primitives and transforms isn't trivial to use, but its not much more difficult than something like POVray's language
[03:55:53] <jmkasunich> which I was seriously considering as a format
[03:56:03] <jepler> yeyah
[03:56:47] <jmkasunich> if I had taken that path, I'd be about 10% done with a parser now
[03:57:31] <cradek> it's easy to get used to 'rapid prototyping'
[03:57:31] <jepler> I don't have the perspective to understand whether, for a completely green user, there's a big difference in difficulty between XML, a format with curly braces (pov or halvcp), or a python program
[03:57:59] <jmkasunich> actually, I wouldn't even be that far along, because the "cool, it works" factor that got me going last night wouldn't be there
[03:58:45] <jmkasunich> for a completely green, python's stack trace error messages are not very informative
[03:59:21] <jmkasunich> a domain specific language can print better messages than a generic one, because the context is more controlled
[03:59:43] <jepler> yeah -- if you write it
[03:59:48] <jmkasunich> right
[03:59:56] <jmkasunich> the tradeoff is the time to write it
[03:59:57] <jepler> "error somewhere near line 10"
[04:00:06] <jepler> "maybe"
[04:00:59] <jepler> jmkasunich: I think I said it before, but I'm thrilled that you took my little prototype and turned it into a much more interesting and maybe even useful program
[04:01:23] <jmkasunich> I think your words were "fucking cool" and they made me grin
[04:01:26] <jmkasunich> thanks
[04:01:45] <jmkasunich> goodnight
[04:02:35] <jmkasunich> and thanks for the "prototype", thats what got me over the learning curve + inertia hump
[04:03:15] <jmkasunich> damn : after if - gets me every time
[04:24:40] <cradek> what is it that causes people to ask for help without posting the error message!?
[05:16:22] <jmkasunich> they want us to practice our mind reading skillz
[06:42:23] <alex_joni> morning
[06:45:55] <alex_joni> jmkasunich: still around?
[13:00:41] <alex_joni> jepler: scara kins sure is nice.. it's almost OK
[13:44:27] <jepler> $ ./scripts/emc configs/scara/scara.ini
[13:44:31] <jepler> scarakins: dlsym: /usr/src/emc2/bin/rtapi_app: undefined symbol: rtapi_app_main
[13:44:37] <jepler> darn, it doesn't work for me
[13:45:06] <jepler> aha think I found the problem
[13:47:06] <jepler> but when I switch to coord mode my arm falls off
[13:47:51] <jepler> that is, if I "home all" first
[13:48:05] <jepler> start, hit "home all", hit "$" to go to coord mode -> x, y become nan
[14:43:20] <jepler> hahah the scara is milling the axis splash screen
[14:44:18] <jepler> cool
[15:08:38] <alex_joni> nice :D
[16:12:00] <skunkworks> I get a kick out of mario.
[16:16:28] <alex_joni> whatever makes you happy :P
[19:22:01] <jepler> anybody thought about how to define the work volume for a nontrivial machine?
[19:53:38] <SWPadnos> I just started thinking about that, and it's nontrivial^2, I think
[20:05:56] <alex_joni> jepler: I don't think you can
[20:06:05] <alex_joni> only generate it from joint limits
[20:10:41] <alex_joni> jepler: hmm.. somthing is still wrong about scara kins..
[20:11:08] <alex_joni> if I jog joint 3, and switch to carthesian, I see the machine pos change
[20:22:27] <jepler> hum
[20:26:28] <alex_joni> and touch-off doesn't seem to work (maybe I don't know how to use it..)
[20:27:58] <alex_joni> I think offsets are useless in TELEOP mode, because the carthesian position gets overwritten with data from teh joints
[20:28:18] <jepler> touch off should probably be greyed unless in cartesian mode
[20:28:17] <cradek> I used touch-off with scara
[20:28:30] <jepler> otherwise I can't imagine why it wouldn't work -- it just sends an MDI command
[20:28:31] <cradek> oh, I was in cartesian
[20:29:32] <jepler> .. and it is greyed out
[20:29:46] <alex_joni> it works in Manual control cartesian
[20:29:54] <alex_joni> (I was beeing stupid..)
[20:30:43] <alex_joni> this is fun...
[20:34:28] <alex_joni> * alex_joni watches scara milling 3d_chips :)
[20:36:41] <jepler> I've milled the axis splash screen a few times
[20:39:41] <alex_joni> it's nice ..
[20:39:55] <alex_joni> I increased accels a bit.. it was way too sluggish on teleop
[20:40:17] <alex_joni> "a bit" = about 10 times
[20:41:06] <alex_joni> I must say I'm really impressed by all this work you've done
[20:41:54] <jepler> me? I've barely done a thing
[20:42:11] <alex_joni> "you" = you, jmk, ..
[20:42:45] <alex_joni> the solution seems so simple now.. but it makes quite a difference ..
[20:42:48] <jepler> ah, the plural
[20:43:39] <jepler> I have a much better idea about nontrivial machines now
[20:43:49] <jepler> but that allows me to worry that we can't fix all the problems in a reasonable amount of time
[20:44:15] <jepler> e.g., for 2.2 or fest
[20:44:41] <alex_joni> no-one says 2.2 must have kins working for all types of robots
[20:46:06] <jepler> but other stuff like work envelope, allowable acceleration, etc
[20:46:11] <jepler> maybe it's not as bad as I think right now
[20:46:18] <alex_joni> yeah..
[20:46:41] <alex_joni> * alex_joni still wonders wth jacobianForward & jacobianInverse do..
[20:47:13] <cradek> I think those are the first derivative
[20:47:38] <alex_joni> I think so too.. so they should act like speed transformations?
[20:47:40] <jepler> they're unused except in the testing code
[21:42:58] <jepler> seems the problem with building a scara is getting the power to the 2nd and 3rd joints
[21:43:14] <jepler> I guess it's simpler if you don't let the joints rotate indefinitely
[21:43:38] <jepler> if you want to go 360 you need some complicated contacts in the arm
[21:45:09] <alex_joni> or wires
[21:45:41] <alex_joni> thinking about building one?
[21:45:45] <jepler> not too seriously
[21:46:25] <alex_joni> ok :)
[21:46:50] <jepler> it seems like if you rotate to +10*360 degrees on the first joint, the wire will get all twisted around
[21:49:11] <SWPadnos> you need a slipring system if you want to allow "infinite" rotation
[21:53:57] <jepler> yeah that's it
[21:57:15] <jepler> I wonder how effective "microstepping" is without current feedback -- just varying the duty cycle blindly
[21:59:21] <SWPadnos> I suspect that there has to be some feedback
[21:59:57] <SWPadnos> any chopper drive already has feedback - you only need to make the OC threshold variable to do microstepping
[22:04:20] <jepler> duh
[22:05:08] <jepler> I missed that the H-bridge chip on the 7i31/7i32 had current sense built in
[22:05:17] <jepler> I thought it was a dumb bridge like l298 or whatever skunkworks used
[22:05:44] <SWPadnos> IRf2111?
[22:05:54] <jepler> could be
[22:06:21] <SWPadnos> woohoo - a 2k resistor fixes monitor detection on my high res flat panel!
[22:06:56] <SWPadnos> hmmm - partly at least
[22:07:00] <jepler> except that it's only one bridge per package, the Allegro A3959 looks like a nice chip compared to L298.
[22:07:08] <jepler> uh oh -- computer trouble?
[22:07:47] <SWPadnos> the 9MP panels tend to be finicky, especially with certain video cards
[22:08:16] <SWPadnos> apparently, the Quadro FX 3500 is one of the bad ones, even though they mention that you can run multiple 9MP panels from one card
[22:11:15] <SWPadnos> wow - that's so funny. X wouldn't start, so I assumed a monitor detection problem. In fact, I had forgotten to connect the 6-piun PCIe power connector, so the server refused to start
[22:15:28] <jepler> ooh time to drive home
[22:16:28] <SWPadnos> heh - see you later
[22:34:01] <Nicolas35LA> Hello, If one uses hardware pulse generation (similar to the Pico systems board), how large a base period can be used. Can it be as large as the servo period, around 1ms?
[22:34:45] <Nicolas35LA> sorry, wrong window