# Different goals in one action server

I have a bit of an issue trying to figure out the best way to implement an action server with different goals. Is it an acceptable practice to use enums if goals are very different from each other or do I need to have multiple action servers? Here is a bit of a background:

I have multiple nodes that need to control arms. I have one node that controls robot arms and accepts float values to specify goals, each arm can only go up and down, left and right. For my application, I only have a few routines that arms need to follow, for example picking an object up. Those routines always send the same values to the arm controlling node. To avoid repeating sending the same set of instructions from every node when I need to pick an object up, I want to create another node that will have those routines implemented, so the other nodes only need to specify which routine they need and let the new node take care of everything else.

From what I understand (I don't have any experience with action servers, so please correct me if I am wrong), I should create an Action Server to move the arms, and the rest of the nodes will be sending goals to it. My concern is, pickup routine will be very different from drop off. I know I can use enums for different routines, and then have a switch statement in the Execute Callback, which should work fine. Are there any issues with using that approach?

edit retag close merge delete

Sort by » oldest newest most voted

Are there any issues with using that approach?

It's a design decision, and what you describe is a valid design.

One reason I can think of not to do it is that you increase coupling between the 'one action server' and the clients. Only clients that know about the special enum will be able to communicate with your action server. This reduces reusability of both client and server, as you've now (unnecessarily) leaked implementation details of the way your intermediate node works to your consumers.

It also influences composability of your nodes/application: adding a new 'behaviour' will require you to extend the enum, which could potentially mean updating the sources of all your clients (to deal with special circumstances fi). If you create an action server per 'behaviour', you completely decouple clients from servers and adding a new behaviour comes down to adding a new server (which should hav no impact on your clients).

I have one node that controls robot arms and accepts float values to specify goals, each arm can only go up and down, left and right

are the 'floats' joint space angles/poses (potentially after some conversion / at a different abstraction level)? If so, it might make sense to reuse existing infrastructure, such as sensor_msgs/JointState, trajectory_msgs/JointTrajectory and the FollowJointTrajectory action (and associated server implementations). If it's Cartesian (ie: EEF/TCP) coordinates, similar infrastructure could be created, analogous to that for joint poses (there may already be community maintained components for that). This could greatly reduce the work that needs to be done.

To avoid repeating sending the same set of instructions from every node when I need to pick an object up, I want to create another node that will have those routines implemented, so the other nodes only need to specify which routine they need and let the new node take care of everything else.

This sounds like either something that could be called a 'process planner' (ie: an entity that abstracts and encapsulates the implementation details (ie: motion, activation sequence, dealing with errors) of a particular behaviour) or a 'motion primitive' (ie: 'pick up', 'place', 'move obj x from y to z'). The process planner only requires higher level goals or tasks, decomposes them into smaller subtasks and then either executes them or coordinates other components while they execute them.

In your current design, you describe only a single piece of information that you will provide in the task description: the value of the enum. If you anticipate that there will be (or there already is) more information that needs to be provided to the process planner, that would again be an indication that separate actions (and thus servers) could be a good idea. They would additionally increase the semantic value of the actions used.

more

If 'different goals' only means: different joint/Cartesian targets to move your robot to, then having multiple servers doesn't make much sense (semantically, it's all "move robot to x, y, z"). If it's really different behaviour that you're abstracting, then multiple servers would work.

( 2018-02-06 03:04:15 -0600 )edit