ROS Best Practices

See also Patterns page.

Overview

ROS was designed to be maximally flexible, starting with the mantra, "we don't wrap your main()." This flexibility has surely contributed to the growth of the user and developer community, allowing ROS to be used on a wide variety of platforms, in myriad ways.

But, with a few years under our collective belt, the community has matured to a point where "best practices" are in demand. We're not talking about standards, but rather statements of how best to achieve common tasks with ROS. Best practices are advice to developers on how to design, build, and configure ROS systems, with the goal of improving efficiency, interoperability, and shared understanding of those systems.

How to describe a best practice

One way to state a best practice is via a ROS Enhancement Proposal (REP). An informational REP can give guidelines and prescribe preferred techniques. In the long term, we expect established best practices to be described in REPs.

But a best practice can be described in other, less formal, ways. Feel free to write up your own ideas for best practices in this wiki or elsewhere, and add links below so that others can find that content.

Existing best practices

Known best practices are indexed here. Please add to this list.

• Standard Units of Measure and Coordinate Conventions

• Coordinate frames for mobile platforms

• Diagnostic System for Robots Running ROS (RFP 107), QA thread with a focus on existing tools

• roslaunch/Tutorials/Roslaunch tips for larger projects

• Using ThirdParty Libraries

• Package versioning

• Summary of ROS Best Practices with C++ template/example package

Needed best practices

Is there some aspect of system design or configuration that you want guidance on? Some existing system that you'd like to emulate but isn't well-documented? Please add your requests here.

See something in the list below that you can help with? Write it up, link it here, and let ros-users know about it. If you can only address part of an item on the list, that's fine; sometimes the initial question can be ill-posed or vague.

• When should I not use ROS?
• I have a mobile robot that isn't currently supported by ROS. How should I structure the driver node(s) to expose my robot's integrated sensors and actuators?

• When should I remap? When launch nodes / add parameters in namespaces?

• When I have the same kind of data coming from multiple sources, should I use different topic names or have the origin of the data in the message?

  • Related thread

• When should I use topics vs services vs actionlib actions (vs dynamic_reconfigure)?

• When should I split my code into multiple packages, and what's a good way to split it (Mention the advantages of message definition packages.)?

  • Related thread 1, 2

• When should I combine several packages into a stack?
• When should I send geometric information over a topic as opposed to TF?
• Designing messages, services and actions.
  • Naming practices

  • Capturing server-side errors for rospy. roscpp

• How to setup ROS for multi-robot domains (how many roscores, namespaces for nodes, tf frames)

• How to structure launch and param yaml files (how to name, where to put, namespaces of params) Related QA

• How can I avoid reimplementing existing functionality before I create a new package?

• How can I integrate/interface non-ROS systems and modules with ROS?

• Which logging mechanism should we use when my module is heavily dependent on 3rd party framework where its logging feature is available?

• Template the workflow of adding test cases for ROS {Services, Action} servers.

• Node structure for UI (web-UI using robot_web_tools etc.) Intermediate node between UI nodes and non-UI nodes allows easy switch of UI implementation (e.g. from Qt-based UI to web UI or vice-veresa) while this adds overhead?

Update: a number of these questions and some others have been posed on answers.ros.org with the best_practices tag. Some have answers, others still do not. Please contribute answers where you can.