On Fri, Oct 7, 2011 at 1:03 PM, Axelrod, Benjamin <baxelrod@irobot.com> wrote:

While I understand the appeal of having a lean and mean core with no robotics code in it; the “R” in ROS does stand for robot… J


Yes, we've joked about the irony.

Another way to think of it is that we don't wish to couple the middleware with a particular robotics ontology. The less coupled each component is, the easier it is to continue to improve each component individually over time.

 - Ken
 

 

 

From: ros-users-bounces@code.ros.org [mailto:ros-users-bounces@code.ros.org] On Behalf Of Ken Conley
Sent: Thursday, October 06, 2011 8:02 PM
To: User discussions
Subject: Re: [ros-users] frame_id in headers

 

This may be a case of telephone game (i.e. a misinterpretation), or perhaps there's yet-another mistake involved, but the way I would put it is: "making Header a first-class concept in ROS was a mistake."

Header is more of a "TF Header".  This has created couplings we wish we didn't have in the client library (roscpp, rospy) code.  Prior to ROS 1.0 we tried to cleanup the main ROS client library code to have no robotics in it; this is the one case that was too difficult to pull out due to the large amount of code that utilizes the Header data structure.

There is currently no alternative.  At some future point in time, where it's worth the cost of being 'clean', we can undo this, but it is currently the case that the costs of undoing it to end users far outweigh the benefit.  Our current resolution to this is that we migrated Header to be 'std_msgs/Header' and we will continue to try and de-specialize its role as much as backwards-compatibility allows.

 - Ken

On Thu, Oct 6, 2011 at 4:39 PM, Geoffrey Biggs <geoffrey.biggs@aist.go.jp> wrote:

Morning all,

I've heard occasionally from various people that putting frame_id in the Header is considered a design mistake that we're now stuck with, at least until a new version where the API can be broken. Can anyone involved comment on why it's considered a mistake, and what the preferred alternative is?

Geoff
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users

 


_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users