btw, spindle orient is good for more than just toolchanging
for example, using a boring head, when you get to the bottom you orient so you can retract without scoring the side of the bore
jmkasunich: dont you have to move the table to avoid scoring the bore?
yeah - but without orient you don't know which way to move it
there's also the use of a lathe spindle as an indexer ...
(or something like that)
I think we have a cycle that bores down, then goes into pause, waits for the user to orient the spindle, and then rapids out
or something :-)
I just use g85 that bores both ways
nominations are over!
did we get at least 5?
7 I think
grr, I hate /sys
what is /sys?
I used to be able to plug in my webcam and /dev/video0 would magically appear, I could do snapshots, etc
now it doesn't
and I have no clue where to start figuring it out
/sys is the new-fangled thing that does a lot of what /dev used to do
[20990742.288000] usb 3-2: new full speed USB device using uhci_hcd and address 3
lsusb says: Bus 003 Device 003: ID 04fc:504b Sunplus Technology Co., Ltd Aiptek, 1.3 mega PockerCam
nothing else at all (I did dmesg -c first)
probably no module matches it then
this is the one you used at the workshop?
do you know what modules used to work?
oh, I recall you compiled it
btw, that's not my typo, it comes across as "Pocker" cam
didn't even notice
I'm sure I've upgraded kernels a few times
I wish drivers like this woule be in the mainstream kernel
probably in 8.04, but not 6.06
I think my brain is rotting from lack of use - I don't even know where to start with the rebuild
don't worry - there shouldn't be too many more kernels for that
* jmkasunich looks around
then make -C /path/to/kernel/source
or something like that
no, just make
kbuild you know
I thought there was still something for making just a single external module
less READ_AND_INSTALL ;-)
I might have had it backwards anyway though - go to the kernel source dir nad make -C /path/to/module
reading the docs is cheating
"The driver should compile and run successfully against most stable versions of
the official Linux 2.6.x kernel upto version 2.6.11"
jmkasunich@mahan:~$ uname -r
methinks maybe I need to download a fresher one
that's the dapper kernel
fresher driver, not fresher kernel
[01:54:01] <jmkasunich> http://mxhaard.free.fr/news.html
latest version there is from 12/24/2007, which is what I have
well if it worked before...
FIX sysfs for kernel upto 2.6.23
that's one of the comments, so maybe the readme is out of date ...
and the one below it mentions a MAKEFILE flag change for 2.6.24
or Makefile even
[20992086.228000] usb 3-2: new full speed USB device using uhci_hcd and address 5
[20992086.372000] /home/jmkasunich/gspcav1-20071224/gspca_core.c: USB GSPCA camera found.Sunplus FW 2
[20992086.372000] /home/jmkasunich/gspcav1-20071224/gspca_core.c: [spca5xx_probe:4275] Camera type JPEG
[20992086.372000] /home/jmkasunich/gspcav1-20071224/gspca_core.c: [spca5xx_getcapability:1249] maxw 640 maxh 480 minw 176 minh 144
now if I can just make it work on a ancient laptop
engineering week approaches
this time, the task is to navigate a maze
black lines on a white floor
cradek: no good deed goes unpunished:
Anchors used in gcode.html but not defined in gcode_main.html:
hey. 640x480 isn't 1.3 mega - is the pockercam not reporting something correctly?
it's 0.3 mega
you aren't getting all your megas
maybe they count R, G, and B separately
that's still 0.9 megas
nah, that still isn't enough
I'm not even getting 640x480 right now
1.3M would be something like 1300*975
1280*960 is common
or 1280x1024 if it's 5:4 aspect
(that's the standard 1.3M screen resolution)
1280x960 is 640x480 * 2
yep, about 1.2+change
so they may round up
ISTR that the camera can take stills at the higher res, and video at the lower
ok, that's common
it's possible that in video mode, they use a full RGGB quad for a single pixel, to avoid having to filter each color plane separately
sending the proper options to vggrabbj let me grab a 640x480 frame
that's probably all the real data the imager takes anyway
no point multiplying the data by 3 just so you can compress it again
I can get 320x240, 352x288, and 640x480 from it
interesting middle resolution there
1/2 of 704x576
(in each dir)
Sets the imagesize of input device, where imagesize is one of:
sqcif= 128x96, qsif = 160x120,
qcif = 176x144, sif = 320x240,
cif = 352x288, vga = 640x480,
svga = 800x600, xga = 1024x768,
sxga = 1280x1024, uxga = 1600x1200,
vggrabbj man page
ok. sxga is 1.3MP
cif is about iphone res ;)
next step is to mess with the vggrabbj source, get images into memory where I can mess with them
I'm probably in way over my head
can vggrabbj write to stdout?
jpg, png, and one other format
even if it can't, you can use imagemagick to do a wicked sharpen on the image
low difference threshold, high gain
err - edge detect I mean
you may be able to define your own kernel too, I'm not sure
once you do that, there are tools to convert to vector
one of those might be able to be coerced into making a line drawing
we're going to be looking for solid black lines on a solid white background
yep, except that they'll be shades of gray in the sensor :)
image to vector is the hard part - any hints as to what tools
I'm assuming some kind of thresholding will be needed
I don't remember the name - I think one of the drawing programs like xfig can do it though
imagemagick might - it can export to svg - I don't know if it can vectorize though
that seems like a hard problem in general
thresholding is what I was talking about for the sharpening kernel
I've been thinking about mounting the camera 18-24" up, facing down/forward
relatively high difference threshold, since you don't want gray gradatyions to show up, but very very high gain, so the high side becomes pure white and the low side pure black
yes, you'll have to do a perspective correction
which imagemagick can do
do some sort of perspective correction - map from camera pixels to "map" pixels, where the map is the floor, with maybe a 1/4" grid
you'll be able to flatten the image wth some keystone correction
the trick for moving from camera to map will be knowing my position and orientation
any given frame will only tell me a small part of the overall map
how big is it expected to be?
50 x 20 feet, approx
1 foot wide "track", with 3/4" wide stripes on both edges and centerline
ok, that's not too bad
intersections will be no closer than two feet, so there will be exposed floor between parallel track sections
so you want at least 1/4"/pixel resolution or thereabouts
is it expected to be on a grid?
not a small map - 50' x 20' at 1/4" is 2.3e6 pixels
ie, there either is or is not an opening on the left this foot
that isn't exactly clear
that's only a few times what you have
you could do 1"/pixel and still have it work, if you can get the whole thing in the depth of field
it would be funny to raise a camera to 6' or so, snap one picture, then lower the camera and navigate the maze :)
I can't believe I could clearly see the whole maze at once
no, it seems unlikely
well, maybe from 6-8'
it depends on which side you start on
50' depth of field would be difficult for that camera I think
if you could control zoom it would be better
I believe we have 5 minutes to explore, we are timed based on fastest run from start to finish, scoring encourages exploring and then running back to the start for a speed run (based on memory)
I have a couple of 3 or 5 MP cameras you could try
can you explore by running over "walls"?
not just DOF - noise, background, contrast, etc will all get iffy the farther away I try to look
by that I mean drive straight ahead X feet, regardless of whether you cross a black line
I think - there was a FAQ published today that said there is no penalty for leaving the track
in theory anyway :)
although it seems like that would let you just ignore the maze and go to the end as the crow flies (after you identify the end)
or is that "no penalty for leaving the maze"?
however, the track is 1/2 or 3/4" thick, so the bump would be rough
the track is the maze
so the 4WD wins the day
they are going to have "boards", 12" x ??", with the lines on them
ok, so you can run all around it, ie "leave" it, but that probably doesn't say anything about running over walls
no walls, the edges of the board are the walls
what I mean is that "leaving the track" probably means "going outside the outer boundary of the maze", not leaving the paths inside the maze
I have (from a previous contest) two wheel mechanisms, 64 count/rev encoders driving worm gears (maybe 50:1?) driving wheels
ok, so you can drive and steer
oh - I'm not sure how much room there will be outside the outer boundary
probably full of spectators
so no penalty for hitting spectators - cool! ;)
I'm hoping I can do moderate dead reckoning, but I'm sure I will have slip and other errors
so a second aspect of the imaging would be to match what I see "now" with what I saw "earlier", to correct my position/orientation estimates
gonna need a frickin cray
you mean a watch, right?
or an ipod
yeah, google found that - haven't read much yet
I wish I could use my work laptop for the brain - core 2 and pretty fast
but it runs windows
can it boot from cd?
my linux laptops are all ancient - 600MHz or less
or better, usb (so you have persistence)
I hear that's getting easier to use
[02:47:12] <SWPadnos> http://en.wikipedia.org/wiki/List_of_raster_to_vector_conversion_software
I think some EMC-related person did something with http://potrace.sourceforge.net/
I wonder how important/usefull a vector representation is for this? would a pixelated map with a modest grid work?
probably, and you don't need the vector representation, just knowledge of where the vectors would be
I've used potrace (long ago)
but since there are programs that will output a vector image, they may be easier to use
I think the chain would be: camera image (including keystone distortion,etc) -> using approx position and orientation, convert to world coordinates (~1/4" grid on the floor) -> merge new images with old, revising estimated position/orientation in the process -> use raster-vector to actually solve the maze (recognizing intersections, etc)
all intersections are T, except for the goal, which is a + (and that is the only way to identify the goal)
oh. that's useful
so you have only 4 kinds of "cell"
no openings (dead end), open front, open L/R/F, open left, open right
no, 8 - hey, they're all there :)
(and 16 if you kep track of what's behind you
I like this potrace option: -t, --turdsize n - suppress speckles of up to this size (default 2)
I think I want my map to be in world coordinates, not "me" coords
IOW, X and Y, rather than left, right, ahead, behine
if there's a grid, you can make a map (e.g., a 50x20 array) with constants that represent which sides are open
for that grid cell
I'm not sure if there are distinct cells, or if they might have track segments that are 17", 39" etc, long
right, that was the question I was asking about earlier
how big is the robot expected to be?
any size that fits on the track
they have photocells across the start and finish, so it can't be much wider than the track
I think they promised 2-3" clearance (for vehicles that want to run feelers on the sides of the track)
the finish junction will have photocells set diagonally, so you can enter from any arm and break the beam
EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.py stepconf.glade): Adda optional desktop launcher we'll see how that works. Fix spindle display option to use an absolute and scale component if necessary. Still need to decide to add halui or remove tool number display
you know, there should be a way to tell EMC that your spindle can't reverse
so it can error if there's an M4 in a program
there are a lot of "capabilities" that a specific machine may or may not have, that the canonical machine always has
like spindle encoder
I guess my statement could be more generic then :)
actually, spindle speed MIN_LIMIT and MAX_LIMIT would be nice
which would also take care of reversal
depends - MIN_LIMIT could be "slowest" or "fastest reverse"
wow - this looks like a nice drawing program: http://www.xaraxtreme.org/
SWPadnos: net dangit motion.spindle-reverse axis.0.amplifier-fault
that would have some of the desired effects
or be more confusing: net ha! motion.spindle-reverse motion.feedhold
actually, if you have at-speed hooked up, you get somethign like that
EMC: 03cradek 07TRUNK * 10emc2/configs/sim/ (6 files): tweaks for lathe config, including spindle-at-speed
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-01-13.txt
cradek, in the 'near' component, is there a reason other than divide by zero to check for scale>1?
is that intended to disable the ratio check?
minor silly optimization: change the comparison to use only multiplication as follows:
if((scale > 1 && in1 <= in2*scale && in2 <= in1*scale) || fabs(in1-in2) <= difference)
which means the scale>1 is no longer needed, unless there's another reason for it
either that expression is write-only or it's too late in the day
I don't see what <1 would mean that you might want
I took part of the existing expression:
in1/scale <= in2
and multiplied both sides by scale to get :
in1 <= in2*scale
I would remove the scale check entirely, or make it scale <=0
but I think if it's <1 both expressions will never be true
that seems true
it's true the scale check is not needed
so the scale check is a shortcut
but changing it to some other number would only muddy the waters
right - leave it alone or remove it
the default settings should give a strict equality test
yes, they appear to
(this late in the day)
let's not change it tonight
ok by me
I know the replacement expression is mathematically equivalent
and that divides still take significantly longer than multiplies (39 cycles instead of 3, IIRC)
and that multiplications never cause divide by zero errors :)
(not that those can happen here anyway)
if I ever need 36 extra cycles I'll start optimizing here
sorry - my microcontroller experience always makes me see things like a/b > c/d as things that really want to be a*d > c*b
even though it's less obvious looking
no problem, it's true it's better
watch the signs though - I think you can accidentally flip the comparison
you can, but I didn't
multiply both sides by b*d
and the inequality / equality remain the same
even if b is negative?
I think so
I think not
the only case where it should blow up is b=0 or d=0
1*1 > 1*-1 (true)
1/-1 > 1/1 (false)
so that's why all my embedded software doesn't work!
so yeah, don't change "near" tonight :-)
well OK then ;)
ah - we know scale is positive because of the check for scale > 1 ;)
KimK - I sent you a private message about Panasonic servos at CNC Workshop
EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Fix pyvcp sample options: add mdi section to ini , if spindle encoder then scale output
EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/pyvcp/ (xyzjog.xml spindle.xml): fix pin type in spindle.xml change border in xyzjog
EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: opps missed a pin name fix for spindle override
I wonder why spindle override needs to come from pyvcp?
I thought AXIS has a slider for that if spindle is activated
it's making connections for halui
I saw that.. but.. why?
imo that will only cause frustration for users who actually want to connect it to some physical pins
oh right - I have no idea why he's connecting pyvcp to halui
it may just be an example that does something noticeable
I don't think that's the purpose of stepconf
to be an "example that does something noticeable"
hah! it is a sample :)
on that note - good night
Hey i saw you online Thought you might want to talk some more about what i was doing in Stepconf
Or do you want to use it more first
well.. I must admit I haven't started it yet :)
only reading commits lately
just wanted to share my concearn that it might get too .. friendly, allowing people to bite themselves
Yes I gathered that. As I said the samples could be changed to anything
I know what your getting at but I don't think it's that bad yet. They can chose not to use any samples
It seems alot of people learn from hacking a working example-that is what I was trying to provide.
I can see the complication it adds to stepcong and that is why I was looking to separate the extra hal code by using The hal command idea (or any other idea)
right.. well, let's wait and get some more feedback
K sounds good
all of the US guys are probably asleep atm
where are you?
GMT + 2
ahh I'm in Canada
[09:56:29] <alex_joni> http://en.wikipedia.org/wiki/.ro
it's 2 am
close to noon here
well that's unfair you are wide awake in this fight lol!
well.. pseudo-busy at work though
(should level things out)
lol ok . Well actually i'm going to bed soon anyways
Thanks for offering your opinion
Guest859 is now known as skunkworks_
steves_logging is now known as steve_stallings
EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: typo
I asked some time ago about kinematic with xz linear and y was rotary
jepler said that can't be done until joint will have velocity constrains or so
jepler: is your patch to periods has some influence on this topic ?
anyway I must write this module becouse of problems with my configration and things that must be done to use this machine (changing scale due to position and so)
man, it's too darned funny to be typing an email, and have the response from jmkasunich come in with the exact same wording
(at least in part)
and the rest was similar enough that I didn't bother :)
he reads in minds (and types faster:)
we're usually in a dead heat :)
steve_stallings is now known as steves_logging
was there any competing "relative angular" proposal to the crazy one where A+90 and A-90 went to the same place but with differing directions of travel?
well, besides the buggy one I tried to do once: G0 the short way, G1 the way the emc does now
sadly nothing else seems like a 'standard'
maybe config option to angular be "wrapable" ?
micges: the question is how should it work
jepler: did "no sign specified" go positiveward, or was it a third behavior?
cradek: oh god, I hope it wasn't a third behavior!
* cradek sighs
my kingdom for a spec
in my opinion when wrap enable there must be (configurable) position that when emc pass is it will zero position
no sign might be default to plus like everything else
just my opinion
I envisioned that the joint position will continue to be just like now-- if the gcode makes it turn 1000 revolutions then the joint position will be about 1000*360.
but this relative rotary axis mode doesn't require the user to keep track of that -- write A-90 if you want to turn to 90 degrees by going clockwise (or whichever way the sign goes)
jepler: I agree with that implementation, especially now that we have doubles
good night all
jepler: what is the catch? it doesn't sound that hard to me today
cradek: new modal group?
back to "no spec"
right now is +A counterclockwise?
huh I thought there was a section in gcode_main.html that talked about this
oh bigjohnt made it a separate document: http://linuxcnc.org/docs/html/common_machining_center.html
'angular position increases without limit (goes towards plus infinity) as the axis turns counterclockwise'
Just a thought - what about having a code that simply resets the axis to within 360 degrees.
say you start at 0 and do 3.5 turns. Issue the code any you are at 180 degrees.
Ideal for synchronized threading etc
LesNewell_: that's a tiny bit like what I tried to do, with "G0 A..." being that "reset" plus a movement to the next spot where you wanted to start..
you can already do that with G10
well, something like it
Not really, because you then have to work out where you are.
G0 X1 Y0 Z0; G1 Z10 A9999; G0 Z.99 Z0; G1 Z10 A9999
er, G0 X.99 Z0 A0
if that makes any sense
oh right, you don't easily have current position
I was thinking about how easy g10 l2 p1 a[position % 360] would be
.. adding a code to fetch the current position into the probing parameters wouldn't be hard ..
yeah, but ick
jepler: I can't think of anything against your idea though having a separate reset gives you more control.
although I don't think the typical scheme (sign gives direction) is that great, I'm against doing anything atypical/emc-specific
the main problem that I recall was that emc assumed every rotary axis was wrapped -- this probably isn't true of the rotary axes on a 5-axis machine. so it would try to go outside the machine constraints to get from -180 to 180 (say)
yeah this definitely needs to be per-axis
"this" being my alternate idea, or the signed motion idea that stuart has told us is "standard"?
any scheme for wrapped axes has to be per-axis
even max5 has one that wraps and one that doesn't
but you can still program every move that makes sense for the non-wrapped axis in the stuart mode
that's true but the nonstuart would be more natural for something that only moves part of a circle
so you're saying there are 6 gcodes in 3 modal groups, or are you saying that the meaning of G1 A-90 in stuart's mode is dependant on the inifile?
I don't like either of those things very much
I was thinking inifile to choose between the two modes of operation for a particular axis (current mode and stuart mode)
cradek: I wrote some words: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?WrappedRotaryAxes
does Gcode allow for anything other than degrees for specifying angles (such as radians or grads)
SWPadnos: we don't have modal codes for angular units
yeah, I didn't remember seeing any
right now in principle it's only degrees, though I don't think anything bad happens if you lie and make 1 = 1 radian or 1 = 1 grad
but I confused myself when thinking about the fact that ini files still have units for angular axes
it's true, they do
hmm - that isn't good
probably a windows update ;)
jepler: "The sign of a nonzero number is ... if it is zero."
not just being pedantic - I really don't undrstand what you meant
I bet strtod() can't tell us +0 vs -0
have to handle the sign separately
block.a_flag, block.a_number, block.a_sign
[23:25:44] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/signed.c
g++ signed.c && ./a.out -1 +1 -0 +0 0
signbit() is defined in c99
btw, I'm ready to go anytime
come on over if you want to help us assemble the blinds
it needs a smart person
how can I resist that -- oh, I know
pretty please? (from Ingrid)
oh you're serious? ok then.