From ros-users-bounces@code.ros.org Sun Feb 19 16:46:30 2012 Return-Path: X-Original-To: www-data@code.ros.org Delivered-To: www-data@code.ros.org Received: from pub5.willowgarage.com (localhost [127.0.0.1]) by pub5.willowgarage.com (Postfix) with ESMTP id B332868156; Sun, 19 Feb 2012 16:46:30 -0800 (PST) X-Original-To: ros-users@code.ros.org Delivered-To: ros-users@code.ros.org Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by pub5.willowgarage.com (Postfix) with ESMTP id 9F5FE68155 for ; Sun, 19 Feb 2012 16:46:29 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id q1K0kRfv016233 for ; Mon, 20 Feb 2012 09:46:27 +0900 (JST) env-from (geoffrey.biggs@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1329698788; bh=wBx8Mmz5gIshiCYCIWuWfqRAQ3SeNaSeC1E/BWRSbL4=; h=Message-ID:Date:From; b=QlId13xDZ7uOmjG2BBvaeFA8TKxpoldwtDcvlQarA7cmZWkaTX53LijSP0Nj2oLgW gj4PLmwM8RdYQwSm7kwHeI5/x+EaTebtc9LHAG7qUeNTAk46+1tA6OXe4gME9Bqoyu H6523CYw859yPAfHO4T4zQ3+c9W3me25TqkkGjSc= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id q1K0kRrH018439 for ; Mon, 20 Feb 2012 09:46:27 +0900 (JST) env-from (geoffrey.biggs@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id q1K0kRv5011553 for ; Mon, 20 Feb 2012 09:46:27 +0900 (JST) env-from (geoffrey.biggs@aist.go.jp) Message-ID: <4F4197E3.6020902@aist.go.jp> Date: Mon, 20 Feb 2012 09:46:27 +0900 From: Geoffrey Biggs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120112 Thunderbird/9.0 MIME-Version: 1.0 To: ros-users@code.ros.org References: <4F3CDAAD.2030507@iri.upc.edu> <4F3D8406.1030305@techfak.uni-bielefeld.de> In-Reply-To: Subject: Re: [ros-users] Current state of SMACH in ROS X-BeenThere: ros-users@code.ros.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: User discussions List-Id: User discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ros-users-bounces@code.ros.org Errors-To: ros-users-bounces@code.ros.org On 20/02/12 02:11, Herman Bruyninckx wrote: > If I understand correctly what you mean, my short answer is "yes"! The > Coordinator just does the event processing, and most of the events > resulting from this will trigger re-configurations of the components that > process the data flow. In other words, there is no need for the FSM to do > the data flow itself. Take the obvious example of the Board of a company: > their decisions are not processing the data in the company itself, but are > giving signals to the upper management to change something in the way the > whole company deals with its data (or products, for that matter). > That's also the reason why a good manager can job-hop to companies with > very different activities without much problems: his coordination skills > are reusable, even with limited domain knowledge :-) This is the approach we take. It works well so far, both for "good" and "bad" events. It does have the disadvantage, which Ingo also pointed out, that the components either need to be designed with the method in mind or need to be some form of stateless. In my opinion, however, if you are doing proper loose coupling then it's not *that* special, so components that are not designed like that probably need fixing. ;) Geoff _______________________________________________ ros-users mailing list ros-users@code.ros.org https://code.ros.org/mailman/listinfo/ros-users