orocos/rtt_geometry

Orocos RTT typekits for Orocos KDL and Eigen types.

rtt_geometry's Issues

Readme

Hi,

Due to the very limited documentation of OROCOS, I have difficulties to integrate existing typekits into orocos rtt components.
Could you please point out/provide install instructions (without ROS/ROS2) and a minimum usage example?
Thanks in advance!

Move this repo to "orocos" organization

As per earlier discussions in orocos/rtt_ros_integration#7 (comment), it makes sense to move this repository to the orocos organization since it's dependent on the core toolchain.

eigen_typekit and kdl_typekit do not install package.xml

REP 136 (http://www.ros.org/reps/rep-0136.html) states that all packages should install a package.xml if released into ROS, and eigen_typekit and kdl_typekit do no do this.

It looks like you have these packages marked as Catkin package, but you don't call catkin_package anywhere in the CMakeLists.txt. In order to bring the packages back into spec, someone must either:

• Call catkin_package() from CMakeLists.txt
• Change package.xml to indicate a plain cmake package and use Bloom to patch the CMakeLists.txt to install the package.xml as instructed here: http://wiki.ros.org/bloom/Tutorials/ReleaseThirdParty#Adding_an_Install_Rule_as_a_Patch

See also ros/catkin#622

Thanks!

Migrate Eigen typekit from itasc to new eigen_typekit package

Currently, the eigen typekit can be found here: http://git.mech.kuleuven.be/?p=robotics/itasc_core.git;a=tree;f=src;h=8ed00b081d57b3a3f879734b39f7996ec080c71c;hb=HEAD

I'll do a git subtree merge from the itasc git to my fork and create a PR on this repo.

Original discussion: http://www.orocos.org/forum/orocos/orocos-users/eigen-typekit

Should we separate the ROS-dependent and non-ROS-dependent packages in rtt_geometry?

It was recently asked [1] on orocos-dev whether the eigen typekit can safely be removed from iTasc, but currently the rtt_geometry repo also has a bunch of stuff that depends on tf.

So, should we separate the ROS-dependent and non-ROS-dependent packages in rtt_geometry? We could potentially move the rtt_tf and rtt_kdl_conversions over to rtt_ros_integration since we already have some of the mid-level ROS interfaces in there like actionlib and soon dynamic_reconfigure.

http://lists.mech.kuleuven.be/pipermail/orocos-dev/2013-December/012717.html

Constructors in eigen_typekit are not thread-safe

Currently constructors in package eigen_typekit have a local instance of the respective type which is initialized and returned by reference from the implemented operator(). This is not thread-safe at all because constructors are singletons registered once when the typekit is loaded.

Each call to operator() should therefore return a new instance by value.

Arm compilation issue

On arm32 i'm having this linking issue :

CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.data.rel.ro+0xc): multiple definition of `typeinfo for RTT::Property<KDL::Wrench>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitWrench.cpp.o:(.data.rel.ro+0x18): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.data.rel.ro+0x18): multiple definition of `typeinfo for RTT::Property<KDL::Twist>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitTwist.cpp.o:(.data.rel.ro+0x18): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.data.rel.ro+0x30): multiple definition of `typeinfo for RTT::Property<KDL::Vector>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitVector.cpp.o:(.data.rel.ro+0x18): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.data.rel.ro+0x24): multiple definition of `typeinfo for RTT::Property<KDL::Rotation>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitRotation.cpp.o:(.data.rel.ro+0x18): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.data.rel.ro+0x0): multiple definition of `typeinfo for RTT::Property<KDL::Frame>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitFrame.cpp.o:(.data.rel.ro+0x18): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.rodata+0x0): multiple definition of `typeinfo name for RTT::Property<KDL::Frame>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitFrame.cpp.o:(.rodata+0x60): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.rodata+0x20): multiple definition of `typeinfo name for RTT::Property<KDL::Wrench>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitWrench.cpp.o:(.rodata+0x64): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.rodata+0x40): multiple definition of `typeinfo name for RTT::Property<KDL::Twist>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitTwist.cpp.o:(.rodata+0x60): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.rodata+0x60): multiple definition of `typeinfo name for RTT::Property<KDL::Rotation>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitRotation.cpp.o:(.rodata+0x68): first defined here
CMakeFiles/kdl_typekit.dir/src/motionproperties.cpp.o:(.rodata+0x84): multiple definition of `typeinfo name for RTT::Property<KDL::Vector>'
CMakeFiles/kdl_typekit.dir/src/kdlTypekitVector.cpp.o:(.rodata+0x64): first defined here
collect2: error: ld returned 1 exit status

