[ros-users] Current state of SMACH in ROS

[Ingo Lütkebohle]

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