joints-axes branch not yet merged

[ArcEye]

Issue by mhaberler
Wed Jan 14 23:56:29 2015
Originally opened as machinekit/machinekit#438

---

current code (mostly motion and jogging-related upper layers) has some fundamental confusion about axes versus joints. Cleaning this up is an important prerequisite for supporting non-trivial kinematics better, and also to clean up dark corners like jogging.

There has been work ongoing for several years mostly by Michal Geskiewicz to remedy this, it's in branches termed 'joints-axes' or 'jaX' both in git.linuxcnc.org and my own machinekit fork on github (possibly others too). The code is mostly in place, but bits and pieces are missing.

Of the options - have those branches linger around on end, or go for an accelerated merge with a likely bumpy period thereafter, I think the second option is the better (and motivation for fixes will be higher).

A likely base branch could be this: https://github.com/mhaberler/machinekit/tree/ja6-candidate-1 which rebases the git.linuxcnc.org ja6 branch onto machinekit while keeping the jog-while-paused feature working

[ArcEye]

Comment by mhaberler
Thu Jan 15 06:54:01 2015

---

problems which will likely pop up:

• Configuration changes needed (Andy's script will help)
• Documentation needs updating
• kinematics modules need KINEMATICS_BOTH to switch between axis+joint modes in manual
• jogging will need updated support in UI's
• jogging might need updated NML messages to carry axis jogs properly
• jogging more than one axis (e.g. diagonal) does work yet due to lacking NML support
• wheel jogging needs to be taught about axis jogs

[ArcEye]

Comment by luminize
Thu Jan 15 08:51:55 2015

---

Would you want me to split these in separate issues? For keeping focus and make the work more manageable?

On 15 Jan 2015, at 07:54, Michael Haberler [email protected] wrote:

problems which will likely pop up:

Configuration changes needed (Andy's script will help)
Documentation needs updating
kinematics modules need KINEMATICS_BOTH to switch between axis+joint modes in manual
jogging will need updated support in UI's
jogging might need updated NML messages to carry axis jogs properly
jogging more than one axis (e.g. diagonal) does work yet due to lacking NML support
wheel jogging needs to be taught about axis jogs
—
Reply to this email directly or view it on GitHub.

[ArcEye]

Comment by mhaberler
Thu Jan 15 09:31:54 2015

---

well it's roughly as I remember them; I'm not sure all of them are still present and relevant
I'd rather wait a bit until somebody gets onto the task and takes stock; then certainly it's a good idea to go for 'one each' to make sure they are addressed

[ArcEye]

Comment by mhaberler
Tue Jan 27 22:26:22 2015

---

I've learned some more parts are in the queue, and they relate to this issue:

• Michal Geskiewicz has been working on jerk-limited trajectory planning based on the old (pre-Ellenberg) planner, but including joints-axes mods (ja4); merging this code might involve significant testing and work
• Yishin Lin has been working on jerk-limited tp for a long time, and that code is already based on the Ellenberg tp modifications; merging might be easier wrt tp code but the status is unclear and it does NOT entail ja4 mods

so we need to decide which code and in which order, and in which relation to jaX (micges suggests: first jaX, then tp mods)
also we'd need a bit of support promise and docs

both projects suggest there be a method to runtime-load complex code pieces like a tp or kinematics, and multiple instances of those if possible; this suggests HAL support for a new kind of object (basically classes which are instantiable, but not components proper, and export a function switch table similar to the c++ vtable or the kernel's device switch; I am looking into that now

[ArcEye]

Comment by mhaberler
Mon Feb 2 19:41:34 2015

---

Michal has suggested that - either way - we first make tp a loadable module

in my never-ending quest for grandiose coding, I'm working on support for loading code which can be instantiated more than once like a class, and added HAL support to it (called HAL classes and vtables); some notes on the idea:

issue:

• right now loading say a kins module rests on load-time symbol resolution (kernel insmod or shared lib dlopen)
• that restricts loading to one-of-a-kind per process space (RT or userland thread) because symbol resolution happens only once - singletons only this way
• ideally we'd have multiple kins live and switchable, and loadable tp's (yishin flavor, micges flavor, robellenberg flavor etc etc ;)
• what these pieces export is a whole API (lots of functions), and sometimes a bit of data
• this is very close to what a C++ vtable does, or rtapi_switch_t does - basically a struct to dispatch functions to the currently loaded RT API; or to what a driver does with the device switch structure (open, close, read, write, ioctl etc); however rtapi is a singleton too - rtapi_switch is a pointer to the dispatch struct which is resolved at load time

approach:

• what the new object would do is export a named switch structure (like the emc/tp/tp.h API); the switch struct would consist of a stock struct at the beginning (name, type, version, refcount) and then function pointers (those are custom to the purpose, eg. one per tp API call)
• the object would have an associated signature field (basically a version ID of the switch struct) as a sanity check (C++ does handle this link-time with its funny signatures, but we're in C land and C dont, so we need a makeshift protection)
• since this is pretty much a class, I'd call it a HAL class for now, and the table a vtable
• technically vtables are first-order HAL objects with name and id, but for them to be useful they would be typically be exported by a component; so there's an optional comp_id param linking a vtable to a component
• loading a class would cause in rtapi_app_main to call to say hal_export_class(name, verson, vtable, component_id) which would generate the vtable object

using code (e.g. motion loading a tp or kins) would call hal_reference_class(name, version, **vtable) and return the class id and set vtable pointer; also increase the refcount

there'd be a matching hal_unreference_class(class_id) to drop the refcount; zero refcount permits unloading the class on rtapi_app_exit

plus some basic halcmd support to view the new objects in a sensible context

once using code has a handle on the switch struct, it would be able to reference say tp API functions by handle->tpFuncX(params..) just like the rtapi_switch does

the whole thing is pretty much a C++ vtable in C, with HAL loading draped around it; the intent is to have those modules instatiable right through the switch struct as designed (other than the hokey halcomps with their confused instance idea)

use case would be RT, but with a minor twist such classes could be loaded into a userland component as well (it would be private to the userland comp, and not callable from RT, also the other way around
this would allow to say load a tp or kins module either in RT or in userland as needed, I think that would help migrating such stuff out of RT

using code needs adapting from calling (params) to handle->(params); for tp that's some 30-40 refs or so, and for kins maybe 2, so much less than the RTAPI migration behind us

halcmd would list class names, comment string, version, refcount, RT (not sure if userland loaded classes should be registered in HAL since they'd be strictly process-local so no reuse or reference possible anyway)

note a HAL class does exactly nothing unless called through the switch struct, which includes instantiation; I'm not promising this be a way to migrate to instantiable comps but it's very close to this idea - separate instantiation from loading - besides exporting any kind of API regardless of the load-time symbol resolution restrictions

[ArcEye]

Comment by mhaberler
Mon Feb 2 22:46:12 2015

---

this branch adds the HAL library, and halcmd support for vtables (I dropped the pathetic 'class' name for what is essentially a typed, named, refcounted pointer intended for level 0 class support). Example included:

https://github.com/mhaberler/machinekit/commits/hal-vtable-support

Next step are:

• modulate the kinematics api to use vtables so several kins can be referenced
• then wrap the tp API into a vtable

(kins first since simpler API)

[ArcEye]

Comment by mhaberler
Tue Feb 3 00:54:09 2015

---

step 1 done - changed trivkins to vtable API: mhaberler/machinekit@51a2de3

changed motion to use it: mhaberler/machinekit@41db5a5

that looks like a pretty simple migration. TP next..

https://github.com/mhaberler/machinekit/commits/vtable-kins

[ArcEye]

Comment by mhaberler
Wed Feb 11 22:45:12 2015

---

status: halfway through disentangling emcmotstatus and emcmotconfig globals access in tp so the tp code can be compiled without referencing those structures

realistically I can get to it only 3rd week of Feb

[ArcEye]

Comment by mhaberler
Tue Feb 17 11:18:49 2015

---

this is where I'm at in state sharing between tp and using code; it seems unraveling the emcmotstatus and emcmotconfig globals access into what could be HAL pins is the most sensible thing to do; they dont have to, but they could be pins

one would pass such an all-pointers-initialized tp_shared struct to tpInit(), and TP_STRUCT would hold a pointer to it:

*/
typedef struct {
...
tp_shared_t *shared;
...
} TP_STRUCT;

access can be wrapped as static inlines like so:

static inline int get_num_dio(TP_STRUCT *tp) { return *(tp->shared->num_dio); }
static inline int get_num_aio(TP_STRUCT *tp) { return *(tp->shared->num_aio); }

not sure I like it yet.. comments?

// this holds all shared data between using code and the tp
// data items can be pins if so desired,
// in this case the tp_shared struct must live in HAL memory, and
// be allocated by hal_malloc()

struct tp_shared {

// read-only by tp, config items
hal_s32_t   *num_dio;
hal_s32_t   *num_aio;

hal_float_t *arcBlendGapCycles;
hal_s32_t   *arcBlendOptDepth;
hal_bit_t   *arcBlendEnable;
hal_float_t *arcBlendRampFreq;
hal_bit_t   *arcBlendFallbackEnable;
hal_float_t *maxFeedScale;

hal_float_t *acc_limit[3]; // tpGetMachineAccelBounds(PmCartesian * const acc_bound)
hal_float_t *vel_limit[3]; // tpGetMachineVelBounds(PmCartesian * const vel_bound)

hal_bit_t *unlock[EMCMOT_MAX_JOINTS];          // write by tp
hal_bit_t *is_unlocked[EMCMOT_MAX_JOINTS];     // read by tp

// read/write by tp: via emcmotStatus->
hal_float_t *spindleSync;
hal_float_t *current_vel;
hal_float_t *dtg[9]; // an EmcPose
hal_bit_t   *spindle_index_enable;
hal_bit_t   *spindleSync;
hal_float_t *spindle_speed; // was emcmotStatus->spindle.speed

// typedef struct {
hal_float_t *double offset; // rw
hal_float_t *double revs;  // rw
hal_s32_t   *int waiting_for_index;  // rw, a motion ID
hal_s32_t   *int waiting_for_atspeed;  // rw, a motion ID
// } tp_spindle_t;

// write-only by tp: via emcmotStatus->
hal_float_t *requested_vel;
hal_float_t *distance_to_go;
hal_u32_t   *enables_queued;

};

[ArcEye]

Comment by mhaberler
Mon Feb 23 10:08:11 2015

---

joint vel/acc limiting with non-trivkins is an issue in the current planner

I had a chat with Michal this morning and he had an interesting idea which might simplify things significantly. Current ideas were so far focused on joint vel/acc limiting in the motion/tp complex.

But it might be easier to prevent moves which exceed joint limits actually hitting tp/motion. One way this could be done is:

• kinematics are made available to the canon layer (a little API exercise but entirely doable).
• the canon layer (currently cartesian only) becomes kins-aware and then may 'plan' for joint space too, using the above kins API
• the joint vel/acc limiting is thus done on the canon layer, meaning moves coming out of canon will already be joint-limited

as usual feed override gets in the way, but one way to deal with that is to worst-case joint-plan in canon using MAX_FEED_OVERRIDE so moves would still be within joint limits if f/o is cranked up to the maximum

one aspect which gets in the way a bit is the fact that many kins modules use HAL for configuration, meaning any kins must run on a HAL/RT host if left unchanged

[ArcEye]

Comment by cdsteinkuehler
Mon Feb 23 12:47:57 2015

---

I like the idea, and I've been hitting issues with the joint vs. axis
limits recently working on one of my non-Cartesian 3D printers (Wally):

http://conceptforge.org/images/Wally.jpg

...which makes the delta-printer kinematics seem simple by comparison.

Also, since adding this would probably touch the world vs. joint motion
limits, could we PLEASE make the test for allowable movement envelope
a function call instead of a "box"?

Charles Steinkuehler
[email protected]

[ArcEye]

Comment by mhaberler
Thu Feb 26 12:40:42 2015

---

that sounds like a wonderful vtable application to me - a comp which exports a function, gets a pose (or two to test a line), and returns bool

motion could use that function

NB there's another limit check in tastk, needs investigating if both need to be replaced

[ArcEye]

Comment by yishinli
Fri Dec 4 01:38:02 2015

---

Merge LCNC.joint_axes9 with MK.master to MK.joints_axes9.

Current work:

• merge motion parts: emccanon.cc, control.c, command.c. control.c tp.c
• skip conflicts of rtapi/, hal/, kinematics/, configs/

Open issues:

• In LCNC.joint_axes9, those hal files in configs/common/ are moved to lib/hallib, which results a clean configs/sim/ directory without symbolic links. The INI.[HAL]HALFILE seems to be able to access .hal files in hal/hallib directly. Current MK.joint_axes9 can't.
• LCNC.joint_axes9: RTAPI and HAL modifications needs to be reviewed and merged.

[ArcEye]

Comment by yishinli
Mon Dec 7 08:00:13 2015

---

I got the following error messages while launching Machineface with joints_axes9:

Exception in thread Thread-3:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/threading.py", line 763, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home/artek/proj/machinekit/bin/mkwrapper", line 1323, in poll
    self.update_status(self.stat)
  File "/home/artek/proj/machinekit/bin/mkwrapper", line 1219, in update_status
    self.update_motion(stat)
  File "/home/artek/proj/machinekit/bin/mkwrapper", line 1190, in update_motion
    name, statAxis[name])
KeyError: 'enabled'

Is this because the EmcStatusMotionAxis of status.proto needs to be revised for joints_axes9?

-Yishin

[ArcEye]

Comment by mhaberler
Mon Dec 7 09:59:05 2015

---

@yishinli - there is a serious issue with this branch - this is a merge of all of linuxcnc into machinekit

you need to isolate the parts which are needed and merge or cherry pick just those which are relevant to the issue - just merging doesnt cut it

there should be code being merged outside motion, any support in task, and possibly UI's and related code

[ArcEye]

Comment by yishinli
Mon Dec 7 10:43:35 2015

---

@mhaberler - please give a guide about what should be done for merging joints_axes9 - I'm willing to follow your instructions, and restart the merging process.

• Which part should be merged?
• Which part should not be merged?
• How to use git for cherry picking or merging part of joints_axes9?

The git commands I used were:

1. git remote add jelper https://github.com/jepler/linuxcnc-mirror.git
2. git checkout --track -b joints_axes9 origin/master
3. git pull jelper joints_axes9
   There were a lot of conflicts after "git pull ..."; so, I started resolving conflicts, and tried to get the simulation working. Please advice the right way to merge ja9.

[ArcEye]

Comment by mhaberler
Mon Dec 7 12:57:31 2015

---

@yishinli
frankly, the first step is to answer the question "is this ready branch for a merge"?

if this is already merged into linuxcnc mainline and bugs are being worked out then I'd say yes; if it is still out on a limb like it has been for several years now the answer might be "no" - not sure what the status is, I still need to look

the branch you pointed to suggests "still diverged": This branch is 212 commits ahead, 137 commits behind master. (212 commits is a lot of code out on a branch - which means we could be importing a huge maintenance problem if we did.

We better get Michal Geskiewicz's opinion on the case to be sure. the changes are not just motion but all the way to conversion of config files, so that is major breakage (!) and needs handholding and testing

one open problem was jogging, dont know where that stands

now assuming the answer is yes - just merging that branch is not an option because it merges all the other changes in linuxcnc since we forked, which is not what we want

what you'd do is to isolate the relevant sequence of commits (first guess - the 212 commits mentioned above, which is a sequence commits expressed like sha1..sha2)

you'd review that sequence and make sure they only apply to joints_axes functionality

in principle you have two options now: you could

• squash the whole sha1..sha2 sequence onto a single commit and cherry pick that onto machinekit
• cherry-pick the above sequence of commits onto machinekit

the first is easier (just one time resolution of conflicts) but you'd loose the history which is bad (but worth it for a quick first stab if things work out)

the second is more work but recommended as debugging /review lateron is easier; I would assume a significant number of these cherry-picks would fail due to a diverged code base, and need manual resolution.

[ArcEye]

Comment by micges
Mon Dec 7 13:13:24 2015

---

Hello,

It's not possible to just merge linuxcnc jax branch to mk, linuxcnc is too far diverged. Jax is qick'n'dirty branch that's why lcnc still didn't merge it to master even that they worked alltogether on it.

[ArcEye]

Comment by micges
Mon Dec 7 13:18:27 2015

---

You can make small steps like it was done to make ja3 to work.

1. separate joint jogging planner to separate module.
2. change teleop planner to use above separated planner so joint and axis joggoing is unified.
3. fix all joint/axes naming in motion (*.h, command defines and struct)
4. introduce hal structures with pins describing cardesian coords (axis pos, axis vel and so on)

[ArcEye]

Comment by yishinli
Mon Dec 7 23:32:19 2015

---

Assume joints_axes9 is NOT a ready branch for a merge.
What would be the better approach for Machinekit to support non-trivial kinematics?
for example, 6-joints-manipulator.

[ArcEye]

Comment by mhaberler
Tue Dec 8 09:26:42 2015

---

@yishinli yes, unfortunately I have to agree

happy to discuss in more detail tomorrow say on skype, just a few ideas & notes here:

• the 'CNC machine driving model' including g-code might not be that great for robotics after all
• the absurd complexity of the online planner in motion is not usually required - robotics packages mostly do offline planning which simplifies things big time (no feed override needed etc)
• this also means kinematics is not done in RT but way before that in userland before playout
• EmcPose is a bit lame as a data structure #151
• some folks (Bas, Charles; Amit showed interest) are looking into integrating ROS with machinekit, such that the HAL layer becomes a payout device for ROS
• have a look at issues #689 which discussed that

we might not be all that far away from tying machinekit into the very vivid world of ROS !

[ArcEye]

Comment by saeugetier
Sat May 6 16:23:10 2017

---

@mhaberler any progress here?

[ArcEye]

Comment by saeugetier
Sat May 6 16:36:34 2017

---

I saw that there is some progress on the topic. See issue machinekit/machinekit#689

[ArcEye]

Comment by ArcEye
Sat May 6 17:26:24 2017

---

@saeugetier
What is it you are actually asking about?

This issue is 17 months old and the one you say has some progress is 14 months old.

Linuxcnc are still having issues with the joints/axes code and unless someone with a particular need/interest in it steps up to the plate and offers to do the work to adapt and merge it, seems unlikely any time soon .

[ArcEye]

Comment by luminize
Sat May 6 17:35:34 2017

---

On 06 May 2017, at 18:36, saeugetier wrote:

I saw that there is some progress on the topic. See issue #689

@saeugetier that's an issue on ROS and Machinekit and is not related to this issue.

[ArcEye]

Comment by saeugetier
Sat May 6 19:33:33 2017

---

@ArcEye The issue is open for a while. I just want to know if there are any news which have not been posted here.

@luminize the last post from @mhaberler was about ROS. So I thought that this topic is related to ROS.

[ArcEye]

Comment by luminize
Sat May 6 21:34:27 2017

---

On 06 May 2017, at 21:33, saeugetier wrote:

the last post from @mhaberler was about ROS. So I thought that this topic is related to ROS.

Well, partly :)
The ROS effort centers about off-line path planning with (interpolation and) playout by Machinekit. Joints/Axes is about realtime planning taking also joint constraints into consideration.

ROS off-line planning already takes care of these joint constrains when calculating the trajectory (and it does not violate these). The trajectory is not calculated in realtime