I've been informed of YAKL (Yet Another Kinematics Library), called RobWork.
The library is (not so surprisingly) very similar to KDL: 3D/2D vectors,
frames, path planning, inverse & forward kinematics, serial chains etc.
Nothing KDL can't do and from a historical perspective, a redundant effort.
Well, if it wasn't for a 'tiny little thing' RobWork got better: their
vector/matrix operations have an open, portable interface, KDL doesn't.
Every RobWork kinematics datatype (e.g. Vector3D, Pose6D,... see
derives from a boost::ublas matrix. This means that within RobWork, they use
the 'user friendly' data types, but they can interface to external algorithms
*and* user defined matrices on the ublas level. Something a KDL user can't
do.
The rationale is straight forward: ublas offers a lot of algorithms, and a
standard matrix interface, RobWork adds a thin layer of type safety or user
readability in a 'kinematics context'. KDL does not need to be any different,
the only thing it needs to do is to derive from a ublas matrix type (or the
robwork data type) instead of using internal 'closed' data storage.
KDL::Frame kf;
rw::math::Pose6D<> rwf;
// ...
kf = rwf;
rwf = kf;
I'm confident that the RobWork people will continue their effort and the KDL
people theirs. I don't mind for that part, different problems (if they are?),
different solutions. But not standardising on the data type level, that would
be a shame. An additional argument is that the RobWork group is using the RTT
and could in this way become a user of (part of) KDL as well and vice versa,
as RobWork and KDL can smoothly interoperate.
That wouldn't be a unique case, check out these libraries that use ublas, and
hence would become compatible with KDL:
and these are just from the top 20 results of google.
Food for thought before KDL 1.0 ?
Peter
KDL & RobWork - make it work ?
On Wed, 2 May 2007, Peter Soetens wrote:
> I've been informed of YAKL (Yet Another Kinematics Library), called RobWork.)
>
> The library is (not so surprisingly) very similar to KDL: 3D/2D vectors,
> frames, path planning, inverse & forward kinematics, serial chains etc.
> Nothing KDL can't do and from a historical perspective, a redundant effort.
> Well, if it wasn't for a 'tiny little thing' RobWork got better: their
> vector/matrix operations have an open, portable interface, KDL doesn't.
>
> Every RobWork kinematics datatype (e.g. Vector3D, Pose6D,... see
>
> derives from a boost::ublas matrix. This means that within RobWork, they use
> the 'user friendly' data types, but they can interface to external algorithms
> *and* user defined matrices on the ublas level. Something a KDL user can't
> do.
This is a trade-off in making oneself dependent on one particular
matrix 'standard'. But there are worse dependencies than this Boost
dependency :-)
> The rationale is straight forward: ublas offers a lot of algorithms,
Such as....? Multiplication and addition... Not really much more, unless I
am very mistaken...
[...]
> I'm confident that the RobWork people will continue their effort and the KDL
> people theirs. I don't mind for that part, different problems (if they are?),
> different solutions.
I don't think so! This would absolutely be a waste of efforts...
> But not standardising on the data type level, that would
> be a shame. An additional argument is that the RobWork group is using the RTT
> and could in this way become a user of (part of) KDL as well and vice versa,
> as RobWork and KDL can smoothly interoperate.
They should merge, in my opinion...
> That wouldn't be a unique case, check out these libraries that use ublas, and
> hence would become compatible with KDL:
>
>
>
Not very relevant for us...
>
Seems to be dead... But the same argument of KLD-RobWork holds for this
project and BFl...
>
Dead too...? jeez, why didn't these people cooperate with BFL from the
beginning! They mention the project and its complementarity, yet they
decided to start another project on their own... Sigh...
But maybe we can recycle something in BFL.
> and these are just from the top 20 results of google.
Please, try to filter the relevant ones...
> Food for thought before KDL 1.0 ?
Yes! Depends on how much the RobWork group wants to adapt in order to
merge...
Herman
KDL & RobWork - make it work ?
On Wednesday 02 May 2007 13:32:18 Herman Bruyninckx wrote:)
> On Wed, 2 May 2007, Peter Soetens wrote:
> > I've been informed of YAKL (Yet Another Kinematics Library), called
> > RobWork.
> > The library is (not so surprisingly) very similar to KDL: 3D/2D vectors,
> > frames, path planning, inverse & forward kinematics, serial chains etc.
> > Nothing KDL can't do and from a historical perspective, a redundant
> > effort. Well, if it wasn't for a 'tiny little thing' RobWork got better:
> > their vector/matrix operations have an open, portable interface, KDL
> > doesn't.
> >
> > Every RobWork kinematics datatype (e.g. Vector3D, Pose6D,... see
> >
> > derives from a boost::ublas matrix. This means that within RobWork, they
> > use the 'user friendly' data types, but they can interface to external
> > algorithms *and* user defined matrices on the ublas level. Something a
> > KDL user can't do.
>
> This is a trade-off in making oneself dependent on one particular
> matrix 'standard'. But there are worse dependencies than this Boost
> dependency :-)
>
> > The rationale is straight forward: ublas offers a lot of algorithms,
>
> Such as....? Multiplication and addition... Not really much more, unless I
> am very mistaken...
Ublas itself is interface and matrix operations mainly. For the algorithms,
you need an additional library ATLAS/LAPACK/...
which is not part of ublas and not (yet) distributed with boost. RobWork
distributes this bindings library as well. See for the bindings lib here:
>
> [...]
>
> > I'm confident that the RobWork people will continue their effort and the
> > KDL people theirs. I don't mind for that part, different problems (if
> > they are?), different solutions.
>
> I don't think so! This would absolutely be a waste of efforts...
If the data types are compatible, I'm hoping there will be quickly a survival
of the fittest.
>
> Dead too...? jeez, why didn't these people cooperate with BFL from the
> beginning! They mention the project and its complementarity, yet they
> decided to start another project on their own... Sigh...
> But maybe we can recycle something in BFL.
>
> > and these are just from the top 20 results of google.
>
> Please, try to filter the relevant ones...
I didn't check for life-signs.
>
> > Food for thought before KDL 1.0 ?
>
> Yes! Depends on how much the RobWork group wants to adapt in order to
> merge...
We know their main argument (although it would be nice if they could confirm
in this discussion).
Peter
KDL & RobWork - make it work ?
On Wed, 2 May 2007, Peter Soetens wrote:
[...])
>>> Every RobWork kinematics datatype (e.g. Vector3D, Pose6D,... see
>>>
>>> derives from a boost::ublas matrix. This means that within RobWork, they
>>> use the 'user friendly' data types, but they can interface to external
>>> algorithms *and* user defined matrices on the ublas level. Something a
>>> KDL user can't do.
>>
>> This is a trade-off in making oneself dependent on one particular
>> matrix 'standard'. But there are worse dependencies than this Boost
>> dependency :-)
>>
>>> The rationale is straight forward: ublas offers a lot of algorithms,
>>
>> Such as....? Multiplication and addition... Not really much more, unless I
>> am very mistaken...
>
> Ublas itself is interface and matrix operations mainly. For the algorithms,
> you need an additional library ATLAS/LAPACK/...
>
> which is not part of ublas and not (yet) distributed with boost. RobWork
> distributes this bindings library as well. See for the bindings lib here:
>
>
Only simple algorithms, no SVD, for example. And no realtime guarantees.
I've been on these roads for decades already :-)
>> [...]
>>
>>> I'm confident that the RobWork people will continue their effort and the
>>> KDL people theirs. I don't mind for that part, different problems (if
>>> they are?), different solutions.
>>
>> I don't think so! This would absolutely be a waste of efforts...
>
> If the data types are compatible, I'm hoping there will be quickly a survival
> of the fittest.
Survival...? You must be kidding: none of the two projects have external
users yet, so survival is obvious :-)
Herman