IEEE Robotics & Automation Magazine - December 2010 - 20

that SMACH state machines also have outcomes of their own.
These outcomes are treated like other transition targets (like
states) in the state machine.
Another simple execution policy is the SMACH
Concurrence. Unlike a StateMachine, which executes
one state at a time in series, the Concurrence executes
more than one state simultaneously. Concurrences are also
states as well, and their outcomes can be determined by one of
several outcome policies defined at construction.

Data Driven
SMACH is not the first architecture to allow users to define hierarchical, concurrent state machines, as these are very old concepts
[3], and people often implement their own state machine API,
markup language, or model. State machines built with SMACH,
however, can diverge from formal state machines with some features unique to SMACH. Each SMACH container has a locally
scoped dictionary of user data that can be accessed by each of its
child states. This allows states to access data that was written by
previously executed states. While this makes analysis more complex, it also makes the system far more powerful since not only
can data be passed around, but data can also be accumulated from
various states to inform a branch later in execution. This means
that the "full" state of a SMACH tree at any given time is the
union of the active task-level states in each container and the contents of dictionary of user data in each container.
Since SMACH is written in Python, any type of Python
object can be stored in a container's user data dictionary. This
includes, for example, ROS message types. Most of the widely
used planning and execution frameworks opt to use their own
languages for describing either plans or information used to
generate plans. While these languages are usually better
designed for this role, it means that support for user-defined
types that can be processed by lower level systems requires
defining and binding data structure translation functions
where the executive interacts with these systems. SMACH's
ability to directly manipulate these structures allows us to
coordinate not only tasks with SMACH but also their associated input arguments and result data.

SimpleActionState: It is a state that represents the
execution of a ROS actionlib action. This is one of
the most used task-abstraction layer in ROS. This state
can be given goal generation and result processing callbacks similar to ServiceState, as well as other goal
and result policies.

Visualization
In addition to ROS tools for visualizing and analyzing data
flow over the network, SMACH adds a tool for analyzing
high-level systems at run-time. Task-level failures are difficult to debug, since they often happen at the system integration points, so this places a large burden on the execution
framework to provide adequate debugging and visualization tools.
We have developed an introspection system that renders
the structure of a SMACH plan, highlights the executing
states at run-time, and lists the contents of the user data
dictionary for a given container. This interface allows a
developer to quickly identify errors in specifying connections
between different states and observe immediately what the
executive is trying to do.
Since the graph shown in the SMACH viewer maps directly
onto the structure of the running code, it is easy to catch errors
and quickly repair them.
While there is a visualization interface for SMACH,
SMACH is not visual programming. One can easily follow
how a SMACH plan will execute by looking at the task graph,
but the plans that are described with SMACH tend to grow to
be too complex to lay out by hand.

Open Source
SMACH has already been used in several projects involving
the PR2, where time was critical, and proved useful for both
iterative development and debugging. These projects included
autonomous recharging, opening doors, and three one-week
"hackathons": playing billiards, integrated table clearing/cart
pushing, and fetching drinks from a refrigerator. More information about and tutorials on SMACH can be found on the
ROS wiki www.ros.org/wiki/smach.

ROS Interfaces
While a developer can create a custom SMACH state class that
executes arbitrary Python code, there are several parametrized
state classes that make it even easier to compose lower level
systems in ROS. Some of these include, but are not limited to:
u ServiceState: It is a state that represents the execution of a ROS service call. This state is parametrized by
the service call name, type, and an optional pair of callback functions for generating a request and processing
the service response.
u MonitorState: It is a state that monitors a given
ROS topic. It can take a user-defined callback function
that gets executed with each message received.

IEEE Robotics & Automation Magazine

References
[1] C. McGann, E. Berger, J. Bohren, S. Chitta, B. P. Gerkey, S. Glaser, B.
Marthi, W. Meeussen, T. Pratkanis, E. Marder-Eppstein, and M. Wise,
"Model-based, hierarchical control of a mobile manipulation platform,"
in Proc. ICAPS Workshop Planning and Plan Execution for Real-World Systems, Thessaloniki, Greece, 2009.
[2] W. Meeussen, M. Wise, S. Glaser, S. Chitta, C. McGann, P. Mihelich,
E. Marder-Eppstein, M. Muja, V. Eruhimov, T. Foote, J. Hsu, R. B.
Rusu, B. Marthi, G. Bradski, K. Konolige, B. P. Gerkey, and E.
Berger, "Autonomous door opening and plugging in with a personal
robot," in Proc. IEEE Int. Conf. Robotics and Automation (ICRA), 2010,
pp. 729-736.
[3] N. J. Nilsson, "Hierarchical robot planning and execution system," Stanford Res. Inst., AICPub76:1973, Apr. 1973.

DECEMBER 2010

http://www.ros.org/wiki/smach

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - December 2010