Re: Re: A nomenclature question

On Tue, 1 Jul 2003, Leopold Palomo Avellaneda wrote:

[...]
> It's a very nice thing to have a generic library. However, I think
> that it's a very dificult thing to implement and mantain. After
> reading the document: http://www.orocos.org/kindyn-doc.html it would
> be very nice to have some kind of objects that represent a Serial321
> robot, or a Parallel321 or a Scara.

The Serial321 is already modelled in the current kinematics library of
Orocos (it's called lrl, for historical reasons, but we plan to extend
it to more general devices). It was modelled after the following papers:
@article{LowDubey86,
 author    = {Low, K. H. and Dubey, R. N.},
 title     = {A Comparative Study of Generalized Coordinates for
              Solving the Inverse-Kinematics Problem of a {6R} Robot
              Manipulator},
 journal   = IJRR,
 year      = {1986},
 volume    = {5},
 number    = {4},
 pages     = {69--88}
}

@article{Featherstone83b,
 author    = {Featherstone, Roy},
 title     = {Position and Velocity Transformations Between Robot
              End-Effector Coordinates and Joint Angles},
 journal   = IJRR,
 year      = {1983},
 volume    = {2},
 number    = {2},
 pages     = {35--45}
}

The Serial321 family includes most 6R "Puma-like" industrial robots. I have
some more extensions coded by students in matlab but not yet
integrated in the C++ code...

The Parallel321 does not exist in reality :-) It's just the simples
full 6D parallel structure with closed-form solutions.

> It could be great to have some kind of:
> move(myrobotSerial321,mycontroler,mypathgenerator,myendposition) 
> my question is about that how I can define a robot to have a mathematical 
> interface to play with?

This is the job we have to do now: give sensible names to the objects
and their methods and attributes, and adapt existing and future code
to use these names.

> I think that the nomeclature helps to define the homogeneous transformation 
> matrices, but I think that always you will need to define SOME parameters to 
> construct your representation of the robot. 

Indeed. And my suggestion is to use ad-hoc parameters for every
"family" of robots. And general homogeneous transformation matrices
("frames") for general architectures.

> > I don't see the advantage of choosing TCS: not that it is bad, but
> > what real advantage does it bring to make contributors learn a
> > particular _convention_? 
> 
> I agree. But you always will need some kind of parameters in the 
> implementation. For example. I would like to simulate, or I would like to 
> construct a new 8DOF arm. I have my phisical prototype constructed with 
> Mecano pieces, some kind of servos, and some control. I would like to make 
> simulations and of the robot to experiment some control algorithm to after 
> put it in the real model. I would like to construct my virtual model and I 
> will need to caracterize this robot to play with. I will need to specifie the 
> parameters. If I use some nomenclature or another maybe in thery will be not 
> important, but I think that it could be important internally to have some 
> kind of consistent library. 

Yes, but that is not difficult: place frames in the joints, define
which of the X, Y or Z axes is your joint axis, define the "zero"
point and the joint limits, and give the relative transformation
between two subsequent joint frames in the "zero" position. Done :-)
Then the programming/user interface is at two levels:
- joint level: just use numbers from 1 to N;
- Cartesian level: place a reference frame where you like (TCP
  offset), and specify your actions in this frame.

[...]
> >  Just let a designer  define his coordinate frames in what seems the most 
> > appropriate way  for a particular mechanism. 
> This is very easy to say but very difficult to implement. 

On the contrary: someone who is designing a device most often has
already an appropriate conceptual model of the thing in his mind.

> > For that mechanism, the efficient  kinematics have to be coded anyway. And 
> > for the "external" use of the  device, all that counts is the tool centre 
> > point or end effector frame.
> 
> Yes and not. You maybe would want to know where is the 3th link because you 
> have a constraint and that link cannot pass some dimension.
> 
Ok, this should be possible. But I don't see why the choice of frame
nomenclature and convention could have any influence on this problem...

Herman

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