Introduction

Dans le cadre de mes études d'ingénieurs, j'avais à réaliser un projet de conception en groupe, dont le sujet pouvait être choisi par les étudiants sous réserve de présenter un cahier des charges cohérent. Après quelques jours de recherche, notre choix s'est porté sur la réalisation d'un drone dont le cahier des charges est décrit ci-dessous :

• Le drone doit être en mesure de voler de manière horizontale ;
• Le drone doit pouvoir transmettre un flux vidéo vers une plateforme web ;
• Le drone doit fonctionner avec un code que nous avons nous-mêmes conçu, tournant sur une carte au choix : un 8051 ou un STM32 ;
• Comme le budget était serré, nous devions le réaliser à partir de matériaux de récupération, c'est-à-dire un AR DRONE 2 de la marque Parrot non fonctionnel, ce qui, vous le verrez, nous a bien compliqué la tâche.

Mon rôle dans l'équipe était d'assurer le pilotage des moteurs de l'AR Drone à la vitesse souhaité via un STM32.

Le fruit de mes recherches est présenté dans une série de 4 articles :
- présentation du projet, reverse engineering hardware du drone et OSINT (cet article)
- reverse engineering du firmware du drone - interactions avec les moteurs - stabilisation du drone - Capteurs et PID

Ce premier article présente mon étude préliminaire du drone. L'objectif ici était d'obtenir quelques informations avant de passer aux choses sérieuses, en menant un travail d'OSINT accompagné d'une brêve analyse hardware du matériel à disposition, afin d'avoir une vague idée sur le fonctionnement général de notre système.

Analyse statique du matériel

Nous avions à notre disposition un drone Parrot AR DRONE 2 non fonctionnel, gentiment fourni par les responsables de la majeure robotique de notre école.

Le Parrot AR.Drone 2.0 est un quadricoptère grand public conçu pour être simple à piloter via un smartphone ou une tablette. Il intègre une caméra HD 720p et de nombreux capteurs permettant une stabilisation automatique très efficace. Léger et polyvalent, il peut voler en intérieur comme en extérieur grâce à ses deux carènes interchangeables.

Ci-dessous une photo de l'appareil :

Démontage

La première étape a consisté à démonter les pièces du drone, afin d'en faire l'inventaire et de sélectionner les composants que l'on pourrait garder. Pour le démonter proprement, nous avons suivi les étapes présentées dans la vidéo ci-dessous.

Nous avons ainsi pu extraire les composants suivants du drone : - 4 moteurs brushless avec contrôleur (avec 4 hélices) - 1 carte mère - 1 châssis de drone - 2 caméras - Une navboard et ses capteurs (accéléromètre et capteurs de distance)

Réalisons une brève analyse hardware des différents composants.

Étude de la carte mère

La carte mère est le cerveau de l'appareil. Elle gère toutes les fonctions essentielles, du pilotage à la communication wifi et au traitement vidéo. Elle est divisée en deux parties, comme on peut le voir sur les images ci-dessous:

On distingue plusieurs composants notables qu'on peut identifier en se basant sur les inscriptions visibles sur chacun d'entre eux.

• Sur la première carte :
  • D9MBZ (documentation disponible ici), une mémoire vive LPDDR SRAM. Son rôle est de stocker temporairement les données et les instructions que le processeur est en train d'exécuter.
  • NQ278 (documentation disponible ici), une mémoire NAND Flash. C'est la mémoire de stockage permanente du drone. Elle contient probablement le firmware ainsi que les paramètres de configuration.
  • TPS65921 (documentation disponible ici), un module responsable de la gestion de l'alimentation et du port USB (Power Management and USB Single Chip). Il prend l'alimentation des batteries du drone et la distribue en différentes tensions régulées et stables nécessaires aux autres composants (CPU, RAM, Flash, etc.). En outre, il gère l'interface USB, essentielle pour les mises à jour du firmware et pour l'ajout d'accessoires comme le module GPS.
  • AR6103G-BM2D-R, un module de communication sans fil WIFI (802.11b/g/n 2.4GHz 72200Kbps LGA). C'est l'élément qui permet au drone de créer son propre point d'accès wifi (réseau Ad hoc) auquel l'utilisateur se connecte via son téléphone. Il permet de recevoir les commandes de vol et de transmettre du flux vidéo en temps réel.
• Sur la deuxième carte :
  • PIC24HJ16GP304 (documentation disponible ici), un microcontrolleur PIC24 16 bits, dédié aux tâches nécessitant une précision et un timing très serrés, comme la lecture rapide des capteurs et le contrôle des moteurs.
  • IMU-3000 de INVENSENSE (documentation disponible ici), un composant de l'Unité de Mesure Inertielle (IMU) (3-AXIS MOTION SENSOR GYROSCOPE, I2C). Il mesure les vitesses angulaires du drone autour de ses trois axes (Roulis, Tangage et Lacet). Ces données permettent sa stabilisation : elles informent le système à quelle vitesse le drone est en train de basculer, permettant au contrôleur PIC24 de calculer les corrections à appliquer immédiatement.

