rosdep

rosdep – definition

rosdep is a command-line dependency resolution tool used in ROS and ROS 2 development. It reads dependency declarations from ROS package manifests, maps abstract dependency keys to operating-system-specific packages, and invokes the appropriate system package manager. On Ubuntu, this is typically apt; other supported installers include dnf, yum, brew, pip, and source-based installers.

In mobile robotics, rosdep is used to prepare a reproducible software environment for a robot workspace. A Leo Rover running ROS 2 Humble or another ROS 2 distribution may require navigation, sensor driver, perception, and simulation packages. rosdep installs the external libraries required by those packages, such as Eigen, OpenCV, GeographicLib, Python modules, or vendor SDK dependencies.

rosdep does not build ROS packages and does not replace colcon. It resolves system dependencies before compilation or deployment. It also does not configure a robot, calibrate sensors, or make a differential-drive UGV autonomous.

How rosdep works in ROS 2

ROS 2 packages declare dependencies in a package.xml manifest. The manifest uses dependency tags defined by the ROS package format. In package format 3, specified by REP 149, common tags include buildtool_depend, build_depend, exec_depend, test_depend, and the combined depend tag.

rosdep resolves a dependency key rather than assuming that the key is identical to the native package name. This abstraction matters because one library may have different package names on Ubuntu, Debian, Fedora, macOS, or other supported platforms.

<package format="3">
  <name>ugv_perception</name>
  <version>0.1.0</version>
  <description>Perception package for a mobile robot.</description>

  <maintainer email="[email protected]">Maintainer</maintainer>
  <license>Apache-2.0</license>

  <buildtool_depend>ament_cmake</buildtool_depend>
  <depend>rclcpp</depend>
  <depend>sensor_msgs</depend>
  <depend>cv_bridge</depend>
  <depend>libopencv-dev</depend>
  <exec_depend>geographiclib</exec_depend>
</package>

For a ROS 2 workspace, rosdep scans package manifests under the source directory. The standard command below installs dependencies that are not already provided by packages in the workspace itself.

cd ~/ugv_ws
rosdep install --from-paths src --ignore-src --rosdistro humble -r -y

The --from-paths src option scans package manifests under src. The --ignore-src option prevents rosdep from trying to install a dependency that is already present as source code in the workspace. The -r option continues after unresolved keys, while -y automatically confirms supported package-manager actions.

rosdep sources, keys, and operating system rules

rosdep uses a database of YAML rule files. These files define how a rosdep key should be resolved for a specific operating system, release, and installer. On Linux systems, source definitions are normally configured in /etc/ros/rosdep/sources.list.d/.

Before dependency installation, rosdep must be initialized and its rule database must be downloaded. System initialization usually requires administrator privileges, while updating the local cache is commonly performed by the current user.

sudo rosdep init
rosdep update
rosdep resolve libopencv-dev
rosdep check --from-paths src --ignore-src --rosdistro humble

The rosdep resolve command shows the installer rule for one key. The rosdep check command reports dependencies that are unresolved or not installed. These commands are useful when deploying a workspace to a Raspberry Pi-based computer on Leo Rover or to an x86_64 computer installed on Raph Rover.

Element	Purpose	Example
rosdep key	Platform-independent dependency identifier	`libopencv-dev`
Installer	Native package installation method	`apt`, `pip`, `brew`
OS rule	Mapping for an operating system and release	Ubuntu Jammy package mapping
package.xml	ROS package manifest scanned by rosdep	`format="3"`

Use on Leo Rover and Raph Rover

Leo Rover is commonly deployed with a Raspberry Pi-based onboard computer. ROS 2 support depends on the installed operating-system image and rover software release. For this platform, rosdep should be run on the same ARM Linux environment that will build and execute the workspace. Installing dependencies on a developer laptop does not guarantee that equivalent ARM packages, repository versions, or binary architectures are available on the rover.

A typical Leo Rover workspace may contain packages for differential-drive odometry, LiDAR drivers, IMU integration, depth-camera processing, Nav2, SLAM, and robot description files. rosdep can install external dependencies for these packages, but hardware-specific prerequisites may remain outside the rosdep database.

LiDAR drivers may require USB permissions and device rules.
Depth cameras may require a vendor SDK, kernel modules, or firmware updates.
GPS/RTK receivers may require serial-port permissions and udev configuration.
GPU-enabled perception nodes may require a CUDA-compatible operating system image and vendor runtime.

Raph Rover can carry a larger payload and can be integrated with more demanding compute hardware. rosdep remains useful for ensuring that a navigation or perception workspace has consistent declared dependencies across development computers, simulation machines, and onboard computers. It does not select sensor placement, validate power budgets, or guarantee real-time behavior.

Custom rosdep rules for robotics projects

A project may require a dependency that is not available in the public rosdep database. In that case, an engineering team can maintain a custom YAML rule file and register it through a local rosdep source list. Custom rules should map a stable rosdep key to a verifiable package, archive, or installer method.

example_sensor_sdk:
  ubuntu:
    jammy:
      apt:
        packages:
          - example-sensor-sdk

Custom rules should be version-controlled and reviewed with the robot workspace. A rosdep key should describe a dependency, not a specific deployment machine. Avoid using rosdep rules to execute arbitrary configuration scripts, create users, change network settings, or modify robot safety parameters.

Limitations and reproducibility

rosdep resolves dependencies according to the current rule database and available operating-system repositories. It does not lock exact package versions by default. Therefore, two installations performed at different times can receive different package revisions if the underlying repository changes.

For reproducible UGV deployments, rosdep is commonly combined with an explicitly selected ROS distribution, an operating-system release, version-controlled source repositories, and container images. Docker can provide stronger environment consistency, while rosdep remains useful inside the image build process.

ROS 1 and ROS 2 both use rosdep, but package names, supported distributions, build tools, and dependency graphs can differ. A ROS 1 workspace built with catkin should not be assumed to be directly compatible with a ROS 2 ament_cmake workspace.

Normative references and official documentation

The following sources define or document the relevant ROS package and dependency-management conventions.

rosdep documentation – ROS documentation project.
REP 149: Package Manifest Format 3 – ROS Enhancement Proposal.
Using rosdep to install dependencies – ROS 2 documentation.
Leo Rover technical documentation – Fictionlab documentation.