Current ROS-MATLAB Bridge Solution at the MPI for biol. Cyb.

[Martin Riedel]

The current implementation of our ROS-MATLAB Bridge is divided into

several steps and requires some adaptation on MATLAB runtime files (prior to MATLAB 2012a).

We currently can operate our solution in Linux and Mac OS (various versions) with MATLAB

(tested with 2011a, 2011b and 2012a). The biggest obstacle concerning a ROS-MATLAB Bridge in

Windows is the (still) limited support of ROS under Windows. Our setup requires three

distinct step:

 

1. Compilation and linking of ROS and additional 3rd-party packages

against the proper boost version provided this specific version of MATLAB.

(e.g.2011a: Boost v1_40; 2011b: Boost v1_44; 2012a: Boost v1_44). Furthermore,

ROS should be compiled with one of MATLABs supported compilers.

(e.g. http://www.mathworks.de/support/compilers/R2011b/glnxa64.html)

Since MATLAB 2012a, support for gcc-4.4 and g++-4.4 was added, which is a native

repository package in Ubuntu 12.04 (no need to compile by hand). Technically, one

can use an unsupported compiler (e.g. 4.6), but this requires to "hack" MATLAB into

using a different c++ std library which (could possibly) lead to stability issues.

(We did that for versions prior to 2012a, and had no problems). Currently, we have

precompiled libraries of the ROS Bare System (fuerte) and some of our custom libraries

for Linux 64bit and MacOS 64bit and MATLAB 2012a. Libraries were compiled with 

the official supported compilers (Linux: g(cc|++)-4.4, MacOS(Xcode4.4): llvm-g(cc|++)-4.2) 

and the boost headers for version 1.44 and linked against the dynamic boost libraries that

ship with MATLAB.

Unfortunately, the process of compiling ROS in this specific setting is quite cumbersome.

The ROS Base System can now (since fuerte) be completely configured per CMake, which allows

for specifying the compiler to use and (technically) also the boost version. However,

one would also need to specify the desired settings for all further (custom) ROS packages,

which I personally find hard to configure in an automatic way (Since packages find boost

via the ROS-tool boost-cfg).

We are willing to share our precompiled binaries upon request. 

 

2. Setting a build environment.

As a prerequisite, MATLAB should have the correct mexopts.sh settings. (e.g. Linux

with gcc-4.4 and MacOS (see patch here: 

http://www.mathworks.de/support/solutions/en/data/1-FR6LXJ/)

 

We compile our mex functions (s-functions) outside of MATLAB with the help of

custom Makefiles. The Makefile identifies the System (Linux/MacOS) and finds the 

the precompiled binaries (from step 1) by looking at defined system variables. The

required build flags (-I,-L,-l) are identified by ROS tools (rospack). The Makefile

looks up the linker flags for the precompiled code, as well as optional include flags

for additional ROS message definitions, that can be found in the "native" ROS

installation of the system. Since ROS messages and services are rewritten into Header-only

definitions, the "precompiled" MATLAB Bridge is also extendable to new messages without

the need for recompilation.

We defined "generic" c s-functions for ROS publisher and subscribers. "Generic" in a

meaning that we can easily adapt them into s functions for a specific ROS message. Since

ROS messages can be freely defined (e.g. nested and arrays), the input/outputs of the

s-functions blocks need to be configured (coded) accordingly. Generic functionality of

the s-function blocks is for example the "topic name" for the publisher/subscriber with

integrated parameter check. As is done in ROS, the Makefile links the distributed

ROS library dependencies in the binary mex file, so that MATLAB can find the shared

libraries at runtime. In our case this does not work on Mac OS yet, there we have

to specify the correct DYLD_LIBRARY_PATH at MATLAB launch to find all required 

shared libraries. (see 3).

The Makefiles are highly customized to our use case, but we would be willing to make

them available to others to understand our build procedure.

3. Running MATLAB 

The "only" thing we have to do in MATLAB is to set the appropriate paths to find the

compiled mex functions. Our lab also created a Simulink Block library to mask and label 

the parameterized s-functions for publishers and subscribers. The attached screenshot 

shows some of the ROS Elements. On Mac OS we launch Matlab in a wrapper script that sets

the appropriate DYLD_LIBRARY_PATH (dynamically determined via rospack).

Conclusion:

At the MPI, we are quite happy with our current working solution. The workflows to

define new ROS (s-)functions (and masks) are well defined and therefore the functionality

of the bridge can be extended dynamically. The biggest challenge for us are new releases

in ROS or MATLAB, since it requires recompilation to that specific version. This process

is not automated (yet) and therefore takes some time to do manually. However, with specific 

extension to the ROS Buildsystem and the ROS CMakefiles for the Bare System, I feel that

this process can be simplified quite a bit.

In my opinion, it would be best to distribute binary code to the "end-users", since the

compilation process is not straightforward and changes with every ROS/MATLAB version. 

From an organizational point of view it should be possible to make the bare communication

system of ROS (e.g. fuerte and electric) available as precompiled code for several

MATLAB versions.

[Martin Riedel]

One important note to add: Personally I hope that the new releases of ROS (groovy and later) will transition to the cmake-only (catkin) build system as soon as possible.
This would tremendously simplify cross compilation of ROS for MATLAB.