> 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.
vpradeep@willowgarage.com