Quels sont les composants d’un drone

Quels sont les composants d’un drone

Companion Computer

Comme expliqué dans le paragraphe précédent, il s’agit de microordinateur peu cher, doté d’une mémoire vive d’en général de 1GB et d’un processeur 64 bits. Étant donné les performances bien plus élevées que peut fournir ce genre d’appareil, il est possible de lancer des programmes avec des calculs complexes qui seront réalisés bien plus rapidement. Il doit être capable d’être intégré à un drone et fonctionner sur une prise 2V qui sera branchée à la batterie. Il est bien évidemment nécessaire de le faire communiquer avec le flight controller. Une option sur le FCU intitulée Offboard, qui permet au CC de prendre le contrôle du drone lorsque celle-ci est activée. Le microordinateur doit être capable de pouvoir supporter la connexion à une caméra, ou différentes sortes de capteur afin de récolter les données de ceux-ci.
Un Companion Computer s’occupera ainsi de réaliser la reconnaissance d’image d’une caméra, et ainsi reconnaitra les obstacles en direct. Puis selon la procédure liée à l’obstacle, il enverra les commandes. Tout cela se réalisera ainsi sur un drone avec le CC en embarqué afin de pallier les problèmes éventuels du réseau tel que lag, perte de réseau ou faible vitesse de communications que peux avoir un système avec un ordinateur au sol.
Il existe une multitude de microordinateurs, les plus connus provenant de la marque Raspberry comme le RPI 3 ou RPI Zero. NVIDIA propose aussi des microordinateurs ayant des caractéristiques très intéressantes, mais un prix plutôt élevé. L’entreprise Intel propose un kit complet pour les drones nommé Intel Aero.

Système d’exploitation du Companion Computer

Un Companion Computer a besoin d’un système d’exploitation pour pouvoir utiliser l’ensemble des ressources physique et programme fourni par le drone et le microordinateur. Ces OS sont en général des noyaux Unix, modifiés pour travailler avec le FCU. Dans l’idéal, le système doit être le plus ouvert possible, afin de proposer un maximum de liberté au développeur.

Couche ROS

Les systèmes d’exploitation embarqués dans ce genre d’appareil peuvent utiliser une couche de middleware que l’on nomme Robotic Operating System (ROS). Par exemple, un robot est constitué de plusieurs microordinateurs qui doivent parfois communiquer entre eux.
Il ne s’agit pas là d’un système d’exploitation, mais d’un framework léger qui fournit tous les outils et librairies nécessaires à la création de robots et l’implémentation de comportements désirés dans ceux-ci. La communication peut aussi être codé en plusieurs langages, ROS étant basé principalement sur du C++ et Python. Dans notre cas, la couche ROS permettra de communiquer de manière indépendante sur le flight Controller. Il est toutefois à noter que ROS est un système Open source avec une licence BSD, qui permet l’utilisation et modification à des fins commerciales.
Nous n’avons pas poussé les recherches plus loin pour une éventuelle alternative à une couche ROS, car l’étudiant ne possède pas les compétences d’ingénierie nécessaire dans les temps impartis.

MavROS

