writing an "ad oc" joint in KDL
| Submitted by gianni borghesan on Wed, 2011-12-14 15:51 |
Dear all,
I was wondering which the simplest way to get a joint that is not
covered by the already availble.
let say that i want a prismatic joint that moves on a curve (i.e. a
slider that follows a not straight rail) of which I have the explicit
relation between the q and pose, ad q_dot and the twist.
Then i want to attach to it other segment/joints, and take advantage of
the nice functions to compute the robot Jacobian, Forward and Inverse
kinematic.
Which is the way i should follow?
Cheers, Gianni.
KDL
Hello,
I am trying the mailing list for the first time. I have been trying to
build the KDL on windows (and mac) with no success. I have found a few
posts like this one:
http://www.orocos.org.binary.priorweb.be/forum/orocos/orocos-users/oroco...
but still there seems to be no answer. The installation page is 4 steps,
so its not very helpful. Now I am wondering if KDL is supported on
windows, can I only build the KDL with python bindings or do I need the RTT
or ROS as well? Ive been working with two computer scientists who have
been stumped as well as to how this can build on windows. Can anyone help
out at all or has support for orocos ended?
Thanks,
Mat
writing an "ad oc" joint in KDL
On Wednesday 14 December 2011 16:51:36 gianni borghesan wrote:
> Dear all,
> I was wondering which the simplest way to get a joint that is not
> covered by the already availble.
> let say that i want a prismatic joint that moves on a curve (i.e. a
> slider that follows a not straight rail) of which I have the explicit
> relation between the q and pose, ad q_dot and the twist.
> Then i want to attach to it other segment/joints, and take advantage of
> the nice functions to compute the robot Jacobian, Forward and Inverse
> kinematic.
>
> Which is the way i should follow?
As the design is today, you can add the joint to the joint.hpp/cpp. This
should be enough to get it working.
In the long run we could make the Joint an abstract interface class and let
the specific joint implementations inherit from this interface class. This
would be a lot more work, especially if we want to keep it backwards
compatible.
> Cheers, Gianni.
Ruben
writing an "ad oc" joint in KDL
On Thu, 15 Dec 2011, Ruben Smits wrote:
> On Wednesday 14 December 2011 16:51:36 gianni borghesan wrote:
>> Dear all,
>> I was wondering which the simplest way to get a joint that is not
>> covered by the already availble.
>> let say that i want a prismatic joint that moves on a curve (i.e. a
>> slider that follows a not straight rail) of which I have the explicit
>> relation between the q and pose, ad q_dot and the twist.
>> Then i want to attach to it other segment/joints, and take advantage of
>> the nice functions to compute the robot Jacobian, Forward and Inverse
>> kinematic.
>>
>> Which is the way i should follow?
>
> As the design is today, you can add the joint to the joint.hpp/cpp. This
> should be enough to get it working.
>
> In the long run we could make the Joint an abstract interface class and let
> the specific joint implementations inherit from this interface class. This
> would be a lot more work, especially if we want to keep it backwards
> compatible.
In Gianni's case, I would rather introduce a "kinematic family" of this
particular mechanism (since it _is_ more of a mechanism, not a "joint").
We want joints to be reused by everyone; Gianni's mechanism will not.
>> Cheers, Gianni.
>
> Ruben
Herman
writing an "ad oc" joint in KDL
On Thursday 15 December 2011 11:54:05 Herman Bruyninckx wrote:
> On Thu, 15 Dec 2011, Ruben Smits wrote:
> > On Wednesday 14 December 2011 16:51:36 gianni borghesan wrote:
> >> Dear all,
> >> I was wondering which the simplest way to get a joint that is not
> >> covered by the already availble.
> >> let say that i want a prismatic joint that moves on a curve (i.e. a
> >> slider that follows a not straight rail) of which I have the explicit
> >> relation between the q and pose, ad q_dot and the twist.
> >> Then i want to attach to it other segment/joints, and take advantage
> >> of
> >> the nice functions to compute the robot Jacobian, Forward and Inverse
> >> kinematic.
> >>
> >> Which is the way i should follow?
> >
> > As the design is today, you can add the joint to the joint.hpp/cpp. This
> > should be enough to get it working.
> >
> > In the long run we could make the Joint an abstract interface class and
> > let the specific joint implementations inherit from this interface
> > class. This would be a lot more work, especially if we want to keep it
> > backwards compatible.
>
> In Gianni's case, I would rather introduce a "kinematic family" of this
> particular mechanism (since it _is_ more of a mechanism, not a "joint").
> We want joints to be reused by everyone; Gianni's mechanism will not.
I didn't know it was a mechanism. But if the mechanism has only 1 DOF a joint
(or link) would be an easy way of introducing it into KDL's solver mechanism.
> >> Cheers, Gianni.
> >
> > Ruben
>
> Herman
Ruben
writing an "ad oc" joint in KDL
Il giorno gio, 15/12/2011 alle 11.58 +0100, Ruben Smits ha scritto:
> On Thursday 15 December 2011 11:54:05 Herman Bruyninckx wrote:
> > On Thu, 15 Dec 2011, Ruben Smits wrote:
> > > On Wednesday 14 December 2011 16:51:36 gianni borghesan wrote:
> > >> Dear all,
> > >> I was wondering which the simplest way to get a joint that is not
> > >> covered by the already availble.
> > >> let say that i want a prismatic joint that moves on a curve (i.e. a
> > >> slider that follows a not straight rail) of which I have the explicit
> > >> relation between the q and pose, ad q_dot and the twist.
> > >> Then i want to attach to it other segment/joints, and take advantage
> > >> of
> > >> the nice functions to compute the robot Jacobian, Forward and Inverse
> > >> kinematic.
> > >>
> > >> Which is the way i should follow?
> > >
> > > As the design is today, you can add the joint to the joint.hpp/cpp. This
> > > should be enough to get it working.
> > >
> > > In the long run we could make the Joint an abstract interface class and
> > > let the specific joint implementations inherit from this interface
> > > class. This would be a lot more work, especially if we want to keep it
> > > backwards compatible.
> >
> > In Gianni's case, I would rather introduce a "kinematic family" of this
> > particular mechanism (since it _is_ more of a mechanism, not a "joint").
> > We want joints to be reused by everyone; Gianni's mechanism will not.
>
> I didn't know it was a mechanism. But if the mechanism has only 1 DOF a joint
> (or link) would be an easy way of introducing it into KDL's solver mechanism.
>
This problem is not (so) peculiar: for example, just some days ago, I
have ben asked how you can take advantage of forward/inverse kinematics
of KDL if you have a coupled joint system ( 2 joints with 1 DoF in
total, a quite common encounter in robotic hands), and probably he has
to go more or less in the direction Ruben pointed.
> > >> Cheers, Gianni.
> > >
> > > Ruben
> >
> > Herman
>
> Ruben
>