Ask Your Question

Revision history [back]

Calling 'C from C++' is a bit of a non-issue: both are compilable by C++ compilers, provided you take proper care (symbol mangling, etc). This is also not very ROS specific. If you're using Matlab code generators, you should be able to call into that code from a C++ based ROS wrapper. Some links:

But again, this is not very ROS specific.

Now if you have an actual binary, that is a different matter. As you wrote in the How to create ROS package for Existing C code, you can execute those using system(). I can see two issues with that:

  1. Why system() is evil.
  2. Overhead: this is already mentioned by the link under point 1, but as you've tagged your question with opencv2, I'm assuming you'll want to do image processing, where processing latency is often undesirable. Starting, executing and stopping a binary for every frame is not going to be very efficient.

A third might be that you're not really integrating with ROS that way, and besides basic input-output wrapping you won't be able to access any of the nice things ROS can offer.

Btw: Mathworks has released an official ROS support package for Matlab 2012b and up. You might be interested in that as well.

Calling 'C from C++' is a bit of a non-issue: both are compilable by C++ compilers, provided you take proper care (symbol mangling, etc). This is also not very ROS specific. If you're using Matlab code generators, you should be able to call into that code from a C++ based ROS wrapper. Some links:

But again, this is not very ROS specific.

Now if you have an actual binary, that is a different matter. As you wrote in the How to create ROS package for Existing C code, you can execute those using system(). I can see two issues with that:

  1. Why system() is evil.
  2. Overhead: this is already mentioned by the link under point 1, but as you've tagged your question with opencv2, I'm assuming you'll want to do image processing, where processing latency is often undesirable. Starting, executing and stopping a binary for every frame is not going to be very efficient.

A third might be that you're not really integrating with ROS that way, and besides basic input-output wrapping you won't be able to access any of the nice things ROS can offer.

Btw: Mathworks has released an official ROS support package package for Matlab 2012b and up. You might be interested in that as well.