How do you avoid ROS design anti-patterns?

1 Use namespaces and remappings

One of the ROS design anti-patterns is to hardcode topic, service, or parameter names in your nodes. This can cause conflicts, confusion, or dependency issues when you want to run multiple instances of the same node or use different hardware configurations. To avoid this, you should use namespaces and remappings to assign or change the names of topics, services, or parameters at runtime. Namespaces allow you to group related nodes under a common prefix, while remappings allow you to redirect the input or output of a node to a different name.

2 Follow the nodelet guidelines

Another ROS design anti-pattern is to use too many nodes when you could use nodelets instead. Nodelets are a special type of nodes that run in the same process and communicate through shared memory, avoiding the overhead of inter-process communication. Nodelets are especially useful for high-frequency or low-latency tasks, such as image processing or sensor fusion. To avoid this anti-pattern, you should follow the nodelet guidelines and use nodelets whenever possible, unless your node requires a lot of memory, CPU, or external resources.

3 Use launch files and parameters

A third ROS design anti-pattern is to rely on manual commands or scripts to start and configure your nodes. This can make your project hard to reproduce, share, or deploy. To avoid this, you should use launch files and parameters to automate and customize the launch of your nodes. Launch files allow you to start multiple nodes with a single command, specify their namespaces and remappings, and pass arguments or environment variables. Parameters allow you to store and retrieve configuration values for your nodes, such as thresholds, gains, or flags.

4 Adopt the ROS conventions

A fourth ROS design anti-pattern is to ignore or violate the ROS conventions for naming, formatting, or structuring your code. This can make your project inconsistent, unclear, or incompatible with other ROS packages or tools. To avoid this, you should adopt the ROS conventions and follow the recommended standards for naming your packages, nodes, topics, services, parameters, messages, or actions. You should also follow the formatting and coding style guidelines for your preferred programming language, such as C++, Python, or Java.

5 Document your project

A fifth ROS design anti-pattern is to neglect or postpone the documentation of your project. This can make your project hard to understand, maintain, or extend. To avoid this, you should document your project as you develop it, using the appropriate tools and formats for ROS. You should document your package.xml file, which contains the metadata and dependencies of your package. You should document your nodes, topics, services, parameters, messages, or actions, using comments, docstrings, or Doxygen annotations. You should also document your launch files, using XML comments or roslaunch-check.

6 Test your project

A sixth ROS design anti-pattern is to skip or skimp on the testing of your project. This can make your project prone to errors, bugs, or failures. To avoid this, you should test your project thoroughly and systematically, using the available tools and frameworks for ROS. You should test your nodes individually, using unit tests or rostest. You should test your nodes together, using integration tests or roslaunch-test. You should also test your project in simulation, using Gazebo or other simulators.

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?