[Rock-dev] What's next in the ruby/typelib bridge

Sylvain Joyeux sylvain.joyeux at m4x.org
Fri Jan 14 12:42:36 CET 2011


Short explanation
=================
In the near future (read: sometime next week), there will be a *real* 
mapping between C++ and Ruby. What it means is that

   my_struct.time

will no longer return something that has a #microseconds field, but a 
Ruby Time.

In the same way,

   rbs.position

will return a Ruby Eigen::Vector3d instead of something that has a #data 
field.

And your scripts will be broken, but that's for the best.

When I do this migration, there will be a table on the package directory 
pages showing all existing convertions.

Moreover, when using orocos.rb, the types will be made accessible 
through Ruby namespaces, i.e. one will be able to do

v = Types::Base::Vector3d.new

instead of Orocos.registry.get('/base/Vector3d').new

Long explanation
================

As some of you may have read

   http://rock-robotics.org/runtime/ruby_and_types.html

the Ruby/Typelib bridge has a way to add custom convertion/extensions 
for types defined in an oroGen interface. The goal being that we can use 
Ruby-defined types to manipulate the types we get to and we write from 
Orocos components.

For instance, there is a default convertion to the Ruby Time class. It 
means that

   laser_sample.time

actually returns a Ruby Time. Which has all the methods you would expect 
from a time class (i.e. adding a time and a number, substracting two 
times, ...)

In the same way, I developped a small Eigen/Ruby binding that allows you 
to have

   rigid_body_state.orientation

return a feature-rich Eigen::Quaternion type instead of the basic C++ type.

However, until now, there was two things in place that are going to change.

The first one is that, when I introduced this mechanism, I kept backward 
compatiblity. It meant that the value returned by laser_sample.time also 
had #seconds and #microseconds methods, so that people could run the 
scripts on /base/Time and on the "converted time" too. That's going to 
be removed.

The second one is that, until now, the conversion was done "on the fly". 
That means that if the Ruby-side Eigen::Vector3d had a normalize!() 
method that *changes the vector instance*, then

   rigid_body_state.position.normalize();

would actually *not* change the value of rigid_body_state.position. The 
reason being that what is being done is

   rigid_body_state.position => return copy converted to Eigen::Vector3d

This will be fixed, and made completely transparent. I.e.

   rigid_body_state.position

will return always the same Eigen::Vector3d object. Idem for arrays 
(converted when accessed) and std::vector (converted to Array).

Moreover, I fixed the "assign Ruby Array to Typelib Array" and "assign 
Ruby Array to std::vector" bugs, i.e. will be able to do

   my_type.array_of_time = [Time.now, Time.now]

Sylvain


More information about the Rock-dev mailing list