On 11/05/2012 09:25 AM, Charles Lesire-Cabaniols wrote:
>
>
> 2012/11/2 Peter Soetens <peter [..] ...
> <mailto:peter [..] ...>>
>
>
>
> Op vrijdag 2 november 2012 schreef Sylvain Joyeux
> (sylvain [dot] joyeux [..] ... <mailto:sylvain [dot] joyeux [..] ...>) het
> volgende:
>
>
> Rock/ROS integration, part 1 <http://blog.rock-robotics.org />
> <http://fusion.google.com/add?source=atgs&feedurl=http://feeds.feedburner.com/rock-robotics/MMgF>
>
>
>
>
> ------------------------------------------------------------------------
>
> Rock/ROS integration, part 1
> <http://blog.rock-robotics.org/post/34755979078>
>
> Posted: 01 Nov 2012 05:19 AM PDT
>
> So … here’s the first of, hopefully not so many posts, about
> the Rock/ROS integration. Namely, we can now (almost) publish
> ports from Rock components on ROS — without changing a line of
> code in existing Rock components.
>
> This first part is about getting the Rock data on ROS topics.
> Direct benefit for Rock: Python, and LISP programmers can read
> and write data from/to ports of Rock components out of the
> box. Of course, it is only a first step.
>
> So, where are we so far ? oroGen can generate ROS message
> descriptions and the transport compile and work fine. The
> convertion code between the Rock data structures and ROS
> messages is not done yet (i.e. the messages are currently
> empty at runtime).
>
> Demonstration:
>
> [~/dev/rock-ros]% cat test.rb
> require 'orocos'
> Orocos.run 'message_producer::Task' => 'task' do
> task = Orocos::TaskContext.get 'task'
> task.configure
> task.start
> task.messages.create_stream(Orocos::TRANSPORT_ROS, '/test')
> sleep
> end
> [~/dev/rock-ros]% ruby1.9.1 test.rb
> [~/dev/rock-ros]% rxgraph
>
> Next step: convert between existing Rock types and existing
> ROS messages. I.e. being able to make tf and
> base/samples/RigidBodyState talk to each other.
>
>
>
> Hi Sylvain,
>
> Looks great! A few questions about it:
>
> Where is this integration actually implemented?
oroGen + some parts of rtt_integration moved into a ros transport
generic library, and extended (which could be used "manually").
> In the orogen magic?
> In typelib/typegen?
The right association would be typelib or orogen/typegen. typeGen *is* a
subset of oroGen. So, in oroGen.
> Is this back-portable to Orocos?
It is part of the orocos toolchain as soon as I merge my changes to the
orocos-toolchain repositories. In other words, it requires nothing in
packages that are not part of the orocos toolchain.
> How is this related to the developments in RTT master-flexiport branch?
OK ... I gave it a thought this week end. A *full* ROS transport, in
which people can publish or subscribe oroGen-registered data types on
*existing* ROS messages (i.e. base/samples/RigidBodyState on tf for
instance) does *not* require flexiport.

What flexiport will bring to the table is:
* related to ROS: the ability to map a given oroGen-registered data
type to various ROS transports
* in general: the ability to do type slicing in general, and in
particular to properly support subclassing (i.e. send a Pose type to an
Orientation port for instance).
>
> Charles.
>
>
> We also support the __name:=nodename command line arguments in
> case you wish to replace rtt_1351... With a meaningful name:
>
I am not using the rtt_integration stuff (even though everything will
work with it ...). oroGen currently initializes ROS itself in its
deployments. In any case, the problem is to find a proper *unique* name.
That would be part of the full rock integration (i.e. of the ability to
run ROS nodes and RTT components from within Rock seamlessly).