Programmation de drones et d'UAV

Ce que comprend la programmation de drones

Nous écrivons la logique des missions autonomes de drones (UAV) et réglons le contrôleur de vol sur le matériel du client : le drone reste le sien, nous préparons le firmware, les itinéraires et le comportement en vol. Le travail comprend la planification des itinéraires de prise de vue aérienne et de survol des objets, le réglage des points d'intérêt pour l'inspection, la calibration des capteurs, des modes de défaillance et des géozones. Nous configurons le stack PX4 ou ArduPilot pour le châssis, la nacelle et la charge utile précis, et relions la télémétrie en MAVLink à la station au sol. À part, nous réglons les scénarios de retour à la base, le comportement en cas de perte de liaison et de perte des satellites, afin que l'appareil ne parte pas en vol incontrôlé. La programmation de drones à ce niveau, ce n'est pas l'assemblage de matériel, mais la configuration de l'autopilote et l'écriture des missions que cet autopilote exécute.

Comment est structurée une mission autonome

À la base se trouve un contrôleur de vol doté d'un autopilote, qui lit le GPS, les capteurs inertiels, le baromètre et le compas, et maintient l'appareil sur une trajectoire donnée. La mission se décrit comme une suite de points de passage avec altitude, vitesse et actions à chaque point : prendre un cliché, faire du surplace, orienter la nacelle, changer d'altitude. La station au sol et l'autopilote échangent commandes et télémétrie via le protocole MAVLink, l'opérateur voit donc la position, la charge et le statut en temps réel. Les algorithmes de stabilisation et de navigation recalculent les signaux de commande des moteurs des dizaines de fois par seconde, en maintenant le cap face au vent et à la dérive. Notre part, c'est de monter ce scénario, de définir les paramètres et les seuils de déclenchement pour que l'appareil du client suive l'itinéraire de façon prévisible.

D'où viennent les autopilotes de drones

Les autopilotes ouverts modernes sont issus de deux projets de la fin des années 2000. La communauté DIY Drones apparut en mai 2007, et Jordi Muñoz écrivit dès la fin 2007 pour Arduino un programme de stabilisation dont est issu ArduPilot — il en sortit la version 1.0 avec Chris Anderson en 2009, année où son appareil remporta le premier concours Sparkfun AVC. En parallèle, en Suisse, Lorenz Meier lança à l'ETH Zurich le projet de recherche Pixhawk : les travaux commencèrent vers 2008, et en 2009 parurent les premiers développements ouverts de commande et de vision par ordinateur. En 2011, l'équipe de Meier réécrivit entièrement le stack de zéro — ainsi naquit PX4, sous la forme qui est à la base de la plateforme actuelle. Ces deux lignées, ArduPilot et PX4, déterminent aujourd'hui la pratique de la programmation de drones.

Pourquoi le logiciel et la précision décident

La prise de vue aérienne et l'inspection ne donnent un résultat exploitable qu'avec un géoréférencement précis : une erreur de positionnement de quelques mètres décale l'orthophotoplan et fait échouer la construction du modèle 3D. La précision de la mission est définie par le réglage de l'autopilote — calibration des capteurs, paramètres du filtre de navigation, géométrie correcte de l'itinéraire avec recouvrement des clichés. La légalité n'est pas moins importante : des géozones correctement définies, des limites d'altitude et un comportement en cas de perte de liaison maintiennent l'appareil dans la zone autorisée et réduisent le risque d'infraction et d'accident. Le drone vole et prend les vues physiquement de lui-même, mais la qualité des données et la sécurité du vol sont déterminées par le programme et son réglage, et non seulement par les caractéristiques du châssis et de la caméra. C'est pourquoi une erreur sur un seul paramètre de tolérance aux pannes coûte plus cher que le choix du matériel lui-même.

Le stack : PX4, ArduPilot, MAVLink

Le stack de travail se construit autour de deux autopilotes et d'un protocole de transport. PX4 — une architecture modulaire au-dessus du temps réel, commode pour l'intégration de ses propres modules et de la vision par ordinateur ; ArduPilot — un stack mature avec une large prise en charge de types d'appareils et une logique développée des missions et des pannes. MAVLink relie l'autopilote à la station au sol et aux modules externes : des messages binaires compacts transportent la télémétrie, les commandes et les paramètres de mission par radio. Par-dessus, nous travaillons avec des stations au sol comme QGroundControl et Mission Planner, et pour la commande logicielle, nous nous connectons à l'autopilote via des commandes MAVLink. Le choix précis entre PX4 et ArduPilot est dicté par la tâche du client et son contrôleur, et non par l'habitude — pour les deux plateformes, nous écrivons des missions et ajustons les paramètres sur son matériel.

Quand sont apparus les outils clés

Le protocole MAVLink fut développé par Lorenz Meier à l'ETH Zurich et publié sous licence LGPL en 2009 dans le cadre du projet Pixhawk. ArduPilot reçut la prise en charge de MAVLink dans les premières versions bêta de 2011, et PX4 l'inclut dès sa sortie vers mars 2012 ; à la même époque, MAVLink fut adopté par la station au sol QGroundControl. En 2017 sortit la version MAVLink 2.0 — elle ajouta la signature des messages pour se protéger de l'usurpation de commandes et des paquets étendus jusqu'à 280 octets. PX4 lui-même, comme plateforme autonome, se constitua après la réécriture complète du stack Pixhawk en 2011, année où le RTOS NuttX fut pris comme base. Ces dates sont importantes en pratique : elles déterminent quelles versions de firmware et de messages considérer comme références lors du réglage de l'autopilote du client.

Pourquoi vous pouvez nous confier la tâche

L'expérience cumulée de notre équipe de développement en informatique dépasse 45 ans, et l'autopilote, pour nous, c'est avant tout du logiciel et sa configuration, et non la magie du matériel. Nous abordons la mission comme une tâche d'ingénierie : nous figeons les paramètres, gérons les versions de firmware et vérifions le comportement de l'appareil en simulation et au sol avant le vol réel. Les scénarios de panne, les géozones et le retour à la base sont testés à l'avance, pour que le premier vol réel ne devienne pas une vérification d'hypothèses. Nous ne fabriquons pas de drones et ne faisons pas passer le matériel d'autrui pour le nôtre — nous programmons et réglons le matériel du client, en nous appuyant sur PX4, ArduPilot et MAVLink. Au final, le client reçoit non une promesse, mais un réglage reproductible, vérifiable d'après les logs et reproductible sur les appareils suivants.