[ros-users] [Ros-developers] [Orocos-Dev] Proposal to restructure orocos_toolchain_ros

[Adolfo Rodríguez Tsouroukdissian]

On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits <ruben.smits at mech.kuleuven.be>wrote:

> Hi Peter,
>
> I'm also forwarding to ros-mailinglists, to make sure we don't miss any
> feedback from that community ;)
>
> On Friday 03 June 2011 00:16:17 Peter Soetens wrote:
> > I'd like to propose to restructure the orocos_toolchain_ros such that
> > new&existing users can more easily find their way. It's mainly about
> > renaming packages:
>
> This is indeed a issue that's waiting for a proposal.
>
> > 1. rtt_ros_integration -> rename to 'rtt_rosnode'
> > -> an import("rtt_rosnode") makes your process a ros node
>
> Looks ok to me
>
> > 2. rtt_ros_integration_xyz_msgs -> rename to 'rtt_xyz_msgs'
> > -> shorter notation, also makes it easier for users to update their
> > manifest file, just prefix with 'rtt_'
>
> Or make rtt a suffix? xyz_msgs_rtt?? And maybe even put them in a seperate
> stack
> (We only provide typekites for the common_msgs stack)
> -> common_msgs_rtt?
>
> > 3. rtt_ros_param -> rename to 'rtt_rosparam'
> > -> consistent naming scheme, service is also named 'rosparam' and not
> > 'ros_param'
>

> Look sane to me.
>
> > 4. rtt_ros_service -> ?
> > -> a bit confusing about what it does, I wonder if the code shouldn't
> > belong in rtt_rosnode instead, since it only provides the ros.topic()
> > operations, which make only sense when running in a rosnode... I would
> > also propose that this global 'ros' service is available from the
> > moment rtt_rosnode is imported. Today you need an extra
> > 'require("ros")' in scripting and something similar in lua.
>
> Maybe we could put the functionality of rospack, rosparam and the
> rtt_ros_service, all in the rtt_rosnode package?
>
> > What do the current users/devs think ?
>

+1 for succinct names, rtt_rosnode sounds fine.

+1 for merging rosnode, topics, services and parameters in a single package.
It makes sense to have a single package expose functionality available in
ROS through a single entity, the ros::NodeHandle class. Also, +1 for
allowing to import all of the functionality with a single statement. If
there is  a significant overhead or bloat if you only want to use part of it
(e.g., only topics), then also provide finer-grained import statements.

+1 for separating messages into different stacks. This will definitely
prevent dependency bloat. Again, I would aim for parallelism with the
structure of the original ROS stacks/packages (rtt_common_msgs <->
common_msgs). This will minimize mental transformations when mapping things
between the Orocos and ROS worlds.

Finally, if we're using rtt_* as prefix in most places, I'd rather write
rtt_common_msgs than common_msgs_rtt. I'm open to be convinced otherwise,
though.

Adolfo.


> If we do the renaming, we will brake a lot of existing applications, since
> we
> are still in the experimental versioning scheme 0.x, I don't have a problem
> with that but we have to communicate this name changing very clearly to our
> users.
>

> > Peter
>
> -- Ruben
> _______________________________________________
> ros-developers mailing list
> ros-developers at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-developers
>



-- 
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
contain confidential information which is privileged and intended only for
the individual or entity to whom they are addressed.  If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution or use of this e-mail and/or accompanying document(s) is
strictly prohibited.  If you have received this e-mail in error, please
immediately notify the sender at the above e-mail address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20110603/4ccd038b/attachment-0003.html>