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
>
>