ROS/CommandLineTools/Review

This review is scoped to command-line tools for end users. Internal tools (e.g. gendeps, rosdeb) are out of scope.

• rosbash

• rosparam

• rostopic

• rosnode

• rosmsg

• rossrv

• rosrecord/rosplay

• rosrun

• rxgraph/rosconviz

• rospack

• vizdeps

General requirements:

• ROS_NAMESPACE-aware, where appropriate

• composable, where appropriate (e.g. rostopic type foo | rosmsg, rosparam dump x.yaml && rosrecord)

• Well documented (currently failing at this)

Questions:

• What is the status of tcsch support?

• Should rosmsg/rossrv adopt the command-based syntax of rostopic/rosnode/rosparam instead of the option-based syntax, e.g. rosmsg show std_msgs/String instead of rosmsg std_msgs/String?

  • rosnode has now moved to the command-based syntax in the sessions branch
• Deprecations?

Current unfulfilled needs:

• ability to query service state. This should probably be folded into rossrv, but this will cause some incongruity with rosmsg

• other needs?

Todos:

• promote rosgraphviz/rosconviz to top level
• standardize naming (vizdeps should have ros prefix)
• remove roscd package
• remove rosmap (DONE)
• remove shparam (DONE)
• remove xmlparam (DONE)

Comments

Brian:

• I like the idea of moving to a common command syntax (e.g., rostopic list, rosmsg show, rospack deps)
• I added rospack to the list, because it is often used by developers.

• In the rospack code review, Rob expressed a desire for placing command-specific options after the command, e.g.:

  program command [options] [package]

  • kwc: rostopic/rosnode/rosparam follow this convention
• If rosparam subsumes the functionality of xmlparam (which it seems to), then the latter should indeed be removed. No need to confuse people with too many options.
• Why do we provide both rosmsg and rossrv? Given that message and service types live in the same namespace, wouldn't a single tool suffice?
  • kwc: rossrv is mostly just an alias of rosmsg as it seemed confusing to call rosmsg to search for a .srv file. They share the same common code, though they do a different search. I'm contemplating whether or not the rossrv tool would get the ability query live services, or whether that is a separate 'rosservice' tool.
    • tbf: The seperation of msg and srv lookups is good to keep. I think that instead of rosservice it could be part of rosnode since they are associated with nodes (e.g. rosnode list-services, or rosnode services my_node)

Tully:

• If we're doing rosrun, shouldn't rosmake be standardized this way too?
  • And if we're doing rosmake I'd really like to be able to build a list of packages efficiently. Two rosmake's of high level packages overlaps a lot.
• rospack vcs is close to unused. remove?
• we may want to differentiate between bash scripts and tools? if you simply type $ros and tab complete there are a lot of options. I can't even identify all of them. I think some of them should be demoted and roslaunched such as rosmakeall it doesn't need to be called from anywhere.

~tfoote $ ros
rosapt-get         roscore            rosed              roslaunch          rosmake-download   rospack            rospmake           rosrun             rostopic
rosbusybox         roscp              rosgcov            rosls              rosmap             rosparam           rosprereq          rossrv             rosupdate
roscd              rosd               rosgcov_summarize  rosmake            rosmsg             rospd              rosrebag           rostar             
roscmd             rosdeb             rosinstall         rosmakeall         rosnode            rosplay            rosrecord          rostest  

Jeremy:

• Tab-completions, in their current implementation are hard to maintain. You always have to go edit the rosbash and rostcsh definitions, and these need to be added for new rostools on an as-needed basis. A solution to this is to count on the programs themselves to generate their own list of tab-completions. This can be done using a special argument such as "TABCOMPLETE" as a first argument that the program always checks for. Then all that needs to go in the rosbash file is a line such as:

complete -C "rosrecord TABCOMPLETE" rosrecord

• In this case, the rosrecord executable is then passed the argument TABCOMPLETE followed by the contents of the arguents being tab-completed. Everything it prints out is then used as the tab-complete candidates. This makes it possible to easily add intelligent tab-completion including options or sub-commands. I'm 99% sure tcsh has a comparable construct which would allow tab-completion rules to live in a single place (the program itself) and work for both bash and tcsh.

Meeting Notes

• rosmsg/rossrv
  • move to command syntax #828
  • add search by default to rosmsg/srv #869
• rospack
  • replace deps with depends but keep deps as an alias #860
  • move command specific options after command (rospack #861 #862)
• add rosservice #867
• roslaunch #868
  • consolidate rosrun and roslaunch
  • standardize on *.launch
  • add flag to force it to launch a file as a launch file if extension is different
• combine rosmake and rospmake, kill rosmake-download #863
  • add profiling
  • add ability to target
  • add switch to do parallel make inside packages
  • add -k to keep going
  • replace rosmake-download with "rosmake -k -t download"
• Follow Jeremy's recommendation for self-reporting of tab completion by tools
• potentially remove rosupdate
• remove rosdeb from PATH #865
• hide #865
  • rosbusybox #865
  • rostar #865
• Hide in rosbash #866
  • roscmd
  • rosd
• promote rosgraphviz #870
• rename vizdeps to rosvizdeps #871
  • change to interactive(long term)
• hide rosinstall until ready #865

Package statuses

• rosmsg: conditionally cleared #828 #869
• rospack: API conditionally cleared #860 #861 #862
• roslaunch: API conditionally cleared #868
• rosparam: API cleared
• rostopic: API cleared
• rosnode: API cleared
• ros(graph)viz: API cleared #870
• rosvizdeps: API cleared #871