MavROS est un package ROS qui permet l’échange de communication entre un Flight Controller utilisant le protocole MavLink et un CC ayant ROS installé dessus.
Nous pouvons ainsi résumer l’ensemble des énergies de cette manière :État de l’art – OS pour Companion Computer Avant d’établir une description des systèmes et un comparatif, nous voulons nous focaliser sur les drones commerciaux déjà existants qui proposent de la reconnaissance d’image et des solutions de drones agricols.
Il s’agit plus d’un descriptif de ce qui se fait sur le marché, car ces drones ne sont que très difficilement modifiables et où le logiciel reste fermé et très peu paramétrable. De plus, Aero 41 cherche surtout à réaliser leur propre version de reconnaissance d’image, en utilisant le drone déjà en production et en respectant un budget limité, ce qui restreint grandement le panorama des solutions existantes.
Il existe actuellement beaucoup de drones équipant des systèmes permettant d’éviter des obstacles grâce à des capteurs ultrasons, mais il s’agit de solutions fermées et disponibles uniquement sur de drone de plus petite envergure telle que DJI Mavic Pro ou Phantom. Sur une grande majorité de drones de plus grosse envergure, il s’agit de drones déjà construits, mais dépourvu de caméra ou de capteur.
Nous pouvons cependant noter que la marque mondialement connue DJI propose déjà des solutions de drone d’agriculture pour le marché chinois et américain sans pour autant intégrer de solutions de reconnaissance d’images. Il embarque un radar, permettant de se tenir à une distance constante des cultures, en cas de variation de terrain. Il s’agit d’un drone équipé de tous les composants de base, plus un réservoir de produit sanitaire et d’un système de sulfatage.
Il existe aussi différentes entreprises développant aussi leur propre drone d’agriculture. Cependant ceux-ci n’étant pas suisse il serait difficile de les importer, car les restrictions en matière de drone en Suisse dépassant les 30 kg obligent une homologation par l’Office Fédéral de l’Aviation Civile (OFAC), comme cité dans cet article de loi (art. 14a règle de l’air) : « Les règles de l’air suivantes s’appliquent aux aéronefs sans occupants d’un poids supérieur à 30 kg, sauf en ce qui concerne les prescriptions sur les hauteurs minimales de vol:
a. en premier lieu les règles figurant dans le règlement d’exécution (UE) no 923/2012;
b. à titre complémentaire, les règles figurant dans la présente ordonnance. »
Maintenant que nous comprenons mieux le fonctionnement d’un drone et ses modes de communications, nous comprenons que la répartition des tâches doit être claire pour chaque composant.

Analyse

Nous avons choisi un ensemble de trois solutions que nous allons analyser. Il s’agit tous de système compatible avec un Raspberry pi 3 qui est notre Companion Computer choisi pour des raisons économiques.
Afin de simplifier les recherches dans un premier temps, nous avons décidé de nous orienter sur les solutions publiques trouvables sur Github. Par la suite, nous les comparerons avec une solution commerciale fournie pour la réalisation de ce travail. Nous nous sommes limités à 3 systèmes pour la durée de réalisation de ce travail, pour des raisons évidentes de temps. Notre analyse se fera via
différents aspects :
L’installation, qui peut se faire via une carte SDD flashée, ou un OS et ajouter des composants comme ROS, OpenCV …
La configuration sera l’une des parties de notre analyse qui aura le plus de points. Étant donné la limitation temporelle de notre analyse, une configuration trop longue et technique à établir bloque les étapes suivantes de notre projet. Quand nous parlons de configuration, il s’agit principalement de configurer le système comme l’accessibilité à la couche ROS, l’utilisation d’une caméra avec la possibilité d’utiliser OpenCV qui sera compilé sur le Raspberry.
Nous analyserons les avantages et désavantages de chaque système. Pour cela nous avons dressé un barème, ainsi que des étapes de test à réaliser sur simulateur ainsi qu’en temps réel.
L’OS open source que nous allons analyser dans un premier temps s’appelle Maverick. Il s’agit d’un OS embarqué dont le but premier est d’interfacer le CC avec le protocole Mavlink le plus efficacement possible.

Maverick

Maverick est une solution open source qui a pour but de faciliter le développement d’UAV en permettant d’utiliser le protocole MavLink.

Installation

L’installation avec un Raspberry est simple. Il s’agit d’une image Raspbian à flasher sur une carte SDD, puis allumer le microordinateur. Il est aussi possible de partir d’une installation récente de Debians et installer au fur et à mesure les composants de Maverick.

Configuration

