> So why are they implemented in two separate code trees? Why do they not
> share everything they could share?
actionlib is not designed to be a solve-all FSM language for robotics.  It
instead defines a very specific protocol for handling the interaction
between a client that dispatches long running goals, and a server that can
execute these goals.  There are in fact two closely coupled state machines
defined inside of actionlib, but these are definitely quite hard-coded to
govern this specific interaction.  We definitely could have designed
actionlib to rely on some generic state machine engine to generate it's two
hardcoded state machines.

> Because your robot will live on, so somewhere it will continue with
> something else. Practically speaking, that means that another FSM will
take
> over, in one way or another; but having half a dozen of termination states
> only leads to a combinatorial explosion of how to go on with the next
> FSM...
...
> But there is a practical difference between mathematical
> models and usable code! Having multiple terminal states leads to
> exponential "fan out"... In other words, it makes sense to reduce the
> number of termination states; a lot of sense.

There is definitely an argument that the server-side state machine would be
clearer if there was only one terminal state that also had an exit code
attached to it.  We decided to fan out these terminal states, as it seemed
more convenient and understandable on the server-side.  Note that in the
client side, we actually have condensed all the terminal goal states into an
exit code, which becomes a part of the *WaitingForResult* and
*Done*states.  Although, fanning and condensing these states are
interchangeable,
in hindsight, it may have been better to be consistent between the server
and client.


> In addition, (and that's my
> other comment in the previous post), the _meaning_ of the state machine
> shown in the ROS documentation is not far away from one single terminal
> state; it has just not been explained that way, because of the semantic
> confusion ("error" rather...) of naming states according to the event that
> led to them. Again, a state must be called according to what activity the
> state represents. (This is also not "mathematical necessary", but just
good
> practice :-)

Just to clarify, the server side and client side state machines refer to an
individual goal, not the actual ActionServer & ActionClient.  Thus, if a
specific goal has been aborted by the ActionServer, why is it unreasonable
for the goal to be in an *Aborted* state?  What would be a better name?


>> .. how can it reply with whether the
>> goal I queried about succeeded, failed or any other states that indicate
>> that the server will not be doing any more processing of that goal?

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

By having multiple terminal states, we're trying to give just enough
information for the client to infer the pertinent parts of how the goal
moved through the server side state machines.  This can be used to answer
questions like:
- Did the ActionServer ever start processing my goal?
- Did the goal prematurely end because of some error, or did someone ask it
to stop?
- Did the goal not start because it was invalid, or because someone canceled
it before it stopped?
All of these questions could be answered by storing all of the server side
state transitions in some world model, but wouldn't acting on these various
paths also lead to the same 'fan out' of possible actions that multiple
terminal states could lead to?
It's also quite possible that answering these questions in a generic way
isn't useful.  If so, we could condense all the terminal states into one,
and let the user send back any custom relevant information in the result.

> - how to apply this to the "resource allocation" problem? Going from
>  allocation of external resources, to the internal coordination of the
>  arms, head and platform in the PR2.
- We are definitely interested in getting a better understanding of how to
do resource allocation in our system.  We'd love to hear what approaches
have worked well for you so far.

---
Vijay Pradeep
Systems Engineer
Willow Garage, Inc.
 <tfoote@willowgarage.com>vpradeep@willowgarage.com