Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Create a Node

Before creating a node, make sure to have a clear understanding of what the node is for, and what it's not for. A node is responsible for one specific issue in the package.

A node can have parameters which can be accessed by external processes. A refresher about ROS2 node parameters can be found here.

Writing the Node

Place the node in the package, under my_package/my_package, where my_package is the name of your package. A typical Python node starts out like this:

import os
import rclpy
from rclpy.node import Node

class MyNode(Node):

    def __init__(self):
        super().__init__('my_node','my_package')
        self.logger = self.get_logger()

        # TODO: declare parameters

        # TODO: initialize models, data, hardware, etc.

        # TODO: declare services and actions

        # TODO: start subscribing and publishing to ROS topics

        # TODO: listen to parameter updates

def main():
    rclpy.init()
    node = MyNode()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()

if __name__ == '__main__';
    main()

Next Steps

It's a good idea to first describe the parameters of the node. This is explained here.

Also make sure your node reacts to parameter updates, as described here.

Once the parameters work as expected, add subscriptions and publications to the ROS topics.

If applicable, also declare services and actions (TODO: page with explainers).

The /monitor Topic

Hardware, as well as cloud services are known to fail from time to time. To vastly reduce the time spent by the field engineer that debugging issues because of this, consider sending periodic status information about your node over the /monitor topic. Integrating this information in the Monitor overview page will allow the engineer to almost immediately figure out what's wrong.

For sensors, consider the following information:

  • whether or not they are responding
  • operational temperature
  • voltage and current
  • the raw sensor readout itself

For cloud services, consider the following information:

  • if the service can be reached
  • general response latency
  • the state of API secrets and

Once you have a clear idea of what to send to the Monitor, contact Desmond to integrate the information in the core and Monitor.