Re: A nomenclature question

A Dilluns 07 Juliol 2003 10:41, Herman Bruyninckx va escriure:
> > > 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...

This is a question to think about it. Howeber maybe we are thinking "too much" 
and there's not optimal solution. Only different approaches to the problem.
>
> 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.

This approach is that I have done. The problem that I have realised now is 
that the classes are too BIG. I'm afraid that, that code would be 
unmaintanaible. Also, I'm not sure that this approach was portable in the 
sense that for a simulator or working off line ok, but if you want to keep 
the same code to use in a real time enviroment I don't think that it could be 
a good idea. So I think that lrl has to be a library that you can use to make 
a simulation, or to put in a controler in a prototype.

> 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...)
me too.

[....]

> > > > 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: 

You are right. I think the same when I'm going to buy a pants!!! 

I think that lrl has to be focalised in give an easy interface to use it, and 
a robust code inside to put it somewhere. I think that is better to give 2 or 
3 conventions to use but a simple/robust code that a lot of conventions to 
use but a difficult code inside. And to do that, I think that is could be 
better to mantain some kind of coherent interface. If you define a 321 robot 
with some nomenclature, you have to be able to define the same robot as 6R. 

> 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 understand your pragmatic approach!. I'm trying to say that I'm afraid to 
have a very versatile thing that do a lot of things but difficult to code. 
That's all.
>
> > 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...

are you talking about free singularity nomenclature for ALL the architectures?

I prefer to have coded the joints in a class to contruct the homogenious 
transfo. that only need one parameter (\theha_i or d_i) than a class that 
need 12/16 parameters every time that I move a joint to construct the result 
homogenius transfo.
>
> [...]
>
> > > 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. 

Maybe I'm wrong, but I have read in some place (papers) about that exist 
nomenclatures singularity free. Or this is a myth?

> (Note that these singularities are _artificial_,
> i.e., due to the chosen representation, and not due to physical
> singularities of the kinematic chain.)

Sure.

[...]

Leo