On Tuesday 12 October 2010 22:51:36 Stefan Kohlbrecher wrote:
> Hi Steven,
>
> > It's like you prefer to design your packages, but you don't need the
> > extra typekit package. You can just add the typekit generation to your
> > brtest_msgs package.
>
> Thanks for the hint, I think I´ll keep them seperated for now though,
> so pure ROS nodes using the messages don´t have to include the RTT
> dependencies.
>
> > Have you taken a look at the docs at
> > http://www.ros.org/wiki/orocos_toolchain_ros?
> > They should be self explaining, but in case something is not clear,
> > let us know and we'll extend them.
>
> Well it wasn´t totally clear to me because I had that wrong typekit
> path which lead me to believe something is amiss with the docs, when
> in reality that wasn´t the case. Having solved that, the integration
> seems to run fine (Just defining ROS messages in one place and using
> them across RTT and ROS really helps productivity and usability).
> So what I´m wondering about now isn´t totally related to the original
> problem like:
> -Is there something planned for carefree compatibility between RTT and
> ROS timestamps?
That depends on what you mean with carefree ;)
> -will services get exposed?
Yes.
This is on the roadmap, but will probably be the hardest to do. Services map
sort of onto the RTT/Operations because Services only provide a subset of the
capabilities of the RTT/Operations: RTT/Operations can be called both
asynchronous and synchronous while services can only be called synchronous.
> -will we have some mapping of ROS parameters into RTT?
Yes.
Also on the roadmap, this will probably be easier to implement, especially for
the basic types (string, ints, doubles etc.) For more complex types we will
have to rely on the lists which I have not studied in detail yet.
> But that might deserve another topic on the mailing list.
>
> regards,
> Stefan
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
(text/plain)