ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org
Ask Your Question
2

Sharing non-ROS code between packages in catkin

asked 2017-11-09 11:11:43 -0500

rkeatin3 gravatar image

I'm currently writing 3 separate packages for 3 different gripper designs. Under the hood, however, they all use the same UDP interface for sending and receiving commands, data, etc.

What is the recommended way to share the common code between those packages? Is standard practice just to add a separate, non-package directory in the catkin workspace for building a shared library containing common code?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2017-11-09 11:14:39 -0500

gvdhoorn gravatar image

updated 2017-11-09 14:01:02 -0500

TwoThree options:

  1. make your shared code a ROS package (ie: add package.xml and use catkin_package(..) in a CMakeLists.txt)
  2. install shared code "system wide" and treat it as a system dependency
  3. create a "plain CMake" package (see REP-134)

My preference is always option 2, especially if the shared code does not have any ROS dependencies.

edit flag offensive delete link more

Comments

A non-package directory is an option as well, right? Though that would necessitate building with catkin_make_isolated as opposed to catkin_make?

I was hesitant to make another package for the common code (since it's not really standalone), but it's better than option 2 for me in this instance.

rkeatin3 gravatar imagerkeatin3 ( 2017-11-09 13:48:07 -0500 )edit

Thanks for your help!

rkeatin3 gravatar imagerkeatin3 ( 2017-11-09 13:48:44 -0500 )edit
1

You're right, there is a third option (and probably some others as well). I've added it to the list.

gvdhoorn gravatar imagegvdhoorn ( 2017-11-09 14:02:23 -0500 )edit
1

Note that it's really easy to create a Debian pkg with something like checkinstall. That makes things immediately usable as system dependency.

gvdhoorn gravatar imagegvdhoorn ( 2017-11-09 14:03:25 -0500 )edit
1

re: not really stand-alone: I'm not sure how that matters. Library code is almost never stand-alone (ie: doesn't do anything by itself if not used by something else).

gvdhoorn gravatar imagegvdhoorn ( 2017-11-09 14:04:36 -0500 )edit
1

Btw: do the designs change the way the shared code is used? If not, it might make sense to create a stand-alone 'driver' node that gets parameterised by the three packages that provide info about the gripper designs.

gvdhoorn gravatar imagegvdhoorn ( 2017-11-09 14:06:00 -0500 )edit

The shared code just does the socket/UDP stuff, and each gripper will likely have a different interface (though that isn't nailed down yet). The way I have it architected now, each gripper can be controlled with or without ROS, so I'll probably want to stick with that (as opposed to strictly...

rkeatin3 gravatar imagerkeatin3 ( 2017-11-09 15:19:09 -0500 )edit

coupling the shared code to ROS).

rkeatin3 gravatar imagerkeatin3 ( 2017-11-09 15:19:20 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2017-11-09 11:11:43 -0500

Seen: 296 times

Last updated: Nov 09 '17