Legado: T265 e vision_to_mavros¶

Caminho indoor histórico que a Black Bee voou antes da D435i + Isaac ROS Visual SLAM: câmera de tracking Intel RealSense T265, computador de bordo (tipicamente um Raspberry Pi), MAVROS, e vision_to_mavros.

Esta página serve para entender logs mais antigos, hardware de fallback, e como a bridge atual do Nectar evoluiu. Para o stack atual, use o README de Localização (procedimento indoor, origem do EKF). Conceitos: Conceitos.

Linha do tempo¶

Fluxo de dados¶

flowchart LR
  t265[T265 on-device VIO]
  rs[realsense-ros TF / odom]
  v2m[vision_to_mavros]
  mavros[MAVROS]
  fcu[FCU EKF]
  t265 --> rs
  rs -->|"/tf"| v2m
  v2m -->|"/mavros/vision_pose/pose"| mavros
  mavros -->|"VISION_POSITION_ESTIMATE"| fcu

Comparado a hoje:

A visão geral do LuckyBird sobre frames e por que uma bridge é necessária: Discourse parte 2. O realsense-ros já publica nas convenções ENU do ROS, mas a montagem da câmera e o alinhamento corpo/mundo do T265 ainda precisam de uma rotação para que o heading do FCU corresponda ao do veículo — esse é um dos principais papéis do vision_to_mavros.

O que o vision_to_mavros faz¶

A partir do README ROS 2 da Black Bee e do pacote upstream thien94:

1. TF → pose — consulta source_frame_id → target_frame_id (padrões em torno de /camera_link e /camera_odom_frame) e publica geometry_msgs/PoseStamped em /mavros/vision_pose/pose.
2. Limitação de taxa — o T265 / TF pode ser muito mais rápido do que o FCU precisa; o LuckyBird cita ~10–15 Hz como mínimo prático e ~30 Hz como típico (output_rate, padrão 30.0 no port ROS 2).
3. Alinhamento de montagem / mundo — roll_cam, pitch_cam, yaw_cam, e gamma_world rotacionam os frames de câmera e de mundo para a convenção de corpo ENU que o MAVROS espera antes da conversão para NED no wire.

Padrões de exemplo voltados para frente (porta USB à direita): roll_cam=0, pitch_cam=0, yaw_cam=0, gamma_world=-1.5707963. Outras orientações estão tabeladas no README do pacote.

Launches (ROS 2):

ros2 launch vision_to_mavros t265_tf_to_mavros_launch.py   # bridge only
ros2 launch vision_to_mavros t265_all_nodes_launch.py       # T265 + MAVROS + bridge

Versões de software (pins do SDK)¶

O T265 precisa de librealsense / realsense-ros mais antigos do que os padrões atuais para D4xx. Os pins vivem em scripts/lib/config.sh, COMPATIBILITY, docs/setup/realsense.md, e guia Docker.

Não misture um T265 com a imagem producer do Isaac cuVSLAM esperando suporte de primeira classe; o caminho Isaac tem como alvo estéreo D435i + IMU para Visual SLAM.

Imagens de companion históricas na equipe também usaram librealsense 2.50.0 durante o bring-up inicial em ROS 2; prefira o override do SDK acima para qualquer coisa nova.

Parâmetros do ArduPilot (T265)¶

A partir da página Intel RealSense T265 do ArduPilot e das notas de bring-up da equipe:

Reinicie o FCU depois de mudar esses parâmetros. No ArduPilot sem fix de GPS, defina a origem do EKF antes dos modos de posição — mesmas regras de hoje (Origem do EKF).

Bring-up histórico (era ROS 2)¶

Procedimento público resumido (LuckyBird + adaptação ROS 2 da equipe):

1. Ligue a aeronave e o companion; confirme o T265 no USB3 e o serial companion↔FCU.
2. No companion: confirme a câmera (rs-enumerate-devices).
3. Suba o stack — tudo em um: ros2 launch vision_to_mavros t265_all_nodes_launch.py ou os três nós separadamente (launch T265 da realsense, MAVROS, t265_tf_to_mavros_launch.py) como na parte 2 do LuckyBird.
4. Verifique a taxa de /mavros/vision_pose/pose (~30 Hz) e o VISION_POSITION_ESTIMATE no MAVLink Inspector da GCS.
5. Defina a origem do EKF no mapa quando o ArduPilot não tiver uma origem derivada de GPS (Origem do EKF).
6. Verificação de escala: levante o veículo ~1 m e o abaixe de novo (orientação do ArduPilot / da equipe para a escala vertical do T265), depois mova manualmente e confirme que o ícone da GCS acompanha.
7. Primeiro voo: Stabilize/AltHold → movimento suave → Loiter com reversão imediata se o tracking falhar — mesmo padrão do Procedimento indoor.

O ROS 1 usava equivalentes do roslaunch (rs_t265.launch, t265_tf_to_mavros.launch, t265_all_nodes.launch); o grafo era o mesmo.

O que se manteve vs o que mudou¶

Ainda verdadeiro hoje

• ArduPilot: origem do EKF exigida quando nenhum GPS fornece um fix (a menos que a restauração de origem gravada da 4.7+ esteja habilitada) — Origem do EKF.
• Verificação de movimento manual / ícone da GCS antes do Loiter.
• Cuidado com soft-mount e vibração.
• Um único feeder de visão para o FCU.
• Stabilize/AltHold antes de confiar no Loiter em um setup novo.

Mudou com o Nectar + cuVSLAM

• O producer roda no Jetson dentro do container Isaac (nectar-vslam), não como VIO no próprio T265.
• A bridge é in-tree (vision_pose.launch.py / VisionPoseBridge / MavrosVisionRelay), não um pacote vision_to_mavros separado.
• VISO_TYPE=1 e o tópico de pose com covariância são o caminho padrão do ArduPilot.
• O loop closure e a visualização da trajetória SLAM/VO são de primeira classe (Visualização).
• A velocidade opcional é derivada no wrapper do Isaac e habilitada por meio da flag send_speed:=true (Velocidade).

Referências¶

• ArduPilot: Intel RealSense T265
• ArduPilot: ROS VIO tracking camera
• Série T265 do LuckyBird — parte 1, parte 2
• thien94/vision_to_mavros · Black-Bee-Drones/vision_to_mavros
• Instalação da RealSense (override para T265)
• Docker RealSense / :humble-t265
• Conceitos — comparação de sistemas