Partial SMACC2 documentation

General
1

Dear all,

Wrt. state machines for ROS2, it seems that there’s not a lot of choice (apart from behavior trees):

  • This post mentions a fork of Smach, but it seems unfinished and unmaintained,
  • SMACC2 on the other hand seems really good, as it is actively developed, has numerous examples and has a state viewer (albeit closed source),
  • I am not aware of possible other libraries.

So I looked into SMACC2, but did not find any real documentation.
There are example state machines, but it is hard (impossible?) to learn SMACC2 from these without further background info, as also experienced by others.

So I decided to try to dig through the code and write down some documentation.

It is by far not finished, but as I currently don´t have time to pursue this further I decided to release my notes in their current state anyway, as they might be helpful to anyone wanting to start with SMACC2.

The notes can be found in this repository.

2 Likes
3

Interesting.

Are there also other licensing options, or is it GPL only?

5

A time to move to away from my comfort zone i guess. A change of environment also to get my mind back to work with you guys so that we can achieve our goals. Thanks for your time and support

6

Hello @JRTG,
These notes are beautiful, thank you.

We’re working on getting a shinx site up for documentation, and we’ll definitely integrate these notes, answer some of the questions contained, etc.

I’m very grateful for this and appreciate the help.

7

@mgonzs13 I doubt there’s a sustainable business model in this, but… prove me wrong! :slight_smile: Or, consider releasing it with a permissive license and be happy that people use it.

8

@brettpac Glad it can help.

I think the primary need wrt SMACC2 documentation is clarification of the rationale behind each of the functional concepts.

For instance:

ISmaccUpdatable provides an interface for periodic functionality,
The timer client also implements periodic functionality, but not as an ISmaccUpdatable

So what is the rationale: when to choose one way or the other? Is it equivalent, and just two possible ways to do the same thing, or are there (subtle?) differences?

Or:
When to implement functionality in a client as opposed to a client behavior?
The website states:

“Every Orthogonal should contain at least one client, and may contain multiple client behaviors.”

But that’s not strictly true: a functional state machine is possible without clients in the orthogonals, if the states configure client behaviors that post the state transition events.
So I would rather think:

“Use clients for functionality that is needed across multiple states, and/or for functionality that has a high setup cost (e.g. something that you only need in a certain state, but takes a substantial initialization time, so you want it initialized beforehand not on state change).”

But this is just an assumption: it is hard to learn the author’s intention by reading code (except maybe by deducting this from multiple examples, but that is the hard / time consuming way, and prone to misunderstandings).


That’s great, although my advice would be: given the limited amount of resources available, write down the documentation first (even if it is a simple markdown readme file, preliminary, maybe even not well structured yet nor completely finished, etc.), just put it in your github repository for now so people can start using it, and only then focus on the website/sphinx/formatting/etc.

10

[EDIT] This was a reply to a post that seems to have been deleted.
So I decided to also remove it as was out of context.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.