On Mon, Feb 20, 2012 at 10:28 AM, Markus Klotzbuecher wrote: > Thanks for your explanation, what you suggest seems a bit like a > component life-cycle FSM on steroids? Well, the distinction between the tasks and the internal component life-cycle is a bit unclear in the paper, I'm afraid. Both the Willow Garage people and myself mostly have experience with systems where components are /not/ using state-machines for their internal state. Thus, we didn't see this potential source of confusion until it was too late. The TSP only talks about the state of /tasks/, these being actions that a component performs. For components which have an internal life-cycle FSM, they usually only perform tasks while in their equivalent of a "running" state, but they may not constantly be performing tasks. For example, a trajectory planner may be ready for planning (i.e. the component is running, configured, and so on), but not actually do anything, until it gets a target input. We think it is useful to track not only the state of the components, but also the state of the tasks. In fact, we usually only track the tasks, not the components, but that is just implementation, not concept. It is expected that over the life-cycle of a component, it will process many tasks -- possibly even in parallel. > I agree it is worthwhile to > "standardize" this pattern, although I wonder if it encourages > creating "fatter" componentents opposed to lighter (and hence more > reusable) smaller ones? Have you gained any insights in this respect? My experience has been that we only make things explicit that have been there anyway. For example, many systems I have seen accept a new target implicitly as an update, while others queue them for later processing. Our state-machine makes that distinction explicit, and communicates it back to the originator. That said, the main difference to the state machines you have shown is update and cancel. Regarding these states, I can say that many of our tasks are executed without updates, either because they are very short, or it is otherwise not necessary, or would be difficult to implement. Our task toolkits make this simple, by providing default implementations which just refuse these requests. Cancels are also less used than the other states, even though are occasionally very important, mostly because using cancels well requires good decision making first as to when to use them, and that's often difficult. cheers, -- Ingo Lütkebohle Bielefeld University http://www.techfak.uni-bielefeld.de/~iluetkeb/ PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B