2011/1/5 Alex Joni <alex.j...@robcon.ro>:
> The kinematics in emc2 don't care if it's the arm or the workpiece that
> move. they both move relative to each other, so you have to take care of
> both in your kinematic file.
> If only the workpiece rotates then surely it's a lot simpler and your
> assumption above is correct (pos->u = joint[6]...)
Yes, that is correct, workpiece only needs to rotate. Thanks, that one
would be sorted out...
> well, the "problem" with genserkins is that it's a generic serial kinematic
> solver.
> That means it's supposed to work for any/all cases of serial linked joints
> (rotary and linear).
> Currently (addressing you next point) the joint type is fixed to rotary, but
> that doesn't mean the calculations aren't working for linear joints.
> Just that currently there is no way of telling genserkins that you first
> joint is linear. To fix this, you would have to add some HAL pins (if you
> want to make it configurable, like it should be) to specify each joint type
> (linear or angular), then init the joint accordingly :
> at line 81 [1] the current assumption is rotary:
> genser->links[t].quantity = GO_QUANTITY_ANGLE;
> that needs to be changed to GO_QUANTITY_LENGTH (defined in
> src/libnml/posemath/gotypes.h) [2]
Please correct me, if I am wrong, but if I will change this line:
81 genser->links[t].quantity = GO_QUANTITY_ANGLE;
to this one:
81 genser->links[t].quantity = GO_QUANTITY_LENGTH;
then it will change all the joints from angular to linear. Is that correct?
I suspect that adding HAL pins, which determine type of joint - LINEAR
or ANGULAR, should look like this:
In HAL file:
# Setting values for joint type - linear or angular.
# These values are used by genserkins kinematics module
# It would be ideal, if values of these pins could be set
automagically, depending on INI file:
# [AXIS_N] TYPE = LINEAR or ANGULAR
# The values are assigned, based on this rule - for linear joints it
is 0 ("false"), for angular joints it is 1 ("true")
setp genserkins.TYPE1 0
setp genserkins.TYPE2 1
setp genserkins.TYPE3 1
setp genserkins.TYPE4 1
setp genserkins.TYPE5 1
setp genserkins.TYPE6 1
In genserkins.c file. My idea is to call that pin "type". I copied my
suggested code together with some previous lines of code, so that it
is easier to understand, where I propose to place it:
struct haldata {
47 hal_float_t *a[GENSER_MAX_JOINTS];
48 hal_float_t *alpha[GENSER_MAX_JOINTS];
49 hal_float_t *d[GENSER_MAX_JOINTS];
50 hal_float_t *type[GENSER_MAX_JOINTS];
59 #define D(i) (*(haldata->d[i]))
60 #define TYPE(i) (*(haldata->d[i]))
595 if ((res =
596 hal_pin_float_newf(HAL_IO, &(haldata->d[i]), comp_id,
597 "genserkins.D-%d", i)) < 0)
598 goto error;
599 if ((res =
hal_pin_float_newf(HAL_IO, &(haldata->type[i]), comp_id,
"genserkins.TYPE-%d", i)) < 0)
goto error;
618 D(0) = DEFAULT_D1;
619 D(1) = DEFAULT_D2;
620 D(2) = DEFAULT_D3;
621 D(3) = DEFAULT_D4;
622 D(4) = DEFAULT_D5;
623 D(5) = DEFAULT_D6;
624 TYPE(0) = DEFAULT_TYPE1;
TYPE(1) = DEFAULT_TYPE2;
TYPE(2) = DEFAULT_TYPE3;
TYPE(3) = DEFAULT_TYPE4;
TYPE(4) = DEFAULT_TYPE5;
TYPE(5) = DEFAULT_TYPE6;
680 for (i = 0; i < 6; i++) {
681 haldata->a[i] = malloc(sizeof(double));
682 haldata->alpha[i] = malloc(sizeof(double));
683 haldata->d[i] = malloc(sizeof(double));
684 haldata->type[i] = malloc(sizeof(double));
697 D(0) = DEFAULT_D1;
698 D(1) = DEFAULT_D2;
699 D(2) = DEFAULT_D3;
700 D(3) = DEFAULT_D4;
701 D(4) = DEFAULT_D5;
702 D(5) = DEFAULT_D6;
703 TYPE(0) = DEFAULT_TYPE1;
TYPE(1) = DEFAULT_TYPE2;
TYPE(2) = DEFAULT_TYPE3;
TYPE(3) = DEFAULT_TYPE4;
TYPE(4) = DEFAULT_TYPE5;
TYPE(5) = DEFAULT_TYPE6;
In genserkins.h file. I added the default TYPE values to be 1. It
looks like this:
46 /* default DH parameters, these should be ok for a puma - at least
according to Craig */
47 #define DEFAULT_A1 0
#define DEFAULT_ALPHA1 0
#define DEFAULT_D1 0
#define DEFAULT_TYPE1 1
#define DEFAULT_A2 0
#define DEFAULT_ALPHA2 -PI_2
#define DEFAULT_D2 0
#define DEFAULT_TYPE2 1
#define DEFAULT_A3 300
#define DEFAULT_ALPHA3 0
#define DEFAULT_D3 70
#define DEFAULT_TYPE3 1
#define DEFAULT_A4 50
#define DEFAULT_ALPHA4 -PI_2
#define DEFAULT_D4 400
#define DEFAULT_TYPE4 1
#define DEFAULT_A5 0
#define DEFAULT_ALPHA5 PI_2
#define DEFAULT_D5 0
#define DEFAULT_TYPE5 1
#define DEFAULT_A6 0
#define DEFAULT_ALPHA6 -PI_2
#define DEFAULT_D6 0
#define DEFAULT_TYPE6 1
So now the remaining part is to create code that would select either
GO_QUANTITY_ANGLE or GO_QUANTITY_LENGTH, based on "type" value - if it
is 0, then GO_QUANTITY_LENGTH, if it is 1, then GO_QUANTITY_ANGLE.
I suspect that linear joint does not need a, d, alpha and theta values
as well. Is that correct?
Could anyone, please, suggest correct syntax for these lines?
73 /* init them all and make them revolute joints */
74 /* FIXME: should allow LINEAR joints based on HAL param too */
75 for (t = 0; t < GENSER_MAX_JOINTS; t++) {
76 genser->links[t].u.dh.a = A(t);
77 genser->links[t].u.dh.alpha = ALPHA(t);
78 genser->links[t].u.dh.d = D(t);
79 genser->links[t].u.dh.theta = 0;
80 genser->links[t].type = GO_LINK_DH;
81 genser->links[t].quantity = GO_QUANTITY_ANGLE;
82 }
> Once you fixed that, you can select for each joint if it's linear or rotary.
> You would still need to define 6 joints for the genserkins part, because the
> solver won't work otherwise (so try to define an extra joint, which you
> won't use), and the rotary table you can add as joint 7.
No problem with that, except that "axis/joints" part in GUI will be
misleading due to the joints vs axis mixup.
Is it correct that in this case I will need to change
GENSER_MAX_JOINTS to 7 in genserkins,h file and probably in few more
places in genserkins.c?
By the way, genserkins.h says:
38 /*!
39 The maximum number of joints supported by the general serial
40 kinematics. Make this at least 6; a device can have fewer than these.
41 */
Could You, please, explain, what is meant by "device can have fewer
than these"? That additional dummy joints will need to be defined so
that in any case total number of joints reaches 6?
Any other comments or suggestions are welcome!
Viesturs
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
