ros-ros2 — правило для Cursor: что делает и как установить
Набор стандартов для робототехники на ROS и ROS2: помогает ИИ писать узлы робота и лаунч-файлы без типичных архитектурных ошибок.
.cursor/rules/ros-ros2.mdcЧто делает ros-ros2
Правило задаёт соглашения для работы с робототехническим стеком ROS и ROS2. Оно направляет ассистента при создании компактных узлов, отделяя потоки данных в сообщениях от длительных задач в action. Конфигурационные файлы отправляются в папку config/, а сценарии запуска — в launch/.
В кодовой базе на C++ и Python правило предписывает использовать трансформации tf2, выбирать профили QoS и избегать зависания колбэков. Долгие вычисления уходят в таймеры или рабочие потоки. Без явного объявления параметров узел ROS2 поведёт себя непредсказуемо при запуске. Сборка и запуск интеграционных тестов опираются на colcon build.
Какие задачи решает
- структурировать пакеты ROS и ROS2 по каталогам
launch/,config/иmsg/ - разделить интерфейсы на потоковые сообщения, сервисы и длительные действия
- исключить блокировку функций обратного вызова при долгой обработке
- написать launch-тесты для поиска пропавших трансформаций
tf2и недоступных сервисов
Примеры запросов агенту
- Напиши ноду ROS2 на C++ для обработки лидара с профилем QoS для сенсоров
- Создай launch-файл на Python для узла навигации с параметрами из
config/ - Добавь launch-тест на проверку недоступных сервисов и устаревших данных датчиков
Как установить ros-ros2
Вручную: положить файлы
.cursor/rules/ros-ros2.mdcВо frontmatter: description, globs, alwaysApply
Вручную: положить файлы
.claude/rules/ros-ros2.mdПоле paths во frontmatter ограничивает файлы: globs из источника → paths
AGENTS.md
Codex читает AGENTS.md: вставьте текст правила туда
Вручную: положить файлы
.github/instructions/ros-ros2.instructions.mdПоле applyTo задаёт, к каким файлам применять: globs из источника → applyTo
Вручную: положить файлы
.devin/rules/ros-ros2.mdВручную: положить файлы
.clinerules/ros-ros2.mdПо шагам, с командами для каждой платформы: Cursor rules: файлы .mdc, четыре режима и замена .cursorrules
Вопросы о ros-ros2
Как установить ros-ros2 в Cursor?
Сохраните файл правила по пути .cursor/rules/ros-ros2.mdc в корне вашего проекта.
Что делает правило ros-ros2?
Оно задаёт архитектурные правила для ROS и ROS2, предотвращая жёстко зашитые имена топиков, блокирующие колбэки и несогласованные профили QoS.
Для каких файлов срабатывает это правило?
Фильтр масок включает исходники C++ и Python, файлы package.xml, CMakeLists.txt, интерфейсы .msg, .srv, .action, лаунч-файлы, а также модели .urdf и .xacro.
Исходный текст
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