ROS Answers should be used as the first step in requesting help, as described below (and in this related question).

See Also

1. https://support

2. The "Wikis, Bug Reports, & Help" section at the bottom of the main Documentation page.

ROS Discourse

To stay on top of the latest ROS news, join http://discourse.ros.org and subscribe to at least the general topic. Feel free to have a look at the historical posts.

For older posts please checkout the ros-users archive.

When something fails

If you are attempting to debug a ROS system

1. First try to troubleshoot using:

   • Troubleshooting

   • FAQ

2. If the troubleshooting guide fails to help, search for an answer, and ask a question if you don't find anything related on

   • ROS Answers

3. If you find an issue or wish to make a feature request, please see the next section

Suggestions for reporting issues/requesting features

1. First, check the issue trackers: Known issues, often with patches or workarounds, are generally found there. If you have something to add to an existing issue, add it as a comment to the issue, rather than posting to the mailing lists.

2. Next, check ROS Answers to see if someone else has asked your question or reported your issue. And try a general search you may also find results from ROS Discourse the ros-users mailing list archive and other sites.

3. 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.

When you open a ticket the best way to demonstrate it is with a Short, Self Contained, Correct (Compilable) Example: http://sscce.org/ or a Minimal, Complete, and Verifiable example https://stackoverflow.com/help/mcve

Guidelines for asking a question (Please read before posting)

Do Not

• 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.

  • It's better to send all questions to ROS Answers or the appropriate mailing list, and report all issues to the issue tracker.

• On ROS Answers, do not use answers for discussion, subsequent questions or just updates. Instead, edit your original post or use the comment functionality.

Do

• 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.

      • Please DO NOT post a screenshot of the terminal or source file. Instead, cut/copy and paste whenever you can. Text in the screenshot images is not searchable (e.g. by any web browsers, by Google etc.)

  • When discussing any compiling/linking/installation issues, also provide:
    • gcc version
• As appropriate, also include your:

  • ROS environment variables (env | grep ROS)

  • Backtraces
  • 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. You must tag at least the rosdistro version.
• Format code snippets. To make your code snippets and error messages better readable, format them correctly (mark the code and press Ctrl-k).

• You are most likely to get a good answer if you provide a Short, Self Contained, Correct (Compilable) Example http://sscce.org/ or a Minimal, Complete, and Verifiable example https://stackoverflow.com/help/mcve

Etiquette

• 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.

  • On https://answers.ros.org you can edit your question to provide more details. The more details that you include in your question the easier it is for others to help you find your solution which makes it more likely for you to get a response.

• 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.

• Do not add unrelated content to posts. The content of posts should be focused on the topic at hand and not include unrelated content. Content, links, and images unrelated to the topic are considered spam.

  • For commercial posts, see also this discussion.

• Minimize references to content behind pay walls. The content posted on the wiki and in Ask should "generally" be free and open to all users. Links to content behind pay walls such as private journal articles, text books, and paid news websites, while helpful and relevant, may not be accessible to all users. Where possible primary sources should be free and open with paid content playing a supporting role.

• Single link posts are to be avoided. Generally speaking, posting a single link answer is less helpful and can be easily confused with spam. Moreover, links may degrade over time or be replaced. Paraphrasing a link's content along with some contextual information and attribution is often much more helpful.