En outre, on peut lire les inscriptions "MYKONOS2_NAV_HW03" sur la deuxième carte, ce qui confirme qu'hypothèse qu'il s'agit de la navboard du drone.

La navboard, ou carte de navigation est une carte dédiée à la lecture des capteurs et à l'exécution de la boucle de contrôle de vol en temps réel permettant de stabiliser et commander des moteurs.

Comme l'objectif était de remplacer la carte mère par un STM32 exécutant notre propre logiciel de contrôle du drone, nous n'avons pas conservé la carte mère ni poussé l'analyse plus loin.

Étude des moteurs

La carte mère n'est pas connectée directement à des moteurs, mais à une carte plus complexe qu'on appellera motorboard. Chaque motorboards est composé :

• d'un contrôleur (un Atmel ATMega8a) dont le rôle est de réguler leur vitesse de rotation.
• d'un moteur brushless
• de 3 transistors MOSFETs c3021ld

On peut faire l'hypothèse au vu des différents composants présents que le contrôleur pilote les transistors comme des interrupteurs afin de générer un signal de type PMW, utilisé pour contrôler la vitesse de rotation des moteurs.

Un signal PWM (Pulse Width Modulation) contrôle la vitesse d'un moteur en variant son rapport cyclique (duty cycle). - Plus le rapport cyclique est élevé (la partie "ON" du signal est longue), plus la tension moyenne appliquée au moteur est haute, et donc plus le moteur tourne vite. - À l'inverse, un rapport cyclique faible donne une tension moyenne faible, et le moteur tourne lentement.

On remarque qu'il n'y a pas de capteurs (de température et autre) au niveau de la motorboard, ce qui signifie qu'il y a très peu de chance que le moteur renvoie des informations vers la carte mère.

Chaque motorboard a 5 PINs, tous connectés à la carte mère.

Quelques recherches sur Google on permis d'obtenir les informations suivantes : Ces cartes moteur ont été spécialement conçues pour l'AR Drone et permette de fournir des performances élevées tout en garantissant une longue durée de vie. Ils ont une puissance de 15 Watts et effectuent 28,000 tours par minute (RPM) en vol stationnaire, ce qui correspond à 3,300 RPM sur les hélices. Les gammes de moteurs commencent à 10,350 RPM et vont jusqu'à 41,400 RPM. Des microcontrôleurs 8 bits basse puissance et des ADC 10 bits contrôlent la vitesse des moteurs.

Analyse dynamique

Comme vous le verrez par la suite, j'ai dû acheté un deuxième drone pour des besoins techniques, et sur celui-ci la carte mère fonctionne, ce qui nous a permis de réaliser diverses mesures.

Mesure de tension

La mesure de l'évolution de la tension sur chaque PIN complété par des tests de continuité nous a permis de déduire leur rôle :

• 1er PIN : 11V, pour l'alimentation des moteurs
• 2ème PIN : 5V, pour l'alimentation de l'ATMega
• 3ème PIN : GND, le ground (ou terre)
• 4ème PIN : TX+RX pour la communication UART avec un baudrate de 115200
• 5ème PIN : Initialement, ce PIN a été interprété, en se basant sur nos recherches en ligne, comme le récepteur d'un signal IRQ (Interruption Request), destiné à remonter des problèmes du drone vers la carte mère. Cependant, une analyse plus poussée (merci à M. Massouri pour son aide précieuse !) a révélé sa véritable nature : c'est un PIN ENABLE. Son rôle est d'activer la réception des données sur la motorboard, ce qui inverse le sens du signal : il va de la carte mère vers la motorboard. Malheureusement, cette clarification est intervenue tardivement, et comme vous le verrez dans les articles suivants, la solution implémentée n'est pas optimale, car nous avons fait un usage inapproprié de ce PIN.

Analyse à la sonde logique

Une analyse complémentaire a été réalisée à la sonde logique sur le PIN TX+RX de la motorboard lors de l'initialisation (allumage du drone).

Cette analyse nous a permis d'obtenir les résultats ci-dessous :

0xE0 [20ms] 0x50 [480us]
0x71 [440us] /64 octets séparés par 9.6us/ [8.38ms] 0x70 [440us]
0x71 [442us] /64 octets séparés par 9.6us/ [8.38ms] 0x70 [440us]
...
0x71 [442us] /64 octets séparés par 9.6us/ [8.38ms] 0x70 [558us]
0x91 [80us] /120 octets séparés par 70-80us/ [503us]
0xA1 [19ms] 0xA0 [180ms] 0x03 [446us]
0x40 [23us] /11 octets séparés par 22us/

Spécificité de la liaison série

Comme les deux lignes de communication sont regroupées en une seule ligne (RX+TX), il nous faudra mettre en place un multiplexeur qui connectera la ligne TX+RX du moteur : - vers la ligne TX de la carte mère lors de la transmission. - vers la ligne RX de la carte mère lors de la réception. De cette manière on pourra envoyer nos commandes vers les motorboard et récupérer leur retour.

OSINT

