Protocole, API et mise en œuvre

MAVLink définit des messages et des services de communication ; MAVSDK fournit des API de développement pour les fonctions prises en charge. Qu’un message existe dans le protocole, qu’une bibliothèque puisse l’envoyer et qu’un appareil puisse l’exécuter sont trois conditions distinctes. La documentation officielle de l’interface offboard indique que les consignes prises en charge et leurs combinaisons dépendent de la pile de vol et du type d’appareil. PX4 Offboard et ArduPilot Guided ne sont pas des noms interchangeables pour un comportement identique. Comparez la documentation de l’API de la bibliothèque installée avec celle de la pile réceptrice, une opération requise à la fois. Affichez la pile de vol et la version détectées lors de la connexion. Un transport fonctionnel peut tout de même mener à une mise en œuvre inattendue ; traitez les combinaisons inconnues comme non vérifiées plutôt que comme immédiatement exécutables.

Traiter l’exécution des commandes comme une machine à états

Représentez le contrôle externe par des états explicites : connexion, contrôle de santé, préparation, exécution, interruption et achèvement. L’accusé de réception d’une commande ne prouve pas que le plan demandé a été volé. Observez le mode, la position, la vitesse et l’état de la caméra par la télémétrie. Mettez en œuvre les exigences de mise à jour ou de signal de vie de la pile réceptrice et définissez quand les consignes périmées sont abandonnées. Perdre l’autorité de commande ne fait pas nécessairement échouer immédiatement chaque appel de réglage. Surveillez explicitement l’autorité et les changements de mode, et rendez l’état résultant compréhensible pour l’opérateur. Gardez séparés dans les journaux la commande, l’accusé de réception et l’observation. Des identifiants corrélés et l’ordre des événements aident à distinguer une panne de communication d’un changement délibéré d’autorité de commande. Les recherches sur un aéronef qui continue de voler après des collisions font l’objet de la fiche d’article du guide Inspection A Collision-resilient Flying Robot.

Préciser ensemble le temps et les coordonnées

Notre exercice de conception original associe à chaque consigne un repère, des unités, une heure de création, une échéance et un identifiant de commande. Cela évite qu’une ancienne estimation du sujet issue de l’image soit traitée comme actuelle. L’heure de réception de la vidéo et l’heure d’exposition peuvent différer ; mesurez donc l’alignement temporel plutôt que de le supposer. Commencez avec de la vidéo enregistrée et une simulation, en injectant des retards et des mises à jour manquantes. Lorsque l’incertitude ou la latence dépasse les limites déclarées, passez à un état prudent prédéfini. La bibliothèque de communication ne prend pas la décision opérationnelle à la place de l’intégrateur. Un décalage d’horloge peut ressembler à une latence de traitement. Définissez comment les appareils se synchronisent et comment la précision de synchronisation est mesurée avant d’affirmer un timing précis d’enregistrement ou de mouvement.

YOUR NEXT STEP

Passez à la pratique.

Attention à ces pièges
  • La prise en charge de MAVLink n’implique pas la prise en charge complète de toutes les commandes standard.
  • N’utilisez pas la temporisation fixe d’un exemple comme confirmation en production qu’un mouvement est terminé.

Sources et périmètre éditorial

Les explications et les exercices sont des contenus éditoriaux originaux. Vérifiez les conditions propres à chaque produit dans la version de la documentation indiquée en lien.

  1. MAVLink — Offboard Control Interface ↗
  2. MAVSDK — Offboard Control ↗
  3. MAVSDK — Offboard Velocity Example ↗

Date de la recherche : 21 octobre 2026. Vérifiez la version liée, le matériel pris en charge et les conditions applicables. Les éléments de preuve comprennent des textes examinés directement et des fiches d'index de recherche officielles.

Lire la méthodologie et les questions ouvertes →