Rosanswers logo

Good day everybody

I am trying to implement a cyclic and premptive behaviour on a state machine for my robot with SMACH. I'm wondering a lot about "how I should do to stay in the smach philosophy" and not re-implement existing things. I would like to implement the following state machine:

  • HARVEST, outcome END -> none, outcome DANGER -> ESCAPE

HARVEST is containing :

  • GOTO A , outcome SUCCEED -> GOTO B
  • GOTO B , outcome SUCCEED -> GOTO A
  • ESCAPE, outcome SUCCEED -> GOTO A

and GOTO A, GOTO B and ESCAPE are state that are most of the time waiting for actions to suceed (not immediate transitions).

My question is

  • I would like that, each cycle, HARVEST transitions are verified. If one of them is true, then states within HARVEST are preempted.

I have a hard time understanding if my GOTO A.execute() function shall be blocking or returning an outcome linked to the same state... And where I can put my checkTransitions() code for HARVEST

Thanks for your help

Originally posted by Moulineau on ROS Answers with karma: 31 on 2011-05-10

Post score: 3


1 Answer 1


Rosanswers logo

If I understand your example correctly, the states gotoA and gotoB each take a longer time. And while gotoA and gotoB are running, you want to check for some transition condition. I see two possible solutions here:

  1. In the execute() methods of gotoA and gotoB, you continuously check for this transition condition, and return an outcome when the transition condition is satisfied.

  2. Use the concurrence container to create a monitor state that runs in parallel with gotoA and gotoB. So gotoA will run in a concurrence container with a monitor state, and gotoB will run in a different concurrence container with a monitor state. All the monitor state does is check for the transition condition. When the transition is satisfied, the concurrence container can automatically preempts gotoA or gotoB.

Originally posted by Wim with karma: 2915 on 2011-05-25

This answer was ACCEPTED on the original site

Post score: 4

Original comments

Comment by phil0stine on 2012-03-31:
Could you give a little clarification on this? The way I understand, gotoA and gotoB would have to run in parallel (as well as monitor) to be part of the concurrence container. If monitor state changes, how could the container only preempt one state and transition to the other? Thanks


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.