Hi Herman and Vijay,

coming in a bit late, so I'll join together a few replies. For
background: I've been working on an action library that, while not
currently in ROS, arrived at similar ideas as the actionlib.

One distinction of my task toolkit (called XTT, for extensible task
toolkit) is that its FSM describes the overall task state. That FSM is
exchangeable, but for an example of the currently used one, see
http://dl.dropbox.com/u/11612286/general-lcm-1.pdf

The goal of the task toolkit is to keep the client's and the server's
view of the common state reconciled as much as possible, allowing for
network latency. To do the reconciling, one possible option is to have
more state machines inside and that might in fact have been a good way
to go, but I only saw that in hindsight ;-)

On 15.09.2010 11:41, Herman Bruyninckx wrote:
>> I'm a bit confused. Firstly, why do we have to go further from a terminal
>> state?
> Because your robot will live on, so somewhere it will continue with
> something else.

It depends on whether your FSM describes the state of a component that
does something, or just the state of the action. The FSM in actionlib
only covers component state insofar as it pertains to its view of the
action state, so I would hold that it fundamentally does the latter.

It certainly makes sense for some components to also use an FSM as their
internal state description for other things, but actionlib can also be
used with components that don't.

> The _event_ that brought you in that 'terminal state' already provided that
> information! If you have to keep it in memory (which is often not a bad
> thing to do) then you have to store that in the "world model" stat(e)(us),
> and not waste a FSM state for that purpose.

Hmm. I concur in general, on the grounds that its better to have fewer
states, if you can do the same thing. I'm not as sure about the world
model argument, however.

If I understand the argument correctly, the goal of treating these
things as events instead of states is to make new events, leading to the
same states, possible. That appears good, but I wonder what the
consequences are.

In particular, I wonder if some tasks wouldn't be easier by splitting up
states (not indiscriminately, but a little bit). For that, I'm  taking
the stance of an external observer that is interested in the action
outcome to coordinate.

The component does the same thing in the "cancelled" and "done" states,
so, by your argument, that could be joined. However, if all I'm
interested in is the outcome, not the sequence of events that lead up to
it, splitting up the states makes that easier, because only two states
need to be observed, instead of many events.

Furthermore -- and this relates directly to your extensibility argument
-- if I always have to look at which event caused a state, all
components will have to be updated whenever a new event is introduced.
In contrast, if the basic distinctions are already given in the state,
nothing will have to be changed in such a case.

Would you agree?

Obviously, one could achieve the same with major and minor event types,
but I wonder if that wouldn't be adding complexity in one place to
remove it in another.

Best Regards,

-- 
Ingo Lütkebohle
fon: +49-521-106-12206
http://aiweb.techfak.uni-bielefeld.de/user/ingo-lutkebohle