problems running recent KDL versions with ROS
| Submitted by Marcus Liebhardt on Thu, 2011-02-10 13:36 |
Dear developers,
we are having problems running recent versions of KDL with ROS.
Because KDL is locked under ROS, we had to come up with other ways to change
or extend existing KDL code. At the moment I'm creating new classes, when I
want to change existing KDL code or extend it. So, for example, I changed
the TreeFkSolverPos_recursive, named it TreeFkSolverPos_recursive_patched,
saved it in my own ROS package and used that one.
This is a possible workaround for patches, but annoying work. Additionally,
it is not possible or feasible, if I want to integrate new developments in
KDL.
We also tried to "overlay" the KDL package with a new version by changing
the ROS_PACKAGE_PATH. But this does not work for prebuild ROS parts. And if
we would build ROS from source, we probably will run into problems with ROS
parts relying on old versions of KDL.
So - at least for the moment - we run out of ideas ...
Does anybody have suggestions how to solve this problem? How do you handle
this on your machine?
Thanks for your help!
:-) Marcus
problems running recent KDL versions with ROS
Marcus,
> we are having problems running recent versions of KDL with ROS.
> Because KDL is locked under ROS, we had to come up with other ways to change
> or extend existing KDL code.
[...]
> We also tried to "overlay" the KDL package with a new version by changing
> the ROS_PACKAGE_PATH. But this does not work for prebuild ROS parts. And if
> we would build ROS from source, we probably will run into problems with ROS
> parts relying on old versions of KDL.
You should be able to overlay on any set of ROS packages, even if you
use precompiled Debian packages. Just make sure that your own version
of KDL comes first in your ROS_PACKAGE_PATH.
If you overlay on the Debian packages, you need to make sure that the
version of KDL you overlay is binary compatible with the version of
KDL in ROS. I think it's likely that this option won't work.
If you compile ROS from source, your version of KDL only needs to be
API compatible for the part of the KDL API that is used by other ROS
packages. If you're not modifying any core KDL classes, then this
option will work fine for you. As Ruben mentioned, you probably want
to overlay with the KDL package available from their git repo.
Wim
problems running recent KDL versions with ROS
Hi Wim!
We tried that already, but ran into problems exactly with the API
compatibility. For example, the interface of one solver changed in the way,
that it now returns a double instead of an int.
So, we expect similar problems in other parts of the ROS code.
But the suggestion of Ruben seems promising, especially because that package
has a different name. So, hopefully my code gets forced to take the new
stuff in orocos_kdl, instead of using old things from the kdl package.
We will try that out and will report about the results.
Thanks for your help!
:-) Marcus
2011/2/10 Wim Meeussen <meeussen [..] ...>
> Marcus,
>
> > we are having problems running recent versions of KDL with ROS.
> > Because KDL is locked under ROS, we had to come up with other ways to
> change
> > or extend existing KDL code.
> [...]
> > We also tried to "overlay" the KDL package with a new version by changing
> > the ROS_PACKAGE_PATH. But this does not work for prebuild ROS parts. And
> if
> > we would build ROS from source, we probably will run into problems with
> ROS
> > parts relying on old versions of KDL.
>
> You should be able to overlay on any set of ROS packages, even if you
> use precompiled Debian packages. Just make sure that your own version
> of KDL comes first in your ROS_PACKAGE_PATH.
>
> If you overlay on the Debian packages, you need to make sure that the
> version of KDL you overlay is binary compatible with the version of
> compatibility <http://www.dict.cc/englisch-deutsch/compatibility.html>
> KDL in ROS. I think it's likely that this option won't work.
>
> If you compile ROS from source, your version of KDL only needs to be
> API compatible for the part of the KDL API that is used by other ROS
> packages. If you're not modifying any core KDL classes, then this
> option will work fine for you. As Ruben mentioned, you probably want
> to overlay with the KDL package available from their git repo.
>
> Wim
>
> --
> --
> Wim Meeussen
> Willow Garage Inc.
> <http://www.willowgarage.com)
>
problems running recent KDL versions with ROS
Marcus,
> But the suggestion of Ruben seems promising, especially because that package
> has a different name. So, hopefully my code gets forced to take the new
> stuff in orocos_kdl, instead of using old things from the kdl package.
> We will try that out and will report about the results.
When you add a new kdl package with a different name, just make sure
that your own package does not depend on the ros kdl package. So make
sure your package does not depend on any other ros package that
directly or indirectly depends on the ros kdl package. Depending on
both kdl packages would cause the include flags of both kdl packages
to get propagated to your package, resulting in lots of trouble ;-)
Wim
problems running recent KDL versions with ROS
Wim,
On Friday 11 February 2011 19:59:50 Wim Meeussen wrote:
> Marcus,
>
> > But the suggestion of Ruben seems promising, especially because that
> > package has a different name. So, hopefully my code gets forced to take
> > the new stuff in orocos_kdl, instead of using old things from the kdl
> > package. We will try that out and will report about the results.
>
> When you add a new kdl package with a different name, just make sure
> that your own package does not depend on the ros kdl package. So make
> sure your package does not depend on any other ros package that
> directly or indirectly depends on the ros kdl package. Depending on
> both kdl packages would cause the include flags of both kdl packages
> to get propagated to your package, resulting in lots of trouble ;-)
How long will WillowGarage stick to the old kdl package in the geometry stack?
Is there still a compelling reason why you do not want to use the orocos_kdl
package in the orocos_kinematics_dynamics stack? How do you get bugfixes from
the orocos_kdl package into the geometry/kdl package?
> Wim
-- Ruben
problems running recent KDL versions with ROS
> How long will WillowGarage stick to the old kdl package in the geometry stack?
> Is there still a compelling reason why you do not want to use the orocos_kdl
> package in the orocos_kinematics_dynamics stack? How do you get bugfixes from
> the orocos_kdl package into the geometry/kdl package?
The kdl package currently lives in the geometry stack, together with a
number of other externally maintained libraries such as bullet and
eigen. But since these libraries do not necessary follow the same
lifecycle, it makes sense to split them into different stacks. For
E-turtle we're hoping to transition the kdl package into its own
stack, with its own maintainer. This could mean a merge of the kdl and
the orocos_kdl package.
For D-turtle we use a tar of the kdl repository, created at the time
the geometry stack got feature-frozen. We can update this tar with
bugfixes, but we can't accept any new features into D-turtle kdl.
Since kdl trunk regulary adds or modifies features (e.g. solvers), we
can't just pull the latest and greatest version into D-turtle. For
E-turtle we can pull in the latest version of kdl, as long as it's
backwards compatible with the D-turtle version of kdl.
Wim
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)
>
problems running recent KDL versions with ROS
On Thursday 10 February 2011 14:32:56 Marcus Liebhardt wrote:
> Dear developers,
>
> we are having problems running recent versions of KDL with ROS.
> Because KDL is locked under ROS, we had to come up with other ways to change
> or extend existing KDL code.
> At the moment I'm creating new classes, when I
> want to change existing KDL code or extend it. So, for example, I changed
> the TreeFkSolverPos_recursive, named it TreeFkSolverPos_recursive_patched,
> saved it in my own ROS package and used that one. This is a possible
> workaround for patches, but annoying work. Additionally, it is not possible
> or feasible, if I want to integrate new developments in KDL. We also tried
> to "overlay" the KDL package with a new version by changing the
> ROS_PACKAGE_PATH. But this does not work for prebuild ROS parts. And if we
> would build ROS from source, we probably will run into problems with ROS
> parts relying on old versions of KDL.
>
> So - at least for the moment - we run out of ideas ...
>
> Does anybody have suggestions how to solve this problem? How do you handle
> this on your machine?
I suggest you use the orocos_kdl package of our orocos_kinematics_dynamics
stack which is available from
git.mech.kuleuven.be/robotics/orocos_kinematics_dynamics.git
All new KDL development will happen in this git repository.
> Thanks for your help!
>
> :-) Marcus
--Ruben