From ros-users-bounces@code.ros.org Sun Feb 19 22:06:26 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 476DC68156; Sun, 19 Feb 2012 22:06:26 -0800 (PST) X-Original-To: ros-users@code.ros.org Delivered-To: ros-users@code.ros.org Received: from georges.telenet-ops.be (georges.telenet-ops.be [195.130.137.68]) by pub5.willowgarage.com (Postfix) with ESMTP id EB0E268155 for ; Sun, 19 Feb 2012 22:06:24 -0800 (PST) Received: from roble.local ([94.224.160.30]) by georges.telenet-ops.be with bizsmtp id c66P1i0010feyny0666PrR; Mon, 20 Feb 2012 07:06:23 +0100 Date: Mon, 20 Feb 2012 07:06:23 +0100 (CET) From: Herman Bruyninckx X-X-Sender: herman@roble To: User discussions In-Reply-To: <4F4197E3.6020902@aist.go.jp> Message-ID: References: <4F3CDAAD.2030507@iri.upc.edu> <4F3D8406.1030305@techfak.uni-bielefeld.de> <4F4197E3.6020902@aist.go.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 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: Herman Bruyninckx , 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 Mon, 20 Feb 2012, Geoffrey Biggs wrote: > 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. ;) Absolutely! Coordinators can only do their job with components that are designed to be coordinated by independently developed FSMs :-) Easier said then done, though... :-( > Geoff Herman _______________________________________________ ros-users mailing list ros-users@code.ros.org https://code.ros.org/mailman/listinfo/ros-users