hey, anyone awake? got a problem with the 'apt-get update' from dsplabs site.
'failed to fetch........unable to find expected entry........(malformed release file?) '
just updated breezy to dapper and am following the wiki instructions to fix things.
edited the source.list file and the 'apt-get' command fails......
Roguish: you are taking out the dsplabs.ro and adding linuxcnc.org in the repository list?
should i be?
the wiki shows to add dsplabs to the list, so i did.
Roguish: I think so. see if http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Repository_Updating
i have been on the 'installing emc2' page. thanks. i'll take out the dsplabs and add the linuxcnc.org
much better. guess the wiki is slightly out of sync.
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.
I saw the instructions long ago, have to find them again.
dsplabs is no longer used - and jepler updated the wiki instructions
Saw that. Was working on the perfect wording for "if you see this, change it to this", and why.
ah ok, thank you
* alex_joni winks at jepler
steve_stallings is now known as steves_logging
SWPadnos_ is now known as SWPadnos
* alex_joni looks around
* jmkasunich looks up and down
alex, do you see any open GL experts in here?
* alex_joni looks dangerously in jeplers direction
dang, he must be hiding
* alex_joni has something for jepler
anyway, what do we want from this thing?
of course I'm hiding
define some simple geometry (boxes, cylinders, cones)
define some rules for articulating it
"move this box and everything attached to it when this variable changes"
and link those vars to hal pins
for series kins (trivkins, puma, scara, and most other robots) the geometry is a tree of transforms
for parallel kins it uglier
* jmkasunich is tempted to ignore parallel kins for now
* jmkasunich is googling
keyword (for series kins) "matrix stack"
I wonder if GLUT would be usefull
AXIS uses gluCylinder/gluDisk etc to draw stuff
you could easily add some stuff to draw a machine
but right now, you would have to hardcode into AXIS a lot of assumptions about the machine
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
I'd prefer to see it draw over the program preview with the tool
afaic, how else do you see if it's working right?
hadn't thought that far
to be honest, this is a digression from a digression (at least)
we've all talked about it before
we (awallin and I) started talking in #emc about pyvcp pin naming
which digressed into hal newinst and hal pin naming
a simple line from elbow to elbow (I don't know the correct terminology) would be a fine representation for testing
which somehow morphed into simulation of machines
lines work for rotary joints, where the angle of the line is the "data"
for slides (traditional machines) not so well
I was thinking rectangular prisms for table, saddle, ways, column, head, etc
for orthogonal machines there's not much to do except draw the tooltip in 3d space
cylinder for spindle
I want to be able to model things like a bport with both knee and quill controlled
that really wouldn't be very hard...
the problem is your draw rate will go down with all those triangles
a rectangular prism is 6 faces, 12 triangles
games render thousands of triangles at 10s of frames per second
I want to render at most a couple hundred
zbuffers are not intuitive - the speed is proportional more to the number of pixels buffered (on-screen size) than the number of triangles
"your draw rate will go down with all those triangles" is what you said ;-)
with software rendering one big triangle takes about as long as many small triangles
err, all those big triangles
to be honest, never even thought about update rate, I assumed it would be a piece of cake
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
open gl may make some performance tradeoffs compared to my handcrafted code, but not enough to offset 10 years of hardware advances
don't people use open gl for games?
not software rendered, no
oh, its all about the graphics card....
modern cards make the fill rate negligible, and the whole scene gets loaded into the card once
we don't have any of that with our realtime machines :-/
thats why my glxgears is so jerky - its software rendered
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
is that puma?
I think so
maybe with that at hand, I might understand the kins
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/
puma is rotary waist, up/down rotary shoulder, up/down rotary elbow, rotary forearm, and up/down (if forearm not rotated) wrist
jmkasunich: sounds like something we can hack together with emc2/HAL
"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."
yes, that seems like exactly what we want
"other programs which produce changing geometry" = emc/hal
* alex_joni starts looking at code
I'd like to do that, but I really need to cut some metal, drill holes, etc
I want to spin a stepper this weekend
(it will be setting on the bench, not attached to the machine, but thats a start
ok, I'll let you know if I have something
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
heh.. there is a geomview package for dapper ÖD
hmm in puma it gets most of the way to the origin (g28) but then everything turns to NAN
it's pretty glacial at 3deg/second on all joints...
and it even works
cradek: there is something borken about the puma kins.
moves like a glacier
if you move a joint.. you'll see in the preview it makes a full circle
and the joint will move from 0 to ~6.3
so I think that's 2*pi, instead of 360 degrees
s1 = sin(joint);
it's obviously assuming joints are in radians
unit fun again
rpy.r = world->a*PM_PI/180.0;
cradek: so joint*180/PM_PI ?
in inverse, it assumes world is in degs
alex_joni: yeah try that
I'm ok with degrees all over
jmkasunich: geomview sure seems nice at the first glance
degrees all over? yuck
internal stuff should be in radians, otherwise the math gets very messy
I think alex means the user will see degrees for the joints
convert from deg to radians at input, and back to degrees at output, use radians for the calcs