Back
[00:10:59] <alex_joni> cradek: not quite working :(
[00:13:41] <cradek> I didn't think it would be that easy, did you?
[00:14:23] <alex_joni> I was hoping
[00:15:47] <alex_joni> jmkasunich: look at this:
http://www.euron.org/miscdocs/docs/euron2/year2/dr-2-2-dataset.pdf
[00:15:52] <alex_joni> page #61
[00:19:28] <alex_joni> unfortunately
http://www.mpml.org doesn't work for me
[00:27:13] <alex_joni> cradek: any idea where: undefined symbol: __vt_9bad_alloc <- comes from?
[00:41:02] <jepler> $ c++filt __vt_9bad_alloc
[00:41:04] <jepler> bad_alloc virtual table
[00:41:07] <jepler> it's some c++ thing
[00:42:33] <jepler> if you're linking it, make sure you're using g++ as the linker, not gcc
[00:42:41] <alex_joni> ./robview_linux: symbol lookup error: ./robview_linux: undefined symbol: __vt_9bad_alloc
[00:42:49] <alex_joni> jepler: I only have the executable..
[00:42:55] <jepler> if it's a dynamic linker error, then it was compiled for a different system
[00:42:56] <alex_joni> might be a wrong libg++ version?
[00:42:59] <jepler> get the source and rebuild it yourself
[00:43:06] <alex_joni> no source available
[00:43:13] <alex_joni> at least none that I could find :(
[00:43:54] <jepler> oh you should use some different application with source
[00:44:13] <alex_joni> http://www-sop.inria.fr/chir/personnel/adhami/XMLSpecs/
[00:44:17] <alex_joni> I was looking at that
[00:44:27] <alex_joni> jepler: atm I am just looking around what exists/works
[00:44:37] <jepler> just being a jerk
[00:44:41] <jepler> I am, I mean
[00:44:48] <alex_joni> I understand.. (I feel the same way)
[00:45:03] <alex_joni> but this looks similar ot what jmk has intended
[00:45:11] <alex_joni> an XML description of the robot (including links)
[00:45:27] <alex_joni> unfortunately the only viewer I found so far is not OSS
[00:45:56] <alex_joni> I was able to run the cygwin version though
[00:52:44] <jepler> jmkasunich: you'll be dismayed to learn that opengl's glRotate* takes degrees, then
[01:10:57] <jmkasunich> alex_joni: interesting paper
[01:11:24] <jmkasunich> jepler: I'll file that under "take input in degrees" ;-)
[01:11:38] <alex_joni> jmkasunich: I have that xml from the paper
[01:11:52] <alex_joni> and I could load it in a doze viewer (no source)
[01:12:02] <alex_joni> looks good, not really usefull
[01:12:03] <alex_joni> :)
[01:13:24] <jmkasunich> the dr-2-2-dataset paper? I didn't realize that one was closed too
[01:14:58] <jmkasunich> the format might be handy in any case
[01:18:46] <alex_joni> yeah, thought so too..
[01:18:58] <alex_joni> but I don't want to start implementing that
[01:19:06] <jmkasunich> heh
[01:19:27] <jmkasunich> its a shame POV-Ray isn't fast
[01:20:29] <jmkasunich> it wouldn't be hard to generate a povray source file that uses substitution of hal pin values to pose the machine
[01:24:39] <alex_joni> I guess the same is true for geomview
[01:30:15] <jmkasunich> don't know enough about geomview yet
[01:30:45] <jmkasunich> I know POVray's scene description language is complete
[01:30:57] <alex_joni> same here.. (with geomview)
[01:31:04] <alex_joni> but I haven't studied it in full
[01:31:13] <jmkasunich> the main pov file could easily include a generated file that defines constants based on hal pins
[01:31:23] <alex_joni> we need a program that prints something like this:
[01:31:24] <alex_joni> http://www.geom.uiuc.edu/software/geomview/geomview_8.html#SEC54
[01:31:37] <jmkasunich> then the scene file would use those constants in expressions like "rotate <0, shoulder, 0>"
[01:36:54] <alex_joni> yay.. figured out what the home position for the puma is :)
[01:37:12] <alex_joni> jmkasunich: exactly as in that pdf on page #61
[01:57:50] <alex_joni> I'm off to bed.. good night all
[01:58:26] <cradek> night alex
[01:59:38] <jmkasunich> goodnight
[02:13:21] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/army.py http://emergent.unpy.net/index.cgi-files/sandbox/army.hal
[02:13:29] <jepler> . emc-environment ; halrun -f army.hal
[02:17:06] <jepler> angles from HAL displayed in opengl with a "robot" made out of some capped cylinders
[02:17:30] <jmkasunich> army?
[02:17:39] <jmkasunich> oh... arm-y
[02:17:39] <jepler> the robot is defined by a tree structure that could be converted from xml
[02:17:40] <jepler> arm-y
[02:18:00] <jepler> middle mouse button to rotate -- it starts looking down from above
[02:18:43] <jmkasunich> pushmatrix - that is the gl matrix stack in action?
[02:18:45] <jepler> yes
[02:19:02] <jmkasunich> gonna try it out as soon as the build finishes
[02:19:15] <jepler> it makes a kind of snake-y looking thing
[02:20:29] <jmkasunich> does the capped in "capped cylinders" just mean they are logs instead of pipes?
[02:20:36] <jepler> yes
[02:20:58] <jepler> if I had somewhere to read the geometry from, there's no reason it couldn't be more sophisticated
[02:21:25] <jmkasunich> python + the right libs can do a lot in not much code
[02:21:44] <jepler> yep, that's one of the reasons I love it
[02:22:54] <jmkasunich> of course, its hard for the uninitiated to read too...
[02:23:04] <jepler> yeah
[02:23:31] <jmkasunich> Collection builds the model, and is recursive, right?
[02:23:37] <cradek> jepler: did you see
http://virtual.cvut.cz/odl/partners/fuh/course_main/node17.html
[02:23:58] <jepler> jmkasunich: yes. the model is a tree, and any node that may have children is a Collection
[02:24:18] <jmkasunich> allply the transform for this part, draw it, then do any children, and finally remove the transform as you work your way back up
[02:24:23] <jepler> Transformations are also Collections, because they transform their children
[02:24:58] <jepler> if you haven't been able to run it yet, here's a pic:
http://emergent.unpy.net/index.cgi-files/sandbox/army.png
[02:25:14] <jmkasunich> the cone is the base?
[02:25:19] <jepler> yes
[02:25:40] <jmkasunich> what is class O all about?
[02:26:20] <jepler> you have to subclass the opengl widget to make it draw what you want
[02:26:34] <jmkasunich> I see it refering to some rs274 stuff - its using libs or something that were originally done for axis?
[02:26:49] <jepler> that's something I developed for axis but it's useful for other stuff as well
[02:26:52] <jepler> gdepth uses it too
[02:27:17] <jmkasunich> waitaminnit - the entire open-gl window is a "widget"?
[02:27:30] <jepler> jmkasunich: yes
[02:27:39] <jepler> that's a tk term
[02:27:41] <jmkasunich> * jmkasunich ponders the implications of that
[02:28:56] <jmkasunich> ok, I sort of grasp most of the general classes
[02:29:07] <jmkasunich> but that wildly indented invocation of Collection hurts
[02:29:22] <jmkasunich> is that really one humongously indented function call?
[02:29:36] <jmkasunich> s/indented/nexted
[02:29:41] <jmkasunich> nested even
[02:29:57] <jepler> a constructor call, which is essentially the same thing
[02:30:13] <jepler> it specifies the structure of the arm, which is also nested
[02:30:33] <jmkasunich> how would you do that if the structure wasn't hard coded?
[02:31:03] <jepler> you would build it up piece by piece from something else, like an xml file
[02:31:34] <jmkasunich> so you can do it iteratively, you don't have to write that nested thing?
[02:31:43] <jepler> right
[02:32:04] <jmkasunich> what do [] mean
[02:32:12] <jmkasunich> something tells me its not an array index
[02:32:19] <jepler> [a, b, c] is a list: a possibly-heterogeneous container
[02:32:40] <jmkasunich> ok, so collection contains cappedcyl and one transform
[02:32:57] <jmkasunich> that transform contains another cyl and another transform
[02:33:00] <jmkasunich> etc
[02:33:15] <jepler> yep -- a very narrow tree of about 5 levels
[02:33:41] <jmkasunich> and the "c, 'c', 360, 1, 0, 0, 0, 0, 2)" parts are the remaining args passed to the transform
[02:33:49] <jmkasunich> transforms
[02:33:52] <jepler> yes
[02:34:24] <jepler> "c, 'c'" is the HAL component and pin name
[02:34:47] <jmkasunich> is there a syntax for "add this thing to the things already there" or do you have to put them all in [ ] at one time?
[02:35:24] <jepler> if you've got a Collection k, you could write this to add something to it: k.parts.append(something)
[02:36:11] <jmkasunich> ok, so a more general approach would make the collection (maybe even empty) then use append to add children to it as they are encountered in a file
[02:36:25] <jmkasunich> as the file nests, you'd append to the children too
[02:36:33] <jepler> yes that works too
[02:36:47] <jmkasunich> * jmkasunich is imagining a file syntax
[02:37:42] <jmkasunich> hmm, what is AngularTransformation used for?
[02:37:44] <jepler> nothing
[02:37:53] <jmkasunich> leftovers?
[02:38:01] <jepler> I wrote 4 transformations (angular and linear; hal and hardcoded) but only one is used
[02:38:51] <jepler> and I tacked on a hardcoded translation to AngularHalTransformation because otherwise I'd have even more levels of structure
[02:39:25] <jmkasunich> if a "piece" (a movable chunk of the model) consisted of several cylinders, you'd use the hardcoded transformations to place them relative to the piece's coordinate system, right?
[02:39:40] <jmkasunich> then use the hal transformationt to move the whole piece as a unit
[02:39:43] <jepler> right
[02:41:51] <jepler> here's another way to build up the same tree:
http://pastebin.ca/339464
[02:42:16] <jmkasunich> finally stopped talking long enough to run it - cool
[02:42:42] <jepler> well, a similar tree -- I changed the cylinder radii
[02:43:17] <jmkasunich> this is really cool
[02:43:49] <jmkasunich> I'm trying to think of the best way to specify the geometry in a file
[02:44:06] <jmkasunich> povray syntax keeps popping into my head
[02:44:15] <jmkasunich> but that would require a parser
[02:44:23] <jmkasunich> xml might be easier to implement
[02:44:55] <jmkasunich> but lets think about the povray style a bit
[02:45:50] <jmkasunich> cylinder { base, top, height , <
[02:45:53] <jmkasunich> oops
[02:46:00] <jmkasunich> I should write and then pastebin, not do it here
[02:46:20] <jepler> especially since my brain is fried and I don't want to think about file syntax at the moment :-P
[02:46:31] <jepler> just be careful you don't elect yourself to write the parser, and in a language you don't know
[02:47:57] <jepler> whee it is a bit hypnotizing to watch it
[02:50:37] <jmkasunich> yep
[02:51:00] <jmkasunich> actually, I'm thinking more of structure than syntax
[02:51:09] <jmkasunich> IOW, what needs specified, not the punctuation
[02:51:19] <jepler> yeah
[02:51:29] <jepler> odds are small that I captured exactly what was important
[02:51:36] <jmkasunich> change <foo> </foo> to define foo = { } and you haven't really changed anything
[02:52:11] <jmkasunich> the tree structure is important
[02:52:30] <jmkasunich> the ability to have several children is implied in the code but not used yet
[02:54:26] <jmkasunich> can objects be given names on the fly?
[02:55:00] <jmkasunich> IOW, would "define foo = capped-cylinder (some args)" then allow you to later on refer to the object you just created as "foo"
[02:55:24] <jmkasunich> or would that have to be explicitly coded (a list of objects, with code to store them, find them, etc)?
[02:56:11] <jepler> that's not hard to do
[02:56:37] <jepler> a 'dict' lets you look up an item by a key -- like a string to some geometry object, for intstance
[02:56:38] <jmkasunich> since the tree can get deep (and moderately broad) that would be beneficial
[02:57:26] <jmkasunich> #define "end_effector" = several primitives with some static transforms to position them
[02:57:58] <jmkasunich> then #define "wrist" = several more primitives with static transforms, plus "end_effector" with a hal transform
[02:58:25] <jmkasunich> then #define "arm" = more of the same, with "wrist"
[02:59:12] <jmkasunich> oh, I just realized that your cylinder isnt a cylinder, its a cone
[02:59:22] <jepler> like the method at
http://pastebin.ca/339464 (same one I pasted earlier) instead of the deeply nested experession in the original .py
[02:59:37] <jepler> it's not *my* fault that the glu library calls the function gluCylinder
[02:59:43] <jmkasunich> heh
[02:59:48] <jepler> but yes it has a possibly-different radius at either end
[02:59:49] <jmkasunich> I'm not complaining
[03:01:22] <jmkasunich> the example ad 339464 is sort of what I was thinking of, but still hardcoded
[03:01:27] <jmkasunich> and it starts at the "base" and works out
[03:01:47] <jmkasunich> no it doesn't, never mind
[03:02:22] <jmkasunich> gotta start at the end and work back, and you are doing exactly that
[03:03:19] <jepler> which is what you were saying, I think
[03:03:33] <jmkasunich> yeah, I just mis-read it
[03:05:27] <jmkasunich> glu primitives are always at the origin? and you translate them as needed?
[03:05:50] <jepler> yes
[03:05:55] <jepler> and their orientation is fixed to
[03:05:56] <jepler> too
[03:06:02] <jmkasunich> and they are never solid?
[03:06:17] <jepler> cylinders aren't
[03:06:26] <jepler> there is a sphere and a torus primitive too
[03:06:35] <jepler> I think you can also make just one call to get the teapot
[03:06:36] <jmkasunich> is disk infinitely thin?
[03:07:03] <jepler> yes
[03:07:08] <jepler> and one sided
[03:07:18] <jmkasunich> invisible from the other side?
[03:07:20] <jepler> right
[03:07:28] <jmkasunich> I guess that means backface culling code is built in
[03:07:40] <jmkasunich> are cylinders invisible from the inside too?
[03:07:48] <jepler> yes I suppose so
[03:08:16] <jepler> actually backface culling is off by default, so I must have enabled it somewhere in my program
[03:08:17] <jmkasunich> imagine looking at an angle into an open can sitting on the counter - you might not see the back wall
[03:09:12] <jepler> hm I don't see where I enable it, but I could have sworn I saw some missing end-caps earlier
[03:09:42] <jmkasunich> hmm, both calls to gluDisk look the same
[03:09:48] <jepler> I see that too
[03:10:06] <jmkasunich> I'd have thought you'd need to tell it "this one is the top, its outside faces thattaway, that one is the bottom, its outside faces the other way"
[03:12:42] <jepler> must be that GL_CULL_FACE is disabled, then
[03:13:17] <jmkasunich> slices and rings are used for triangulating things?
[03:13:48] <jepler> yes
[03:15:11] <jmkasunich> hmm, looks like gluQuadrics are only suitable for round things
[03:15:16] <jmkasunich> how would we make boxes?
[03:16:15] <jepler> glBegin(GL_QUADS); glVertex3f (6 times); glEnd()
[03:16:27] <jepler> er, not 6 times, but 24 times
[03:16:33] <jepler> for 6 quads total
[03:18:11] <jmkasunich> box, cylinder and sphere should be an adaquate set of primitives
[03:18:51] <jmkasunich> boxes are not created at the origin are they - you can specify any coords you want
[03:19:41] <jepler> since you specify all the vertices explicitly, you can put it wherever you want without additional transformations
[03:19:45] <jmkasunich> right
[03:20:32] <jmkasunich> although unless you are pretty good at visulisation and geometry, its probably easier to define it with sides parallel to the axes, then rotate and or translate it into place
[03:21:13] <jmkasunich> something like box (xlo, xhi, ylo, yhi, zlo, zhi)
[03:22:09] <jmkasunich> * jmkasunich needs to brush off his 3d math
[03:22:25] <jmkasunich> a user friendly cone would be"
[03:22:41] <jmkasunich> cone { x1, y1, z1, radius1, x2, y2, z2, radius2 )
[03:23:11] <jmkasunich> that would need to be converted into a glucone with x1,y1,z1 = 0 and x2,y2 = 0, then rotated and/or translated
[03:23:32] <jmkasunich> I'm sure I could work out the math for that
[03:24:07] <jmkasunich> pretty sure anyway ;-)
[03:24:54] <jmkasunich> sphere { x, y, z, radius } is trivial
[03:25:25] <jepler> I think that gluSphere is not exposed to python yet in my 'minigl' module, but if not it's easy to add
[03:25:49] <jmkasunich> its probably the least useful primitive anyway
[03:26:00] <jmkasunich> are quads already there?
[03:26:48] <jepler> yes
[03:26:51] <jmkasunich> cool
[03:27:08] <jmkasunich> pov uses "union" and "intersection" for combining things
[03:27:14] <jepler> not easy in opengl
[03:27:24] <jmkasunich> we're not gonna go that far, but we do want to be able to group things
[03:27:26] <jepler> union is easy, but intersection and difference are not
[03:27:31] <jmkasunich> no need for those
[03:27:33] <jepler> a Collection is similar to a Union
[03:27:53] <jmkasunich> Collection is not a python thing, thats something you just wrote, right?
[03:28:06] <jepler> yes
[03:28:44] <jepler> I mean that the effect is similar -- it will draw all the surfaces of the objects it contains, which will look like a union of those objects
[03:28:47] <jmkasunich> right
[03:29:23] <jmkasunich> in the army example, there is only one explicit call to collection
[03:29:33] <jmkasunich> with everything else nested inside it
[03:29:53] <jepler> AngularHalTransformation is a Collection
[03:30:08] <jmkasunich> oh
[03:30:24] <jmkasunich> "class AngularHalTransformation(Collection)"
[03:30:26] <jepler> class Derived(Base):
[03:30:28] <skunkworks> sorry - Goofing around with machine visualization?
[03:30:38] <jmkasunich> yes
[03:31:04] <skunkworks> wow.. better and better. you guys are great.
[03:31:12] <jmkasunich> and /me is getting a total newbies intro to object oriented programming
[03:31:27] <jepler> skunkworks:
http://emergent.unpy.net/index.cgi-files/sandbox/army.png
[03:32:16] <jepler> basically, for puma type robots
[03:32:26] <jmkasunich> "glTranslatef(x*v, y*v, z*v)" does this apply the hal varable to all three axes?
[03:32:30] <jmkasunich> sure looks like it
[03:33:02] <jepler> right -- you'd construct with (1,0,0) if you want to move along x by 1 for each unit in the hal variable
[03:33:35] <skunkworks> jepler: that is exactly what I was visualizing from your guys talk.
[03:33:52] <jmkasunich> oh, ok.... the (1,0,0) defines the axis of movement, and the hal var moves along the axis
[03:34:14] <skunkworks> * skunkworks goes back to lurking.
[03:34:27] <jmkasunich> ditto for rotate then - three constants (probably) define the axis of rotation, then the hal var rotatates around that axis
[03:34:32] <jmkasunich> (I think - rotations get tricky)
[03:35:19] <jmkasunich> ah, glRotate is clever
[03:35:27] <jmkasunich> pov rotations don't work that way
[03:35:54] <jmkasunich> rotate ( 1, 2, 3) would rotate by 1 radian around X, then 2 around Y, then three around Z
[03:36:04] <jmkasunich> you can get into gimbal lock and such doing that
[03:36:14] <jmkasunich> by the time you do the Z rotate, Z isn't where you thought it was
[03:36:44] <jmkasunich> so, more primitives -
[03:37:00] <jmkasunich> translate (amount,x,y,z)
[03:37:04] <jmkasunich> rotate(amount,x,y,z)
[03:37:25] <jmkasunich> with some syntax such that amount can be a constant or a hal pin
[03:37:32] <jmkasunich> screw that
[03:37:53] <jmkasunich> translatehal(pin,x,y,z) and rotatehal(pin,x,y,z) would be better
[03:37:59] <jmkasunich> the plain ones take constants only
[03:42:19] <jmkasunich> jepler: does the code in "collection" run repeately, or does it run once and build the model somewhere inside GL?
[03:42:46] <jepler> jmkasunich: it runs every time, because HAL values might have changed
[03:42:55] <jmkasunich> duh
[03:43:10] <jmkasunich> thats good though
[03:43:22] <jmkasunich> what it means is that any variable could be a hal reference
[03:43:36] <jmkasunich> well, I dunno what it means in python
[03:43:39] <jepler> if you have a complex geometry item (read from a file with 10,000 triangles) it might make sense to do something clever like vertex arrays or display lists with it, but not for the pushing/popping of transforms
[03:44:11] <jmkasunich> in any case, we're only gonna want to read the file once
[03:44:22] <jmkasunich> so we have to build our own in-memory represetation
[03:44:30] <jmkasunich> then we traverse that calling gl
[03:44:56] <jmkasunich> anyplace the in-memory representation has a number, it can be a constant or a hal reference
[03:45:25] <jmkasunich> I'm thinking of things like cylinders that stretch
[03:45:55] <jepler> you could do that with a function like this one:
http://pastebin.ca/339519
[03:46:10] <jepler> er
http://pastebin.ca/339520
[03:46:57] <jepler> goodnight
[03:47:08] <jmkasunich> goodnight
[03:59:33] <jmkasunich> cradek: you around?
[04:00:08] <cradek> yes
[04:00:29] <jmkasunich> did you see Jeff's army.py?
[04:00:40] <cradek> yes but I didn't try to run it
[04:01:10] <jmkasunich> thats ok, I just wanted to see if you were following the conversation at allk
[04:01:18] <jmkasunich> how hard is it to interface C to py?
[04:01:57] <cradek> the data passing and handling reference counts is a little tedious, but SMOP
[04:02:08] <jmkasunich> http://mrl.nyu.edu/~dzorin/cg05/handouts/pov-parser/index.html
[04:02:17] <jmkasunich> I found the above, which is quite interesting
[04:02:31] <jmkasunich> haven't determined exactly how/if its licensed yet
[04:02:56] <jmkasunich> but there is contact info for the author
[04:06:07] <cradek> this is going to sound negative, but in your place I'd hardcode the puma robot and wait until we rethink our file formats...
[04:06:19] <cradek> this is such a special purpose thing
[04:06:26] <jmkasunich> if I'm gonna hardcode anything, I won't do it at all
[04:07:04] <jmkasunich> you are exactly right that it is special purpose, so why does it care about the rest of our formats?
[04:07:28] <cradek> I thought the goal was to get puma (and maybe all nontrivkins) working, which requires a puma simulator - you must have another goal, which is fine
[04:09:18] <jmkasunich> I'm being generic again
[04:09:31] <jmkasunich> I want a tool that allows you to build a puma simulator
[04:09:35] <jmkasunich> or a scara simulator
[04:09:39] <cradek> I guess I think a python command sphere() is as good as a pov-format file sphere {} that has to be parsed
[04:09:42] <jmkasunich> or a bridgeport simulator
[04:10:11] <cradek> except the first is done, the second requires lots of additional code and work
[04:10:13] <jmkasunich> I don't want the guy building the model to have to deal with opengl
[04:10:30] <jmkasunich> maybe I'm being dense
[04:11:10] <jmkasunich> is there a way that the parts of army.py that implement the primitaves and transforms and such can be separated from the part that defines the actual geometry>?
[04:11:32] <cradek> I'm sure there is
[04:11:34] <jmkasunich> that is my goal, and I immediately thought of using some other file to define the geometry
[04:11:49] <cradek> you mean some other format?
[04:11:55] <jmkasunich> if that file is in python, that is probably fine, except if the syntax is completely obscure to non-python folks
[04:12:09] <cradek> well the pov format for translate is: translate <0.0996195, -0.371785, 0.544331>
[04:12:19] <jmkasunich> exactly
[04:12:28] <cradek> parsing that to change it into glTranslate( [the same] ) is silly
[04:12:57] <jmkasunich> I'm thinking like a compiled language programmer, sorry
[04:13:04] <cradek> it adds complexity (a lot of it) for no reason
[04:13:18] <cradek> ah, I understand
[04:13:25] <jmkasunich> I wouldn't think of letting somebody program "user configurable data" in C because they'd need to compile it
[04:13:46] <jmkasunich> if the python can do the equivalent of #include <their-stuff> and just execute it, then sure, that works
[04:14:20] <jmkasunich> otoh, if they have to write something like this:
[04:14:21] <jmkasunich> t.model = Collection([
[04:14:19] <jmkasunich> CappedCylinder(1, .5, 2),
[04:14:19] <jmkasunich> AngularHalTransformation(
[04:14:19] <jmkasunich> [
[04:14:19] <jmkasunich> CappedCylinder(1, 1, 2),
[04:14:21] <jmkasunich> AngularHalTransformation(
[04:14:23] <jmkasunich> [
[04:14:25] <jmkasunich> CappedCylinder(1, 1, 2),
[04:14:27] <jmkasunich> AngularHalTransformation(
[04:14:29] <jmkasunich> [
[04:14:31] <jmkasunich> CappedCylinder(1, 1, 2)
[04:14:35] <jmkasunich> ], c, 'c', 360, 1, 0, 0, 0, 0, 2)
[04:14:37] <jmkasunich> ], c, 'b', 360, 0, 1, 0, 0, 0, 2)
[04:14:37] <cradek> yeah yeah
[04:14:40] <jmkasunich> ], c, 'a', 360, 1, 0, 0, 0, 0, 2)
[04:14:42] <jmkasunich> ])
[04:14:44] <jmkasunich> thats not pretty at all
[04:15:04] <cradek> quadric{
[04:15:05] <cradek> <64, 1, 1>,
[04:15:05] <cradek> <0, 0, 0>,
[04:15:05] <cradek> <-128, 0.5, 0>,
[04:15:05] <cradek> 63.0625
[04:15:10] <jmkasunich> its not converting translate<1,2,3> to py that is the issue
[04:15:17] <jmkasunich> its the nesting and structure
[04:15:49] <jmkasunich> hmm. something tells me that povray parser doesn't get me some key things that I wanted
[04:15:56] <cradek> you're probably not going to be able to make it very simple no matter what.
[04:15:56] <jmkasunich> namely #define
[04:17:39] <cradek> that kind of thing is another good reason to use a programming language
[04:19:12] <jmkasunich> I really should learn some more languages - it would broaden my horizons
[04:20:07] <cradek> you are
[04:20:13] <jmkasunich> I are what?
[04:20:27] <cradek> you are learning at least one more language
[04:20:38] <jmkasunich> and that is?
[04:20:44] <cradek> python
[04:20:49] <jmkasunich> no I'm not
[04:20:58] <cradek> well, I saw you check in some python code the other day
[04:21:12] <jmkasunich> I'm learning just enough to cut and paste things that other people did
[04:21:33] <jmkasunich> knowing a language means being able to start from scratch and write a program (even a simple one)
[04:21:54] <jmkasunich> I don't know what hello world looks like in python, let alone how to do more complex things
[04:21:57] <cradek> with book or man pages in hand, or not? because I know very few languages if not
[04:22:12] <cradek> (maybe none, actually)
[04:22:22] <jmkasunich> by that standard, I know one - C
[04:22:29] <cradek> yeah, me too, probably
[04:22:48] <jmkasunich> and thats pretty much the K&R dialect, with function prototypes
[04:22:50] <cradek> but I'll still look at the manpage every time I want to use strrchr
[04:23:04] <jmkasunich> I'm not good with the libraries - I use manpages all the time
[04:23:20] <jmkasunich> (or I write things that are already in a library because I don't know better)
[04:23:36] <cradek> I think that's a big danger with python
[04:23:47] <cradek> someone has written pretty much everything already
[04:23:53] <jmkasunich> but I don't consider the libs (except for some core ones like stdlib) to be part of the language anyway
[04:25:13] <cradek> I used to think that I wasn't a programmer, even though I could do useful things with programs, now I don't worry about the difference
[04:25:21] <cradek> often I can accomplish a thing I set out to do
[04:25:45] <cradek> whether I "know" a language or not, who cares
[04:26:00] <jmkasunich> I can too - but if that means spending a week writing C when a real programmer would use a lib or a differnt language and have it in a day, then....
[04:27:23] <jmkasunich> well poo - that parser doesn't support #define anyway
[04:29:19] <jmkasunich> hmm, somebody has written a povray patch the uses opengl to pre-render the scene
[04:30:41] <cradek> that's neat
[04:31:08] <jmkasunich> not usefull for me tho - its a patch to the doze version of pov, and pov isn't gpl
[04:31:10] <jmkasunich> (nor is the patch)
[04:32:08] <cradek> is there enough functionality in army already to draw the puma robot like it's shown on that .cz site?
[04:32:34] <jmkasunich> the only primitives are cylinders
[04:32:46] <jmkasunich> (and cones)
[04:32:52] <cradek> ok
[04:32:58] <cradek> need at least rectangular solids
[04:33:03] <jmkasunich> you'd have to fake it for some of the parts, but you could do a passible imitation
[04:33:36] <jmkasunich> defining the robot arm geometry would be ugly at least for me
[04:33:37] <cradek> link2 and link3 look similar - maybe that would be a useful primitive
[04:34:02] <jmkasunich> you have the url to that image handy?
[04:34:05] <cradek> yeah it's going to be ugly...
[04:34:09] <cradek> http://virtual.cvut.cz/odl/partners/fuh/course_main/node17.html
[04:35:01] <jmkasunich> an "all cylinder/cone" version could use a long cylinder to replace the tapered rectangular part
[04:35:10] <jmkasunich> with short crosswise cylinders at the ends
[04:35:23] <jmkasunich> the axis of motion would be thru the center of the cross cylinders
[04:36:08] <cradek> gl (zbuffers actually) are unhappy if you have coplanar polygons
[04:36:23] <jmkasunich> maybe I should just go for it - see how ugly the puma is in pure python
[04:36:49] <cradek> it would be a very cool demo, and useful for kins work, even if it's not yet generalizable
[04:36:55] <jmkasunich> povray doesn't like it (coplaner) either
[04:37:13] <jmkasunich> you get speckles, as it can't decide which one is in front and visible
[04:37:21] <cradek> yeah, same problem
[04:38:31] <jmkasunich> well, I'm gonna go for it - would you mind holding my hand a little as I run into things?
[04:38:48] <cradek> I'll try
[04:39:43] <jmkasunich> this approach:
http://pastebin.ca/339464 seems nicer than that massive nested thing
[04:40:00] <jmkasunich> so first step is to modify army.py to use that and make sure it works
[04:43:30] <jmkasunich> so far so good....
[04:44:56] <cradek> cool!!
[04:45:02] <cradek> (I got it running here)
[04:45:20] <jmkasunich> did you paste the alternate syntax part in yet?
[04:45:29] <cradek> no
[04:51:02] <jmkasunich> ok, its now exporting 6 pins called joint1-6
[04:51:08] <jmkasunich> and I have six signals
[04:51:21] <jmkasunich> the first three go to siggens, the others are free for sets commands
[04:52:01] <jmkasunich> python comments are #comment, right?
[04:52:19] <cradek> yes
[04:53:08] <cradek> ok I know how to do the base and link 0...
[04:53:34] <cradek> seems like I should have been watching when you guys were talking about how army worked
[04:53:50] <jmkasunich> I'm starting by using more names
[04:56:16] <jmkasunich> hmm, his rotate transform actuall rotates and translates
[04:56:31] <jmkasunich> I need to figure the transforms out and add some comments
[04:57:32] <cradek> in order to rotate around x,y,z you have to translate x,y,z to the origin and then rotate
[04:57:42] <jmkasunich> yeah
[04:58:38] <jmkasunich> xyz is the axis around which it rotates I think
[04:58:57] <cradek> yes
[04:59:03] <jmkasunich> and dxdydz is the offset
[04:59:11] <cradek> yes
[04:59:20] <jmkasunich> not sure why he does both at the same time tho
[05:01:05] <cradek> AngularTransformation is wrong (it doesn't rotate)
[05:01:17] <jmkasunich> yeah, he never used it
[05:01:38] <jmkasunich> I'm pulling the translation out of angular hal translation, (renamed the original to combined hal translation)
[05:01:48] <jmkasunich> easier to understand that way
[05:05:40] <jmkasunich> woohoo, combined two parts into one
[05:06:21] <cradek> cool
[05:06:29] <cradek> I'm going to try to write class RectangularSolid
[05:08:15] <jmkasunich> cool
[05:08:21] <jmkasunich> I seem to have locked it up
[05:09:13] <jmkasunich> help - I have a defunct python process, and a window that won't go away
[05:09:22] <cradek> kill?
[05:09:26] <jmkasunich> tried it
[05:09:31] <jmkasunich> kill -9 too
[05:09:31] <cradek> kill -9?
[05:09:36] <cradek> strange
[05:09:47] <jmkasunich> defunct means already dead but not reaped by parent?
[05:09:48] <cradek> did you kill halcmd etc?
[05:09:51] <cradek> yes
[05:09:56] <cradek> kill the parent
[05:10:19] <jmkasunich> I don't think so:
[05:10:32] <jmkasunich> 3033 1 [python] <defunct>
[05:10:32] <jmkasunich> 3170 13474 ps o pid,ppid,cmd
[05:10:46] <jmkasunich> I'm not gonna kill init
[05:11:09] <cradek> hmmmm
[05:11:10] <jmkasunich> I bet what happened is I killed the parent (halcmd) before the child died
[05:11:14] <jmkasunich> so init inherited it
[05:14:19] <jmkasunich> google says "If the parent itself dies, then "init" (the system process with the ID 0) will take over fostership over its children and catch up on the neglected parental duties."
[05:14:25] <jmkasunich> init is slacking off
[05:14:52] <cradek> I don't see why you can't kill it
[05:15:05] <jmkasunich> its already daid
[05:15:57] <jmkasunich> http://foldoc.org/?defunct+process
[05:16:05] <jmkasunich> I just minimized the window and I'm going to ignore it for now
[05:16:17] <jmkasunich> I'll probably have more before I'm done
[05:29:10] <cradek> got RectangularSolid but I think it's inside-out, I have to get my directions right
[05:32:24] <jmkasunich> btw, can we change "CappedCylinder" to "Cone" and "RectantularSolid" to "Box"
[05:32:32] <jmkasunich> typing those names is gonna get old fast
[05:33:17] <cradek> PossiblyTruncatedOrDegenerateCone
[05:33:45] <cradek> how about Cyl or Cylinder
[05:33:45] <jmkasunich> I could live with Frustrum
[05:33:56] <jmkasunich> that works
[05:34:19] <jmkasunich> since you can make the ends different diameters its not quite a cylinder, but I can live with that
[05:34:27] <jmkasunich> I'm changing to Cylinder here
[05:34:43] <jmkasunich> if you want, when you have box working, pastebin it and I'll add it to my copy
[05:35:45] <jmkasunich> I'm also changing AngularTransformation to Rotate, and LinearTransformation to Translate
[05:37:23] <cradek> ok, I think now instead of some of my quads being the wrong way, they all there
[05:37:26] <cradek> grrr
[05:37:27] <cradek> all are
[05:37:33] <jmkasunich> are all
[05:51:57] <cradek> no matter which way I face them, they don't seem to be lit correctly
[05:52:14] <jmkasunich> all of them? some of them?
[05:52:30] <cradek> all of them
[05:56:32] <cradek> huh, when I set the normal with glNormal() it works
[05:56:59] <cradek> maybe you have to do that for GL_QUADS (because they aren't necessarily planar)
[05:57:12] <jmkasunich> maybe
[05:58:14] <cradek> http://timeguy.com/cradek-files/emc/box.png
[05:58:53] <jmkasunich> cool
[05:58:58] <cradek> http://pastebin.ca/339621
[06:00:20] <jmkasunich> thanks
[06:00:35] <cradek> the inputs are the width1, width2, length
[06:00:41] <jmkasunich> perfect timing - I needed a "floor" so I could see what is what
[06:00:58] <jmkasunich> oh....
[06:01:35] <cradek> for a floor, you'd use (large, large, small)
[06:01:41] <jmkasunich> right
[06:01:53] <jmkasunich> but you centered it on X and Y, offset it on Z
[06:01:59] <cradek> yes
[06:02:06] <jmkasunich> * jmkasunich hacks
[06:02:16] <cradek> so it'll draw in the center of the "room" with a certain "floor height"
[06:02:22] <A-L-P-H-A> * A-L-P-H-A hides
[06:02:25] <cradek> I think it's just what you want
[06:02:32] <jmkasunich> generic box (xmin, xmax, ymin, ymax, zmin, zmax)
[06:02:58] <jmkasunich> for the floor, I want the top surface to be at Z=0
[06:03:33] <cradek> then translate it down
[06:03:39] <cradek> http://timeguy.com/cradek-files/emc/floor.png
[06:03:44] <jmkasunich> you did the hard part, I'll do the rest
[06:03:47] <cradek> http://timeguy.com/cradek-files/emc/floor.png
[06:03:50] <cradek> oops
[06:03:58] <cradek> anyone want to see that link again?
[06:05:12] <jmkasunich> is writing 2. instead of 2 neccessary? or just a convention?
[06:05:56] <cradek> I don't know all the details about that
[06:08:11] <cradek> LinearTransformation([RectangularSolid(5, 5, .1)], 0, 0, -.1),
[06:09:03] <cradek> I still kind of think this is what you want - it works just like the cylinder
[06:10:02] <jmkasunich> the 6 coords version avoids a translation
[06:10:11] <jmkasunich> because you can just specify the coords right away
[06:10:40] <jmkasunich> you can also specify centered or non-centered boxes without having to make the box and then translate
[06:14:37] <jmkasunich> I renamed your Box to BoxCentered
[06:14:45] <jmkasunich> and made Box take 6 args
[06:15:02] <jmkasunich> can I define BoxCentered in terms of Box?
[06:15:38] <jmkasunich> I think I want draw(self) to invoke draw(Box)
[06:15:48] <jmkasunich> something like that, I have no idea what the syntax is
[06:16:16] <cradek> class BoxCentered(Box):
[06:16:19] <jmkasunich> Box(-xw/2, xw/2, -yw/2, yw/2, 0, zw)
[06:16:36] <cradek> then override just __init__ to set the self.coords you want
[06:16:43] <cradek> (I think)
[06:17:14] <cradek> so BoxCentered won't have its own draw()
[06:18:27] <jmkasunich> class BoxCentered:
[06:18:27] <jmkasunich> def __init__(self, xw, yw, zw):
[06:18:27] <jmkasunich> self.coords = -xw/2, -yw/2, -zw/2, xw/2, yw/2, zw/2
[06:18:29] <jmkasunich> like so?
[06:18:36] <cradek> yes
[06:18:47] <cradek> well
[06:18:52] <cradek> it should be 0 and zw
[06:18:59] <jmkasunich> right
[06:18:59] <cradek> and class BoxCentered(Box):
[06:19:06] <jmkasunich> (actually that will be yet another one)
[06:19:06] <cradek> that's how you inherit another class
[06:19:36] <jmkasunich> class BoxCenteredXY(Box):
[06:19:36] <jmkasunich> def __init__(self, xw, yw, zw):
[06:19:36] <jmkasunich> self.coords = -xw/2, -yw/2, 0, xw/2, yw/2, zw
[06:19:54] <cradek> yes I think that's the trick
[06:19:59] <jmkasunich> * jmkasunich tries it
[06:20:00] <cradek> but I didn't try it...
[06:20:48] <cradek> http://pastebin.ca/339636
[06:20:55] <cradek> yes I think it's right
[06:21:24] <jmkasunich> if x1 > x2
[06:21:24] <jmkasunich> ^
[06:21:24] <jmkasunich> SyntaxError: invalid syntax
[06:21:34] <cradek> if x1 > x2:
[06:21:34] <jmkasunich> is testing for greater than strange?
[06:21:43] <cradek> you forgot the :
[06:21:43] <jmkasunich> oh
[06:21:52] <jmkasunich> no I didn't
[06:21:59] <jmkasunich> to forget implies that I once knew
[06:22:02] <cradek> haha
[06:24:43] <jmkasunich> something is off center
[06:26:14] <jmkasunich> and either box or cylinder has a normal wrong I think
[06:26:49] <cradek> I'm pretty sure my version is right
[06:26:50] <jmkasunich> I set a large flat cylinder on a larger flat box (sticking up a bit, not coplaner)
[06:27:23] <jmkasunich> as I tilt things, the top of the cylinder shades from light to dark, while the top of the box shades from dark to light
[06:27:37] <cradek> wonder which side of a gluDisk is the front
[06:28:04] <jmkasunich> dunno
[06:28:25] <cradek> I tried to change the color of the back faces (with two calls to glMaterial) but failed
[06:28:45] <jmkasunich> actually there is stil something messy about boxes, I can see into it on at least one side
[06:28:52] <jmkasunich> but I may have messed up that myself
[06:28:57] <jmkasunich> when I went to the 6 coords box
[06:29:23] <jmkasunich> I swap x1 and x2 if x2 is lower, likewise for y and z, so that shouldn't mess it up
[06:29:40] <jmkasunich> I used x1 where you used -x, etc
[06:30:01] <cradek> since the normal is forced, it doesn't matter which way you draw it
[06:30:29] <cradek> although I think I had them all drawn with the front outward anyway
[06:30:57] <jmkasunich> one side is transparent for some reason, I'll check the normals
[06:31:18] <jmkasunich> (made a cube, with a cylinder inside, and I can see the cyl from one side)
[06:31:32] <cradek> ack, I'm going to bed
[06:31:37] <jmkasunich> goodnight
[06:31:39] <cradek> goodnight, this was fun
[06:31:51] <jmkasunich> yep, I'm having loads of fun
[06:31:54] <jmkasunich> steppers can wait
[06:33:51] <cradek> woo if I change the update to 10msec instead of 100, it's really smooth on my nvidia
[06:35:06] <jmkasunich> fixed the transparent face - it was my error
[06:35:21] <jmkasunich> now I gotta figure out why the cylinder is off center in the box
[06:35:27] <jmkasunich> or maybe the box is off center in the cylinder
[06:35:39] <jmkasunich> no way to tell without a reference
[06:36:09] <jmkasunich> actually there is I think
[06:36:31] <jmkasunich> when you use the middle mouse button to rotate, does it rotate around 0,0,0?
[06:36:44] <cradek> yes I think so
[06:37:36] <cradek> it's cool we can reuse the good navigation we worked hard on in AXIS
[06:37:37] <jmkasunich> its rotating around the center of the cylinder, the box is wrong
[06:37:50] <cradek> mine's right :-)
[06:38:05] <jmkasunich> I wonder if I'm not passing the params correctly from BoxCentered to Box
[06:38:17] <jmkasunich> lemme try it with box
[06:38:27] <cradek> really going now - goodnight again
[06:38:35] <jmkasunich> night
[06:39:15] <jmkasunich> yeah, its the param passing, Box works perfectly
[06:39:22] <jmkasunich> gotta read about inheritance
[07:19:23] <jmkasunich> damned self-typing variables
[07:19:54] <jmkasunich> when doing xw/2, you better write xw/2.0
[07:20:03] <jmkasunich> or the damned thing will do an integer divide
[07:50:52] <SWPLinux_> SWPLinux_ is now known as SWPLinux
[09:30:16] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[10:21:07] <jmkasunich> alex_joni: wake up!
[11:04:36] <alex_joni> I am up
[11:26:37] <jmkasunich> http://jmkasunich.dyndns.org/cgi-bin/blosxom/simulated-machine-02-04-07.html
[11:29:43] <alex_joni> cool.. I was just having a blast reading back
[11:30:07] <alex_joni> if we ever want to go to a file format, I think the xml's are great
[11:30:09] <alex_joni> let me mail them to you
[11:30:36] <jmkasunich> I'm going to sleep
[11:30:44] <jmkasunich> (6:30 am here)
[11:31:43] <alex_joni> oh my :)
[11:31:55] <alex_joni> 13:30 here
[11:32:02] <jmkasunich> your mission is to replace puma.hal with something that uses EMC and the pumakins instead of siggens
[11:32:24] <alex_joni> :D
[11:32:36] <alex_joni> and figure out why TELOP jogging doesn't work for puma
[11:32:40] <jmkasunich> did you commit a sample puma config?
[11:32:43] <alex_joni> yes
[11:32:51] <alex_joni> and joint jogging works great..
[11:33:02] <jmkasunich> shouldn't be terribly hard to connect the joints to puma.py then
[11:33:10] <alex_joni> nope.. easy
[11:33:19] <jmkasunich> show me when I wake up
[11:33:31] <alex_joni> I already commited some pyvcp with widgets to show joint positions
[11:33:41] <alex_joni> but it can wait 8h
[11:33:48] <alex_joni> (don't sleep too long :P)
[11:36:32] <alex_joni> jmkasunich: just looked at your site .. whoa! nice job!
[11:37:00] <alex_joni> http://jmkasunich.dyndns.org/pics/puma.py
[11:37:08] <alex_joni> RTAPI: ERROR: could not open shared memory (errno=2)
[11:37:10] <alex_joni> HAL: ERROR: rtapi init failed
[11:37:18] <alex_joni> bet that's not what you wanted there ..
[11:38:54] <alex_joni> * alex_joni whines about having to wait for JMK to wake up
[14:52:03] <jepler> jmkasunich: fucking cool
[14:52:11] <jepler> you can do a lot between 11PM and 6AM, it would seem
[14:53:22] <jepler> I hope you didn't lose the source though
[14:54:37] <alex_joni> same here :)
[14:55:04] <SWPadnos> I hope I can read back far enough to follow what you guys talk about :)
[14:55:20] <jepler> hi SWPadnos
[14:55:27] <SWPadnos> hi jepler
[14:55:32] <alex_joni> SWPadnos:
http://jmkasunich.dyndns.org/cgi-bin/blosxom/simulated-machine-02-04-07.html
[14:55:48] <SWPadnos> I see that, and second the "fucking cool" comment
[14:56:14] <alex_joni> heh
[14:56:17] <SWPadnos> I read a little last night, and saw the "army
[14:56:20] <SWPadnos> " thing
[14:56:27] <SWPadnos> but went to bed before reading much more
[14:56:29] <alex_joni> then I guess it's official.. it's "fucking cool"
[14:56:52] <SWPadnos> heh - that's what the user list email will say :)
[14:57:12] <alex_joni> I dare you..
[14:57:26] <SWPadnos> how difficult do you think it would be to add collision detection to the code?
[14:57:35] <SWPadnos> alex_joni, heh. don't do that ... :)
[14:57:48] <alex_joni> SWPadnos: collicion detection is pretty difficult
[14:58:16] <SWPadnos> I'm wondering if there are any openGL features to help in that
[14:58:40] <SWPadnos> like "oops, a pixel at this depth was already drawn here" ....
[14:59:49] <alex_joni> maybe using this:
http://pyode.sourceforge.net/
[15:00:39] <SWPadnos> that's cool. I may just be thinking of detecting overlap - not figuring out maximum angles and such
[15:01:31] <alex_joni> http://pyode.sourceforge.net/tutorials/tutorial3.html
[15:01:48] <SWPadnos> kewl
[15:02:10] <SWPadnos> I think I ned to go eat breakfast now, but I actually may be here for most of the day (woohoo!)
[15:02:19] <alex_joni> nice
[15:02:33] <SWPadnos> yeah - finally :)
[15:14:12] <EHJ-2> Re: simulation and collision detection, I don't know how it would integrate here or with EMC, but there is a hardware solution through a video card with a physics engine. See:
http://www.pcper.com/article.php?aid=140 for example.
[15:15:13] <SWPadnos> oh yeah. I know it can be done - I was wondering if it would be any easier with the tools at hand :)
[15:17:52] <EHJ-2> I saw an article on slashdot about it a while back, and my first thought was I wonder if I can do something with it and EMC.
[15:18:58] <SWPadnos> yeah - that hardware would be great for the "metal remaining" visualization, since you could do cutter (or full machine) simulation to determine what gets cut
[15:20:02] <EHJ-2> exactly
[15:33:06] <jepler> http://hackedgadgets.com/2007/02/04/kuka-juke-bot-the-robotic-dj/
[16:33:27] <cradek> hi guys
[16:35:20] <cradek> oh man, I hope he didn't overwrite his work
[16:36:08] <cradek> skunkworks:
http://jmkasunich.dyndns.org/cgi-bin/blosxom/simulated-machine-02-04-07.html
[16:40:39] <skunkworks> cradek: saw that last night. very cool.
[16:40:56] <SWPadnos> the consensus seems to be "fucking cool"
[16:41:47] <cradek> skunkworks: you guys must have a lot of life left after 1am, when I go to bed
[16:42:17] <skunkworks> this was around 9:00
[16:43:59] <skunkworks> we stayed up all night friday-saturday trying to get house stuff done - A buyer wanted to see it saturday morning. wiped us out
[16:44:58] <skunkworks> Holy crap - I didn't see the two bottom pictures - yes - fucking cool
[16:49:16] <cradek> now we just have to put the picture of Chips with his safety glasses on it
[16:50:42] <skunkworks> combine that with jeplers part simulator and you could have it simulat cutting chips out ;)
[16:51:08] <lerneaen_hydra> dont forget to have good physics simulation of the actual chips :p
[16:51:28] <skunkworks> chips is the penguin :)
[16:51:40] <lerneaen_hydra> not that chips :p
[16:51:48] <lerneaen_hydra> I'm not *that* wet behind the ears
[16:51:55] <skunkworks> sorry - not enough sleep
[16:51:59] <lerneaen_hydra> (only almost)
[17:17:31] <skunkworks> I have a question
[17:18:05] <skunkworks> I did a cvs -z5 update -Pd
[17:18:17] <skunkworks> configure and such - emc2 runs just fine.
[17:18:40] <skunkworks> I just tried to run the puma hal and get
[17:19:13] <skunkworks> samco@samco-desktop:~/emc2-head$ halrun -f puma.hal
[17:19:15] <skunkworks> File "puma.py", line 1
[17:19:15] <skunkworks> RTAPI: ERROR: could not open shared memory (errno=2)
[17:19:15] <skunkworks> ^
[17:19:15] <skunkworks> SyntaxError: invalid syntax
[17:19:15] <skunkworks> HAL:3: ERROR: python exited without becoming ready
[17:21:19] <skunkworks> could it be I am running 'head' and not 'trunk'?
[17:21:19] <jepler> skunkworks: yeah it looks like jmkasunich uploaded the wrong file
[17:21:26] <skunkworks> ah
[17:21:30] <jepler> look at the contents of the file puma.py
[17:22:20] <skunkworks> thats funny ;)
[17:23:55] <jepler> it's only funny if jmk still has a good copy on his system
[17:25:34] <skunkworks> He seems like someone who would make backups of his backups ;)
[17:45:35] <cradek> I'm afraid people make more mistakes at 6am - I hope he's still got his editor open or whatever
[17:53:30] <skunkworks> oops
[18:07:06] <jtr> Yeah, mistakes happen when you've been up all night. I hope it's not lost - that looks awesome!
[18:11:23] <jepler> now that the joint positions are on HAL pins it should be possible to hook it right up
[18:11:30] <jepler> just have to make the puma kins settings match the simulated machines
[18:30:35] <alex_joni> or rather the other way around :)
[18:37:50] <jepler> just have to make the puma kins and simulated machine match
[18:44:27] <alex_joni> right :)
[18:44:40] <alex_joni> anyone around here good with ramdisks & initrd?
[18:45:12] <cradek> I've played with initrd a bit
[18:46:03] <alex_joni> I wanna do the following thing: I have a bootloader on an arm board. with that I can load the kernel into RAM (through /dev/ttyS0) and boot it. but I need to do the same for the cramfs
[18:46:39] <alex_joni> I can load the kernel and the cramfs into ram (at known locations), but I am not sure what kernel params to pass so the kernel knows where to get the / from
[18:47:04] <alex_joni> wonder if that came across right..
[18:47:06] <cradek> hmmm
[18:47:13] <cradek> yes I understand
[18:49:49] <alex_joni> I think I got it.. something like this "root=/dev/ram0 console=/dev/ttyS0 init=/initrc ramdisk_start=0x3010000 ramdisk_size=0x10000"
[18:50:09] <alex_joni> the alternative would be looking at mounting / from NFS
[18:50:12] <cradek> it's ramdisk_image I think
[18:50:27] <cradek> 0218/4 2.00+ ramdisk_image initrd load address (set by boot loader)
[18:50:27] <cradek> 021C/4 2.00+ ramdisk_size initrd size (set by boot loader)
[18:50:34] <alex_joni> for 2.4.x ?
[18:50:44] <alex_joni> should have said this is 2.4.18 ..
[18:50:45] <cradek> no, I'm looking at 2.6/i386
[18:50:54] <alex_joni> what file?
[18:51:04] <cradek> Documentation/i386/boot.txt
[18:51:15] <cradek> also arch/i386/boot/setup.S
[18:51:41] <alex_joni> hmm.. not there for ARM
[18:52:34] <alex_joni> drivers/block/rd.c:__setup("ramdisk_start=", ramdisk_start_setup);
[18:52:51] <cradek> aha
[18:52:57] <cradek> looks promising
[18:54:40] <alex_joni> * alex_joni hopes so
[18:54:50] <alex_joni> takes a while to upload 2M over serial
[19:18:58] <jmkasunich> * jmkasunich is very confused
[19:19:03] <jmkasunich> no, I didn't lose the code
[19:19:09] <jepler> jmkasunich: oh good
[19:19:16] <jmkasunich> the original copy is where I wrote it
[19:19:27] <cradek> that's a relief
[19:19:33] <jepler> the copy on your website is just an error message
[19:19:36] <jmkasunich> and the copy in the server directory is correct when I cat it or ls it
[19:19:42] <jmkasunich> but the server is serving the wrong thing
[19:19:49] <cradek> it's serving from pics/
[19:19:52] <jepler> it's executing it as a python script
[19:20:00] <jmkasunich> I just realized whats happening - the server is running it
[19:20:00] <cradek> oh
[19:20:03] <cradek> hahahaha
[19:20:33] <jmkasunich> fsck, how do I fix that
[19:20:35] <jepler> you must have been told to misconfigure you webserver when you installed py-blah-sucks-some
[19:20:50] <jmkasunich> :-P
[19:20:57] <jepler> rename it puma.py.txt ?
[19:21:08] <jmkasunich> that works for now....
[19:21:13] <cradek> army.py doesn't execute
[19:21:21] <cradek> maybe the permissions are executable on puma.py
[19:21:22] <jepler> that's on my website
[19:21:41] <cradek> duh
[19:23:05] <cradek> wheee!
[19:23:37] <jmkasunich> fixed, you should be able to get the code
[19:23:57] <cradek> got it
[19:24:02] <cradek> it's beautiful
[19:24:10] <cradek> (except for the purple of course)
[19:27:31] <jmkasunich> I have no idea why that happened
[19:28:31] <skunkworks> wow - very nice.
[19:28:43] <jepler> move self.r_back = self.g_back = self.b_back = 0
[19:28:55] <jepler> below the call to the base class __init__
[19:28:59] <jepler> around line 256
[19:29:30] <cradek> yay
[19:48:59] <jtr> jmkasunich: Not sure your latest blog entry looks quite like you intended...
[19:49:56] <jtr> I'm just sitting here watching the puma run. Can't stop watching.
[19:50:12] <skunkworks> The arm goes through the base without any scraping or sparks. :)
[19:51:10] <cradek> jtr: I agree...
[19:53:04] <jtr> At first I thought that was the workaround to get puma.py Or do you mean watching the puma?
[19:53:40] <jmkasunich> jtr: what about the blog entry?
[19:53:57] <cradek> jmkasunich: look for yourself
[19:54:17] <jepler> * jepler has puma.py hooked up to to emc so that he can jog the joints manually
[19:54:28] <cradek> jepler: check it in
[19:54:42] <jepler> once I go into cartesian mode it doesn't work right :(
[19:55:20] <cradek> yeah the kins are somehow not right
[19:55:25] <jtr> jmkasunich: It starts out "import rs274..."
[19:56:06] <jepler> jtr: yes that's how the file should start
[19:56:13] <jepler> import rs274.OpenGLTk, Tkinter, hal
[19:56:13] <jepler> from minigl import *
[19:56:13] <jepler> class Collection:
[19:56:13] <jepler> ...
[19:56:37] <cradek> jepler: he's talking about jmk's last blog entry, which is bogus
[19:56:38] <jmkasunich> wtf
[19:56:43] <cradek> as he just noticed
[19:56:51] <jmkasunich> oh
[19:57:02] <jepler> oh!
[19:57:04] <jepler> oops
[19:57:06] <jmkasunich> the blogging sw says "if it ends in txt its a post'
[19:57:17] <jmkasunich> * jmkasunich goes for workaround #2
[19:57:39] <jmkasunich> which I dunno what that is at the moment
[19:59:30] <jepler> make a .tar file?
[19:59:52] <jepler> make your webserver not execute .py files from any directory?
[20:01:47] <skunkworks> jtr: did know you can manipulate it as you can manipulate it in axis - pan/tilt/zoom?
[20:01:53] <jmkasunich> the latter is the right choice
[20:01:59] <jmkasunich> but I'm in the middle of something else
[20:02:21] <jepler> not exactly as in axis -- scrollwheel doesn't work, for instance
[20:02:27] <jepler> and you can't hit "v" for preset views
[20:02:43] <skunkworks> * skunkworks doesn't have a scroll wheel on this portable.
[20:03:46] <skunkworks> * skunkworks didn't know you could use v in axis ;)
[20:07:02] <jtr> skunkworks: um, no. Oh, cool! Oops - I just shrank (shrunk?) it to nothing. Any way to fix that other than kill and restart?
[20:07:28] <cradek> right drag
[20:08:04] <jtr> Ok, found the corner of it. Thanks.
[20:11:50] <jepler> jmkasunich: btw this is the traditional way to write 'swap' in python: a, b = b, a
[20:13:01] <jmkasunich> I figured there was a better way
[20:13:25] <jmkasunich> we should get this committed so more people can hack on it and improve it
[20:13:47] <alex_joni> jmkasunich: commit it to the puma config dir
[20:13:53] <jmkasunich> but I'd like to consider splitting it, so later we can do scara, etc without duplicating the code that implements the primitives
[20:14:00] <cradek> I think jepler has it hooked up
[20:13:59] <alex_joni> then it can run with loadusr from the normal hal file
[20:14:11] <alex_joni> jmkasunich: we can always split it later
[20:14:21] <alex_joni> * alex_joni runs home.. been fighting ARM till now
[20:16:37] <jepler> put just about everything up to this line in a file in lib/python: c = hal.component("pumagui")
[20:16:57] <jepler> then it is a re-usable library
[20:17:36] <jmkasunich> "just about"?
[20:18:26] <jmkasunich> lemme guess - the first two lines should not be part of the lib
[20:18:51] <jepler> well -- the import of hal, maybe not
[20:19:06] <jepler> I was thinking more about how the stuff at the very end should also be in the library
[20:19:17] <jepler> the stuff that takes care of redrawing about 10fps
[20:19:18] <jmkasunich> yes
[20:19:52] <jmkasunich> since I have no clue how include works in py, I can either flail around for a while, or let you do it and commit the results ;-)
[20:20:58] <jmkasunich> would you mind doing it?
[20:21:25] <jmkasunich> I just posted a version with the swaps and background color fixed
[20:21:36] <jmkasunich> (but you probably already did that to your local copy anyway)
[20:21:40] <jepler> sure I'll commit it shortly
[20:21:44] <jmkasunich> thanks
[20:21:57] <jmkasunich> * jmkasunich reads about webserver config
[20:33:57] <cradek> ImportError: No module named vismach
[20:36:49] <jepler> argh
[20:42:26] <cradek> working here now!
[20:42:31] <jepler> good
[20:48:05] <cradek> jepler: how do you say which is the front of a gluDisk? they seem to light wrong
[20:48:40] <jepler> cradek: they have one front, but I forget which it is.
[20:49:20] <jepler> With respect to orientation, the +z side of the disk is considered to
[20:49:23] <jepler> be "outside" (see gluQuadricOrientation). This means that if the ori-
[20:49:26] <jepler> entation is set to GLU_OUTSIDE, then any normals generated point along
[20:49:29] <jepler> the +z axis. Otherwise, they point along the -z axis.
[20:52:51] <jmkasunich> I flipped one end of the cylinder over because it was lighting wrong, but...
[20:53:52] <cradek> I think all the disks are wrong
[21:02:53] <jepler> I thought I copied the original code from axis; it must be wrong too
[21:03:35] <cradek> could be - we would never notice
[21:06:06] <jepler> in axis, I make the "bottom" cap with negative radius and the "top" cap with positive radius
[21:06:20] <jepler> axis.py line 836 and nearby
[21:06:40] <jepler> gluCylinder(q, r, r, 8*r, 32, 1)
[21:06:40] <jepler> gluDisk(q, 0, -r, 32, 1)
[21:06:40] <jepler> glTranslatef(0,0,8*r)
[21:06:40] <jepler> gluDisk(q, 0, r, 32, 1)
[21:06:55] <jepler> if negative radius actually changes the normals then this seems right
[21:07:22] <jepler> you can see wrong-facing polygons more obviously if you glEnable(GL_CULL_FACE) in basic_lighting
[21:10:40] <fjungclaus_> fjungclaus_ is now known as fjungclaus
[21:11:02] <jepler> cradek: I can check in a fix for the discs, but it looks like the cube is wrong too
[21:11:33] <cradek> really? I thought the cube was right
[21:22:24] <cradek> much better, thanks
[21:22:48] <cradek> but I'm puzzled about how the quads could have been wrong when the normal is specified
[21:25:49] <jepler> they were probably lit right but when I enabled backface culling (based on winding direction, not normal) the faces still disappeared
[21:26:29] <cradek> ah ok
[21:36:58] <alex_joni> hi guys
[21:37:08] <alex_joni> * alex_joni is finally home.. (11pm)
[21:38:08] <alex_joni> the puma loads just fine.. :)
[21:38:53] <alex_joni> but the HOME position is not ok (seems that homing with offset doesn't keep the values on the joints)
[21:42:22] <skunkworks> alex_joni: did you write the kins for the puma?
[21:42:28] <alex_joni> no
[21:48:19] <alex_joni> skunkworks: if I did, I probably would understand it better
[21:49:08] <skunkworks> :) jepler had mentioned that it might not be right
[21:49:21] <alex_joni> as it is now, it's clearly not right
[21:49:29] <skunkworks> ah
[21:49:33] <jepler> I start, hit 'home all', then hit '$' a few times -- the machine changes position each time
[21:49:42] <alex_joni> what's $ ?
[21:49:44] <alex_joni> toggle joint/world?
[21:49:54] <jepler> yes
[21:49:54] <skunkworks> side question - is 'modbus' supported?
[21:50:07] <jepler> no
[21:50:32] <skunkworks> ok - I was not talking out of my ass
[21:50:37] <alex_joni> jepler: it seems the revolution for a joint is 0..1 right?
[21:50:49] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=31808
[21:51:56] <jepler> there's something in classicladder about modbus but I don't think it does anything
[21:59:03] <alex_joni> jepler: is there any way I can set initial joint offsets?
[22:00:09] <jepler> HOME_OFFSET?
[22:00:31] <alex_joni> I did that.. but the joint (motor-pos-cmd) is still at 0
[22:00:41] <alex_joni> only the emc internal offset works OK..
[22:00:50] <jepler> right
[22:00:59] <alex_joni> I meant for the pumagui display
[22:01:43] <jepler> that's what .joint-pos-{cmd,fb} is
[22:02:42] <alex_joni> I don't think I was clear enough..
[22:02:57] <alex_joni> try to home it.. and look at the joint positions
[22:03:19] <jepler> 28999 float IN -90 pumagui.joint3 <== j2
[22:03:18] <alex_joni> 0 0 -90 0 -90 90
[22:03:37] <alex_joni> but the model is still upright here
[22:04:10] <jepler> something moves
[22:04:48] <alex_joni> yes, but j2 (joint3) is pretty visible if it moves by 90 degrees..
[22:06:53] <jepler> joint positions are in degrees?
[22:07:35] <alex_joni> yes
[22:08:23] <alex_joni> http://www.euron.org/miscdocs/docs/euron2/year2/dr-2-2-dataset.pdf
[22:08:44] <alex_joni> I think that's the closest to the kins written
[22:08:46] <alex_joni> page 61 or so
[22:17:55] <alex_joni> can anyone else try the latest puma config? I am pretty happy now with how it moves
[22:18:07] <alex_joni> (in joint mode, will look at world mode in a bit)
[22:37:41] <jepler> alex_joni: you must have missed my change where I made the pumagui joints be angles .. that together with your Jxscaled change makes it work lss well than before
[22:37:44] <jepler> * jepler has to leave now
[22:39:01] <alex_joni> oh you did?
[22:58:17] <alex_joni> jmkasunich: still around?
[22:58:23] <jmkasunich> who me?
[22:58:27] <alex_joni> yeah :)
[22:58:49] <jmkasunich> yeah
[22:58:57] <alex_joni> something odd happening.. I fear we need to start understanding the inverse kins code :(
[22:59:01] <jmkasunich> looks like you guys were having fun with puma
[22:59:17] <alex_joni> forward works ok.. and now the robot moves as it should (joint space jogging9
[22:59:19] <jmkasunich> (while I was getting my server to not execute .py files)
[22:59:46] <alex_joni> but I think the kinematicsInverse is somehow busted
[23:00:04] <alex_joni> or maybe it assumes joints as radians not degrees, or similar
[23:00:19] <alex_joni> I had to "fix" kinematicsForward so it works ok..
[23:00:32] <jmkasunich> * jmkasunich fires up emc2/puma
[23:00:32] <alex_joni> but I have no idea what to do to kinematicsInverse
[23:00:39] <alex_joni> cvs up first
[23:00:43] <alex_joni> and make
[23:00:56] <jmkasunich> of course
[23:01:16] <jmkasunich> on this project, you need to update every 10 mins, or you miss something
[23:01:36] <alex_joni> yes..
[23:02:05] <jmkasunich> hmm, the little meters don't work
[23:02:20] <jmkasunich> did they get disconnected when the 3d model was added
[23:02:25] <alex_joni> might be..
[23:02:32] <alex_joni> not important right now :D
[23:03:04] <alex_joni> try homing (Ctrl-Home) just after you load up
[23:03:37] <alex_joni> if you put AXIS and tk#2 right next to each other they should move in unison
[23:04:41] <jmkasunich> every time I hit home all it moves more
[23:05:09] <alex_joni> close it.
[23:05:21] <alex_joni> then when you start, you hit ctrl-home (home all axes) once
[23:05:37] <alex_joni> you'll see the robot will move to a certain position
[23:05:53] <alex_joni> now you can jog joints, and the two displays should 'fit'
[23:06:54] <jmkasunich> looks that way
[23:07:04] <jmkasunich> 90 degree offset
[23:07:18] <jmkasunich> (3d is pointing down, axis pointing right
[23:08:39] <alex_joni> hmm.. maybe we need to move joint0 too (by 90 degrees)
[23:09:00] <alex_joni> jmkasunich: try jogging joints, they should move very nicely (preview and 3d)
[23:09:57] <jmkasunich> only 0, 1, and 2 work in the preview
[23:10:11] <alex_joni> right
[23:10:22] <alex_joni> the other are hard to plot
[23:10:38] <jmkasunich> the axis cone is hard-coded to be vertical maybe?
[23:10:43] <alex_joni> yes
[23:11:28] <jmkasunich> ok, now what?
[23:11:43] <alex_joni> well.. switch to world..
[23:11:47] <alex_joni> but that will fail :(
[23:12:00] <jmkasunich> how do you switch to world in axis?
[23:12:03] <alex_joni> $
[23:12:09] <alex_joni> or from the menu
[23:13:03] <jmkasunich> it moved when I did that
[23:13:08] <jmkasunich> not good
[23:13:43] <alex_joni> yup :(
[23:13:47] <alex_joni> the joints get reset to 0
[23:13:50] <alex_joni> no idea why
[23:14:03] <jmkasunich> this is too complicated for my tired brain
[23:14:11] <jmkasunich> I'm thinking we might want to start with something simpler
[23:14:15] <jmkasunich> like a scara robot
[23:14:29] <jmkasunich> I could make a scara 3d model pretty quickly
[23:14:42] <jmkasunich> that only has 3 dof
[23:15:10] <alex_joni> right
[23:15:29] <jmkasunich> once we understand the simpler kins, we can move on to bigger and better things
[23:15:53] <alex_joni> right :(
[23:16:08] <jmkasunich> we have scara kins already don't we?
[23:16:13] <alex_joni> in emc1
[23:16:17] <alex_joni> not sure about the license
[23:16:36] <alex_joni> scarakins.c is a copyright work of Sagar Behere, May 2003.
[23:16:36] <jmkasunich> what other kins are in emc2?
[23:16:39] <jmkasunich> just the tripod?
[23:16:44] <alex_joni> tripod kins
[23:17:04] <jmkasunich> I'm not ready to try 3d modeling for parallel kins
[23:17:23] <jmkasunich> its fundamentally different, not just a tree
[23:17:49] <jmkasunich> weren;t the scara kins done by some indian student?
[23:17:59] <jmkasunich> saga behere or something like that
[23:23:48] <alex_joni> jmkasunich: we can proceed with scara :)
[23:24:40] <jmkasunich> you want to put the kins into emc2?
[23:24:46] <jmkasunich> I can start the model
[23:24:52] <alex_joni> I can put the kins
[23:25:09] <jmkasunich> the kins use some parameters to describe the robot geometry, right?
[23:25:23] <jmkasunich> seems the model should use the same parameters, rather than hardcoded like I did for the puma
[23:26:37] <alex_joni> I made them HAL parameters for now
[23:26:48] <alex_joni> but they default to some values
[23:30:56] <jmkasunich> at least right now, the dimensions of the model are set when it first runs, and they can't change later
[23:31:02] <jmkasunich> of course hal params can.....
[23:31:08] <alex_joni> yup
[23:34:05] <jmkasunich> I'm NOT gonna spend all night figuring that out - just gonna have some constants at the top of the file, which match the defaults in the kins file
[23:34:09] <alex_joni> right
[23:34:15] <jmkasunich> gotta know what the variables are called, and what they represent
[23:34:20] <alex_joni> A1 360
[23:34:22] <jmkasunich> probably aren't that many
[23:34:23] <alex_joni> A2 250
[23:34:27] <alex_joni> D1 489
[23:34:30] <alex_joni> D4 197
[23:34:36] <alex_joni> that's all for scara
[23:34:55] <jmkasunich> what do they mean in english?
[23:35:03] <alex_joni> A1=nfc
[23:35:12] <alex_joni> A2=not even that
[23:35:15] <alex_joni> ...
[23:36:26] <jmkasunich> angle limits for the two rotary joints?
[23:36:32] <alex_joni> A are usually angles
[23:36:35] <alex_joni> D is distances
[23:37:02] <jmkasunich> why don't you copy the kins code into emc2 asap and commit it, then we'll figure it out
[23:37:16] <alex_joni> ok, I was working on that
[23:39:45] <alex_joni> building now.. if it's ok, I'll commit
[23:41:53] <alex_joni> there you go..
[23:42:52] <jmkasunich> updating
[23:43:27] <jmkasunich> phone
[23:44:12] <alex_joni> http://www.ecse.rpi.edu/Courses/F04/ECSE4490/notes9.pdf
[23:44:24] <alex_joni> page #5
[23:44:46] <alex_joni> (I would think those are a1,a2,d1,d4)
[23:47:01] <jmkasunich> ok, first things first
[23:47:20] <jmkasunich> there are absolutely no excuses for something as complicated as kins to have undocumented parameters
[23:48:03] <alex_joni> I think those are generally valid
[23:48:14] <jmkasunich> a1 and a2 are arm lengths
[23:48:29] <jmkasunich> x = SCARA_A1*cos(q0) + SCARA_A2*cos((q0+q1));
[23:48:40] <alex_joni> Joint i connects link i-1 to link i
[23:48:40] <jmkasunich> A1 is the upper arm
[23:48:50] <jmkasunich> A2 is the lower/outer arm
[23:48:55] <alex_joni> .I is the skew angle from zi-1 to zi measured about xi
[23:48:53] <alex_joni> di is the distance from xi-1 to xi measured along zi-1
[23:48:53] <alex_joni> .i is the angle from xi-1 to xi measured about zi-1
[23:49:24] <alex_joni> a* are distances between links (articulations)
[23:49:34] <alex_joni> so the arm lengths as you name them ::)
[23:50:18] <jmkasunich> D4 isn't even used
[23:51:10] <jmkasunich> I'm gonna add some comments and recommit
[23:51:36] <SWPLinux> cd ..
[23:51:45] <SWPLinux> oops
[23:51:57] <alex_joni> ok
[23:53:01] <alex_joni> do we want a scara config dir?
[23:53:10] <jmkasunich> yes