Dans l'objectif de comprendre le protocole de communication entre la carte mère et les motorboard, mon premier réflexe a été de me renseigner sur Internet pour trouver d'éventuelle documentation publique. Mes recherches m'ont rapidement montré que le protocole de communication entre la carte mère et les motorboards était un protocole propriétaire Parrot non documenté, se transmettant par liaison UART avec un baudrate de 115200. Comme notre drone ne fonctionnait pas à ce moment-là, il nous était impossible là de réaliser nous-mêmes des captures des échanges entre la carte mère et les moteurs pour les analyser et comprendre le protocole. Par chance, nous sommes tombés sur une série de discussion sur un forum présentant et interprétant des captures réalisées sur le même modèle de drone. Voilà un bref résumé de ce que nous avons appris.

⚠️ Certaines de ces informations sont fausses, l'article suivant expliquera pourquoi.

Protocole de communication

Le moteur peut recevoir deux grands types de commandes : des commandes unicast (à destination d’un seul moteur) et multicast (à destination de tous les moteurs). Les commandes unicast servent à configurer le programme du contrôleur de chaque moteur, tandis que les commandes multicast permettent de paramétrer la vitesse d’un moteur.

Commande UNICAST

L'ensemble des commandes UNICAST est décrit dans le tableau ci-dessous:

Nom de la commande	Valeur	Description	Valeur de retour
Récupérer le statut du moteur	E0	Récupère le statut du moteur	00 : ok 50 : besoin de flash la mémoire
Écrire dans la mémoire du contrôleur du moteur	71 XX…XX 70	Écris dans la mémoire le programme du moteur. Le programme doit faire 64 octets, représenté par les XX…XX dans la commande	00
Récupérer le checksum de la mémoire	91	Demande de récupérer le checksum du moteur.	120 octets, correspondant au checksum de la mémoire
Fixer le statut comme étant ok	A1	Fixe le statut du moteur comme étant ok.	A0 FF
Assigner un moteur comme étant le moteur 1,2,3 ou 4	01 ou 02 ou 03 ou 04	Assigner un moteur comme étant le moteur 1,2,3 ou 4	00
Récupérer la version du moteur	11	Récupérer la version du moteur sous la forme de 11 octets. Exemple : 01 0b 03 00 01 01 0a 0a 1a 0a 0a = soft version 1.11, hard version 3.0, supplier 1.1, lot number 10/10, FVT1 26/10/10	11 octets

Commande MULTICAST

L'ensemble des commandes multicast est décrit pas le tableau ci-dessous:

Nom de la commande	Valeur	Description	Valeur de retour
Démarrer une communication multicast.	A0 A0 A0 A0 A0 A0	Démarrer une communication multicast. Tous les échanges qui suivent seront à destination de tous les moteurs.	00
Fixe la vitesse de rotation des moteurs	2x xx xx xx xx		00
Vérifie si les moteurs sont encore opérationnels	89 ou 8A ou 8B ou 8C	89 : moteur 1, 8A : moteur 2, 8B : moteur 3, 8C : moteur 4	28 2F
Fixe la couleur de la LED des moteurs	6x xx ou 7x xx (commence par les bits 011…)	Bit n°5 à 1 : LED rouge moteur arrière gauche Bit n°6 à 1 : LED verte moteur arrière gauche Bit n°7 à 1 : LED rouge moteur arrière droit Bit n°8 à 1 : LED verte moteur arrière droit Bit n°9 à 1 : LED rouge moteur avant droit Bit n°10 à 1 : LED verte moteur avant droit Bit n°11 à 1 : LED rouge moteur avant gauche Bit n°12 à 1 : LED vert moteur avant gauche c'est-à-dire de la forme : 011grgrg rgrxxxx (ça aurait changé pour l'ARDRONE 2: 011rrrrx xxxggggx)	00

Exemple d'un échange

Exemple d’une capture réalisé par wiredrat disponible ici. Ce qui suit un < est une commande envoyée par la carte mère vers le moteur. Ce qui suit un > est le résultat de la commande envoyé par le moteur vers la carte mère.

< 0xe0           RST?
> 	0xe0
> 	0x00
< 0x01           MOTOR 1
> 	0x01
< 0x40 (@)       GET INFO
> 	0x40 (@)      
> 	0x01
> 	0x0b
> 	0x03
> 	0x00
> 	0x01
> 	0x01
> 	0x09
> 	0x0a
> 	0x07
> 	0x0a
> 	0x0a

Références

• https://si.lycee-desfontaines.eu/sequences-1s/capte/res/Dossier-technique-AR-Drone.pdf

• https://web.archive.org/web/20200808210510/https:/www.drone-forum.com/forum/viewtopic.php?f=13&t=1025&start=15

Pour la suite

Nous avons maintenant une première idée du fonctionnement du protocole de communication BLC. Seulement, comme les sources sont relativement anciennes et que nous n'avons aucune preuve de leur véracité, j'ai décidé de réalisé le reverse engineering du firmware du drone, disponible sur Internet. Je vous explique tout ici.