Back
[01:24:58] <jmkasunich> powersaving can be really annoying when you are trying to profile something
[01:25:34] <jmkasunich> s/profile/time
[01:26:22] <jmkasunich> if I run 20 iterations of my perspective correction code, the speed jumps dramatically somewhere around the 15th time
[01:26:36] <jmkasunich> thats when the power management decides to turn the CPU clock up
[01:32:17] <jmkasunich> original implementation: 579mS per frame
[01:32:29] <jmkasunich> improved implementation: 14.7mS per frame
[01:40:37] <SWPadnos> that's an improvement :)
[01:40:42] <jmkasunich> yeah
[01:41:18] <jmkasunich> pre-calculating the "ray trace" part and using a lookup table took it down to about 66ms
[01:41:40] <SWPadnos> jepler, the hal_input patch makes the Tormach/Contour device almost work. there's still a missed "tick" at zero, because the dial is reported as relative so it doesn't output the zero position
[01:41:46] <jmkasunich> getting rid of the atan2, sin, and cos (rect to polar and back) did most of the rest
[01:41:49] <SWPadnos> (or the kernel doesn't report the event anyway)
[01:42:00] <SWPadnos> I can imagine
[01:42:12] <SWPadnos> I'd be curious to see what ImageMagick does with that problem
[01:42:41] <jmkasunich> how would you tell it the correction curve?
[01:42:43] <SWPadnos> there is a barrel distortion correction filter that could work, but I'm not sure how you'd get the coefficients
[01:43:00] <SWPadnos> there's a program to calculate them for you somewhere
[01:43:16] <SWPadnos> and you can experiment a little to get the right numbers once you're close
[01:43:29] <jmkasunich> given arbitrary optics dimensions? or given some images of a grid or something like that?
[01:43:52] <SWPadnos> some optics numbers I imagine
[01:44:07] <SWPadnos> but youcould take an image of a grid to see how the parameters work
[01:44:21] <SWPadnos> I think there are only two (other than the center XY)
[01:44:37] <jmkasunich> that seems not enough
[01:44:38] <SWPadnos> I briefly read about it, but have never used it
[01:45:09] <jmkasunich> maybe enough for "normal" barrel distortion, but not the extremes of a fisheye setup like this
[01:45:13] <SWPadnos> it's meant to flatten fisheye images, so it may not even do what you want
[01:45:40] <jmkasunich> my version detects rays that miss the mirror, rays that are angling up and never hit the floor, etc
[01:45:50] <SWPadnos> there may be assumptions about the direction of curvature (which I think may be different for your setup than a standard fisheye)
[01:46:27] <jmkasunich> did you ever notice how many times you rewrite things?
[01:46:35] <jmkasunich> I'm back in the frame grabber code now
[01:47:00] <jmkasunich> I want to do most of my processing in grayscale, so I'm adding "output a grayscale image" to my grabber routine
[01:47:11] <SWPadnos> heh
[01:47:29] <jmkasunich> then I get to revise the frame flattener to use 1 bpp instead of 3bpp (which should make it a bit faster ;-)
[01:47:41] <SWPadnos> 2 bits
[01:47:43] <SWPadnos> :)
[01:47:52] <jmkasunich> bytes per pixel
[01:48:03] <SWPadnos> oh, then it should be 2 bytes faster :)
[01:48:30] <jmkasunich> I figure the sooner in my pipeline I shrink the images, the better
[01:48:38] <SWPadnos> in general, yes
[01:58:29] <jmkasunich> SWPadnos: know any speedup tricks for RGB to grayscale conversion?
[01:58:55] <SWPadnos> SSE/MMX should help, but I don't know how :)
[01:59:12] <jmkasunich> the weighted sum approach with floating point weights seems a bit slow
[01:59:30] <jmkasunich> I'm not interested in assembly language level optimization (SSE, etc)
[01:59:43] <SWPadnos> one thing I do on microcontrollers is to do an integer multiply and then use the high word as my result
[01:59:48] <SWPadnos> kind of a fractional multiply
[01:59:56] <jmkasunich> yeah
[02:00:13] <jmkasunich> one place on the web has weights of 0.3, 0.59, and 0.11
[02:00:26] <SWPadnos> sounds close, if that's R,G,B
[02:00:29] <jmkasunich> 0.3, 0.6, and 0.1 would probably be plenty close for my purposes
[02:00:58] <jmkasunich> actually that doesn't help
[02:01:00] <SWPadnos> it makes no difference what the weights are, you just make sure the numbers add up to 1.0 (or higher if you want to brighten)
[02:01:35] <jmkasunich> what I want is integer weights that add up to a power of two (2^8 if using the high byte of a 16 bit var)
[02:01:40] <SWPadnos> how is the RGB data organized? 32-bit packed words, bytes, ...
[02:01:50] <jmkasunich> 3 bytes per pixel
[02:02:00] <jmkasunich> no alpha component
[02:02:03] <SWPadnos> ok, so 100 pixels occupies 300 bytes
[02:02:07] <jmkasunich> yeah
[02:02:14] <SWPadnos> instead of 400, with 1 byte unused
[02:02:22] <SWPadnos> (per)
[02:03:11] <SWPadnos> hmmm. I think the rubber band fell out of my hair and has now been snow-blown onto the lawn somewhere
[02:03:50] <jmkasunich> heh
[02:04:18] <jmkasunich> last sunday a non-trivial portion of the newspaper was snow-blown onto the lawn
[02:12:40] <jmkasunich> I'm going to assume that gcc is smarter than me regarding microoptimizations
[02:12:41] <jmkasunich> *dst = (78*src[0] + 150*src[1] + 28*src[2])/256;
[02:12:56] <jmkasunich> it should be able to decide the smartest way to multiply and divide by constants
[02:13:02] <jmkasunich> shifts, etc
[02:15:18] <jmkasunich> although I wonder - src and dst are both pointers to unsigned char... I bet it won't promote to integer, I might wind up with overflow of the intermediate
[02:17:24] <SWPadnos> and MMX would do all that in a single instruction
[02:17:35] <SWPadnos> (or SSE or 3dnow or something)
[02:17:57] <jmkasunich> this isn't so critical that I want to dip into assembly
[02:18:19] <jmkasunich> there are other portions of the code that will be more critical
[02:18:30] <jmkasunich> RGB to gray is done once per captured frame
[02:18:32] <SWPadnos> 8-bit values and multiply them by 4 other 8-bit values, storing the result in - you guessed it - 4 8bit values packed into a 32-bit register
[02:18:38] <SWPadnos> yep
[02:18:42] <jmkasunich> I'm going to be doing a lot more expensive things per image
[02:18:57] <SWPadnos> do you get the bytes individually from the camera, or is it a buffer of byte triplets?
[02:19:16] <jmkasunich> the video4linux driver does the nasty work
[02:19:20] <SWPadnos> I guess it would be bulk, since it's USB
[02:19:32] <SWPadnos> you may be able to ask v4l to give you a grayscale frame
[02:19:45] <jmkasunich> there is a buffer that is mmap'ed, the image winds up in there
[02:20:05] <SWPadnos> is this camera also a still camera?
[02:20:09] <jmkasunich> you can attempt to set a pallette, it may or may not succeed depending on what your camera/driver combo supports
[02:20:20] <jmkasunich> for this camera, grayscale doesn't succeed
[02:20:22] <SWPadnos> if so, it may work with gphoto
[02:20:36] <SWPadnos> oh. hmm
[02:20:39] <jmkasunich> in theory it is also a camera, but I've never used it that way
[02:20:58] <jmkasunich> anyway, I'm not gonna start over - the video4linux interface works fine
[02:25:16] <jmkasunich> that conversion formula works without any casts - the compiler must promote to int by default
[02:25:31] <jmkasunich> if I was jepler, I'd have probably known that already
[02:31:00] <jmkasunich> that's a little dissapointing - no change in the speed of the flattening routine when changed to grayscale
[02:31:16] <jmkasunich> (or at least no change that isn't swamped by other random variations)
[02:36:23] <SWPadnos> ok - you wouldn't be able to use imagemagick anyway, unless you compile it yourself or use Jaunty anyway :)
[02:36:40] <SWPadnos> (I need to get stuff done with IM, so I had to look anyway)
[02:37:15] <SWPadnos> how many times do you access each pixel in the distortion routine?
[02:39:23] <jmkasunich> depends on which pixel
[02:39:36] <jmkasunich> for each pixel in the output image, I compute which camera pixel should be used
[02:39:44] <jmkasunich> then I read the camera pixel and write the output pixel
[02:39:52] <jmkasunich> so output pixels get touched once
[02:40:19] <jmkasunich> camera pixels might be read more than once - near the edge of the image, multiple output pixels might map to one camera pixel
[04:00:48] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/pyvcp/blank.xml: move comment to be clear about where pyvcp code goes
[04:18:59] <jepler> jmkasunich: seems like you might decide to just take "G", if the colorspace conversion ends up being a problem.
[04:19:14] <jepler> otherwise, you could approximate the conversion using only shifts, except that's patented.
http://www.google.com/patents?id=QQobAAAAEBAJ&pg=PA2&source=gbs_selected_pages&cad=1_1#PPA3,M1
[04:23:28] <jepler> (in my tests, the shift-algorithm isn't any faster)
[04:23:40] <jepler> 'night
[04:24:55] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: remove debug print
[04:31:07] <SWPadnos> argh. Nikon software destroyed Firefox
[04:31:31] <SWPadnos> and didn't do any good either, so I removed it
[04:36:28] <cradek> "Unreachable arc in concave corner during cutter compensation would cause gouging"
[04:36:48] <cradek> is there a better wording for this? is it clear what "unreachable" means?
[04:37:31] <SWPadnos> does it mean "a spot beyond a choke point narrower than the cutter diameter"?
[04:37:43] <cradek> no
[04:37:58] <cradek> think a tiny arc in a 90 degree corner
[04:38:05] <cradek> the tool can't reach it without cutting one of the "walls"
[04:38:12] <SWPadnos> is it a small arc thats beyond the intersection of two offset lines?
[04:38:27] <cradek> not beyond the intersection - that would be fine
[04:38:48] <SWPadnos> then no, I'm not sure it's clear what it means :)
[04:38:53] <cradek> heh, I figured
[04:39:14] <SWPadnos> it's not a fillet with radius smaller than the cutter?
[04:39:23] <cradek> close
[04:39:29] <cradek> radius smaller than cutter is an automatic error
[04:39:42] <cradek> but this radius is bigger than the cutter
[04:39:59] <SWPadnos> ok, then pictures are probably better than words here
[04:40:05] <cradek> one sec
[04:40:12] <SWPadnos> (so others can help with words)
[04:41:15] <cradek> I bet it's an extremely unusual case but I detect it - explaining the problem to the user succinctly is another matter
[04:41:27] <SWPadnos> apparently :)
[04:41:39] <SWPadnos> though an actual user may understand better than me
[04:44:21] <cradek> http://timeguy.com/cradek-files/emc/unusual-error-condition.png
[04:44:31] <cradek> ignore the red and green, those are the origin
[04:44:57] <SWPadnos> ok, so it's another case of the tiny fillet problem
[04:45:03] <cradek> white is the path, the tool is following it from the right
[04:45:11] <cradek> notice the arc radius is not smaller than the tool
[04:45:15] <SWPadnos> yep
[04:45:22] <SWPadnos> could be a straight line even
[04:45:42] <cradek> but, if the tool moves into the bottom concave corner, it will gouge
[04:46:02] <SWPadnos> yes, I see that if the tool touches the "unreachable" segment, it will gouge
[04:46:03] <cradek> yes if it were a straight line, the error is different: "Motion in concave corner less than tool radius during cutter compensation would cause gouging"
[04:46:20] <cradek> that one might need more work too
[04:46:24] <SWPadnos> that's still accurate, isn't it?
[04:46:44] <cradek> very close
[04:47:20] <cradek> "motion ... less than" already sucks, I think
[04:47:28] <cradek> confusing arc length in there makes it worse
[04:47:57] <SWPadnos> "segment in concave corner is too small for cutter to reach without gouging" :)
[04:48:17] <cradek> is an arc a segment?
[04:48:21] <SWPadnos> sure
[04:48:29] <SWPadnos> an arc segment is anyway
[04:48:47] <cradek> too short?
[04:49:08] <SWPadnos> hmmm
[04:49:31] <SWPadnos> unreachable is a better word, but it's not obvious how to work it in there
[04:49:58] <cradek> it's not that there's anything wrong with the arc - if the move after it was different, it could be reached and cut around just fine
[04:50:30] <cradek> it's the whole situation of the arc and the corners it forms with both adjacent moves that's the problem
[04:50:34] <SWPadnos> sure, it just can't be touched when it's sitting in some concave corners
[04:50:46] <SWPadnos> same with short line segments
[04:50:55] <cradek> right
[04:51:15] <SWPadnos> the path is outside the cutter radius when it's tangent to the surrounding segments
[04:51:23] <SWPadnos> "it" being the cutter
[04:51:34] <cradek> that error is wrong isn't it - being lonver than a tool radius is no guarantee at all
[04:51:45] <cradek> (the straight move version of the error)
[04:52:22] <cradek> is being longer than a diameter always safe?
[04:52:26] <cradek> hmmm
[04:52:30] <SWPadnos> I think it's technically correct for anything smaller than 120 degrees or so (thinking of a hexagon)
[04:53:08] <SWPadnos> yes, I think so - if the other segments wouldn't cross "in front" of the segment in question
[04:53:14] <SWPadnos> ie, no bow tie shapes allowed
[04:53:52] <cradek> crossing in front means the tool will loop around the outside (remember we are doing "right" or "left", not "inside")
[04:54:11] <SWPadnos> I'm thinking of an ice cream cone shape
[04:54:19] <SWPadnos> or part of one
[04:54:47] <SWPadnos> but those are degenerate cases for other reasons
[04:55:16] <SWPadnos> so I think it holds that any segment >= the cutter diameter should be touchable
[04:55:36] <cradek> "Segment in concave corner is too short to be reachable by the tool and would cause gouging"
[04:56:03] <cradek> not really always a corner
[04:56:06] <cradek> but it is a concave 'area'
[04:56:30] <SWPadnos> yeah, I suppose you could have three arcs and have the same problem
[04:56:44] <cradek> yes and that is detected too
[04:57:17] <cradek> I'm leaning toward the more-vague error I just typed (for all the cases)
[04:57:49] <cradek> or I could say "arc motion in..." and "straight motion in..."
[04:57:58] <cradek> might be nice to know that info
[04:58:35] <SWPadnos> ok, I think that wording is clearer
[04:59:04] <SWPadnos> if you have separate cases for lines and arcs, then different wording is fine too
[04:59:08] <cradek> ERF(("Arc motion in concave corner is too short to be reachable by the tool and would cause gouging"));
[05:00:42] <SWPadnos> Arc move maybe
[05:00:45] <SWPadnos> and linear move
[05:01:14] <cradek> yes move is better than motion
[05:02:30] <cradek> the docs mix "linear" and "straight" unfortunately
[05:02:36] <cradek> not sure which to use
[05:02:38] <cradek> probably either is fine
[05:02:53] <SWPadnos> or pick one and eventually we can edit for consistency :)
[05:04:01] <cradek> ERF(("Arc move in concave corner too short to be reachable by the tool would cause gouging"));
[05:04:11] <cradek> fewer words - but is it clearer or worse?
[05:04:57] <SWPadnos> Arc move in concave corner is too short to be reached by the selected tool without gouging
[05:04:58] <cradek> it could be read as the 'corner' is too short (what?)
[05:10:17] <cradek> argh, it's not always detected right
[05:10:50] <cradek> trying to get "garbage in => error out" 100% right is so hard
[05:12:25] <SWPadnos> yes
[05:12:39] <SWPadnos> at least you have some good error text though, so that part's done :)
[05:13:16] <cradek> I think I grasp the remaining problem too
[05:13:23] <cradek> "the" haha
[05:14:23] <SWPadnos> heh
[05:38:36] <cradek> isnan error in emcTrajCircularMove
[05:41:12] <SWPadnos> urk
[06:41:33] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/ (4 files): detect the rest of the localized gouging cases (unreachable arcs in corners). give nice error messages.
[13:58:58] <KimK> cradek and SWPadnos: * Re:
http://timeguy.com/cradek-files/emc/unusual-error-condition.png * Rather than "unreachable", I think what you want is to say is something about the "future"?
[14:00:27] <KimK> Tool will gouge in future toolpath? Gouging will occur in subsequent move? Downstream toolpath cannot be reached without gouging?
[14:05:15] <KimK> In this type of error, will it always be followed (if the "future toolpath gouging"(?) error is allowed) by a conventional "inside corner too tight for tool" error? (I may not have considered every case you have generated.)
[14:09:55] <KimK> Hmm... Maybe the error text EMC2 should report is wrong in both cases? Maybe what EMC2 should say can be clarified (for easier "G-code troubleshooting"(?) ) by having just two error reports:
[14:13:50] <KimK> In the existing case of error due to inside corner too tight for tool, "Cutter comp error: Would not remove enough material"
[14:14:42] <KimK> In the new case of error due to future toolpath, "Cutter comp error: Would remove too much material"
[14:18:49] <KimK> Let EMC2 report whichever one it discovers "first". If the user corrects one error in the g-code, and that reveals another error, so be it. And the user should be able to see what is going on with the AXIS display, right?
[14:20:18] <KimK> Maybe the EMC2 error reports could include the point of first occurrence? "Cutter comp error: Would remove too much material beginning at XYZ whatever"
[14:21:36] <KimK> OK, I'll shut up now, LOL
[14:24:02] <BigJohnT> darn, cvs is down
[14:36:20] <KimK> cradek and SWPadnos: Oooh! Let AXIS finish the bad move on screen, filling the "not enough removed" / "too much removed" area in a different color? (Yeah, yeah, "let us know when you get it done", right? OK, now I'm shutting up for sure, LOL)
[14:47:42] <jepler> cvs service should be restored shortly. the machine cvs is hosted on crashed during the night.
[14:50:51] <BigJohnT> and like magic cvs is back :)
[15:00:24] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (gs2_panel.png pyvcp_scale.png xyz_buttons.png): add images
[15:07:03] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (pyvcp.lyx pyvcp_examples.lyx pyvcp_scale.png): move to images directory
[15:08:20] <BigJohnT> and some updates to pyvcp :)
[15:23:31] <jepler> Failed to remake target file `../docs/src/hal/pyvcp_scale.png'.
[15:23:57] <BigJohnT> opps
[15:24:08] <jepler> did you miss changing one in the lyx file?
[15:24:26] <BigJohnT> I bet I know where it is
[15:25:19] <jepler> or am I doing something wrong yet again
[15:26:07] <jepler> bbl, I'm hungry for breakfast
[15:26:12] <BigJohnT> nope I forgot about the _fr one
[15:28:57] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp_fr.lyx: fix broken link because I moved the image
[15:39:30] <jepler> oh that would explain it
[15:41:57] <BigJohnT> I am getting a bunch of errors during a make clean something to do with hostmot2 I think... they have scrolled off the terminal
[15:42:33] <BigJohnT> emc/rs274ngc/interp_queue.cc: In member function ‘int Interp::move_endpoint_and_flush(setup*, double, double)’:
[15:42:33] <seb_kuzminsky> if you pastebin the errors i'll take a look
[15:42:34] <BigJohnT> emc/rs274ngc/interp_queue.cc:483: warning: ‘y2’ may be used uninitialised in this function
[15:42:36] <BigJohnT> emc/rs274ngc/interp_queue.cc:482: warning: ‘x2’ may be used uninitialised in this function
[15:42:38] <BigJohnT> emc/rs274ngc/interp_queue.cc:481: warning: ‘y1’ may be used uninitialised in this function
[15:42:39] <BigJohnT> emc/rs274ngc/interp_queue.cc:480: warning: ‘x1’ may be used uninitialised in this function
[15:42:41] <BigJohnT> emc/rs274ngc/interp_queue.cc:440: warning: ‘y2’ may be used uninitialised in this function
[15:42:42] <BigJohnT> emc/rs274ngc/interp_queue.cc:439: warning: ‘x2’ may be used uninitialised in this function
[15:42:44] <BigJohnT> emc/rs274ngc/interp_queue.cc:438: warning: ‘y1’ may be used uninitialised in this function
[15:42:45] <BigJohnT> emc/rs274ngc/interp_queue.cc:437: warning: ‘x1’ may be used uninitialised in this function
[15:42:56] <BigJohnT> might not have been hostmot2 :/
[15:43:03] <BigJohnT> but just before it
[15:43:10] <seb_kuzminsky> ok whew!
[15:43:24] <seb_kuzminsky> the buildbot gets the same errors fwiw:
http://emc2-buildbot.colorado.edu/buildbot/builders/hardy-x86-trunk-realtime-rip/builds/432/steps/compile/logs/warnings
[15:43:26] <BigJohnT> it goes by so fast ...
[15:45:29] <BigJohnT> * BigJohnT wanders out to add wood to the fire in the shop heater
[15:53:54] <cradek> those are my fault - I know that stuff won't be used for other planes, but the compiler doesn't
[15:54:16] <BigJohnT> so does anyone know how to center up a led in a vbox in pyvcp?
[15:54:29] <BigJohnT> silly compiler
[15:55:35] <cradek> no big deal - I just have to either give an error or trick it (initialize them anyway)
[15:56:11] <cradek> I don't understand why I sometimes don't get those warnings. maybe I just miss them.
[15:58:04] <BigJohnT> I only get them when you edit the file or I do a make clean :)
[16:00:31] <skunkworks> it is funny that not ever being able to jog while paused - I don't seem to have a yearning
[16:01:12] <BigJohnT> seems like many do want to jog to set the z of a tool held by a collet for example
[16:01:23] <archivist> I do, currently I re run the gcode in its entirety
[16:01:56] <archivist> I jog 2 directions due to collets
[16:02:22] <archivist> and the third for diameter final accuracy
[16:22:44] <BigJohnT> does M60 allow you to jog? I see it is not spelled out what it allowed when stopped with M60...
[16:25:53] <BigJohnT> hmmm, nope
[16:27:28] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (pyvcp_borders.png pyvcp_labelframe.png): add images
[16:30:50] <BigJohnT> does M30/60 turn on a pin of some sort to start the pallet shuttle change?
[16:31:38] <cradek> I don't think pallet shuttle is implemented at all
[16:31:47] <BigJohnT> ok, thanks
[16:32:07] <SWPadnos> hmmm. Stuart should have complained about that :)
[16:32:13] <BigJohnT> btw cradek my new goldwing is suposed to get 40 to 45 mpg :)
[16:32:36] <SWPadnos> that's about the same as my old Plymouth Horizon got
[16:32:44] <cradek> you got another new goldwing?
[16:32:59] <BigJohnT> no I traded the black one in
[16:33:12] <BigJohnT> the black one was a 98
[16:33:34] <cradek> only new to you, then
[16:33:35] <skunkworks> did you actually drive the back one? I thought you had just gotten it ;)
[16:33:42] <BigJohnT> the blue one is a 2009
[16:33:53] <cradek> yeah it wasn't very long
[16:33:55] <BigJohnT> yea, I put about 3k miles on the black one
[16:34:12] <BigJohnT> I have 26 miles on the blue one
[16:34:36] <BigJohnT> picked it up Thursday
[16:35:59] <cradek> a friend of mine just bought a new car. seems like they are giving them away. if you can manage it (and need one), this is a good time.
[16:36:32] <BigJohnT> I'm looking at a Honda Civic Hybrid for the wife
[16:40:59] <BigJohnT> should I note in the manual that M30/60 at the present time is the same a M0/2
[16:47:27] <BigJohnT> http://powersports.honda.com/Assets/Models/2009_GoldWingAudioComfortNaviXMABS_2000x1275_MetallicBlue_42515B.jpg
[16:57:57] <jmkasunich> jepler: they patented shift/add? wtf?
[16:59:45] <jmkasunich> I derived basically the same thing in about 5 minutes, and discarded it guessing that shift/add isn't really that much faster than multiply by a const these days
[17:00:17] <jmkasunich> (at least on PC class hardware)
[17:01:52] <archivist> I have a feeling I have prior art in the form of a PCB behind me
[17:02:16] <archivist> we did a frame grabber
[17:07:28] <jepler> jmkasunich: yes, it looks that way
[17:09:12] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (pyvcp.lyx pyvcp_examples.lyx): more pyvcp updates
[17:09:17] <jmkasunich> it's so nice to have fast hardware and a good compiler
[17:09:47] <jepler> quite a luxury
[17:09:51] <jmkasunich> let's you focus optimization on algorithms, rather than cycle counting micro-optimizations that might change on the next CPU anyway
[17:10:56] <BigJohnT> we have come a long way since hot was 512k of memory and blazing was 640k
[17:11:05] <skunkworks> jmkasunich: is this still the rat trap powered compitition? or something new?
[17:11:12] <jmkasunich> something new
[17:11:15] <jmkasunich> every year is different
[17:11:19] <skunkworks> ah - neat
[17:11:29] <jmkasunich> this year we need to autonomously navigate a maze
[17:12:04] <BigJohnT> visual or physical boundries?
[17:12:13] <jmkasunich> vehicles will be impounded before the final maze is unveiled, no user input except a start button
[17:12:26] <jmkasunich> bigJohnT both, sort of
[17:12:29] <jmkasunich> no walls
[17:12:50] <BigJohnT> cliffs?
[17:12:52] <jmkasunich> but the "track" is 1/2" or so thick, so you could hang feelers over the side
[17:13:05] <jmkasunich> yeah, cliffs ;-) but only 1/2" hi
[17:13:13] <BigJohnT> cool
[17:13:21] <jmkasunich> there are also black lines along the edges and along the centerline of the track
[17:13:30] <BigJohnT> so it has to learn somewhat to find the way out
[17:14:14] <jmkasunich> yeah
[17:14:48] <jmkasunich> they are encouraging learning - scoring is (total_time_in_maze/30) + (time_of_fastest_start_to_finish_run)
[17:14:50] <jmkasunich> low points wins
[17:15:17] <jmkasunich> so if you can explore, then go back to start and do a speed run, you can do better than someone who just explores till they find the goal
[17:15:50] <jmkasunich> http://jmkasunich.com/pics/aMazingRaceSampleMaze.pdf
[17:16:04] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Stepper_Diagnostics.lyx: fix funny lines that show up in html
[17:18:00] <BigJohnT> ok, more than one way to solve the puzzle...
[17:18:05] <jepler> jmkasunich: what's your "unfisheye" code look like? the simplest inner loop seems to me to be something like for(int i=0; i<NPIXELS; i++) { *out++ = in[*map++]; }, assuming you precompute 'map', which says what input pixel offset for each output pixel.
[17:18:54] <jmkasunich> I didn't want to precompute a full-size translation map
[17:19:31] <jmkasunich> since it would be close to 500K bytes
[17:19:37] <jepler> yeah, it will be outside of cache
[17:20:04] <jmkasunich> given a dest pixel, I compute the radial distance from the center of the image (hypot)
[17:20:30] <jmkasunich> then that distance goes to a lookup table that gives me the a scale factr
[17:20:32] <jmkasunich> factor
[17:21:04] <jmkasunich> the dest x & y are multiplied by that to get the src x and y
[17:21:40] <jmkasunich> I also do a rotation matric at the same time, so I can rotate the camera image to line up with my "map"
[17:22:15] <jmkasunich> if the vehicle happens to be going north-east, I still want north up on the images I am working with
[17:22:27] <jepler> makes sense
[17:23:35] <jmkasunich> the real computation hog is gonna be correlation
[17:23:37] <jepler> and you can't do that in a single step with a fixed 'map'
[17:24:06] <jepler> (the rotation, I mean)
[17:24:22] <jmkasunich> given a large image called "field" and a smaller one called "target", find the best fit (if any) of target in field
[17:25:03] <jmkasunich> I'm trying to design the imaging pipeline such that I only need to do 1D correlations
[17:25:18] <jmkasunich> target and field are the same height, but target is narrower
[17:27:05] <jmkasunich> the basic correlation value for any particular alignment of target and field is the sum of target_pixel * field_pixel over the entire area of target
[17:27:26] <jmkasunich> pixel values are signed - +127 = white, -127 = black, 0 = ignore this pixel
[17:29:00] <jmkasunich> the naive approach is to calculate a correlation sum for the entire target at one offset, then at another offset, etc, the highest sum = the best offset
[17:29:06] <jmkasunich> but that would thrash cache
[17:29:47] <jmkasunich> instead if I'm doing N offsets, I want to calculate N sums for one target pixel, then move to the next target pixel, update the N sums, etc
[17:30:22] <jmkasunich> the N sums + one line of the field image + one pixel of the target image will fit in cache a lot nicer
[17:33:35] <jepler> yeah
[17:36:29] <jmkasunich> correlation is still O(H*Wt*(Wf-Wt)) though H = height of both images, Wt = width of target, Wf = width of field
[17:36:43] <jmkasunich> that's more or less N^3 - ick
[17:37:12] <jmkasunich> a 2D version would be N^4
[17:38:28] <jepler> http://en.wikipedia.org/wiki/Phase_correlation
[17:38:33] <jepler> "In image processing, phase correlation is a fast frequency-domain approach to estimate the relative translative movement between two images."
[17:39:06] <jmkasunich> yeah, I read that page - the idea is appealing
[17:39:37] <jmkasunich> http://www.fftw.org/ would handle the FFTs
[17:48:54] <cradek> ahh I bet I see why I don't get those warnings. I'm using -O0.
[17:53:14] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/Makefile: emacs says this line was suspicious because of the spaces, but I doubt gnu make cares one bit
[17:59:00] <cradek> BigJohnT: the docs sometimes say 'straight' (feed/move/traverse) and sometimes say 'linear'. which term should I use in an error message?
[17:59:39] <BigJohnT> straight seems more straitforward to me
[17:59:52] <cradek> ok, will do
[17:59:57] <BigJohnT> straightforward
[18:01:05] <SWPadnos> linearforward
[18:01:10] <SWPadnos> doesn't work as well
[18:09:58] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_queue.cc: fix warnings, cleanup and commenting
[19:17:38] <KimK_> KimK_ is now known as KimK
[20:42:58] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.py stepconf.glade): change xyzbutton pyvcp example
[20:45:08] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/configs/common/configurable_options/pyvcp/xyzjog.xml: change xyzbutton pycvp example
[22:48:19] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: splain a bit more on g2/3 and a few minor edits
[22:51:03] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: minor edits
[22:53:45] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/halui.lyx: fix typo Chris M. spotted
[23:07:19] <cradek> currently, saved G92 offsets are applied when EMC starts. They are unapplied when M2/M30 is reached. This means that if you use G92 offsets, the first and subsequent runs of a program are different. This baffles users until they learn not to use G92. How should it work?
[23:16:12] <BigJohnT> hmmm
[23:16:47] <BigJohnT> seems like it should be consistant between runs
[23:17:26] <BigJohnT> I would think that unless the G92 is in the g code don't apply it...
[23:17:28] <cradek> if it stays after m2/m30, it seems fairly sane (expermineting with that now)
[23:19:51] <cradek> a much bolder change would be to make G92 actually set the coordinates of the active G5x system
[23:20:20] <cradek> right now it is an additional offset that applies on top of all G5x systems
[23:22:20] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl): add pyvcp examples to html
[23:23:02] <BigJohnT> there is so many ways to offset it makes my head spin :/
[23:23:13] <cradek> agreed
[23:25:54] <BigJohnT> I use g92/g92.1 in my plasma cutter but I make sure I do a G92.1 at the end of the file
[23:26:48] <BigJohnT> I would think that a pop up warning about a g92 offset at start up with a choice to delete it would be good
[23:26:49] <cradek> I've done that too in lathe code. take a couple facing passes, G92 Z0, rest of program, G92.1
[23:27:52] <BigJohnT> yea, I move to my start point and the G92 makes the code universal so to speak
[23:28:39] <cradek> the least invasive change that might make people less confused is to leave g92 alone at m2/m30, and continue to load it at startup
[23:28:41] <BigJohnT> If I cut a whole bunch of parts then I add a move to the next start position before the G92.1 and the end of the file
[23:29:18] <cradek> that sounds very clever. you just don't care where you are, I suppose
[23:29:45] <BigJohnT> just so I'm over some material and there is enough to finish the part I'm ok
[23:30:04] <cradek> so you don't use g54, touchoff, etc
[23:30:10] <BigJohnT> nope
[23:30:55] <cradek> that makes a lot of sense for plasma. for a mill, not so much
[23:30:56] <BigJohnT> I throw a piece of plate up there, attach the ground, jog to where I want to start and hit go!
[23:31:06] <BigJohnT> exactly
[23:31:39] <BigJohnT> when I mill I zero the X Y Z axis then hit go
[23:32:22] <cradek> if I made the bold change, I don't know what g92 would do
[23:32:27] <cradek> errr
[23:32:37] <cradek> if I made the bold change, I don't know what g92.1/g92.2 would do
[23:32:56] <BigJohnT> I think it would be good to at least advise folks at start up that a g92 offset is/will be applied
[23:32:56] <cradek> they could be removed maybe
[23:34:15] <cradek> do you mean just document it?
[23:34:26] <BigJohnT> no a pop up warning
[23:34:43] <BigJohnT> just in case you forgot
[23:35:06] <cradek> wellllll I think of that sort of thing as nagging. we don't warn them about g54
[23:35:37] <BigJohnT> would it be normal to leave a g92 in place when you shut down emc?
[23:35:45] <cradek> if that's what I wanted I can imagine muttering to the program: I KNOW THIS, just like I knew it the last thousand times you told me! :-)
[23:36:08] <BigJohnT> like quickbooks!
[23:36:31] <cradek> BigJohnT: what do you mean by normal?
[23:37:37] <BigJohnT> I can only go on how I use it with my plasma and I "make sure" I do a g92.1 before the end of the file so I don't get suprised
[23:38:01] <BigJohnT> I guess I'm thinking when would you want to leave it in at shutdown?
[23:38:19] <cradek> if you used it to locate some workpiece
[23:38:25] <cradek> workpiece is still there
[23:38:45] <BigJohnT> that makes sense...
[23:39:22] <BigJohnT> your doing a 12 hour job and you do 1/2 and the power goes out while your having a pint...
[23:39:41] <BigJohnT> you come back and you don't want to zero again...
[23:39:53] <cradek> you should have used g54...
[23:40:12] <BigJohnT> yep
[23:40:19] <cradek> that's my struggle. I don't like there being two ways
[23:40:28] <cradek> maybe I shouldn't change it, I dunno
[23:41:11] <BigJohnT> well we can say that the G92 is for things that make sense for it and the g54 is for fixtures and multi vise setups
[23:41:41] <BigJohnT> g54 for things that don't change between setups and g92 for things that do change....
[23:42:10] <BigJohnT> btw, I'm abbynormal
[23:46:55] <BigJohnT> I would change the g92 to not load up on boot up and leave it not in after a m2/30... and I'll elaborate in the manual what each is used for
[23:48:35] <cradek> I think I will make m2/m30 not do g92.2 equivalent and leave all other boldness for another day
[23:48:53] <BigJohnT> ok
[23:49:07] <cradek> I don't see any big drawback - if we think of one, we can take it back out
[23:50:47] <BigJohnT> the only drawback is if you think it needs to change before 2.3 comes out... times a wasting
[23:51:15] <cradek> I don't understand
[23:51:54] <BigJohnT> you don't want to change it after 2.3 right? confuse people
[23:52:06] <cradek> right, now is definitely the time
[23:54:49] <BigJohnT> I like bold, go ahead and change it so saved g92 offsets don't get loaded at boot up :)
[23:55:45] <BigJohnT> it makes sense even to a redneck
[23:56:10] <CIA-1> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: don't unapply g92 offset (like g92.2) at m2/m30.
