{"filename":"ros-ros2.mdc","content":"---\ndescription: ROS and ROS2 rules for packages, nodes, launch files, messages, services, actions, simulation, and testing\nglobs: [\"**/*.py\", \"**/*.cpp\", \"**/*.hpp\", \"**/*.h\", \"package.xml\", \"CMakeLists.txt\", \"**/*.launch.py\", \"**/*.msg\", \"**/*.srv\", \"**/*.action\", \"**/*.urdf\", \"**/*.xacro\"]\nalwaysApply: false\n---\n\n# ROS and ROS2 Rules\n\n## Package Structure\n\n- Keep packages focused on one robot capability or integration boundary.\n- Use `package.xml` and `CMakeLists.txt` or `setup.py` consistently with the package type.\n- Keep launch files under `launch/`, configs under `config/`, messages under `msg/`, services under `srv/`, and actions under `action/`.\n- Use namespaces and remapping instead of hardcoded topic names when nodes may be reused.\n\n## Nodes and Interfaces\n\n- Keep nodes small and composable.\n- Use parameters for tunable behavior; declare ROS2 parameters explicitly.\n- Prefer messages for state streams, services for quick request/response operations, and actions for long-running goals with feedback.\n- Use standard message types before creating custom interfaces.\n- Document topic, service, action, frame, and parameter contracts.\n\n## Timing and Frames\n\n- Use ROS time when simulation or bag replay matters.\n- Use `tf2` for frame transforms and document frame names.\n- Avoid blocking callbacks; move long work to timers, worker threads, or actions.\n- Set QoS profiles intentionally for sensor data, latched-like config, and reliable command paths.\n\n## Build and Test\n\n- Use `colcon build` and keep package dependencies explicit.\n- Run linters and formatters used by the workspace.\n- Add launch tests or integration tests for multi-node behavior.\n- Use simulation, bags, or recorded fixtures for repeatable sensor scenarios.\n- Test failure cases such as missing transforms, stale sensor data, and unavailable services.\n\n## Common Mistakes\n\n- Do not hardcode absolute paths; use package share directories.\n- Do not publish commands without validating frame, units, and timestamp assumptions.\n- Do not create custom messages when a standard message fits.\n- Do not ignore QoS mismatches between publishers and subscribers.\n"}