On Mon, 20 Feb 2012, Ingo Lütkebohle wrote:

> On Mon, Feb 20, 2012 at 10:28 AM, Markus Klotzbuecher
> <markus.klotzbuecher@mech.kuleuven.be> 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.

FSM deal with (discrete) _behaviour_ of components, your 'task tracker' is
all about _data structures_ of where the execution of a task is wrt to
where it is expected to be. These are two very different concerns, so you'd
better keep them separate.

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

Herman