Re: A nomenclature question

On Sun, 6 Jul 2003, Leopold Palomo Avellaneda wrote:

[...]
> > 2. symbolic representation that describes the kinematic family and
> >    the conventions used (positive direction, joint limits,
> >    connectivities, etc.)
> 
> Ok. You prefere to divide this information. I have worked in a ONE class with 
> all this information. 

I am not quite sure whether we can suggest _the_ best way of
approaching this problem of where to put what functionality...

First possibility: there is _one_ object for each kinematic chain,
that contains all information about that kinematic chain (symbolic,
numeric, "state" in the sense of current joint and end effector
positions and velocities, etc.). This is easy, because all method
calls can be kept small, because most information is found through the
object on which the method is performed. In the most extreme
case, one could end up with "empty" method calls, such as:
 MyKinematicChain.JointToCartesianVelocity().
All the information needed in this call (kinematic structure and
parameters, actual joint positions and velocities) are found in the
MyKinematicChain object, and the result (Cartesian velocity of end
frame) is also stored in that object.

Second possibility: all information is given as explicit arguments to
the call:
EndFrameTwist = JointToCartesianVelocity(MyKinematicChain,JointPositions,JointVelocities).

Both approaches have their advantages and disadvantages, I guess. I am
very interested in hearing comments about both possibilities (and some
thinkable alternatives in between...)

> > 3. for each specific family: an efficient and ad hoc implementation of
> >    the internal kinematics API.
> 
> I think that this point is something to take care. I'm thinking that you have 
> to be able to simulate/operate your 321 robot with classes of the its family 
> and with the serial6f genreric family.
Yes, such as the object that contains joint positions or velocities;
or the representation of Cartesian reference frames; etc.

> > > Kleinfunger-Khalil nomenclature that the Travelling Coordinate System. I
> ...
> > I don't like very much these conventions that _impose_ how you have to
> > choose reference frames, for the simple reason that people loose too
> > much time trying to adhere to the convention. While there is no real
> > need for such "systematic" conventions: any choice of frames on the
> > links and joints will do, and designers most often have very good
> > intuition about where they want their joint axes to lie. 
> 
> Reading that, I have remembered that almost ALL the papers that I
> have read to find some nice generic model to solve the inverse
> kinematic are developed using some nomenclature to contruct the
> formules to work with. 

Yes, but there is no need to use _the same convention_ for _all_ of
them: for some families, one particular choice of frames fits better
than another choice, although this latter is better suited for another
family. I would take the pragmatic approach: let's see how things work
out, and change our minds when there is a need to do so.

> I agree with you with the idea of the nomenclature as a minimal question. But 
> for example. If I would like to implement the Manocha method to solve the 
> general kinematic inverse, in all of his-theirs papers he (they) develop the 
> formulas using D-H, to conctruct the polinomian, working after with the 
> \theta_i. I think that this method is nomenclature dependant, or all least 
> the information that I have. To have some nomenclature helps you to develop 
> formulas to work, I think. 
The problem is less with how one "names" things than with the fact
that _very_ DH representation has mathematical singularities for
particular architectures...

[...]
> > All the
> > conventions (including Kleinfinger-Khalil) work with constructions
> > such as the common perpendicular between two axes, etc. I think this
> > is not really necessary; it maybe _was_ interesting in the past, when
> > being able to use only four numbers instead of 6 or 16 was important,
> > which is not so important anymore with modern systems... 
> 
> big red light, big red light!!!!!!  The people is lazy. We are lasy.
> If I need only 4 number to define one thing I will use only 4 not
> 16. This principly can be aplicable to all the things. 
The is a _huge_ cost involved in opting for these four numbers:
singularities! I would  not like to see our kinematics algorithms
littered with "if...then...else" statements in order to cope with
these singularities. (Note that these singularities are _artificial_,
i.e., due to the chosen representation, and not due to physical
singularities of the kinematic chain.)

[...]
> I construct a industrial robot that I _think_ that is a pure 321 with all the 
> intersections, parallel axes, etc. My mathematical model of the robot is 
> perfect. I have some nice efficients formulas, etc. 
> 
> Howeber, the reality is that I don't have exactly an intersection, or I have 
> some error parameters. (I'm reading your notes pag.105, section 7.7) To make 
> some nice simulation it would be ok, but to work experimentally with my robot 
> I will need some general formulas. So, I think that it's very important to 
> have efficent general formulas to work experimentally.
> 
Absolutely: the numeric algorithms should indeed be both generic and
efficient. And in this respect I think the homogeneous transformation
matrices are the best compromise to reach both goals :-) In many
cases, most of the 16 numbers in the homogeneous transformation matrix
are zeros, or copies of other elements, such that efficient coding
remains possible.

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480