How to Configure Client Behaviors to Run Sequentially?

[NithishkumarS]

Hi SMACC2 Team,

I have a question regarding the configuration of client behaviors to run sequentially within the SMACC2 framework. In an example case of a mobile manipulation task and I need to ensure that certain actions occur in sequence. For example:

1. Move the base using CbNavigateNextWaypoint (from the navigation client).
2. Then move the arm using CbMoveNamedTarget (from the MoveIt client).

From my understanding, state reactors do not handle the sequence of these actions. I would prefer to offload these tasks to a mobile manipulation client behavior that configures these two client behaviors.

In the past, our team also has encountered issues when trying to trigger client behaviors sequentially and had to implement workarounds. Could you provide guidance or examples on how to achieve this in a more straightforward and reliable manner?

Thank you for your assistance.

[brettpac]

Hello @NithishkumarS Thanks for the question.

In my mind, the most reliable (and straightforward) method would simply be to use two states, probably encapsulated within a superstate.

So within SSTransportItemX (or whatever)... In state 1, Move the base using CbNavigateNextWaypoint (from the navigation client), then... In state 2, move the arm using CbMoveNamedTarget (from the MoveIt client).

Data that needs to be shared between the states could be stored in either the superstate, or within the clients or components (probably components) of the Nav2z or Moveit2z clients.

Advantages of this technique include the fact that you would be able to easily visualize the runtime operation and events, and also maintain modularity. Let's say that later you want to add a third step (something like CbAskChaptGPTWhatToDo), it would be as simple as just adding another state to the sequence.

Alternatively, I suppose you could write a custom client behavior that would essentially combine everything into one client behavior that you could use in a single state.

But, then debugging would basically be limited to ROS INFO messages or something similar, and my question would be why? Why is it necessary to accomplish everything in a single state. It's better to chop your problems up into little pieces (states).

As far as state reactors go, you're correct, they simply throw 2nd order events.

Can you tell me a little more about your use case?

[NithishkumarS]

Hi @brettpac. Thanks for the quick response.

We are using clients to share data between states. We might favor writing a custom client behavior for the current situation. In our use case, we already have 5-6 super states for different tasks/applications our robot needs to perform. Each super state has additional tasks to complete, including some that involve mobile manipulation.

The design choice of having a single mobile manipulation client behavior allows us to reuse inner states across the existing super states, preventing state explosion. This means I can choose to use the mobile manipulation client behavior in the transportItemX state(for example), depending on the super state I am currently in.

I do feel there might a limitation with the logging as you had mentioned. Does this help understand the use case better?