ros-ros2 — Cursor rule: what it does, how to install
Enforces conventions for ROS and ROS2 workspaces, covering composable nodes, package layout, and launch testing.
.cursor/rules/ros-ros2.mdcWhat ros-ros2 does
The rule steers the AI assistant when generating or editing ROS and ROS2 workspaces. It organizes packages by keeping launch scripts in launch/ and parameters in config/. The guidelines direct the agent to choose standard message types first and declare ROS2 parameters explicitly.
For runtime logic, it mandates tf2 frame transforms, intentional QoS profile selection, and moving long work out of callbacks into timers. Hardcoded topic names and absolute paths break node reusability in shared workspaces. Multi-node integration relies on colcon build and launch tests to catch stale sensor feeds.
What it helps with
- organize ROS and ROS2 packages with proper directory structure
- declare explicit ROS2 parameters and configure QoS profiles
- prevent callback starvation by delegating long work to timers or actions
- write launch tests to verify missing transforms and unavailable services
Example prompts for the agent
- Write a C++ ROS2 node that subscribes to sensor data with an appropriate QoS profile
- Generate a Python launch file that remaps topic names and loads parameters from
config/ - Create an integration test for multi-node behavior using simulation fixtures
How to install ros-ros2
Manually: put the files in place
.cursor/rules/ros-ros2.mdcFrontmatter: description, globs, alwaysApply
Manually: put the files in place
.claude/rules/ros-ros2.mdThe paths frontmatter field limits the files: move globs from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.github/instructions/ros-ros2.instructions.mdThe applyTo field sets which files it applies to: move globs from the source into applyTo
Manually: put the files in place
.devin/rules/ros-ros2.mdManually: put the files in place
.clinerules/ros-ros2.mdStep by step, with commands for each platform: Cursor rules: .mdc files, four modes and what replaced .cursorrules
Questions about ros-ros2
How to install ros-ros2 in Cursor?
Add the rule configuration file to .cursor/rules/ros-ros2.mdc in your workspace root.
What does the ros-ros2 rule do?
It provides development patterns for ROS and ROS2, preventing hardcoded topic names, callback starvation, and QoS mismatches.
Which file formats trigger this rule?
The rule monitors C++ and Python files, package.xml, CMakeLists.txt, .launch.py files, interface definitions (.msg, .srv, .action), and robot models (.urdf, .xacro).
Source text
ros-ros2.mdc · CC0-1.0
--- 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.
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules
