\(\def\dt{\Delta t}\)
\(\newcommand{\transpose}[0]{^\mathrm{T}}\)
\(\newcommand{\half}[0]{\tfrac{1}{2}}\)
\(\newcommand{\Half}[0]{\frac{1}{2}}\)
\(\newcommand{\norm}[1]{\left\lVert#1\right\rVert}\)
\(\newcommand\given[1][]{\:#1\vert\:}\)
UP | HOME

ROS Dependencies and Related Tools

Table of Contents

1 Notes on package.xml files

  • We know that all ROS packages must have a package.xml
    • This file contains meta-data about the package that is used in a variety of ROS tools (bloom, the wiki, etc.)
    • It also contains ROS package and system dependencies
      • If these are incorrect, the package may work on your system, but not work when distributing to others or when building for release on the build farm via bloom
  • Specs for these files were originally defined by REP 127 (sometimes called Format 1) which was introduced in ROS Groovy Galapagos, and corresponded to the switch to catkin.
  • Specs are now defined by REP 140 (sometimes called Format 2).
    • Format 2 is now the preferred format.
    • REP 140 doesn't take over unless <package format="2"> is added to the package.xml file
    • The primary changes of REP 140 are copied below (from here)
      • <run_depend> was replaced by <build_export_depend> and <exec_depend>.
      • <depend> was added as a synonym for <build_depend>, <build_export_depend> and <exec_depend>.
      • <test_depend> now fulfills configuration and build-time test requirements in addition to the objects needed for running them.
      • <doc_depend> was added for documentation specific dependencies.
      • <buildtool_export_depend> was added to enable the same cross-compilation semantic for <build_export_depend> as it is already available with <buildtool_depend> for <build_depend>.
    • See this page on how to migrate a Format 1 package.xml to a Format 2
    • Further documentation on Format 2 is available with the catkin documentation
  • In both formats, there are several required tags that provide package meta-data
    • <name> specifies the package name
    • <version> specifies the package version
    • <description> a short description of the package
    • <maintainer> at least one required, but there may be multiple
    • <license> the license that the package is distributed with (may be multiple)
  • Note that when specifying system dependencies (non-ROS packages) in a package.xml file, you should be using rosdep keys (see rosdep description below)
    • <exec_depend> does not normally use keys that end in -dev for system dependencies
    • <build_depend> normally uses keys that end in -dev for system dependencies

2 What is rosdep?

  • rosdep is a command line tool for installing system dependencies and other ROS packages.
  • The main documentation is here
  • With rosdep it is possible to automatically install both non-ROS system dependencies, and ROS packages that have been released for your OS/distribution
  • rosdep has support for installing things on a variety of Linux/Unix distros and using a variety of package managers
    • Linux: Fedora, Debian/Ubuntu, Arch, Gentoo all using their default package managers (yum, apt-get, aur, portage)
    • OSx: works via homebrew, some work has been done on supporting macports
    • Python: There is also support for installing Python modules that have been released on PyPi (using pip)
    • Ruby: Much like Python, there is some support for installing things via gem
  • There is a YAML file available online that follows the rosdep YAML format
    • Given a rosdep "key", this file allows the rosdep command line tool to lookup how to satisfy a given dependency on your system using the appropriate package management tool and package name.
    • These YAML files are defined in the ros/rosdistro GitHub repository
    • For example, check out base.yaml for an example of these YAML files in action
    • Most likely, the definition of which YAML files should be used by rosdistro on your system are located in /etc/ros/rosdep/sources.list.d/20-default.list
    • Running rosdep update downloads the contents of the YAML files defined in this file, and stores the contents in a local cache, by default, located at ~/.ros/rosdep/sources.cache/
    • You can see all available keys (for use in a package.xml) with rosdep keys -a
  • From an end-user's perspective, the most common use-case for rosdep is for automatically installing system dependencies for a set of ROS packages that you are trying to build from source.

    • Imagine you have a catkin workspace at ~/catkin_ws then the command we most often use is something like 

      rosdep install --from-paths ~/catkin_ws/src/ --ignore-src --rosdistro=melodic
    • Notes about above command:
      • Be sure to set the rosdistro argument correctly
      • Can pass -y switch to automatically agree to any questions that tools like apt-get might ask you (a bit dangerous perhaps)
      • Passing --simulate will allow you to see what would happen before actually executing the commands (good idea!)
      • Running rosdep --help is a great way to learn about all of the options

3 What is rosinstall?

  • rosinstall is a tool for updating a variety of source-based installs at once
  • Let's look at some examples of why someone might use rosinstall
    1. Let's say you have a collection of ROS packages that should all be working together. You have not released them to the ROS buildfarm which means they are not installable via apt-get. Then rosinstall would provide you an easy way to distribute a file that people could use to get all of your repositories cloned into their workspace using the correct branches/versions. This would work even if they weren't all Git repos. Check out the Baxter SDK rosinstall file as an example of one of these files. Check out the 1.2.0 Workstation Source installations instructions on the Baxter Wiki to see how they have you use this file.
    2. What if you are on a Linux distribution that doesn't have all of ROS available to install as a binary package? You can use rosinstall to build ROS from source code.
  • The rosinstall_generator tool can be combined with rosdep to create the .rosinstall files that are read by rosinstall. For an example, check out the instructions on building ROS from Source.
  • In order to use a .rosinstall file, one uses the wstool command line tool.
    • wstool allows you to clone a set of repositories specified in a rosinstall file
    • You can merge multiple rosinstall files using wstool merge
    • Updating a workspace is done with wstool update
    • Running wstool --help is a great way to learn about all of the options

3.1 Example

See the example below.

4 Resources

Creative Commons License
ME 495: Embedded Systems in Robotics by Jarvis Schultz is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.