When comparing SMACC to other libraries in the ROS universe, inevitable comparisons are made to SMACH, authored by Jonathon Bohren, and Flexbe, which originated at the University Virginia and counted among it’s core developers Phillip Schillinger. From my reading, Flexbe can almost be thought of as a newer version of SMACH and incorporates many of the same concepts such as outcomes, userdata, and containers that are more specific to SMACH that the history of State Machines.
And these comparisons have some validity, SMACC was definitely inspired by SMACH, and the SMACH viewer. And SMACH’s features of Hierarchy (through the use of containers) and Concurrency definitely bear similarity to the SMACC/Boost Statechart/D. Harel(87) concepts of Hierarchy and Orthogonality.
C++ vs. Python
I think that the first major difference between the libraries is the use of C++ for SMACC vs. Python for SMACH and Flexbe. For SMACC, this provides two main advantages…
- Compile time validation (through the use of template metaprogramming)
- Real-time capabilities
There may be some squabbling from Python enthusiasts over the claim that Python is inappropriate or incapable of real-time applications, but it doesn’t change the fact that as an interpreted language, you don’t have the same granular control over memory layout that you have with C and C++.
Boost Statechart is something older library, developed around 2004 by Andreas Huber Donni, and relies heavily on the Boost MPL library, written by David Abrams, the founder of Boost. MPL stands for Meta Programming Language, and for those unfamiliar with C++ template metaprogramming, it’s essential difference from normal C++ programming is that the operations it does are performed at compile-time as opposed to run-time. Many programmers, simply think of using templates to avoid having to write different functions for ints, doubles, and floats, which was it’s original purpose.
But other advanced applications of C++ template metaprogramming evolved, most notably Cryptography which took advantage of the fact that you could do things like encryption of string literals at compile time.
And very early on, David Abrams realized that Finite State Machines, could also be validated (i.e. checked for correctness) at compile, since all states and transition are known at compile time.
Boost Statechart, and through inheritance SMACC, uses Boost MPL to evalutate your state machine’s hierarchy, and all of your transitions at compile time. And that’s a BIG deal.
Because it works. It’s one thing to write a state machine library, it’s another to write one that works. I think SMACH falls in this category unfortunately. I, like many, tried SMACH, and it didn’t work.
I’m not a daily user of SMACH anymore, so perhaps things have changed, but I’m skeptical.
Andreas Huber Donni’s was a Boost developer at this time, and a colleague of David Abrams. Andreas Huber Donni built upon the Protocol State
But wheras developers such as David Abrams, who wrote
Reference Library
Client Library
Concurrency/Orthogonality
SMACH & Flexbe do offer concurrency, which has many similarities conceptually to orthongonality although…
In SMACH it never worked
And that it’s use is explicitly tied to states. This is because wh
NEW
Although SMACH & Flexbe appear to offer both Hierachy and Orthogonality (Via Concurrency), they really don’t. Let’s talk about why…
In SMACH & Flexbe, Concurrency is handled by the creation of a container, that you then put multiple states inside (that are now concurrent). But, a container is effective an entirely new SM (inherits from the same base class as a SM), that you’ve now “nested” inside of your new machine.
This is similar to the way SML handles hierarchy, which sucks (see ________). The base reason for why it sucks, is that you now have to handle the data passing between your state machines, which goes south in a hurry.
This is also the way that SMACH & Flexbe handle hierarchy, which still sucks. And it gets even worse once you try to use this technique (nesting different state machines inside your existing state machine) to solve hierarchy and orthogonality at the same time.
One telling and important difference that SMACC offers due to its different solution to the “nested” issue discussed above, is that in SMACC, Orthogonals have a lifetime that matches the State Machine.
This allows us to put Clients into each Othogonal, which also have a lifetime equal to that of the state machine, which allows them to have persistent data relevant to each client. This is huge.
A good example of this in action is our odometry tracker for the MoveBaseZ client (interacts with the MoveBase server node of the NavStack). We have another one in our MoveIt client as well, and I’m confident that this is a sign of a correct design pattern.