Ros Ros2

Cursor-Regel für ROS/ROS2-Robotik-Projekte: Code folgt typischen Node- und Topic-Konventionen.

Original-Beschreibung der Autoren: ROS and ROS2 rules for packages, nodes, launch files, messages, services, actions, simulation, and testing

Die Regel

---
description: ROS and ROS2 rules for packages, nodes, launch files, messages, services, actions, simulation, and testing
globs: ["**/*.py", "**/*.cpp", "**/*.hpp", "**/*.h", "package.xml", "CMakeLists.txt", "**/*.launch.py", "**/*.msg", "**/*.srv", "**/*.action", "**/*.urdf", "**/*.xacro"]
alwaysApply: false
---

# ROS and ROS2 Rules

## Package Structure

- Keep packages focused on one robot capability or integration boundary.
- Use `package.xml` and `CMakeLists.txt` or `setup.py` consistently with the package type.
- Keep launch files under `launch/`, configs under `config/`, messages under `msg/`, services under `srv/`, and actions under `action/`.
- Use namespaces and remapping instead of hardcoded topic names when nodes may be reused.

## Nodes and Interfaces

- Keep nodes small and composable.
- Use parameters for tunable behavior; declare ROS2 parameters explicitly.
- Prefer messages for state streams, services for quick request/response operations, and actions for long-running goals with feedback.
- Use standard message types before creating custom interfaces.
- Document topic, service, action, frame, and parameter contracts.

## Timing and Frames

- Use ROS time when simulation or bag replay matters.
- Use `tf2` for frame transforms and document frame names.
- Avoid blocking callbacks; move long work to timers, worker threads, or actions.
- Set QoS profiles intentionally for sensor data, latched-like config, and reliable command paths.

## Build and Test

- Use `colcon build` and keep package dependencies explicit.
- Run linters and formatters used by the workspace.
- Add launch tests or integration tests for multi-node behavior.
- Use simulation, bags, or recorded fixtures for repeatable sensor scenarios.
- Test failure cases such as missing transforms, stale sensor data, and unavailable services.

## Common Mistakes

- Do not hardcode absolute paths; use package share directories.
- Do not publish commands without validating frame, units, and timestamp assumptions.
- Do not create custom messages when a standard message fits.
- Do not ignore QoS mismatches between publishers and subscribers.

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Cursor-Regel richtet sich an Projekte mit ROS bzw. ROS2, dem verbreiteten Framework für Robotik-Software. Sie gibt Cursor Konventionen vor, die für Robotik-Code typisch sind — etwa zu Node-Struktur, Topics, Launch-Dateien oder der Trennung zwischen ROS1- und ROS2-Idiomen, die sich in wichtigen Punkten unterscheiden. Sinnvoll für Entwickler, die an Robotik-Stacks arbeiten und wollen, dass von Cursor generierter Code sich an ROS-Konventionen statt an generischem C++/Python-Stil orientiert. Ein Nischen-Werkzeug: außerhalb von Robotik-Projekten mit ROS/ROS2 bringt die Regel keinen Mehrwert, innerhalb spart sie aber wiederholtes Erklären robotikspezifischer Muster.

Praxis-Tipp

In .cursor/rules/ des ROS-Workspace ablegen, dann z. B. prompten: „Erstelle einen neuen ROS2-Node für Sensordatenverarbeitung“ — Cursor hält sich an ROS-typische Struktur.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …