Back
[01:21:32] <Roguish> hey, anyone awake? got a problem with the 'apt-get update' from dsplabs site.
[01:23:41] <Roguish> 'failed to fetch........unable to find expected entry........(malformed release file?) '
[01:26:00] <Roguish> just updated breezy to dapper and am following the wiki instructions to fix things.
[01:28:05] <Roguish> edited the source.list file and the 'apt-get' command fails......
[01:41:40] <jtr> Roguish: you are taking out the dsplabs.ro and adding linuxcnc.org in the repository list?
[01:42:10] <Roguish> no.
[01:43:04] <Roguish> should i be?
[01:43:46] <Roguish> the wiki shows to add dsplabs to the list, so i did.
[01:44:25] <jtr> Roguish: I think so. see if
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Repository_Updating makes sense.
[01:47:10] <Roguish> i have been on the 'installing emc2' page. thanks. i'll take out the dsplabs and add the linuxcnc.org
[01:48:19] <Roguish> much better. guess the wiki is slightly out of sync.
[01:49:24] <jtr> I think that wiki page should be updated to say you might have either lines, but should update to yadda yadda.. I'll see if I can fix it.
[01:51:30] <jtr> I saw the instructions long ago, have to find them again.
[02:45:55] <cradek> dsplabs is no longer used - and jepler updated the wiki instructions
[03:02:35] <jtr> Saw that. Was working on the perfect wording for "if you see this, change it to this", and why.
[03:02:54] <cradek> ah ok, thank you
[15:03:39] <alex_joni> * alex_joni winks at jepler
[15:26:07] <steve_stallings> steve_stallings is now known as steves_logging
[16:00:28] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[22:33:19] <alex_joni> * alex_joni looks around
[22:33:30] <jmkasunich> * jmkasunich looks up and down
[22:34:03] <jmkasunich> alex, do you see any open GL experts in here?
[22:34:22] <alex_joni> * alex_joni looks dangerously in jeplers direction
[22:41:08] <jmkasunich> dang, he must be hiding
[22:41:41] <alex_joni> * alex_joni has something for jepler
[22:41:52] <jmkasunich> anyway, what do we want from this thing?
[22:41:55] <jepler> of course I'm hiding
[22:42:11] <jmkasunich> define some simple geometry (boxes, cylinders, cones)
[22:42:25] <jmkasunich> define some rules for articulating it
[22:42:43] <jmkasunich> "move this box and everything attached to it when this variable changes"
[22:42:52] <jmkasunich> and link those vars to hal pins
[22:43:23] <jmkasunich> for series kins (trivkins, puma, scara, and most other robots) the geometry is a tree of transforms
[22:43:33] <jmkasunich> for parallel kins it uglier
[22:45:16] <jmkasunich> * jmkasunich is tempted to ignore parallel kins for now
[22:46:32] <alex_joni> right
[22:53:25] <jmkasunich> * jmkasunich is googling
[22:57:29] <jmkasunich> keyword (for series kins) "matrix stack"
[23:18:30] <jmkasunich> I wonder if GLUT would be usefull
[23:20:41] <cradek> AXIS uses gluCylinder/gluDisk etc to draw stuff
[23:20:52] <cradek> you could easily add some stuff to draw a machine
[23:21:11] <cradek> but right now, you would have to hardcode into AXIS a lot of assumptions about the machine
[23:21:51] <jmkasunich> I'd rather have this be a window (that could perhaps be displayed by axis, like pyvcp windows) rather then make it part of axis
[23:22:50] <cradek> I'd prefer to see it draw over the program preview with the tool
[23:23:10] <cradek> afaic, how else do you see if it's working right?
[23:24:57] <jmkasunich> hadn't thought that far
[23:25:29] <jmkasunich> to be honest, this is a digression from a digression (at least)
[23:25:47] <cradek> :-)
[23:25:51] <cradek> we've all talked about it before
[23:26:15] <jmkasunich> we (awallin and I) started talking in #emc about pyvcp pin naming
[23:26:30] <jmkasunich> which digressed into hal newinst and hal pin naming
[23:26:33] <cradek> a simple line from elbow to elbow (I don't know the correct terminology) would be a fine representation for testing
[23:26:42] <jmkasunich> which somehow morphed into simulation of machines
[23:27:11] <jmkasunich> lines work for rotary joints, where the angle of the line is the "data"
[23:27:28] <jmkasunich> for slides (traditional machines) not so well
[23:27:33] <cradek> sure
[23:27:51] <jmkasunich> I was thinking rectangular prisms for table, saddle, ways, column, head, etc
[23:27:55] <cradek> for orthogonal machines there's not much to do except draw the tooltip in 3d space
[23:27:55] <jmkasunich> cylinder for spindle
[23:28:28] <jmkasunich> I want to be able to model things like a bport with both knee and quill controlled
[23:28:30] <cradek> that really wouldn't be very hard...
[23:28:49] <cradek> the problem is your draw rate will go down with all those triangles
[23:29:11] <jmkasunich> a rectangular prism is 6 faces, 12 triangles
[23:29:21] <jmkasunich> games render thousands of triangles at 10s of frames per second
[23:29:29] <jmkasunich> I want to render at most a couple hundred
[23:29:50] <cradek> zbuffers are not intuitive - the speed is proportional more to the number of pixels buffered (on-screen size) than the number of triangles
[23:30:22] <jmkasunich> "your draw rate will go down with all those triangles" is what you said ;-)
[23:30:23] <cradek> with software rendering one big triangle takes about as long as many small triangles
[23:30:32] <cradek> err, all those big triangles
[23:31:33] <jmkasunich> to be honest, never even thought about update rate, I assumed it would be a piece of cake
[23:32:25] <jmkasunich> the last time I did this kind of stuff was mid 90's, I was doing transformation matrix stacks, projection, z-buffering, and the like, almost entirely in software, and getting reasonable results with hundreds of smooth shaded triangles on pentium 1
[23:33:37] <jmkasunich> open gl may make some performance tradeoffs compared to my handcrafted code, but not enough to offset 10 years of hardware advances
[23:33:56] <jmkasunich> don't people use open gl for games?
[23:34:05] <cradek> not software rendered, no
[23:34:16] <jmkasunich> oh, its all about the graphics card....
[23:34:20] <cradek> yeah
[23:34:47] <cradek> modern cards make the fill rate negligible, and the whole scene gets loaded into the card once
[23:34:54] <cradek> we don't have any of that with our realtime machines :-/
[23:35:01] <jmkasunich> thats why my glxgears is so jerky - its software rendered
[23:35:13] <cradek> I'm not saying you shouldn't experiment, just remember from the start to keep it very simple
[23:35:14] <alex_joni> http://virtual.cvut.cz/odl/partners/fuh/course_main/node17.html
[23:36:05] <cradek> alex_joni: cool
[23:36:18] <cradek> is that puma?
[23:36:38] <jmkasunich> I think so
[23:36:41] <alex_joni> cradek: yes
[23:36:50] <alex_joni> maybe with that at hand, I might understand the kins
[23:36:57] <alex_joni> this seems interesting.. "Visualization of the robot arm is based on Geomview, a public domain 3D visualization software."
[23:37:11] <alex_joni> http://www.geom.uiuc.edu/software/geomview/
[23:37:29] <jmkasunich> puma is rotary waist, up/down rotary shoulder, up/down rotary elbow, rotary forearm, and up/down (if forearm not rotated) wrist
[23:37:44] <alex_joni> jmkasunich: sounds like something we can hack together with emc2/HAL
[23:37:58] <alex_joni> "Geomview is an interactive program written by the staff of the Geometry Center for viewing and manipulating geometric objects. It can be used as a standalone viewer for static objects or as a display engine for other programs which produce dynamically changing geometry."
[23:38:08] <jmkasunich> yes, that seems like exactly what we want
[23:38:27] <jmkasunich> "other programs which produce changing geometry" = emc/hal
[23:39:16] <alex_joni> right
[23:39:21] <alex_joni> * alex_joni starts looking at code
[23:39:54] <jmkasunich> I'd like to do that, but I really need to cut some metal, drill holes, etc
[23:40:05] <jmkasunich> I want to spin a stepper this weekend
[23:40:22] <jmkasunich> (it will be setting on the bench, not attached to the machine, but thats a start
[23:41:08] <alex_joni> ok, I'll let you know if I have something
[23:43:05] <jmkasunich> geomview bookmarked - that really seems like a good place to start
[23:45:11] <alex_joni> http://www.geom.uiuc.edu/software/geomview/geomview_8.html#SEC54
[23:46:53] <alex_joni> heh.. there is a geomview package for dapper ÖD
[23:46:53] <alex_joni> :D
[23:47:40] <cradek> hmm in puma it gets most of the way to the origin (g28) but then everything turns to NAN
[23:47:59] <cradek> it's pretty glacial at 3deg/second on all joints...
[23:50:37] <alex_joni> and it even works
[23:50:55] <alex_joni> glacial?
[23:51:03] <jmkasunich> slow
[23:51:07] <alex_joni> cradek: there is something borken about the puma kins.
[23:51:08] <cradek> moves like a glacier
[23:51:31] <alex_joni> if you move a joint.. you'll see in the preview it makes a full circle
[23:51:40] <alex_joni> and the joint will move from 0 to ~6.3
[23:51:52] <alex_joni> so I think that's 2*pi, instead of 360 degrees
[23:51:55] <cradek> ah
[23:52:28] <cradek> s1 = sin(joint[0]);
[23:52:36] <cradek> it's obviously assuming joints are in radians
[23:54:10] <jmkasunich> unit fun again
[23:54:21] <cradek> rpy.r = world->a*PM_PI/180.0;
[23:54:34] <alex_joni> cradek: so joint[0]*180/PM_PI ?
[23:54:44] <cradek> in inverse, it assumes world is in degs
[23:54:59] <cradek> alex_joni: yeah try that
[23:55:00] <alex_joni> I'm ok with degrees all over
[23:55:11] <alex_joni> jmkasunich: geomview sure seems nice at the first glance
[23:55:35] <jmkasunich> degrees all over? yuck
[23:56:03] <jmkasunich> internal stuff should be in radians, otherwise the math gets very messy
[23:56:22] <cradek> I think alex means the user will see degrees for the joints
[23:56:25] <jmkasunich> convert from deg to radians at input, and back to degrees at output, use radians for the calcs
[23:56:29] <cradek> right
[23:57:49] <alex_joni> yes