Re: A nomenclature question

A Dilluns 07 Juliol 2003 12:01, Herman Bruyninckx va escriure:
> On Mon, 7 Jul 2003, Leopold Palomo Avellaneda wrote:
>
> [...]
>
> > > 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.
>
> There are two complementary issues involved here:
> - one needs only one parameter to encode the position of a joint, and
>   hence the relative position of two links;
> - one needs a full 6D transform to know the position and orientation
>   of each of the links (or their frames) in the world.
> So, the "convention" is all about modelling the kinematics in such a
> way that both issues are served best.

Ok, I agree. Let me think about it.

> [...]
>
> > > There 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?
>
> No, that's not a myth, but then you should use homegeneous
> transformation matrices. (Or some "minimized" form of them.) 

minimized form ... are you talking about to have some kind way to construct 
your homegeneous transformation matrices but with less parameters that 12?

> _Any_
> representation of relative position and orientation of frames or rigid
> bodies that uses 6 or less numbers will have representation
> singularities. Each and everyone of them.
> The mathematical proof of this fact is that there is no 3D single cover
> of SO(3) :-)

Ok

Leo