How to best handle dependencies on topics, services etc to gracefully handle startup and error recovery? (ROS2)

Question

Is there a standard approach we should be using to handle dependencies on topics and services? Our system has a number of nodes and some nodes provide interfaces to external sensors. We'd like to be able to cleanly handle startup and error recovery conditions.

We are considering a few different situations and looking for advice

If we have a node 'A' that depends on topics and services provided by other nodes, nodes 'B', and 'C' how should node 'A' determine when it is ready and should go online?

Should 'A' wait to complete its startup until it sees the topics provided by 'B' and 'C' providing data values? Eg. node 'A' has some flags and flips them to true when data comes in and when they are all flipped node 'A' can go online?

We'd like our system to reasonably handle sensors going away.

Maybe not in all cases but for particular sensors this is important. If we have sensors that go away, how do we indicate that information through to the users of the node that provides access to those sensors?

For example should node 'B' stop publishing its topics if its sensor goes away? In that case should node 'A' be tracking the last update time for the topic provided by 'B' and if a timer expires node 'A' can use the lack of data to detect the sensor going offline and itself go offline, waiting until data is available before resuming its operation?

---

We've looked around and can't seem to find any guidance on this, however we suspect this may be due to our not searching using the correct terminology or missing or misunderstanding the design intent of Ros2.

We'd appreciate any tips or pointers you might have.

Answer 1

A few quick places to look: You may check the Qos Policies for topics and services, Qos would help you to establish under what circumstances a subscriber is able to get data from a publisher, but to my understanding, you want something more than that. For the topics, I would say it isn't as convenient. For services, though, you have helper functionalities such as (this->client.wait_for_server()).

Typically, you declare the dependencies (build and execution time) of your package in package.xml but this is just to determine the correct build and execution of your package, meaning that it does not have the knowledge of when it is time for a topic or service to go online.

But, for more deterministic behavior of your nodes, you may use LifeCycleNodes concept in ROS2. This way, you explicitly assign a state (e.g., active, unconfigured, inactive, etc) to your node, and with some legwork, you can decide when it is time for the node to be active/inactive. You can always use the the timestamp of a ROS message to determine if it is still useful to you.

For example, should node 'B' stop publishing its topics if its sensor goes away?.

If you are publishing these topics after you receive and process sensor data in a callback, naturally the node will stop publishing if no sensor data is available since the callback won't be triggered. Additionally, you can define a timer callback to periodically check the time stamp of latest received message and let the user know about this.