When something fails
If you are attempting to debug a ROS system
- First try to troubleshoot using:
- If the troubleshooting guide fails to help, search for and answer, or ask a question on
- If you find a bug or wish to make a feature request, please see the next section
Suggestions for reporting issues/requesting features
First, check the issue trackers: Known bugs, often with patches or workarounds, are generally found there. If you have something to add to an existing bug, add it as a comment to the bug, rather than posting to the mailing lists.
If all the above steps failed, the best thing to do file a ticket.
If you're not sure what you found is a bug you can ask on ROS Answers. If the problem is confirmed as a bug, please then open a ticket. Tickets are preferred if you are posting about a bug because they will be reviewed by the developers.
Guidelines for asking a question (Please read before posting)
The following are not appropriate questions:
- general debugging/programming questions not specific to ROS
- questions about software that is not ROS related
- your homework
- Don't contact the developers/maintainers directly.
- The community can't see question or answer(s) not asked/answered publicly.
- Open Source development works best when the entire community participates in discussions and helps to answer questions.
- Send all questions to Answers.ros.org or the appropriate mailing list, and report all bugs to the bug tracker.
On answers.ros.org, do not use answers for discussion, subsequent questions or just updates. Instead, edit your original post or use the comment functionality.
- Be as specific as possible, with steps to reproduce.
Describe exactly what you were doing or are trying to do, and exactly what, if anything, went wrong. If you say, "rviz doesn't work," we can't help you.
- If following a Tutorial or online instructions provide a link to the specific instructions.
Use a descriptive headline or subject line. Bad: "rviz doesn't work". Good: "Rviz crashing looking for missing .so after latest apt update"
- Always provide the following information:
Names and versions of stacks/packages that you're using. "I'm using ROS C Turtle with pr2_simulator 1.1.1 and vocabulary_tree r30294"
Your platform (architecture, OS & version/distro). "I'm running OS X 10.5 on an iBook," or "I'm running Ubuntu Karmic on an x86, with kernel 2.6.31." For Linux, always provide the distro and kernel versions.
Any warnings or errors. Cut and paste them directly from the terminal window to which they were printed. Please DO NOT re-type them yourself. Small typing mistakes can make a large difference and time wasted.
- When discussing any compiling/linking/installation issues, also provide:
- gcc version
- As appropriate, also include your:
- Relevant config files
- Graphics card model and driver version
Ogre.log for rviz, if possible (run with rviz -l)
- Bag files and code samples that can reproduce the problem
- Screenshots or movies to demonstrate the problem
- Always tag your questions appropriately.
- Format code snippets. To make your code snippets and error messages better readable, format them correctly (mark the code and press Ctrl-k).
Assume 'good faith': It's easy to mis-interpret the meaning or tone of comments on the internet. Assuming good faith gives the benefit of the doubt to those trying to help you, avoiding: insulting well meaning community members, and poisoning the mood. Assuming 'good faith' when responding almost always works better even if the original response was not in fact in good faith.
Please don't send your question more than once: The question was seen. If you didn't get a response then likely nobody has had time to answer you. Alternatively, it could be that nobody knows the answer. In any case, sending it again is poor form and akin to shouting and is likely to aggravate a large number of people. This also applies to crossposting. Try to pick the forum which you think matches best and ask there. If you are referred to a new forum, provide a link to the old discussion.
It's considered bad form to list your personal deadlines; Community members answering questions also have them.
Do not beg for help. If there is someone willing and able to help with your problem, you usually get a response. Asking for faster answers will mostly have a negative effect.
Guidelines for Moderating
It is the responsibility of the community to maintain the community ethos. We use several public forums to communicate about our work: mailing lists, issue trackers and ROS Answers. If you see behavior in any of these forums that does not meet our community standards, please promptly respond following the guidelines below, always remaining courteous and polite.
Spam in general
- Delete spam immediately. If the account has been created just for spamming, block the account as well.
- If a duplicate question is asked, comment on the new question to say that questions should not be duplicated, then delete the less detailed of the two.
- If an inappropriate (e.g., rude or offensive) question or answer is given, quickly reword it if possible, including a comment with the reason for the edit. If it cannot be reworded easily, leave a comment as to why the question was deleted and delete it, suggesting that the submitter resubmit following the guidelines.