Abonniere die ROS Users Mailing Liste um auf dem neuesten Stand über ROS zu sein und durchsuche das ROS Users Archiv.

Nichtsdestotrotz bleibt ROS Answers die erste Anlaufstelle für Hilfe.

Wenn etwas schief läuft

Du möchtest dein ROS System debuggen? Dann folge diesen Schritten:

1. Problemsuche / Erste Hilfe:

   • Troubleshooting (en)

   • FAQ

2. ROS Answers

3. Bugs und Feature requests werden im nächsten Abschnitt behandelt

Probleme melden / Features anfordern

1. Suche nach dem Problem im Issue tracker: Bekannte Probleme mit Patches und Workarounds sind oftmals hier zu finden. Hast du eine Anmerkung, so ergänze dies mit einem Kommentar zum Problem nicht über die Mailing Liste.

2. Suche im Mailarchiv und auf ROS Answers.

3. Wenn bisher nichts geholfen hat, eröffnest du am besten ein Ticket.

Bist du dir nicht sicher ob dein Problem ein Fehler ist, verwende ROS Answers. Wird das Problem als Fehler bestätigt kann daraufhin ein Ticket eröffnet werden. Tickets sind die bevorzugte Art Fehler zu melden, da sie von den Entwicklern gesichtet werden.

Leitfaden zur richtigen Fragestellung

Erwünscht

• Setze entsprechende Tags
• Fragen so spezifisch wie möglich stellen

  • Beschreibe was du gemacht hast, was du gerne hättest und was genau fehlgeschlagen ist. Aufgrund von "RVIZ funktioniert nicht" kann niemand weiterhelfen.

    • Wenn du anhand eines Tutorials oder einer Onlineinstruktion vorgehst, füge einen Link zur Frage hinzu.

    • Benutze aussagekräftige Titel:
      

      • Schlecht: "RVIZ doesn't work".
        Besser: "RVIZ crashing looking for missing .so after latest apt update"

  • Folgende Informationen sollten nicht fehlen:

    • Namen und Versionen von Stack und Paketen die im Einsatz sind.
      "I'm using ROS C Turtle with pr2_simulator 1.1.1 and vocabulary_tree r30294"

    • Deine Plattform (Architektur, Betriebssystem, Version, Distribution).
      "I'm running OS X 10.5 on an iBook," or "I'm running Ubuntu Karmic on an x86, with kernel 2.6.31."
      Für Linux sollten immer die Distribution und Kernel Version angegeben werden.

    • Warnungen und Fehler. Füge diese direkt aus dem Terminal ein. Abtippen führt zu kleinen Schreibfehlern mit grosser Auswirkung.

  • Bei Fragen zu Kompilation, Linken oder Installation ist zudem die GCC Version wichtig.
• Weitere Informationen falls vorhanden:
  • Backtrace
  • Konfigurationsdateien
  • Grafikkarte und Treiber

  • ogre.log für rviz. Wenn möglich sollte rviz -l verwendet werden

  • Bag Dateien and Beispielcode, welcher das Problem reproduziert
  • Bildschirmaufnahmen und Filme, welche das Problem aufzeigen
• Formatiere Codeauszüge und Fehlermeldungen mit CTRL-K zur besseren Lesbarkeit.

Zu vermeiden

• Nicht angebracht sind:
  • Allgemein gehaltene Programmier- und Debugfragen
  • Fragen über ROS fremde Software
  • Fragen zu deinen Hausaufgaben
• Kontaktiere Entwickler und Maintainer nicht direkt
  • Die Community kann diese fragen weder sehen noch beantworten.
  • Open Source Entwicklung funktioniert am besten wenn die ganze Community mithilft.

• ROS Answers:

  • Antworten sollen nicht für Diskussionen, weiterführende Fragen oder Updates genutzt werden. Dafür ist die Bearbeiten Funktion der Originalfrage sowie die Kommantarmöglichkeit vorhanden.

Etiquette

• Assume 'good faith': Kommentare können im Internet leicht missverstanden werden. Nehme immer an, dass dir in gutem Willen geholfen wird. So vermeidest du Missmut.

• Fragen nur einmal senden: Wenn du keine Antwort auf deine Frage erhältst, hatte womöglich noch niemand Zeit dir zu antworten. Womöglich weiss auch niemand eine Antwort.

• Keine Deadlines: Es sollten keine Endtermine für Antworten gesetzt werden. Die anderen Communitymitglieder haben das gleiche Problem.

• Nicht betteln Normalerweise kriegst du eine Antwort, wenn dir jemand helfen kann. Um schneller Antworten zu betteln hat meist einen negativen Effekt.