Ask Your Question
2

ROS1 -> ROS2: Migration standard

asked 2022-04-13 02:51:52 -0500

Agju gravatar image

HI,

I'm trying to migrate a project from ROS1 Melodic to ROS2 now that it is getting a "LTS" release in May. I've followed tutorials, did some tests and simple packages, and I wanted now to migrate some "simple" packages to ROS2.

I have a big question regarding standards though. Let me try with an example:

(All this is ROS1 current code) I have a package called sensors_manager that, well, manages the sensors data. The code is split in 2 parts:

  • sensor.cpp: Class that has a NodeHandle, a subscriber for raw sensor data, another for a trigger to report to a file, and a method to filter and report to a file.
  • sensors_manager_node.cpp: Main function that inits a ros node, instantiates a bunch of sensor class, and spins

When trying to convert to ROS2, I'm not getting clear what's the desired standard to use. I've though about 2 solutions:

  1. Delete the NodeHandle and subscribers of sensor.cpp Class. Add them to the manager, and use each instantiated sensor member function as subscriber callback.
  2. Convert sensor class to Node, instantiate a bunch of nodes in sensor_manager, add them to executor and spin. (composition?)

Is there any other way of doing it that ROS2 intends to 'prioritize'? I'm not getting the second one, because what if there's 20 sensors, are we creating 20 nodes?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2022-04-18 08:10:05 -0500

clalancette gravatar image

It really depends on what you are trying to do, and what your sensor suite looks like.

If your sensors are truly independent, in that any one of them could be used standalone, then I'd suggest making each of them a separate Node. That way, you (or your users) will be able to arbitrarily compose them in different ways.

On the other hand, if the sensors are all tied together, and will always be used together, then you can either create one "mega" node that handles them all, or make one node at the top-level and pass that into each of the constructors for the individual sensors. I'd opt for the "mega" node myself (if they aren't separate they may as well all be handled together), but either way will work.

edit flag offensive delete link more

Comments

1

Thanks!!

They are all "ambient" sensors (temperature, humidity, etc) that just read data and report to a file. They are configurable to be ON or OFF, but there's honestly no use on having a sensor outside of the usual "node" that runs them.

I've also opted for the "mega" node, as they will always run in the same place.

Agju gravatar image Agju  ( 2022-04-19 08:06:41 -0500 )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

3 followers

Stats

Asked: 2022-04-13 02:51:52 -0500

Seen: 178 times

Last updated: Apr 18