ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Sorry, but I disagree with the previous answers. You can and it is even quite straight-forward.

Problem 1: I have a non ROS software and I want to depend on a ROS package.

I have written this piece of CMake to detect ROS packages: https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/ros.cmake

It relies on rospack to retrieve the flag you need, it is a simple alternative to rosbuild which is independent from ROS itself. Just copy/paste this script in your code.

To use it, you must first look for the package using:

ADD_ROSPACK_DEPENDENCY(my_ros_package) # i.e roscpp, tf or whatever you want.
USE_ROSPACK_DEPENDENCY(my_target my_ros_package) # my_target is your binary or library which will be linked against my_ros_package.

The only thing you have to do is making sure that rospack is in your path before launching cmake in your project. This is the case if you have sourced your ROS config.sh file.

Problem 2: How to get custom messages/services for my non ROS software?

There is no way to generates files corresponding to messages and services from outside ROS for now.

However, a good practice is anyway to separate ROS interfaces from the code, so you can just write a simple ROS package with just your messages and services and make your software depend on it using the strategy described in (1). Of course, this one is a ROS package living inside ROS.

Conclusion:

In term of architecture, you should probably end up with three packages:

  • mybiglib (the one you already developped / non ROS library)
  • mybiglib_interface (the ROS messages and services, no code, use the ROS build system for now)
  • mybiglib-ros (the ROS bridge / non ROS library, depending on ROS using the strategy describe in (1) and in particular depends on mybiglib_interface)

And that's it :)

I use this solution for my development and I never ran in any kind of trouble (I tested with C++ only though)

Sorry, but I disagree with the previous answers. You can and it is even quite straight-forward.

Problem 1: I have a non ROS software and I want to depend on a ROS package.

I have written this piece of CMake to detect ROS packages: https://github.com/jrl-umi3218/jrl-cmakemodules/blob/master/ros.cmake

It relies on rospack to retrieve the flag flags you need, it is a simple alternative to rosbuild which is independent from ROS itself. Just copy/paste this script in your code.

To use it, you must first look for the package using:

ADD_ROSPACK_DEPENDENCY(my_ros_package) # i.e roscpp, tf or whatever you want.

And then declare a dependency between your target (binary or library) and the particular ROS package you have detected before:

USE_ROSPACK_DEPENDENCY(my_target my_ros_package) # my_target is your binary or library which will be linked against my_ros_package.

The only thing you have to do is making sure that rospack is in your path before launching cmake in your project. This is the case if you have sourced your ROS config.sh file.

Problem 2: How to get custom messages/services for my non ROS software?

There is no way to generates files corresponding to messages and services from outside ROS for now.

However, a good practice is anyway to separate ROS interfaces from the code, so you can just write a simple ROS package with just your messages and services and make your software depend on it using the strategy described in (1). Of course, this one is a ROS package living inside ROS.

Conclusion:

In term of architecture, you should probably end up with three packages:

  • mybiglib (the one you already developped / non ROS library)
  • mybiglib_interface (the ROS messages and services, no code, use the ROS build system for now)
  • mybiglib-ros (the ROS bridge / non ROS library, depending on ROS using the strategy describe in (1) and in particular depends on mybiglib_interface)

And that's it :)

I use this solution for my development developments and I never ran in any kind of trouble (I tested with C++ only though)

trouble.