ROS Robótica
Quando usar
Use esta habilidade quando a solicitação do usuário envolver qualquer um dos seguintes tópicos:
catkin_ws、colcon_ws、src/CMakeLists.txt、package.xml、setup.py- Criação, migração, compilação, teste e depuração de pacotes ROS 1 / ROS 2
launch/launch.py、parâmetros YAML、URDF/Xacro、RViz、TFtopic/service/action/msg/srv/QoS- Chassi、IMU、LiDAR、câmera、localização、SLAM、Navigation2、
ros2_control - Simulação Gazebo / Ignition、simulação de sensores、
ros_gz_bridge - Desenvolvimento ROS em contêineres Docker、orquestração multi-nó com
docker-compose - Nós de Lifecycle、componentização
rclcpp_components、comunicação intra-processo - Gravação e reprodução com
rosbag2、mcap、diagnóstico offline - Mapeamento SLAM (Cartographer、SLAM Toolbox、ORB-SLAM)
- Configuração DDS / QoS、
ROS_DOMAIN_ID、seleção RMW、rede multi-máquina - Definição e geração de interfaces personalizadas (
msg/srv/action) - Sistemas multi-robô、isolamento de namespace、comunicação entre máquinas
- Planejamento de movimento MoveIt 2、SRDF、plug-ins de cinemática
- CI/CD para ROS 2 (GitHub Actions、colcon test、ament_lint)
- Foxglove Studio / PlotJuggler para visualização de dados e análise offline
- Desenvolvimento colaborativo com MCU / RTOS / UART / CAN /
micro-ROS
O que fazer primeiro
1. Identificar o workspace primeiro
python scripts/detect_ros_workspace.py <caminho-do-workspace>
2. Verificar a consistência
python scripts/check_ros_workspace_consistency.py <caminho-do-workspace>
3. Carregar a documentação mínima necessária de acordo com o problema
- ROS 1：
references/ros1-catkin.md - ROS 2：
references/ros2-colcon.md - Misto / Migração：
references/interop-and-migration.md - Modelo / TF：
references/robot-description-and-tf.md - Navegação：
references/navigation2.md - Controle：
references/ros2-control.md - Embarcado：
references/micro-ros-and-embedded.md - Simulação：
references/gazebo-simulation.md - Lifecycle / Componentes：
references/lifecycle-and-components.md - DDS / QoS / Rede：
references/dds-qos-networking.md - Gravação / Reprodução / Diagnóstico：
references/rosbag-diagnostics.md - SLAM / Mapeamento：
references/slam-mapping.md - Docker：
references/docker-ros.md - Interfaces Personalizadas：
references/custom-interfaces.md - Multi-robô：
references/multi-robot.md - MoveIt 2：
references/moveit2.md - CI/CD：
references/ros2-cicd.md - Visualização：
references/foxglove-visualization.md - Solução de problemas：
references/debug-playbooks.md - Revisão：
references/review-checklist.md
Princípios que devem ser seguidos
- Identifique o sistema de build primeiro, depois altere o código
- Corrija a consistência de
package.xml/CMakeLists.txtprimeiro, depois fale em refatoração - Verifique TF, timestamp, frame e unidades primeiro, depois culpe o algoritmo
- Cadeia de evidências primeiro, depois modificação: a saída da build, tópicos, TF, parâmetros e logs devem ser verificáveis
- ROS 1 → ROS 2: faça bridging ou migração em camadas, não tente reescrever tudo de uma vez
- MCU /
micro-ROS: primeiro avalie se realmente é necessário entrar no grafo ROS
Abordagem para tarefas comuns
Novo pacote ou correção de pacote
- Primeiro determine o tipo de pacote:
catkin、ament_cmake、ament_python - Primeiro adicione a declaração de dependências, depois a lógica de build, depois as regras de instalação
- Para
msg/srv/actionpersonalizados, verifique primeiro a ordem de geração e o ciclo de dependências (vejareferences/custom-interfaces.md)
Falha na build
- Execute
rosdepprimeiro - Depois verifique
package.xmle os scripts de build - Depois verifique se o ambiente está source corretamente
- Depois verifique dependências de sistema, ABI e compatibilidade de distribuição
Funciona mas o robô não se comporta corretamente
- Primeiro verifique launch、namespace、remap、parâmetros
- Depois verifique nome do tópico、frequência、timestamp、unidades、
frame_id - Depois verifique se o TF tem uma raiz única e se estática/dinâmica está correta
- Por último, suspeite do algoritmo em si
Nav2 / ros2_control
- Navigation2: priorize a verificação da cadeia
/cmd_vel, qualidade de localização, frequência de controle e unidades do chassi ros2_control: priorize a verificação do tipo de interface de hardware, YAML do controlador, ciclo de leitura/escrita e status ativo
MCU / micro-ROS
- Primeiro avalie se o nó de ponte do lado Linux é suficiente
- Se o MCU precisar entrar no grafo ROS 2, considere
micro-ROS - Verifique rigorosamente endianness, checksum, timeout, reconexão, fonte de tempo e proteção contra perda de conexão
Anti-padrões
- Misturar
catkineamentno mesmo pacote - Alterar apenas
CMakeLists.txtsem alterarpackage.xml - Ignorar TF, timestamp, unidades e definição de eixos
- Colocar driver, protocolo, filtragem, controle e diagnóstico tudo em um único nó grande
- Ao migrar ROS 1 → ROS 2, fazer apenas substituição de API sem validação do sistema
Requisitos de saída
Ao usar esta habilidade para processar tarefas, priorize a saída:
- Identificação do workspace atual e tipo de pacote
- Argumentos e suposições principais
- Pontos de alteração e suas razões
- Comandos mínimos de build / teste / execução
- Pontos de risco e pontos de verificação de regressão