Robotics StackExchange | Archived questions

ROS1 -> ROS2: Migration standard

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:

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?

Asked by Agju on 2022-04-13 02:51:52 UTC

Comments

Answers

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.

Asked by clalancette on 2022-04-18 08:10:05 UTC

Comments

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.

Asked by Agju on 2022-04-19 08:06:41 UTC