Back
[00:21:02] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/drivers/hostmot2.lyx: programmer speak translation
[00:22:33] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Glossary.lyx: add instance entry
[00:25:26] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: minor cleanup
[00:26:13] <BigJohnT> say goodnight Gracie
[00:40:50] <jepler> greetings from just outside the everglades (florida city)
[00:40:55] <jepler> all is well but the net access gets spotty
[00:42:19] <skunkworks> Nice :) what is next?
[00:42:41] <SWPadnos> remember to look for coconut-heads
[00:43:24] <SWPadnos> (that's what we started calling manatees, because an everglades tour guide said their heads look like coconuts on the water :) )
[00:52:47] <jepler> haven't seen them yet
[00:53:16] <SWPadnos> we only spotted one
[00:53:18] <jepler> we were told there were some out in the bay by flamingo park in the everglades, but we didn't find them ourselves
[00:53:37] <SWPadnos> in a river near the road, on the way back from our "everglades eco-safari" thingy
[00:53:55] <jepler> neat
[00:54:10] <jepler> we didn't do any "slogging", just dry trails with good birdwatching
[00:54:12] <jepler> and gators
[00:54:17] <SWPadnos> heh
[00:54:31] <SWPadnos> we didn't see many of those, it was surprising
[00:54:54] <jepler> we saw two dozen over the course of the day
[00:55:01] <SWPadnos> cool
[00:55:03] <SWPadnos> ish
[00:55:51] <SWPadnos> you'll be getting back, and I think skunkworks and I are both leaving for next week
[00:56:09] <jepler> oh well have good trips
[00:56:22] <jepler> that's right, I heard where sam was going. what about you?
[00:56:22] <SWPadnos> thanls, you too :)
[00:56:27] <SWPadnos> Honolulu
[00:56:51] <jepler> cool .. or warm
[00:56:55] <SWPadnos> oh right - he's off to Vegas
[00:57:03] <SWPadnos> yeah, it should be one or the other
[00:57:04] <jepler> I keep saying to Ingrid about the weather here: this is the cool season !?
[00:57:17] <SWPadnos> what's it like right now?
[01:01:58] <jepler> dark
[01:02:01] <jepler> it cooled off as well
[01:02:09] <jepler> and in this coffee shop it's over-airconditiond
[01:02:17] <SWPadnos> ah
[01:02:21] <jepler> we're wearing our jackets, in fact
[01:02:35] <SWPadnos> weather underground said ~80s for the highs
[01:02:37] <jepler> during the day it was in the upper 70s. mostly clear and very bright
[01:02:52] <jepler> could have been 80s, I'm not sure
[01:02:54] <SWPadnos> yeah, the south makes me want to wear sunglasses
[01:03:00] <SWPadnos> as does the snow :)
[01:03:18] <SWPadnos> hmmm. wifey calls. see you later. enjoy your trip
[01:03:28] <jepler> see you
[01:03:30] <jepler> likewise
[03:19:15] <cradek> wonder if we should/could move the schedule up. the stabilization seems pretty much done.
[03:19:48] <cradek> I guess by that I mean it seems like I'm not finding stuff to fix anymore
[03:22:09] <skunkworks> you guys do good work :)
[03:29:13] <SWPadnos> does anyone remember which recent kernel "just doesn't work with RTAI"?
[03:29:17] <SWPadnos> was it 2.6.27?
[03:37:30] <cradek> sorry, no idea
[03:53:18] <SWPadnos> ok
[03:53:39] <SWPadnos> I thought Alex had mentioned something about some recent kernel not working at atll, but the next version being fine
[03:54:02] <cradek> sounds typical in my experience
[03:54:40] <SWPadnos> heh
[03:55:29] <SWPadnos> this is so funny. I have an ad with the following quote:
[03:55:49] <SWPadnos> "Save over $200 and cost-effectively ensure greater success for your business"
[03:56:02] <SWPadnos> this is junk mail from DirecTV
[03:56:27] <SWPadnos> I'm just wondering how satellite TV, with hundreds of digital channels, could ensure greater sucecss for my business
[09:09:23] <rob> rob is now known as Guest84261
[13:12:07] <skunkworks_> logger_dev: bookmark
[13:12:07] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-02-19.txt
[17:19:57] <SWPadnos> hmmm. sim/axis doesn't run for me now (on my jaunty testbed)
[17:20:45] <SWPadnos> I wonder if I have gdb installed so I can look at the coredump
[17:22:24] <SWPadnos> I wonder if the coredump was actually written
[17:24:49] <cradek> what part crashes?
[17:26:13] <SWPLinux> steve@jauntyA3:/Project/emc2/src$ emc -l
[17:26:15] <SWPLinux> EMC2 - pre-2.3 CVS HEAD
[17:26:17] <SWPLinux> Machine configuration directory is '/Project/emc2/configs/sim'
[17:26:18] <SWPLinux> Machine configuration file is 'axis.ini'
[17:26:20] <SWPLinux> Starting EMC2...
[17:26:22] <SWPLinux> alloc: invalid block: 0x7ffe3fde7558: 0 0 0
[17:26:24] <SWPLinux> /Project/emc2/scripts/emc: line 637: 24228 Aborted (core dumped) $EMCDISPLAY -ini "$INIFILE" $EMCDISPLAYARGS $EXTRA_ARGS
[17:26:42] <SWPadnos> I probably need to configure something so I actually get a core dump - I can't find the core file
[17:26:59] <cradek> ulimit -c unlimited
[17:27:36] <SWPLinux> thanks
[17:27:45] <SWPLinux> and it conveniently ends up in configs/sim/core ;)
[17:36:58] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: hiding new functionality by default is a disservice to users. allow reasonable override values by default.
[17:47:27] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: remove the other two (!) places that each of these defaults was hardcoded.
[18:54:22] <cradek> I'm so proud of myself for deleting the sentence about "crack monkey" from my commit message
[18:59:30] <skunkworks_> heh
[19:02:07] <seb_kuzminsky> http://crackmonkey.org/crackdeb.jpg
[19:02:52] <cradek> yep that's about the picture I had in my mind
[19:08:10] <SWPLinux> hmmm. I don't immediately see how to look at this core file (in a meaningful way) with gdb
[19:09:28] <SWPLinux> I can get a backtrace, but there are no symbols. (do I need to install some python-*-symbols package??)
[19:09:38] <cradek> gdb /program/that/made/the/core core
[19:09:54] <cradek> if there are no symbols, the binary may have been stripped, and you're not going to get much out of it
[19:10:00] <SWPLinux> except that axis is a script, so it complains that it's not elf format
[19:10:05] <cradek> system binaries in debs are usually stripped
[19:10:17] <cradek> then the program that dumped core was /usr/bin/python or so
[19:11:59] <SWPLinux> ah, ok
[19:13:32] <SWPLinux> http://pastebin.ca/1342165
[19:13:45] <SWPLinux> I think this tells me that it's too deep for me to figure out ;)
[19:14:18] <SWPLinux> it used to work, so it's probably some screwage with the daily 100-200M of updates
[19:14:19] <cradek> lovely
[19:14:21] <SWPLinux> heh
[19:14:32] <SWPLinux> I could probably install symbols for tcl/libc6/...
[19:14:33] <cradek> does gl still work?
[19:14:49] <SWPLinux> yes, glxgears runs fine
[19:15:56] <jmkasunich> jmkasunich resembles
http://crackmonkey.org/crackdeb.jpg right now
[19:15:57] <SWPLinux> oh interesting. my eyes skipped right over the togl line in the backtrace
[19:16:01] <SWPLinux> heh
[19:16:12] <skunkworks_> * skunkworks_ looks at the clock...
[19:16:15] <jmkasunich> working on this crazy eweek robot
[19:16:31] <skunkworks_> when is the deadline?
[19:17:10] <jmkasunich> 9am tomorrow
[19:17:16] <jmkasunich> I took the afternoon off
[19:17:17] <cradek> eek
[19:17:51] <jmkasunich> last night (at 3am) it traversed the maze using the camera to stay on the road - but I had to tell it where the road is
[19:18:00] <jmkasunich> today's mission - to discover the road
[19:18:05] <cradek> jeez
[19:18:10] <cradek> sounds like a big part remaining
[19:18:29] <jmkasunich> to a degree, but there is a ton of "infrastructure" that is already done
[19:18:45] <jmkasunich> all possible road intersections are defined, the in-memory model of the maze is defined and tested, etc
[19:19:14] <jmkasunich> and much of the image proceesing that worked for road following will also be reused
[19:19:30] <cradek> do you think anyone else is going to have a successful run? totally autonomous is the rule?
[19:19:40] <jmkasunich> totally autonomous is the rule
[19:19:46] <jmkasunich> and plenty of other folks will succeed
[19:19:51] <cradek> wow...
[19:19:54] <jmkasunich> because they didn't decide to use cameras
[19:19:58] <cradek> your coworkers are not like mine :-)
[19:20:08] <jmkasunich> there is apparently a commercial/kit thing made just for tasks like this
[19:20:22] <cradek> line/edge following seems like the only other approach
[19:20:27] <SWPadnos> the hard part for path discovery is probably going to be dealing with areas that haven't been seen yet
[19:20:29] <jmkasunich> about a 4" round PC board, with 5? optical sensors on the bottom, and motor driven wheels on the sides
[19:20:48] <SWPadnos> sure, all you need is a couple of optos on each side, plus a couple more for front/back
[19:21:05] <SWPadnos> but you get no knowledge of "distant edges" like you do with a camera
[19:21:08] <jmkasunich> I think 3 or 4 teams are using those
[19:21:17] <jmkasunich> well, for me distant is about 20"
[19:21:23] <SWPadnos> better than 3" ;)
[19:21:26] <jmkasunich> I can see out to 22", but things get muddy that far out
[19:21:27] <jmkasunich> yeah
[19:21:29] <SWPadnos> it's also almost two "grids"
[19:21:29] <cradek> you should have a huge speed advantage if you can manage
[19:21:35] <skunkworks_> that seems like cheating..
[19:21:38] <jmkasunich> not so much on the speed
[19:21:48] <jmkasunich> the little round things skoot along pretty good
[19:21:55] <jmkasunich> no mass to speak of
[19:22:00] <cradek> seems hard to do that without overshooting corners
[19:22:09] <jmkasunich> they can stop on a dime
[19:22:25] <cradek> formidable :-)
[19:25:45] <cradek> I would have made a format of maze that the commercial doohickeys couldn't follow, but I'm just difficult that way
[19:26:23] <jmkasunich> found it:
http://www.pololu.com/catalog/product/975
[19:26:38] <jmkasunich> in action:
http://www.youtube.com/watch?v=mJV-KDqHgDQ
[19:28:11] <cradek> follow-left-wall
[19:28:31] <jmkasunich> that alone won't work for our contest - the maze _will_ have loops
[19:29:04] <cradek> does the pololu handle that? I don't see how it could.
[19:29:13] <cradek> I guess if it knows there are square corners...?
[19:29:41] <jmkasunich> the stock programming won't, but it can be extended
[19:29:48] <cradek> ah
[19:30:03] <jmkasunich> if it was just a matter of using the stock programming, it wouldn't be a contest
[19:30:23] <cradek> sure
[19:31:17] <jmkasunich> our maze has 90 degree corners, and is on a coarse grid
[19:31:21] <cradek> but it sounds like today you're where they all started (you can follow stuff)
[19:31:42] <jmkasunich> yeah, I guess
[19:32:00] <jmkasunich> if I had known about that pololu I probably wouldn't have taken the path I did
[19:32:23] <jmkasunich> I didn't want to fight with finicky sensors ;-)
[19:32:45] <jmkasunich> I've seen the pololu get confused by bumps in the road, or small gaps between sections
[19:33:03] <jmkasunich> and if I was doing my own from scratch, that would probably be 10x worse
[19:33:51] <jmkasunich> I should shut up and code....
[19:34:12] <BJT-Work> good luck jmkasunich
[19:34:18] <cradek> yes
[19:35:28] <jmkasunich> thanks
[19:35:56] <BJT-Work> may the force be with you :)
[19:36:08] <BJT-Work> * BJT-Work heads out
[20:26:51] <rob> rob is now known as Guest15571
[21:03:45] <Guest15571> Guest15571 is now known as robh_
[21:19:20] <jmkasunich> programming challenge: given an angle in floating point degrees, what is the simplest way to reduce it to integer quadrants (0 = -45 to +45 deg, aka north, 1 = +45 to +135 deg, aka east, etc)
[21:19:39] <jmkasunich> I want 0, 1, 2, 3, for any value of theta, including thetas that may represent many revolutions
[21:19:53] <jmkasunich> language is C
[21:20:15] <cradek> two calls to fmod?
[21:20:21] <jmkasunich> there has to be something better than this cruft that I came up with:
[21:20:22] <jmkasunich> // remove any windup
[21:20:22] <jmkasunich> theta = fmod(guess->theta, 360.0);
[21:20:22] <jmkasunich> // make sure it's positive
[21:20:22] <jmkasunich> theta += 360.0;
[21:20:22] <jmkasunich> // round to nearest quadrant
[21:20:24] <jmkasunich> dir = nearbyint(theta/90.0);
[21:20:26] <jmkasunich> // deal with >= 360 degrees
[21:20:28] <jmkasunich> dir &= 3;
[21:20:45] <jmkasunich> dir is an int, theta is a double (as is guess->theta)
[21:21:21] <jmkasunich> I wrote even worse cruft at 3am last night, after what I thought was a straightforward implementation gave incorrect results
[21:21:57] <jmkasunich> the first fmod can give anything from -359.9999 to +359.999
[21:22:48] <cradek> yuck, mod(negative) always causes suckage
[21:22:54] <jmkasunich> yeah
[21:23:32] <cradek> if yours is tested and works right, I'd go on, doubt you'll do a whole lot better
[21:23:44] <jmkasunich> yeah, it just irks me
[21:24:08] <cradek> optimize last, if you have time...
[21:24:18] <jmkasunich> its not even an optimization
[21:24:28] <jmkasunich> its not in an inner loop or anything
[21:25:56] <jmkasunich> I was actually googling a different rounding problem (that doesn't have the mod issues that angles do), and thought some of the functs I ran across would help my cruft from last night
[21:26:08] <jmkasunich> you're right, I shouldn't get distracted from the actual problem at hand
[21:32:50] <SWPadnos> jmkasunich, asin, acos, atan take <15 clocks on the core2 duo (which the atom is similar to)
[21:33:11] <SWPadnos> you may be anti-optimizing by trying to do with logic and formulas
[21:33:19] <jmkasunich> I'm not doing sin, cos, etc
[21:33:38] <jmkasunich> I have a lot of code that cares which of the four cardinal directions I'm (nominally) traveling in
[21:33:40] <SWPadnos> oh, right. you already have an angle
[21:34:02] <jmkasunich> for example, if I'm going east or west, I correct Y based on my cross-track error, if going north or south, I correct x
[21:37:40] <cradek> quadrant = ((signbit(sin(theta)) <<1) | signbit(cos(theta)))
[21:38:15] <jmkasunich> lol - I like that
[21:38:32] <jmkasunich> I'm sure the C library has highly optimized quadrant code
[21:38:41] <jmkasunich> its a shame you have to call the lib twice to use it tho
[21:38:50] <SWPadnos> plus/minus an offset since you want -45 to +45 to be one quadrant, etc.
[21:39:00] <jmkasunich> right
[21:39:11] <SWPadnos> quadrant = ((signbit(sin(theta+45) <<1) | signbit(cos(theta+45)))
[21:39:43] <jmkasunich> or something based on magnitudes of cos and sin
[21:40:01] <jmkasunich> if fabs(cos) > fabs(sin), then .....
[21:40:15] <jmkasunich> that deals with the offsets automagically, since they are == at 45 deg
[21:40:31] <cradek> geektrap!
[21:40:33] <SWPadnos> true, though you lose which side you're pointing at
[21:40:35] <SWPadnos> heh
[21:40:40] <SWPadnos> at least there are not buses on IRC :)
[21:40:48] <SWPadnos> no
[21:41:58] <jmkasunich> SWPadnos: right - for quadrants, you'd need to use the signs as well as the comparison result
[23:23:51] <jmkasunich> these makefiles are killing me
[23:24:35] <jmkasunich> aren't RT components (like siggen) built even with --enable-simulator?
[23:24:48] <SWPadnos> yes
[23:24:56] <SWPadnos> but not drivers
[23:25:37] <jmkasunich> right
[23:25:53] <jmkasunich> I have a custom component (c, not comp, and not a driver)
[23:26:02] <jmkasunich> I was going nuts because it didn't seem to be building
[23:26:15] <jmkasunich> turns out I did the last half hour of edits (on that file only) in another tree
[23:26:23] <jmkasunich> too many files in too many places
[23:26:24] <SWPadnos> heh
[23:26:33] <SWPadnos> you can use comp for C components also
[23:26:48] <SWPadnos> sudo comp --install doodad.c
[23:26:59] <SWPadnos> you don't need a full make/build
[23:27:22] <SWPadnos> (or --compile, you don't have to install)
[23:28:00] <jmkasunich> too many hoops to jump thru
[23:28:08] <jmkasunich> it was easier to start with a working c file
[23:28:13] <jmkasunich> that is water under the bridge anyway
[23:28:18] <jmkasunich> I'm still going nuts here
[23:28:59] <jmkasunich> I can't tell where the heck the build is fetching its source files from
[23:29:15] <jmkasunich> I mv'ed a directory two days ago, and it seems like there are still vestiges of that borking things up
[23:29:20] <jmkasunich> I can't deal with thsi right now
[23:29:24] <SWPadnos> oh. yeah
[23:29:55] <SWPadnos> you may need to remove the configure cache and re-configure
[23:30:18] <SWPadnos> ./configure detects some paths, especially for RIP
[23:31:31] <jmkasunich> I've reconfigured several times - what is this configure cache of which you speak?
[23:32:05] <SWPadnos> hmm - one sec
[23:32:35] <SWPadnos> config.status maybe?
[23:33:14] <SWPadnos> yep - config.h, config.status, config.log, and config.status.lineno all have the path in them somewhere
[23:33:33] <jmkasunich> just rm those buggers and re-run configure?
[23:33:35] <SWPadnos> in addition to some other generated files of course
[23:33:48] <SWPadnos> I think so - and maybe only config.status
[23:33:52] <jmkasunich> there ought to be ./configure --clean
[23:34:05] <SWPadnos> there probably is, I just don't know how to spell it :)
[23:40:07] <jmkasunich> arrgh
[23:41:25] <SWPadnos> ?
[23:42:24] <jmkasunich> I have no idea what is going on
[23:42:32] <jmkasunich> and I have no time to figure it out
[23:42:53] <jmkasunich> I looked at a normal EMC realtime C component - siggen
[23:43:37] <jmkasunich> my component "james.c" (it does low-level driving stuff, like "home, James" the chaueffer), has exactly the same lines in the Makefile as siggen (with the name changed of course)
[23:43:44] <jmkasunich> but siggen builds and james doesn't
[23:43:55] <jmkasunich> I get "depending siggen" after a make clean, but not "depending james", etc
[23:44:21] <jmkasunich> I have removed config.h, config.status, and config.log, redone the configure (more times than I can count)
[23:44:52] <SWPadnos> strange
[23:45:02] <SWPadnos> the only place I see siggen referred to is in Makefile
[23:45:07] <jmkasunich> * jmkasunich <--- stressed
[23:45:17] <SWPadnos> on 3 places
[23:45:25] <SWPadnos> heh, yeah - I can tell :)
[23:46:05] <jmkasunich> yup, three places
[23:46:17] <jmkasunich> grep siggen and grep james return lines that differ only in the name
[23:46:55] <jmkasunich> jmkasunich@mahan:~/emcdev/maze/src$ find -name siggen*
[23:46:55] <jmkasunich> ./hal/components/siggen.c
[23:46:55] <jmkasunich> ./depends/rthal/components/siggen.d
[23:46:55] <jmkasunich> jmkasunich@mahan:~/emcdev/maze/src$ find -name james*
[23:46:55] <jmkasunich> ./hal/components/james.c~
[23:46:56] <jmkasunich> ./hal/components/james.c
[23:46:58] <jmkasunich> j
[23:47:13] <jmkasunich> the file is in the right directory tree (I think that was the stress talking earlier)
[23:47:23] <SWPadnos> heh
[23:48:02] <SWPadnos> have you tried a new shell?
[23:48:11] <SWPadnos> in case some emc-environment is crufty or something
[23:48:26] <jmkasunich> trying
[23:49:18] <SWPadnos> and presumably you've done make clean almost as many times as ./configure ...
[23:50:33] <jmkasunich> more
[23:51:55] <jmkasunich> no change
[23:52:08] <jmkasunich> this is killing me
[23:52:13] <SWPadnos> comp --compile james.c
[23:52:25] <SWPadnos> if you have emc2-dev installed, that should just work
[23:53:16] <jmkasunich> even tho its not a .comp file?
[23:54:39] <jmkasunich> well that did make it compile (and spew forth the dozens of errors I was expecting)
[23:55:11] <jmkasunich> thats how I spotted the problem in the first place - I made some changes I knew weren't complete and did a build, and got no errors or warnings
[23:59:54] <jmkasunich> I was doing ok before this mess started, now my stack is so blown I don't even know what I was writing
