[ros-users] Current state of SMACH in ROS

Ingo Lütkebohle iluetkeb at gmail.com
Mon Feb 20 12:23:11 UTC 2012


On Mon, Feb 20, 2012 at 12:47 PM, Herman Bruyninckx
<Herman.Bruyninckx at mech.kuleuven.be> wrote:
>> 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.

I'm not sure we're talking about the same thing here. The TSP models
state in a discrete fashion, with states such as "initiated"
(submitted by the client for execution), "accepted" (marked by the
server as executable), "running" (in execution), "completed/failed",
etc. The only _data structure_ it has contains metadata such as the id
of a task and its current state.

It is explicitly /not/ about the internal progress measure, which is
usually specific to the component. In fact, the separation between
these specific information items and the abstract state is one of the
central ideas. Thus, unless I understood you wrong, it explicitly
realizes the separation you're asking for.

best regards,

-- 
Ingo Lütkebohle
Bielefeld University
http://www.techfak.uni-bielefeld.de/~iluetkeb/

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B



More information about the ros-users mailing list