Ask Your Question
1

Integrating ROS with an existing C++ code base

asked 2018-08-21 18:14:00 -0600

twink gravatar image

I have an existing C++ code base building in Eclipse and running under Ubuntu 16.04 and I would like to incorporate some ROS (melodic) functionality (nodes, services, etc, for starters). I've been reading the tutorials and documentation about catkin and such, and also done some searching, but I'm still unsure of the best way to make this happen. For example, is there a way that I can add the ROS build constructs to the existing Eclipse project? Or do I need to create a new project, and import the source? In the latter case, do I need to add lines for all the cpp files to CMakeLists.txt manually?

I've also found this: http://wiki.ros.org/IDEs , which is surely relevant, but doesn't quite describe my situation.

If someone could point me in the right direction, I'd appreciate it.

Thanks!

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
2

answered 2018-08-22 04:02:01 -0600

gvdhoorn gravatar image

updated 2018-08-22 14:15:15 -0600

Can you clarify what sort of integration you are looking for?

Best practice is to keep non-ROS code "non-ROS code" and to create separate, relatively small (or thin) wrappers that make use of functionality provided by libraries etc.

Doing it that way, there should be no need to import any sources or existing infrastructure into a ROS-aware IDE: just develop the non-ROS code as you always do, make sure the necessary parts can be found (by CMake) and keep the ROS adapters as ROS pkgs in a ROS workspace.

CMake has all the support for such a workflow (and Catkin too).


Edit:

it sounds like in the setup you're describing, the executables would end up being the ROS nodes, and other system code would be called via libraries. Yes?

that was my suggestion yes.

I was hoping there was a way to basically add some ROS functionality to our project, sort of like a 3rd party SDK, rather than essentially ROS-ifying our whole project. This is starting to look like a naive notion...

As to the type of integration you mention in your comment on @PeteBlackerThe3rd: see gerkey/ros1_external_use (this post talks a bit about it).

Note: this is not a typical workflow / setup, so you could run into some issues. There will also not be many people able to help you, as I believe 98% of ROS (1) users would be doing the regular Catkin based approach combined with my suggestion (calling into libraries from ROS nodes).

Another alternative way to integrate with ROS is to not integrate at all.

That may sound strange, but you could just use an IPC with rosbridge_suite on the ROS side, and some JSON parsing/emitting code on the other. Of course this could be done the other way around as well: write a ROS node that implements / uses the ROS API that you'd like to offer / consume and use any IPC system to communicate with your existing system (gRPC, etc).

This is a commercial product, not a research project, so I need to have a clean, maintainable design.

And personal perhaps, but please refrain from such comments. You're implying that all "research project" code is not clean or maintainable. I know that is a popular thing to claim, but it is far from true and not a very nice thing to say or write.

edit flag offensive delete link more

Comments

@gvdhoorn , thanks very much; your comments are very interesting, since that's actually what I would prefer to do. This is a commercial product, not a research project, so I need to have a clean, maintainable design. So we currently have an executable that spawns some subsystem threads.

twink gravatar imagetwink ( 2018-08-22 12:41:52 -0600 )edit

My thought was to use create a ROS service out of one of those threads and a ROS service client out of another. But it sounds like in the setup you're describing, the executables would end up being the ROS nodes, and other system code would be called via libraries. Yes?

twink gravatar imagetwink ( 2018-08-22 12:50:21 -0600 )edit

Or are you suggesting wrapping the ROS stuff somehow? Thanks!

twink gravatar imagetwink ( 2018-08-22 12:51:39 -0600 )edit

@gvdhoorn thanks again for the ideas, and especially for pointing me to that discussion It gets exactly to the crux of my initial reaction to ROS and it's very good to hear folks talking and thinking about it.

twink gravatar imagetwink ( 2018-08-22 15:48:12 -0600 )edit

Re commercial vs research use, please accept my apologies. I didn't mean to imply that all research code is not maintainable, etc. Just that some research-related code may have a relatively short life-span, and hence may not have maintainability as a priority or goal, understandably.

twink gravatar imagetwink ( 2018-08-22 16:02:43 -0600 )edit
0

answered 2018-08-22 03:54:30 -0600

I think you're on the right track. I would create a new catkin package and add the executable and all its source files to the CMakeLists.txt file. You can also add any non standard library dependencies and compiler flags if you need to. You should be able to compile the same project without any code changes, so within catkin but with no ROS calls to test everything is working.

Then you can start adding the ROS functionality you mentioned.

You can edit the new source directory in eclipse by adding an 'existing source repository'. Personally I build my packages on the command line but you can setup build and run commands within eclipse if you want.

edit flag offensive delete link more

Comments

@PeteBlackerThe3rd thanks very much. I believe I can do what you're suggesting. I was hoping there was a way to basically add some ROS functionality to our project, sort of like a 3rd party SDK, rather than essentially ROS-ifying our whole project. This is starting to look like a naive notion...

twink gravatar imagetwink ( 2018-08-22 12:59:59 -0600 )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

2 followers

Stats

Asked: 2018-08-21 18:14:00 -0600

Seen: 680 times

Last updated: Aug 22 '18