La configuration est cependant plus difficile, car les commande pour régler le réseau proposé par Maverick, provoque l’arrêt de celui-ci. La configuration se fait par les commandes de Maverick, qui ajouterons les bonnes configurations du git. Durant notre installation, nous avons remarqué que les configurations du réseau dans les interfaces, etc/network/interface étaient réécrites, ce qui provoqué un arrêt du service réseau du Raspberry. De plus pendant la configuration et l’utilisation du Raspberry, la chaleur du processeur montait très vite. Nous pensons qu’il s’agit d’une mauvaise gestion des ressources due à l’OS installé. La configuration du réseau restant impossible dû à la configuration de la commande maverick-configure, nous avons abandonné l’utilisation de ce système d’exploitation. Ensuite, pour configurer le reste des fonctionnalités comme l’accès à la couche ros, il est nécessaire de l’installer par différent module.

Table des matières
Table des illustrations
Liste des abréviations 
Glossaire
1. Introduction
1.1. Problématique et contexte
1.2. Méthodologie de travail
1.2.1. Étude
1.2.2. État de l’art
1.2.3. Choix technologique
1.2.4. Récolte de données
1.2.5. Reconnaissance d’image
1.2.6. Implémentation
1.2.7. Validation
2. Drone
2.1. Qu’est-ce qu’un drone
3. Quels sont les composants d’un drone
3.1. Le châssis
3.2. Le système de propulsion
3.2.1. Les moteurs
3.2.2. Les hélices
3.2.3. Electronic Speed Control Circuits (ESCs)
3.3. Système d’alimentation
3.3.1. Power Distribution Board
3.3.2. La batterie
3.4. Système de communication
3.4.1. Radiocommande (TX)
3.4.2. Récepteur RX
3.4.3. Ground Station
3.4.4. Protocole MavLink
3.5. Flight Control Unit
3.6. Companion Computer
3.6.1. Système d’exploitation du Companion Computer
3.6.2. Couche ROS
3.6.3. MavROS
4. État de l’art – OS pour Companion Computer
4.1. Analyse
4.2. Maverick
4.2.1. Installation
4.2.2. Configuration
4.2.3. Fonctionnement
4.2.4. Problèmes
4.2.5. Test en simulateur
4.2.6. Durabilité
4.2.7. Licence
4.3. Dronecode/ArduPilot
4.3.1. Installation
4.3.2. Fonctionnement
4.3.3. Configuration
4.3.4. Fonctionnalité
4.3.5. Test en simulateur
4.3.6. Test en temps réel
4.3.7. Durabilité
4.3.8. Licence
4.3.9. Résumé
4.4. FlytOS
4.4.1. Installation
4.4.2. Fonctionnement
4.4.3. Fonctionnalités
4.4.4. Test en simulateur
4.4.5. Test en temps réel
4.4.6. FlytPod
4.4.7. Durabilité
4.4.8. License
5. Choix technologique
5.1. Restrictions matérielles
5.2. Simulation
5.3. Problèmes rencontrés
5.4. Tableau de comparaison
6. Etat de l’art – Machine Learning embarqué
6.1. Solutions observer
6.1.1. Iris on board
6.1.2. MobileEYE
6.1.3. Ainstein
6.1.4. Px4 Obstacle Avoidance
7. Implémentation
7.1. Business Understanding + récolte
7.2. Data understanding
7.3. Data preparation
7.4. Modelisation
7.4.1. Clarifai
7.4.2. Darknet
7.4.3. Réseau de neurones
7.5. Data preparation (2)
7.6. Modélisation
7.6.1. Paramétrages
7.7. Evaluation
7.7.1. Code de reconnaissance d’image
7.8. Déploiement
7.8.1. MavProxy DroneKit
7.8.2. Code de changement de mode
7.8.3. Code de reconnaissance d’image puis changement de mode
7.8.4. Tests effectués
8. Conclusion
8.1. Script et contrôle sur le FCU
8.1.1. Bilan technique
8.1.2. Problèmes rencontrés
8.1.3. Améliorations futures et recommandations
8.2. Reconnaissance d’image
8.2.1. Bilan technique
8.2.2. Problèmes rencontrés
8.2.3. Améliorations futures et recommandations
8.3. Bilan général
8.4. Conclusion personnelle
Références
Annexes
Déclaration de l’auteur

Télécharger le rapport complet