Might be related to why kdl_typekit is not available in the debian repo ?

Support accessing eigen_matrix elements in eigen_typekit

I would like to use the [ , ]-operator for eigen_matrix to get and set elements.
I saw that there is already an attempt in the code to achieve that, but unfortunately, newTernaryOperator seems to be missing.

So I tried to get the input for a statement like this mat[0,1] by utilizing the getMember function for the MatrixTypeInfo.
Using the following cast, I am able to get the first index in this case 0, but not the second one.

RTT::internal::DataSource<int>::shared_ptr id_indx = RTT::internal::DataSource<int>::narrow( RTT::internal::DataSourceTypeInfo<int>::getTypeInfo()->convert(id).get() );

I don't know if it makes sense this way... Perhaps someone could point me in the right direction :)

Do not use namespace Eigen and KDL for Orocos types

From #26 (comment):

But the VectorTypeInfo<T> and related functions should not be exposed as part of the Eigen namespace and deserve their own namespace eigen_typekit or similar instead. There might be some difficulties related to argument depending lookup. For example, the istream streaming operators should be defined in the RTT::types namespace so that they will be found by the implementation of TypeStreamSelector without having to "pollute" the Eigen namespace. An alternative to define streaming operators is to specialize this template class for Eigen types and don't use the streaming operators at all.

Error loading libkdl-transport-mqueue-gnulinux.so through docker when openGL is enabled

Hi,

When running an (etasl) orocos application through docker, kdl_typekit loads without problem when openGL forwarding (so hardware acceleration) is disabled.
However, when the forwarding is enabled (adding '--device=/dev/dri:/dev/dri ' and '-v=/dev/dri:/dev/dri:rw' to docker run), I get the following error (with shortened paths)

.816 [ ERROR ][ComponentLoader::import(path_list)] could not load library '/kdl_typekit/lib/orocos/gnulinux/kdl_typekit/types/libkdl-transport-mqueue-gnulinux.so': /kdl_typekit/lib/orocos/gnulinux/kdl_typekit/types/libkdl-transport-mqueue-gnulinux.so: undefined symbol: _ZNK3RTT4base18ChannelElementBase15isRemoteElementEv
0.816 [ ERROR ][ComponentLoader::import(path_list)] Some found plugins could not be loaded !
0.819 [ ERROR ][/opt/ros/indigo/bin/rttlua-gnulinux::main()] Exception raised while executing an operation : Some found plugins could not be loaded !
/opt/ros/indigo/bin/rttlua-gnulinux: /opt/ros/indigo/share/lua/5.1/rttlib.lua:762: Operation.call: caught exception 'Unable to complete the operation call. The called operation has thrown an exception'
stack traceback:
[C]: in function 'op'
/opt/ros/indigo/share/lua/5.1/rttlib.lua:762: in function 'import'
...igo/etasl/share/etasl_rtt_examples/custom/deploy.lua:22: in function 'initializePackages'
...igo/etasl/share/etasl_rtt_examples/custom/deploy.lua:152: in function 'deploy'
...igo/etasl/share/etasl_rtt_examples/custom/deploy.lua:199: in main chunk

Do I have to compile kdl differently when openGL will be used?

Best,
Broes

Should we move kdl_lua into the orocos_kinematics_dynamics repository?