Different goals in one action server

edit

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.