Revision history [back]

A node is a process that performs some form of logic as part of your full robot control system, a topic is an interface through which multiple nodes can communicate. A node can publish and subscribe to any number of topics, and any number of nodes can publish and subscribe to a single topic (though it's more common that only a single node is responsible for publishing on a topic).

This also implies that a topic can exist separately from any node that contains a publisher for it. If there is an active subscription to the topic but nobody is publishing on it, then the topic will also still show up in ros2 topic list. For instance if you run ros2 topic echo foo std_msgs/msg/Bool, then in another terminal run ros2 topic list, then you will see the /foo topic even though nobody has ever published anything on it! The output of ros2 topic info /foo will show that, telling you that there is 1 subscription but 0 publishers:

$ ros2 topic info /foo
Type: std_msgs/msg/Bool
Publisher count: 0
Subscription count: 1

Adding the -v flag will give more output about the possible publishers or subscriptions:

$ ros2 topic info /foo -v
Type: std_msgs/msg/Bool

Publisher count: 0

Subscription count: 1

Node name: _ros2cli_340
Node namespace: /
Topic type: std_msgs/msg/Bool
Endpoint type: SUBSCRIPTION
GID: 01.0f.3e.26.54.01.00.00.01.00.00.00.00.00.05.04.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RMW_QOS_POLICY_RELIABILITY_BEST_EFFORT
  Durability: RMW_QOS_POLICY_DURABILITY_VOLATILE
  Lifespan: 2147483651294967295 nanoseconds
  Deadline: 2147483651294967295 nanoseconds
  Liveliness: RMW_QOS_POLICY_LIVELINESS_AUTOMATIC
  Liveliness lease duration: 2147483651294967295 nanoseconds

So this says that the subscription comes the node _ros2cli_340, which is the name picked by the ros2 echo command.

This situation also could happen if you run RQT or Rviz to monitor or visualize a topic, then kill the publishing node: they keep their subscription and the topic still exists.

Another situation I have seen in the past is if the publisher is run on another machine (your robot) and you run ros2 topic list on another machine connected to the same network (your laptop), then when you kill the publisher it may take a while for your machine to notice that the topic is gone, even without any subscription to it.

So all that is to say that if you see a topic, it doesn't necessarily mean you have a zombie process publishing to it. To figure out what is happening I would: * run ros2 topic info /topic -v to see if there is either a publisher or a subscription and what their name is, which could help determining where to look for it. * maybe run ros2 node list -a to help further to understand all the nodes that are running * Finally if that doesn't give anything or your not able to find where they are running (which shouldn't happen easily if you just use ros2 run and ctl+c in terminals to start and stop your nodes), I'd run ps aux | grep ros to see if there are hidden things running, and then kill them with kill, or perhaps even kill everything with pkill ros (which will also kill anything else that happens to have ros in its name)

A node is a process that performs some form of logic as part of your full robot control system, a topic is an interface through which multiple nodes can communicate. A node can publish and subscribe to any number of topics, and any number of nodes can publish and subscribe to a single topic (though it's more common that only a single node is responsible for publishing on a topic).

This also implies that a topic can exist separately from any node that contains a publisher for it. If there is an active subscription to the topic but nobody is publishing on it, then the topic will also still show up in ros2 topic list. For instance if you run ros2 topic echo foo std_msgs/msg/Bool, then in another terminal run ros2 topic list, then you will see the /foo topic even though nobody has ever published anything on it! The output of ros2 topic info /foo will show that, telling you that there is 1 subscription but 0 publishers:

$ ros2 topic info /foo
Type: std_msgs/msg/Bool
Publisher count: 0
Subscription count: 1

Adding the -v flag will give more output about the possible publishers or subscriptions:

$ ros2 topic info /foo -v
Type: std_msgs/msg/Bool

Publisher count: 0

Subscription count: 1

Node name: _ros2cli_340
Node namespace: /
Topic type: std_msgs/msg/Bool
Endpoint type: SUBSCRIPTION
GID: 01.0f.3e.26.54.01.00.00.01.00.00.00.00.00.05.04.00.00.00.00.00.00.00.00
QoS profile:
  Reliability: RMW_QOS_POLICY_RELIABILITY_BEST_EFFORT
  Durability: RMW_QOS_POLICY_DURABILITY_VOLATILE
  Lifespan: 2147483651294967295 nanoseconds
  Deadline: 2147483651294967295 nanoseconds
  Liveliness: RMW_QOS_POLICY_LIVELINESS_AUTOMATIC
  Liveliness lease duration: 2147483651294967295 nanoseconds

So this says that the subscription comes the node _ros2cli_340, which is the name picked by the ros2 echo command.

This situation also could happen if you run RQT or Rviz to monitor or visualize a topic, then kill the publishing node: they keep their subscription and the topic still exists.

Another situation I have seen in the past is if the publisher is run on another machine (your robot) and you run ros2 topic list on another machine connected to the same network (your laptop), then when you kill the publisher it may take a while for your machine to notice that the topic is gone, even without any subscription to it.

So all that is to say that if you see a topic, it doesn't necessarily mean you have a zombie process publishing to it. To figure out what is happening I would: * would:

• run ros2 topic info /topic -v to see if there is either a publisher or a subscription and what their name is, which could help determining where to look for it. * it.
• maybe run ros2 node list -a to help further to understand all the nodes that are running * running
• Finally if that doesn't give anything or your not able to find where they are running (which shouldn't happen easily if you just use ros2 run and ctl+c in terminals to start and stop your nodes), I'd run ps aux | grep ros to see if there are hidden things running, and then kill them with kill, or perhaps even kill everything with pkill ros (which will also kill anything else that happens to have ros in its name)