Feature to get a list of running action servers

[130s]

Asked here. While the proposed way that uses rostopic list (thus is a bit of a hack) seems to work perfectly, I like to have a feature to do that. I wouldn't mind opening a PR but just wonder:

• What form is the best? A command like rosaction with a list verb may sound too much, since there may not be many other things to do with rosaction command.
• Where's the right place? This should be just determined once "what form" is resolved.

[luator]

I would also like to have a tool like this, to easily check if an action server is set up correctly.

[keerthanamanivannan]

+1

[mikaelarguedas]

What form is the best? A command like rosaction with a list verb may sound too much, since there may not be many other things to do with rosaction command.

@130s I think that creating a CLT for this single verb is a bit too much as well. A python script installed by the package that can be rosrun'd would do the job I think (e.g. rosrun actionlib list_action_servers). So I'll lean toward a script in the tools folder of actionlib.

I would also like to have a tool like this, to easily check if an action server is set up correctly

@luator I'm not sure this will save you a lot of time to run rosrun actionlib list_action_servers | grep my_action_server rather than rostopic list | grep my_action_server if the only goal is to know if the topics are advertised. Could you clarify what you mean by "check if an action server is set up correctly." ? what type of information(if any) not provided by rostopic would you like this tool to give you access to ?

@keerthanamanivannan, @ruffsl Could you describe what you'd like such a tool to do? a strict equivalent of rostopic list | grep -o -P '^.*(?=/feedback)' or something different?

Thanks!

[ruffsl]

Here would be my supposed wishlist for rosaction:

rosaction list

List the namespaces of available actions, e.g:

$ rosaction list
/arm_controller/follow_joint_trajectory
/arm_with_torso_controller/follow_joint_trajectory
/dock
/dock2
/gripper_controller/gripper_action
/head_controller/follow_joint_trajectory
/torso_controller/follow_joint_trajectory

rosaction info

Return info about a given action, e.g:

$ rosaction info /dock
Type: fetch_auto_dock_msgs/DockAction

