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

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)


  • 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?


  • 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)



  • 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)


  • 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  


  • 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

Wiki: ROS/CommandLineTools/Review (last edited 2010-02-19 00:33:25 by KenConley)