ROS Best Practices
See also Patterns page.
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.
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 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?
- 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.)
- When should I combine several packages into a stack?
- When should I send geometric information over a topic as opposed to TF?
- Instructions and best practices for naming messages, topics, and services.
- 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?
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.