Back
[00:39:21] <micges> jepler: in simulator mode in which file rtapi_app is started?
[00:41:43] <cradek> when using halrun I notice it gets started only at the first loadrt
[00:41:53] <cradek> so no script file starts it
[00:48:10] <micges> oh I see
[00:48:17] <micges> thanks
[00:55:05] <Dave911_> Dave911_ is now known as Dave911
[03:37:10] <Dave911_> Dave911_ is now known as Dave911
[05:57:50] <Dave911_> Dave911_ is now known as Dave911
[12:55:20] <jthornton> hmm, looks like shift left, right, up, down, pg up, pg dn does not work in 2.3.4
[13:00:40] <jthornton> in Axis
[13:05:28] <CIA-62> EMC: 03jthornton 07master * rcf07f2595033 10/docs/src/gui/axis.lyx: Add info on feed override keys and a few markup fixes
[14:59:26] <jepler> jthornton: shift-jog is not in 2.3 as far as I know. cradek committed it on master 2009-04-29 d104b69dcef52fef89a691fc8c37affb38eba731
[15:12:13] <cradek> strange - I don't remember adding that and I don't think I've ever used it.
[15:30:59] <jthornton> ok, I just noticed it when working on the 2.4 manual and it didn't click that I was running 2.3 and looking at 2.4 :)
[17:13:17] <CIA-62> EMC: 03jepler 07master * r6ec54367dfe8 10/src/emc/usr_intf/pncconf/pncconf.py: pncconf: avoid problems with comma-using locales
[17:13:29] <CIA-62> EMC: 03jepler 07master * r31ea441cefef 10/src/autogen.sh: make autogen bail after a failure
[17:34:39] <SWPadnos> is there any reason why the
[17:35:36] <SWPadnos> is there any reason why the "fix threading oscillation" commit hasn't been backported to 2.3? ( be0dad0 )
[17:36:48] <cradek> probably should be if several people have tried it and it's better
[17:37:16] <cradek> not sure we'll bother with another 2.3 release though
[17:37:20] <SWPadnos> it sounds that way, but I don't know :)
[17:37:48] <SWPadnos> well, even if we want to do 2.4 around April (which is the current plan), there's still room for another 2.3
[17:38:11] <SWPadnos> might as well give people all the appropriate improvements without forcing them to upgrade
[17:39:18] <SWPadnos> bbiab
[19:07:13] <alex_joni> jepler sure is toggling today
[19:38:45] <micges> alex_joni: got few minutes?
[19:54:31] <jepler_> jepler_ is now known as jepler
[20:45:01] <alex_joni> micges: yeah
[20:45:09] <alex_joni> (sorry.. was away)
[20:45:19] <micges> np
[20:45:33] <micges> I'm messing with ja3
[20:45:43] <alex_joni> ok
[20:46:48] <micges> for teleop working motion need to mess with some axis config/status data
[20:47:46] <micges> so
[20:50:16] <micges> I think that it makes sense to move some canon velocity estimate to motion to realtime control of axes/joints velocities
[20:51:01] <micges> so only trajectory planners are decide what should velocity commanded be
[20:51:01] <alex_joni> can you be a bit more specific?
[20:51:31] <alex_joni> hmm.. not sure I understand
[20:51:45] <alex_joni> teleop used to say: go in X+ with 10mm/sec
[20:52:31] <micges> alex_joni: sorry I'm not talking about teleop
[20:52:46] <micges> this is ok and works
[20:53:08] <micges> I'm talking about joints/axes constrains
[20:53:22] <alex_joni> in all modes?
[20:54:00] <micges> teleop and coord
[20:54:13] <alex_joni> ok.. I'm listening
[20:54:43] <alex_joni> currently the g-code is beeing interpreted and in canon there are some velocity caps done
[20:54:50] <alex_joni> (I think that needs to change)
[20:55:04] <micges> yes I'm talking about it
[20:55:38] <micges> velocity estimate and caps should be done at tp level
[20:55:44] <alex_joni> right
[20:56:04] <alex_joni> although that's not always the best solution
[20:56:26] <alex_joni> if you do it in realtime you're a bit limited by what you can do
[20:56:43] <alex_joni> if you do it in userspace you have more options
[20:57:52] <alex_joni> you know that carthesian max_vel changes based on joint position.. right?
[20:58:16] <micges> now we don't know what should be done at either level
[20:58:22] <alex_joni> right
[20:58:32] <alex_joni> not even what could be done
[20:58:34] <micges> you mean on nontriv kins?
[20:58:41] <alex_joni> yes
[20:59:30] <micges> an example please?
[21:00:08] <alex_joni> hmm..
[21:00:20] <alex_joni> imagine a robot with 2 linear axes
[21:00:25] <alex_joni> and a rotary axis
[21:00:49] <alex_joni> when you put the rotary axis so that the 2 linear axes are parallel, the tooltip can go twice as fast in that direction
[21:01:33] <micges> mhm
[21:01:41] <alex_joni> not sure that's clear enough
[21:02:06] <micges> more less
[21:02:25] <micges> I can imagine general idea
[21:02:58] <micges> how did you manage this limit in your robots?
[21:03:12] <alex_joni> hmm.. it's kinda complicated
[21:03:47] <alex_joni> but the idea is that coordinated moves are way way waaaaaay slower than non-coordinated moves
[21:04:16] <micges> ah secure attempt
[21:04:20] <alex_joni> not really
[21:04:28] <alex_joni> it's also based on necessity
[21:04:53] <alex_joni> you only use coordinated moves for machining operations (e.g. welding)
[21:05:04] <alex_joni> and process speeds are usually < 1m / min
[21:05:19] <alex_joni> rarely faster, but even then not faster than 5-6m/min
[21:05:27] <micges> I understand
[21:05:28] <alex_joni> that's 100mm/sec
[21:07:49] <micges> if I skip max joint vel based on position that will be simpler? ;)
[21:08:42] <micges> I'm working to make gantry config and such controllable by emc without any hacks
[21:09:08] <micges> robots will be later (must first build (buy) one for teaching)
[21:09:15] <alex_joni> well.. gantries are another problem
[21:09:34] <alex_joni> buying is cheaper ;)
[21:09:44] <alex_joni> you can find older ones for ~1-2k
[21:10:36] <micges> nice
[21:11:21] <alex_joni> anyways .. back to robots (if you want to hear how it works)
[21:11:30] <micges> what problems do you see in gantries ?
[21:11:40] <alex_joni> slaving an axis to the other
[21:11:48] <alex_joni> e.g. synching them
[21:12:05] <alex_joni> I mean allowing the 2 to move independently
[21:12:20] <alex_joni> but also be able to lock them together
[21:12:25] <micges> that is easy
[21:12:42] <alex_joni> it's not a huge problem.. just having the infrastructure
[21:12:50] <micges> no limits on teleop is problem
[21:12:51] <alex_joni> and a way of starting/stopping the sync
[21:13:15] <alex_joni> and a way of specifying which joints are synced
[21:13:16] <micges> not allowing to jog before homing fixes all problems
[21:14:10] <micges> allowing to jog gantry in joint mode will kill machine
[21:14:21] <alex_joni> not necessarely ;)
[21:14:36] <alex_joni> you're thinking of gantry limited to XYYZ machines
[21:14:53] <alex_joni> we have rotary axes on the robots which are synched
[21:14:55] <alex_joni> let me find a pic
[21:16:46] <alex_joni> micges:
http://www.roboti.ro/wp-content/uploads/2009/04/real.jpg
[21:17:56] <micges> with what joint rotary is synced?
[21:18:10] <alex_joni> you see the blue table in the foreground?
[21:18:16] <alex_joni> (left in the pic)
[21:18:28] <micges> yes
[21:18:33] <alex_joni> it's a rotary table, the same as the one on the right
[21:18:42] <alex_joni> they are actually different joints
[21:18:52] <alex_joni> but they (usually) move together
[21:18:55] <alex_joni> sync=1
[21:18:57] <alex_joni> sign = -1
[21:19:18] <micges> ah two motors on same rotary joint?
[21:20:01] <alex_joni> 2 rotary joints, each with it's own motor
[21:20:11] <alex_joni> during normal operation you drive them as 1 axis
[21:20:38] <micges> (two joints (+) and (-) and one rotary)
[21:21:04] <alex_joni> didn't understand that
[21:21:28] <micges> ignore above, I understand idea
[21:21:48] <alex_joni> ok.. my point is that there are applications where synced joints are desireable
[21:21:56] <alex_joni> but not always is the syncing done 1:1
[21:22:49] <micges> yes
[21:23:29] <alex_joni> there are 2 ways to solve it
[21:23:38] <alex_joni> make it quickly work for trivkins and gantry
[21:23:56] <alex_joni> solve it in a general way -> involves a lot more infrastructure and configuration abilities
[21:25:02] <micges> alex_joni: ok thanks for cooling me down ;)
[21:25:20] <micges> bbl
[21:25:22] <alex_joni> I think #1 is a nice adition too
[21:25:38] <alex_joni> even if it doesn't solve the general problem, it surely helps more users than #2
[21:25:48] <alex_joni> (currently I don't know of anyone needing #2)
[21:25:55] <micges> I think the same
[21:27:05] <alex_joni> ok.. now back to joint limits
[21:27:24] <alex_joni> there are 2 kinds of limits.. position limits and velocity limits
[21:27:33] <alex_joni> (if you have time now, and don't need to leave)
[21:34:59] <micges> go on
[21:44:43] <micges> alex_joni: can we talk in about 45min?
[21:45:28] <alex_joni> sure
[21:45:32] <alex_joni> even better
[21:45:40] <micges> ok
[22:26:55] <tom3p> the cmd 'comp mux2bit.comp' gets me 'command not found' in a run-in-place install after '. scripts/emc-environment' while in it's root. why?
[22:28:21] <tom3p> i thought the purpose of emc-environment was to allow the rip's bin commands
[22:33:53] <cradek> chris@rover2:~$ . emc2.trunk/scripts/emc-environment
[22:33:53] <cradek> chris@rover2:~$ which comp
[22:33:53] <cradek> /home/chris/emc2.trunk/bin/comp
[22:33:53] <cradek> chris@rover2:~$ comp asdf
[22:33:53] <cradek> Unrecognized file type for mode preprocess: 'asdf'
[22:34:22] <tom3p> if i force it with 'sud /home/tomp/emc-dev/bin/comp --install mux2bit.comp' , it runs but has several warnings ( undefined symbols ).
[22:34:30] <cradek> are you sure you're reading the error right? did your compile work?
[22:34:30] <tom3p> it reports that it did 'cp mux2bit.ko /home/tomp/emc2-dev/rtlib/',
[22:34:31] <tom3p> yet when i try to loadrt mux2bit in a hal file, emc2 reports Can't find module 'mux2bin' in /home/tomp/emc2-dev/rtlib
[22:34:45] <tom3p> cradek: i think you have to spec the extant
[22:34:57] <cradek> what?
[22:35:16] <tom3p> comp asdf vs comp asdf.comp
[22:35:41] <tom3p> did the compile work, well it runs, has run for a month now
[22:35:56] <cradek> I meant to show you that it finds comp in my path.
[22:36:13] <tom3p> oh qwert keyboard, got it
[22:36:33] <cradek> pastebin exactly what you type and exactly what it says?
[22:36:57] <cradek> but if you've been using sudo here and there you've probably got your permissions in your source tree all screwed up now
[22:37:20] <cradek> maybe you should start again with a new git clone and build
[22:37:45] <tom3p> nm: it's terminal dependant, i used another terminal (done this b4) sorry
[22:38:10] <tom3p> the orig terminal does comp asdf fine
[22:38:20] <cradek> oh ok
[22:38:34] <micges> alex_joni: I'm back
[22:51:26] <alex_joni> cool
[22:51:38] <alex_joni> trying to get my son to go to sleep ...
[22:52:52] <micges> np
[22:54:48] <alex_joni> ok, almost there.. but I can type ;)
[22:56:15] <alex_joni> so.. lets talk about joint limits
[22:56:22] <alex_joni> first position limit (end of travel)
[22:56:35] <alex_joni> obviously each joint has a min-travel limit and a max limit
[22:56:58] <micges> yep
[22:57:00] <alex_joni> there are other positions of a joint which should be excluded but not referring to only one joint
[22:57:12] <alex_joni> a combination of joints which is forbidden
[22:57:24] <alex_joni> positions where inverse kins have no solution
[22:57:45] <alex_joni> but lets skip those first
[22:57:58] <alex_joni> you have no way of knowing if a carthesian move will hit a joint limit
[22:58:10] <alex_joni> before the move is made
[22:58:29] <alex_joni> because that info only comes from inverse kins, run at all traj points
[22:58:44] <alex_joni> so the only way would be to simulate the move before actually running it
[22:59:28] <micges> mhm
[23:00:10] <micges> so tp simulates move at axis level and get back data for joints level
[23:00:54] <alex_joni> yeah, but I don't think there's time to do it in realtime
[23:01:26] <alex_joni> if/when we implement this, it would be best to be a machine model running in canon or thereabouts
[23:01:41] <micges> ok I understand
[23:01:55] <alex_joni> obviously the same tp and kinematics code
[23:02:10] <alex_joni> but for now we can skip this part and just assume the limit isn't hit
[23:02:28] <alex_joni> so a teleop move or a carthesian coordinated move will just try to get to the endpoint
[23:02:37] <alex_joni> and if a joint limit happens on the way, it stops
[23:03:41] <micges> ok
[23:04:22] <tom3p> cradek: still no luck with comp, heres the terminal capture
http://pastebin.ca/1736764 & re 'using sudo here & there' i followed "How to write a hal component" which says "sudo comp --install joycounts.comp" is that wrong?
[23:06:15] <alex_joni> tom3p: cp: cannot create regular file `/home/tomp/emc2-dev/rtlib/mux2bit.ko': Permission denied
[23:06:27] <tom3p> right. why?
[23:06:28] <alex_joni> at some point you used sudo when you shouldn't have
[23:06:42] <alex_joni> either rtlib is owned by root or the mux2bit.ko file is
[23:06:52] <alex_joni> check the permissions (ls -al is your friend)
[23:07:02] <tom3p> k thx
[23:07:05] <alex_joni> ls -al /home/tomp/emc2-dev/rtlib/
[23:07:38] <alex_joni> micges: it's pretty similar for velocities
[23:07:58] <alex_joni> the simulation tp should run the move, and see if any joints exceed their max vel by what value
[23:08:04] <alex_joni> and scale the move accordingly
[23:08:16] <alex_joni> that's the more correct solution
[23:09:00] <alex_joni> another (dirty) solution is: start the move, and if any joints get to their max_vel's (maybe 10% under max vel) use adaptive_feed or something similar to slow down
[23:09:42] <micges> I like it ;)
[23:09:45] <alex_joni> approach #2 means you don't need to know the machine in advance, but it also means that the move is not performed at the same vel - which I don't think is that important anyways
[23:10:11] <alex_joni> if joints get out of max_vel area, you can speed up again
[23:12:25] <micges> ok I follow all time
[23:13:14] <micges> position limit can be check in every cycle and stop if hit
[23:13:56] <micges> velocity limit can be simulated in userspace and send or send and scaled in every servo cycle
[23:14:25] <micges> both vel limits implementations are scary ;)
[23:14:32] <alex_joni> heh, yeah
[23:15:27] <alex_joni> accel is even scarier
[23:16:30] <micges> I don't like accel, it should be always set to 200 ;P
[23:16:36] <alex_joni> hmm
[23:16:49] <micges> kidding
[23:17:06] <alex_joni> there was a german guy asking about jerk limiting today
[23:17:17] <alex_joni> his machine does 4.9m/s^2 accel
[23:17:38] <micges> what about holes in joints space? (don't know proper name)
[23:17:51] <SWPadnos> singularities :)
[23:17:59] <alex_joni> SWPadnos is right
[23:18:03] <micges> thx ;)
[23:18:12] <SWPadnos> like black holes
[23:18:14] <alex_joni> although singularities are not the only thing that could be modeled
[23:18:25] <alex_joni> it's places not to go to
[23:18:34] <alex_joni> the problem is to model them in carthesian space
[23:18:46] <alex_joni> where they have non-trivial shape
[23:19:08] <micges> 4900 mm/s^2?
[23:19:11] <alex_joni> I don't think you can model them in joint space
[23:19:13] <alex_joni> micges: yes
[23:19:49] <micges> I have one machine with 7500mm/s^2 :)
[23:19:59] <alex_joni> brrr
[23:20:30] <alex_joni> 4900mm/s^2 is close to 200"/s^2
[23:20:38] <alex_joni> (like you said above ;)
[23:20:53] <alex_joni> anyways.. back to ranges
[23:21:10] <micges> what means limiting jerk? (can't translate it)
[23:21:19] <alex_joni> jerk = d(accel)
[23:21:34] <micges> ah ok
[23:21:45] <alex_joni> currently emc2 limits accel to a max_accel
[23:21:54] <alex_joni> rezulting in trapezoidal velocity profile
[23:22:03] <alex_joni> but jerk can be infinite
[23:22:50] <alex_joni> anyways.. back to ranges
[23:23:06] <micges> should be S shapes..
[23:23:06] <alex_joni> you can easily define the working range in joint space
[23:23:14] <micges> ok back to ranges
[23:23:19] <alex_joni> micges: right, jerk limited = s-shaped
[23:24:41] <alex_joni> in joint space you can define ranges where it's ok to be or not ok to be
[23:24:56] <alex_joni> maybe a list: (OK to be in..)
[23:25:08] <alex_joni> -min_limit ... some_value
[23:25:16] <alex_joni> some_other_value .. max_limit
[23:25:46] <alex_joni> but implementing this is quite a bit of work
[23:28:09] <micges> based on that limitations limit joints jogging area ?
[23:28:17] <micges> or cartesian area?
[23:31:41] <alex_joni> hmm.. good point
[23:31:52] <alex_joni> certainly there needs to be a limit for cartesian area
[23:32:05] <alex_joni> don't think that for joints jogging it's needed
[23:32:51] <alex_joni> because if you limit joints then you can't ever get around the interval.. which means the other end is useless so you can just define the first interval as the complete travel for that joint
[23:33:15] <micges> good point
[23:33:54] <micges> alex_joni: let's hold discussion right now
[23:34:25] <alex_joni> ok
[23:34:47] <micges> I must go sleep now, tomorrow I'll reread rethink and we can continue
[23:34:58] <alex_joni> perfect
[23:35:12] <micges> namy thanks
[23:35:20] <micges> goodnight
