Revision history [back]

The only way I see to accomplish this is to have a central "broker" that manages the set of actions. You need one place in the code that knows the state of all mutual exclusive actions to be able to reject (or abort, depending on your design) goals if another one is already running. You can implement that for example by having some type of lock that needs to be acquired to execute an action and if that lock cannot be acquired within some timeout, the goal gets aborted.

There are many possible ways of implementing this and it depends on your requirements. For example, if you have one process that holds all action servers, a simple mutex that you try to lock at the beginning of your execute callbacks could work. If the action servers are distributed over multiple processes, you could add some central lock mechanism using ROS services (best encapsulated in some class or even in a specialization of ActionServer).

The only way I see to accomplish this is to have a central "broker" that manages the set of actions. You need one place in the code that knows the state can check if one of all the mutual exclusive actions is already running to be able to reject (or abort, depending on your design) goals if another one is already running. incoming goals. You can implement that for example by having some type of lock that needs to be acquired to execute an action and if that lock cannot be acquired within some timeout, the goal gets aborted.

There are many possible ways of implementing this and it depends on your requirements. For example, if you have one process that holds all action servers, a simple mutex that you try to lock at the beginning of your execute callbacks could work. If the action servers are distributed over multiple processes, you could add some central lock mechanism using ROS services (best encapsulated in some class or even in a specialization of ActionServer).