Can I handle multiple client requests of different action types with one action server?

Question

I have a requirement as follows:

One GUI window has an Action Server. This should serve multiple client requests (may be one at a time) but each request type is different (ex:- 1.MoveAction 2.RunAction 3.WalkAction) Based on the request, the message type will be different. The Action server should be able to recognize it in executeCB and serve the request back. (just like a web server) Is that possible with action lib?

I could write all the messages in one combined custom message and set an indicator for request type but that takes so much memory for each request that i make. I think there should a better way to do it.

Please let me know if you need any further information. Thanks in advance.......

---

Edit 1: Method overloading is not an option... Cuz action server definition is as follows with the message type:

actionlib::SimpleActionServer<aps_msgs::FileSelectAction> as_;

Can we make the initialization of the action server more generic?

---

Originally posted by ghkraju on ROS Answers with karma: 80 on 2017-01-12

Post score: 1

---

Original comments

Comment by ghkraju on 2017-01-12:
Can method overloading to executeCB be helpful? I can think of this as best known sol as of now.

Answer 1

No, afaik this is not possible. ROS is a type based pub/sub middleware, and in those middlewares only messages of the same type can be published on a single 'channel'. Actions are basically pub/sub over a few different topics, so the same restrictions apply.

---

Originally posted by gvdhoorn with karma: 86574 on 2017-01-17

This answer was ACCEPTED on the original site

Post score: 3

---

Original comments

Comment by ghkraju on 2017-01-19:
Yes, you are correct. As of now, I have to create multiple action servers for different message types. May be it can be a future scope of improvement to generic type of action servers in ROS too like web APIs.

Comment by gvdhoorn on 2017-01-20:
I don't know whether I'd be a fan of that: strongly typed systems have their advantages, and especially in component based systems I don't think it's so bad that already at the type level things are guarded against incompatibilities. Especially since semantics are strongly coupled with syntax here.