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