How can ROS Custom Messages be exchanged or even moved to another folder?

The task seems simple:

Generate ROS Custom Message for a ROS Package and copy it to other machines, so that my students don't have to go through with generating the custom message by their own. Before R2020b it was no problem. We generated the message definitions by the separate toolbox and could exchange the created folder with it's message definitions. Since R2020b has build in support for generating ROS custom messages I can't even move the generated folder on the same PC.

What System is used: Ubuntu 20.04, Matlab R2020b

Workflow:

I generate my message type by starting Matlab with:

LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libstdc++.so.6:/usr/lib/x86_64-linux-gnu/libcurl.so.4" matlab

(LD_PRELOAD is needed, because cmake is not working with std-libs provided by the Matlab version.)

Using rosgenmsg(...) is working and I can use:

addpath(...);clear classes;rehash toolboxcache;

rosmessage('...') is giving me my custom message object.

Restarting Matlab and using addpath again still works for getting my object.

Now I simply rename the generated "matlab_msg_gen_ros1" folder into "matlab_msg_gen_ros1_"

After restarting Matlab and using addpath(...);clear classes;rehash toolboxcache; with the modified path, the message type is not recognized by Matlab anymore.

(Now, even renaming the folder back into the old name and using the old path for addpath ... is not working anymore. Only if I redo the rosgenmsg procedure, it is working again)

Is there a way to exchange / move the generated message definition, or is there another way to export and import (share) custom message definitions?

Answer 1

[Cam Salzberger]

Hello Sven,

The "addpath" command is only a small part of getting the custom messages working with MATLAB. It is required to register the generated M-files with MATLAB, but the libraries that get built are registered in a different way as part of the "rosgenmsg" run.

In R2020b, if you run rosgenmsg on a custom message folder, and then re-run it without changing anything, it shouldn't actually build the messages a second time. A quick check is done (on a package-by-package basis) to see if the message definitions have changed, and if not, they are simply re-registered to MATLAB.

You can take advantage of this to transfer pre-built packages between computers. Be aware that it only works when built by the same MATLAB version and on the same computer architecture (OS). If your folder structure looks like this:

custom_interfaces/
|-matlab_msg_gen_ros1/
|-package_1_msgs/
| `-msg/
|   `-MyMsg.msg
`-package_2_msgs/
  `-msg/
    `-MyMsg2.msg

then transfer the full "custom_interfaces" folder to the other machine and run "rosgenmsg" on that folder. It won't work if the generated folder name changes from "matlab_msg_gen_ros1", as that will make it appear that messages have not been generated at all.

-Cam

[Sven Lange]

Thanks for the fast answer and the insight, cam. Unfortunately, it still remains a problem, as I just tested. I used an Ubuntu 18.04 with Matlab R2021a. For that machine, I have to build CMake by my own, because Matlab needs a newer version of it than shipped with the distro. I used rosgenmsg successfully with the new CMake version using the structure you proposed. Afterwards, copied the structure (like your "custom_interfaces" folder) to another folder on the same machine and switched back to the CMake version from the distro. rosgenmsg fails because of the old CMake version. So I think currently there is no way to distribute pre-build message definitions to my students. They may have to do the same complex things like building their own CMake version to get the custom messages running. If you can think of an more elegant way, please let me know. Thanks again, Sven.

[Cam Salzberger]

Hmm, that's a good point. I believe the initial "integrety" checks are done first ("are these valid ROS messages", "is the folder structure as expected", "are the required CMake, Python, and compiler installed"), before it gets to checking if the messages need to be rebuilt. I'll pass on your feedback to the relevant group, but I'm not sure there is an immediate workaround.

From what you are saying, though, it seems like the issue is more about how long it takes to get the system set up for message generation (building CMake, etc.) than about how long the rosgenmsg call actually takes? Or is that an issue as well?

Are all of your students using the Ubuntu 18.04, or are some of them on different versions of Ubuntu, or even not using Linux entirely?

Just trying to get the whole picture here. Thanks!

-Cam

[Sven Lange]

You are right with your guess, that it is not an issue of the time needed generating the messages, but getting the given code / model to run. The students have to work on their own computers (because of restricted access to the university) and may have different Ubuntu or in general Linux distributions running (even different Matlab versions, but hopefully everyone sticks to linux). They are getting incomplete code from us as a starting point to reach the learning goals of a lecture. I would like them to waste as less time possible to get the given code running, so they can concentrate on the lecture's contents.

I can imagine, that it is not possible to be compatible in general between these various software combinations, but it would help, if one could say the given message definitions work out of the box for e.g. Ubuntu 18.04 and R2021b. So maybe some checks like the one for the compiler could be done later in the sequence.

It sounds plausible, that there is currently no workaround, but as you said, maybe it is a useful feature for later versions.

[Cam Salzberger]

Thanks for the additional information. I do know that certain CMake versions are required due to issues of compatibility between CMake and certain versions of ROS and ROS 2. But I agree with your point that if no build is required, the pre-requisites for the build shouldn't be checked. I've passed on a report to our team regarding this issue.

-Cam

[Cam Salzberger]

Hello Sven,

I followed up with the team, and found that I was somewhat mistaken about the way the build-check worked. Apparently it makes use of CMake and catkin (Python tool) to perform the check to see if a rebuild is required or not. So simply changing around the order of operations would make sense, since those build tools are required to see if a build is necessary.

I have opened a separate enhancement request to allow for the registration of pre-created custom messages without checking for rebuild, but it's not a trivial request. Sorry about the confusion!

-Cam