[prev in list] [next in list] [prev in thread] [next in thread] 

List:       orocos-dev
Subject:    [Orocos-Dev] Adding joint limits to the Joint description in KDL
From:       Herman.Bruyninckx () mech ! kuleuven ! be (Herman Bruyninckx)
Date:       2008-07-24 8:58:57
Message-ID: alpine.DEB.1.00.0807240855330.11776 () roble
[Download RAW message or body]

On Wed, 23 Jul 2008, Ruben Smits wrote:

> On Wednesday 23 July 2008 15:41:02 Herman Bruyninckx wrote:
>> On Wed, 23 Jul 2008, Alexis Maldonado wrote:
>>> Hi *,
>>>
>>> This is a small patch to the Joint class of KDL to add storage of joint
>>> limits. We hope to use them in some new inverse kinematic solvers, and
>>> Ruben Smits (sitting next to me at a summer school) suggested this
>>> change.
>>
>> Thanks! But in my opinion, this is only a short term solution :-) Why?
>> Because some solvers will also need limits on the joint velocities, or
>> joint accelerations, or joint torques, etc. We should not add all these to
>> the generic Joint class, since then that becomes too overloaden.
>
> I can remember a discussion about the different levels of the KDL classes in
> the sence that you can have a Position level, a Velocity level and an
> Acceleration level. Each of this levels adds level specific properties to the
> Joint:

Indeed...

> This will result in the following for the joint:
>
> Position level:
> - get the cartesian pose of the joint (using joint position value), see
> Joint::pose in the API
> - position limits
> - stiffness

The stiffness could also be a _function_, if it is nonlinear (which it
normally is...).

> Velocity level adds:
> - get the cartesian velocity of the joint (using the joint velocity value),
> see Joint::twist int the API
> - velocity limits
> - damping
>
> Acceleration level adds:
> - get the acceleration of the joint (we do not have this yet)
> - acceleration limits
> - mass
The "mass" is then the mass of the motor shaft? Because the Body should
contain the link inertia...

> I'm not really sure where the torque values/properties should be added.
That's one of the reasons I think it might be good to take these properties
outside of the Joint class... (And into the Solver and Chain, maybe...?)

I don't know for sure yet where they belong best...

Herman


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

[prev in list] [next in list] [prev in thread] [next in thread]