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:
1. rtt_ros_integration -> rename to 'rtt_rosnode'
-> an import("rtt_rosnode") makes your process a ros node
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_'
3. rtt_ros_param -> rename to 'rtt_rosparam'
-> consistent naming scheme, service is also named 'rosparam' and not
'ros_param'
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.
What do the current users/devs think ?
Peter
Proposal to restructure orocos_toolchain_ros
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 ?
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
Proposal to restructure orocos_toolchain_ros
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 ?
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] Proposal to restructure orocos_toolchain_ros
On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits <ruben [dot] smits [..] ...>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 [..] ...
> https://code.ros.org/mailman/listinfo/ros-developers
>
[Ros-developers] Proposal to restructure orocos_toolchain_ros
On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits <ruben [dot] smits [..] ...>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 [..] ...
> https://code.ros.org/mailman/listinfo/ros-developers
>
[Ros-developers] Proposal to restructure orocos_toolchain_ros
On Friday 03 June 2011 09:23:36 Adolfo Rodríguez Tsouroukdissian wrote:
> On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits
<ruben [dot] smits [..] ...>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.
I agree here too. Let's stick to one prefix, and not start mixing with suffixes.
Target release for these changes ? We're in 0.x, so it can happen at any time,
but we should/must stick to 0.x == 2.x version mapping for clarity.
Peter
[Ros-developers] Proposal to restructure orocos_toolchain_ros
On Friday 03 June 2011 09:23:36 Adolfo Rodríguez Tsouroukdissian wrote:
> On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits
<ruben [dot] smits [..] ...>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.
I agree here too. Let's stick to one prefix, and not start mixing with suffixes.
Target release for these changes ? We're in 0.x, so it can happen at any time,
but we should/must stick to 0.x == 2.x version mapping for clarity.
Peter
[Ros-developers] Proposal to restructure orocos_toolchain_ros
On Tuesday 07 June 2011 11:08:12 Peter Soetens wrote:
> On Friday 03 June 2011 09:23:36 Adolfo Rodríguez Tsouroukdissian wrote:
> > On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits
>
> <ruben [dot] smits [..] ...>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.
>
> I agree here too. Let's stick to one prefix, and not start mixing with
> suffixes.
>
> Target release for these changes ? We're in 0.x, so it can happen at any
> time, but we should/must stick to 0.x == 2.x version mapping for clarity.
I would like to do one more release without the renaming, 0.4.0
We could do this in 0.4.1, but that seems odd, but I also do not want to wait
until 2.5 comes out.
Does anyone have a countervote to do it in 0.4.1?
> Peter
-- Ruben
[Ros-developers] Proposal to restructure orocos_toolchain_ros
On Tuesday 07 June 2011 11:08:12 Peter Soetens wrote:
> On Friday 03 June 2011 09:23:36 Adolfo Rodríguez Tsouroukdissian wrote:
> > On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits
>
> <ruben [dot] smits [..] ...>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.
>
> I agree here too. Let's stick to one prefix, and not start mixing with
> suffixes.
>
> Target release for these changes ? We're in 0.x, so it can happen at any
> time, but we should/must stick to 0.x == 2.x version mapping for clarity.
I would like to do one more release without the renaming, 0.4.0
We could do this in 0.4.1, but that seems odd, but I also do not want to wait
until 2.5 comes out.
Does anyone have a countervote to do it in 0.4.1?
> Peter
-- Ruben
[Ros-developers] Proposal to restructure orocos_toolchain_ros
2011/6/7 Ruben Smits <ruben [dot] smits [..] ...>
> On Tuesday 07 June 2011 11:08:12 Peter Soetens wrote:
> > On Friday 03 June 2011 09:23:36 Adolfo Rodríguez Tsouroukdissian wrote:
> > > On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits
> >
> > <ruben [dot] smits [..] ...>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.
> >
> > I agree here too. Let's stick to one prefix, and not start mixing with
> > suffixes.
> >
> > Target release for these changes ? We're in 0.x, so it can happen at any
> > time, but we should/must stick to 0.x == 2.x version mapping for clarity.
>
> I would like to do one more release without the renaming, 0.4.0
>
> We could do this in 0.4.1, but that seems odd, but I also do not want to
> wait
> until 2.5 comes out.
>
> Does anyone have a countervote to do it in 0.4.1?
>
>
ok for me
>
> > Peter
>
> -- Ruben
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[Ros-developers] Proposal to restructure orocos_toolchain_ros
2011/6/7 Ruben Smits <ruben [dot] smits [..] ...>
> On Tuesday 07 June 2011 11:08:12 Peter Soetens wrote:
> > On Friday 03 June 2011 09:23:36 Adolfo Rodríguez Tsouroukdissian wrote:
> > > On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits
> >
> > <ruben [dot] smits [..] ...>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.
> >
> > I agree here too. Let's stick to one prefix, and not start mixing with
> > suffixes.
> >
> > Target release for these changes ? We're in 0.x, so it can happen at any
> > time, but we should/must stick to 0.x == 2.x version mapping for clarity.
>
> I would like to do one more release without the renaming, 0.4.0
>
> We could do this in 0.4.1, but that seems odd, but I also do not want to
> wait
> until 2.5 comes out.
>
> Does anyone have a countervote to do it in 0.4.1?
>
>
ok for me
>
> > Peter
>
> -- Ruben
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
[ros-users] [Ros-developers] Proposal to restructure orocos_tool
2011/6/3 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
>
>
>
> On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits <ruben [dot] smits [..] ...>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.
>
I totally agree on those. The faster it is done the better :p
>
>
>> 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 [..] ...
>> 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.
>
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>
[ros-users] [Ros-developers] Proposal to restructure orocos_too
2011/6/3 Adolfo Rodríguez Tsouroukdissian <adolfo [dot] rodriguez [..] ...
>
>
>
> On Fri, Jun 3, 2011 at 8:40 AM, Ruben Smits <ruben [dot] smits [..] ...>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.
>
I totally agree on those. The faster it is done the better :p
>
>
>> 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 [..] ...
>> 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.
>
> _______________________________________________
> ros-users mailing list
> ros-users [..] ...
> https://code.ros.org/mailman/listinfo/ros-users
>
>