ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Compiling ROS2 node with large nr of subscribers doesn't scale

asked 2020-08-07 16:38:23 -0500

scme2048 gravatar image

updated 2021-03-30 09:35:00 -0500

gvdhoorn gravatar image

Hello. I'm having some trouble creating a subscriber node that contains a large amount of messages. In terms of code structure, I'm implementing the same type of subscriber node as shown here: https://index.ros.org/doc/ros2/Tutori...

The issue, is that as the number of messages increases, each with a unique message type and callback, the module becomes impossible to compile due to memory constraints. At ~60 messages, the cc1plus process is consuming 6GB of RAM attempting to compile. This makes sense, as the single compilation unit is becoming quite large. Additionally, I believe that the underlying templates for the create_subscription are exploding the memory consumption. Setting the compile flag -ftemplate-depth=XX yields that a single subscription has a template depth greater than 50.

So... with that lead in, is there a more scale-able way to implement a subscriber node with custom callbacks and message types?

edit retag flag offensive close merge delete

Comments

1

60 subscribers for a single node? Seems like you might want to make things more modular, which is the ROS-y way of doing things.

stevemacenski gravatar image stevemacenski  ( 2020-08-07 17:29:11 -0500 )edit

I do admit some level of ROS in-familiarity, but coming from other pure messaging frameworks 60 subscriptions seems rather low for some applications (I'm used to hundreds). I'm fine coming up with a scheme that limits node subscriptions, but am curious if there are ways to allow for N subscribers (generic run-time subscribe, etc).

scme2048 gravatar image scme2048  ( 2020-08-10 13:13:21 -0500 )edit

coming from other pure messaging frameworks 60 subscriptions seems rather low for some applications (I'm used to hundreds)

hundreds of different subscriptions in a single node?

Could you give a (high-level) example of the type of system(s) you're creating?

gvdhoorn gravatar image gvdhoorn  ( 2021-03-30 09:37:48 -0500 )edit

Sure. For example, our ROS environment needs to interface with an external device, so a node is serving as a serializer of a set of ROS messages that need to be sent to the device, where that set of messages could be in the hundreds of unique messages.

scme2048 gravatar image scme2048  ( 2021-03-30 14:42:52 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-03-29 12:59:47 -0500

scme2048 gravatar image

Revisiting this post much later to report a solution/workaround. For each message subscription, moving the create_subscription call into a message specific subscribe function as well as the message callback functions into individual .cpp/.hpp files allows each one message/subscription to be its own compilation unit. The node subscriber then forward declares the message specific subscribe functions and calls the message specific subscribe functions to create the subscriptions. This method seems to be scalable to N number of messages in terms of compile time RAM usage. The impact is then on compile time rather than system RAM. Currently I have a node with 100+ subscriptions that takes ~10 minutes to compile, but does not consume inordinate amounts of RAM, which is an acceptable solution for my use case.

edit flag offensive delete link more

Comments

This is primarily about C++ templating, correct?

The question title suggests a runtime aspect to it, which does not appear to be the case. Perhaps a clarification is in order?

gvdhoorn gravatar image gvdhoorn  ( 2021-03-30 03:37:42 -0500 )edit

At the root level, yes it is about C++ templating in that the recursion at compile time was causing RAM usage proportional to the the number of message subscriptions, and at some point hindering compilation due to system resource limits. If the compilation succeeded, there were no issues at run time.

scme2048 gravatar image scme2048  ( 2021-03-30 09:26:51 -0500 )edit

I've updated the question title to reflect this better.

Whatever the root cause, you'd already discovered it was building which seemed to take a long time. So I've added that to the title.

gvdhoorn gravatar image gvdhoorn  ( 2021-03-30 09:35:54 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2020-08-07 16:38:23 -0500

Seen: 303 times

Last updated: Mar 30 '21