Server: 
 /robotdriver (http://127.0.0.1:37673/)

rosaction type

would just return give just the type for action, e.g:

$ rosaction info /dock
fetch_auto_dock_msgs/DockAction

rosaction find

Return list of action namespaces matching a given action type, e.g:

$ rosaction frind fetch_auto_dock_msgs/DockAction
/dock
/dock2

rosaction [send|get|call?]

Call the action with the provided args. Sort of like rosservice call, but gives feedback and result like the GUI for rosrun actionlib axclient.py /dock, e.g:

$ rosaction send goal /dock fetch_auto_dock_msgs/DockGoal '{dock_pose:{header:{frame_id:"base_link"},pose:{x:1.0},orientation:{z:1.0}}}'

also perhaps similarly some other one off client API calls: rosaction get state /dock rosaction cancel all_goals /dock* etc..

This is all lose pseudo code, so not sure if fetch_auto_dock_msgs/DockGoal would need to be stated, or if other syntax form would be better, just trying to follow the common convention of the rest of the ros command line interfaces.

[luator]

@mikaelarguedas To be honest, I wasn't aware that I could simply check for the topics (when thinking about it, it totally makes sense, though). However, only because the topic is listed by rostopic list does not necessarily mean that the action server is really running (the node could have crashed or been restarted with a change that now does not start the server).

Anyway, I think a tool as proposed by ruffsl could be useful.

[keerthanamanivannan]

I also had in mind something like what @ruffsl proposed.

[artivis]

In the line of this discussion, have a look at axcli.
One might find most of what necessary for the aforementioned features (List, Info, Type etc...) From a terminal a call to axcli [tab|tab] lists the available actions.
Its auto-completion also works for the action/goal to send (e.g. axcli my_action [tab|tab]).

[ruffsl]

Interesting, the [tab|tab] listing uses rostopic list and just scrapes for uses of goal.

[gavanderhoorn]

Just came across mcgill-robotics/rosaction:

This is a ROS action command-line tool that works just like the built-in rostopic and rosservice commands.

For now, all functionality is there except for autocompletion.

[130s]

Thanks for the interesting finding for some existing repos. I've asked if maintainers of each repo gets interested in sending pull requests to the upstream somewhere appropriate so that the rest of us in rosland can use without adding extra dependency:

• https://github.com/po1/axcli/issues/5
• https://github.com/mcgill-robotics/rosaction/issues/1

[felixvd]

A bit of a +1 post. Just want to note that the fact that no good CLI like rosservice call exists for actions has kept us from using them in the past, and made us use services where they were not appropriate. We have been using tab completion of empty service calls constantly, and would use something like rosaction call just as much.

[maximkulkin]

Hey, I managed to compile stuff from other projects into a CLI tool. Now I want to add bash completion. This should not be hard, it's pretty similar to rosservice and much of completion code can be reused. My question is: what is the best way to add it? Thing is that existing completions live in rosbash package and provide completions for ROS core CLI tools while actionlib is kind of add-on package. It would be nice if rosbash provided some plugin API to allow other packages to provide more completions. What do you think?

[maximkulkin]

Nevermind guys, I figured out how to provide completions for new tool. Just need to make it pass CI.

[gavanderhoorn]

@maximkulkin wrote:

Hey, I managed to compile stuff from other projects into a CLI tool.

+1 for doing this, but looking at the files in #115, I don't see any licenses or mentions of the (authors of the) projects you used.

Would that be something you still need to add?

[anassinator]

Author here of mcgill-robotics/rosaction, which seems to be the basis of #115. I don't know much about licensing, but I'm open to relicensing or whatnot if that helps get this in.

Also, wouldn't the autocompletion need to support zsh, fish, and tcsh as well?

[maximkulkin]

Well, I used above mentioned projects as an examples and source code is not copyrighted although am OK to put whatever mention you feel necessary.

[maximkulkin]

As of autocompletion: I do not use those other shells, so I can not test it there. I'll leave it to people who use those shells.

[gavanderhoorn]

@maximkulkin wrote:

Well, I used above mentioned projects as an examples and source code is not copyrighted although am OK to put whatever mention you feel necessary.

I don't believe it works that way :)

Software is always copyrighted. It is the license attached that allows you to use it, or not.

In this case the following licenses were attached to the source code of the two above mentioned projects:

• mcgill-robotics/rosaction: MIT (license)
• axcli: BSD (license statement)

So both of those projects expressly permit you to use the source code, *provided that you leave any copyright notices in tact, and that you acknowledge the work and authorship of the developers that contributed to those projects. See also the handy summary that Github displays above the LICENSE file for mcgill-robotics/rosaction ("Conditions: License and copyright notice").

Regardless of whether you used any of the code directly, it would probably be fair to mention at least the names of the authors of those other projects.

[maximkulkin]

I disagree: I used sources of those projects to figure out how to do basic things and then implemented that stuff myself, adding error handling and tests. It's like you use tutorials or examples to know how to do things. There were no tricky algorithms involved, just obvious stuff that could be found elsewhere. The MIT license says that copyright should be preserved in "all copies or substantial portions", but those are neither this or that.

[gavanderhoorn]

I'll leave it to you to do what you feel is the right thing to do.

I just wanted to correct you when you wrote "source code is not copyrighted".

---

Edit:

I used sources of those projects to figure out how to do basic things

This is called "conceptual reuse" and is actually something that is considered by some people to also be covered by licenses: without looking at those sources it would have possibly taken you more time to figure out how to things.

By allowing you to look at the sources of those other projects, the authors potentially saved you valueable time. That in itself might be enough to list those projects as inspiration or precursors.

[maximkulkin]

Well, the license does not mention anything on "conceptual reuse".

I actually don't care who will be listed where (and I do not list myself anywhere), but I do not see this practice used in ROS projects, so I do not know where to put this stuff. And it looks like original author don't mind (@anassinator are you?).

[anassinator]

I don't have any strong opinions about this TBH. I would expect this repo's owners might have something in mind anyways.

BTW, it seems like this repo already has a few precedents like here: https://github.com/ros/actionlib/blob/indigo-devel/src/actionlib/action_server.py#L29-L30

[maximkulkin]

Hey I've added a reference to original rosaction repository and my last CI run completed successfully. Take a look.