Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA5 2020/2021 P1

2021-01-07T18:01:23Z

Egury : /* Gestion des trames */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Historique des balises====

L'utilisateur peut accéder à l'ensemble des relevés des balises. Les relevés pouvant être nombreux, l'utilisateur à différents filtres à sa disposition. En effet il peut filtrer les relevés par balises, par localisation, mais surtout par date.
Il peut renseigner soit une plage de date, soit une seule date pour avoir tous les relevés jusqu'a cette date ou tous les relevés à partir de cette date.

====Affichage sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

====Gestion utilisateur====

Premièrement, la gestion utilisateur ne doit être accessible qu'aux personnes en ayant les droits, il est donc nécessaire de mettre en place un système de login. Tout se joue avec la fonction session_start(), avant d'envoyer la page concernant le gestion des capteurs au client, on verifie d'abord si ce dernier est connecté, i-e si la variable $_SESSION['login'] existe, sinon on redirige ce dernier vers l'ecran de connexion.

L'utilisateur entre login et mot de passe et on compare ces derniers a ce qui est stocké dans la base de données. Par mesure de sécurité des données de l'utilisateur et en cas de faille de la base, le mot de passe est stocké en hashé.
Une fois connecté l'utilisateur à trois actions possibles, il peut ajouter une balise, modifier une balise et enfin supprimer une balise. En cas d'erreur de saisie, cette dernière est notifiée à l'utilisateur.

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes) FAIT
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs) FAIT
gerer sur la carte l'affichage des balises et l'etat de la route FAIT
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique) FAIT
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down) FAIT

====Connexion à l'application====

Pour rendre l'application accessible depuis l'extérieur et sans passer par le proxy de l'école, j'ai réutilisé la marchine virtuelle deployé en PRA, a savoir trompettedelamortdans mon cas, avec comme ip public 193.48.57.188

Dans bind9, j'ai ajouté un nouvel enregistrement dans /etc/bind/db.trompettedelamort.site
pfe IN CNAME ns1

En faisait cela, le nom pfe.trompettedelamort.site nous retourne bien l'adresse vers le site.

Ensuite, il reste juste a rediriger l'utilisateur vers le bon site lorsqu'il saisie pfe.trompettedelamort.site. Pour cela, la machine trompettedelamort fait office de reverse proxy, dans /etc/apache2/sites-availables ilfaut donc ajouter une nouvelle configuration:

<VirtualHost *:80>
ServerName pfe.trompettedelamort.site
ProxyPreserveHost On
ProxyPass / http://172.26.189.23:80/
ProxyPassReverse / http://172.26.189.23:80/
</VirtualHost>

Ainsi lorsqu'un utilisateur souhaite accéder à pfe.trompettedelamort.site, ce dernier est résolue en 193.48.57.188:80 qui lui même redirige vers 172.26.189.23:80 qui correspond bien à l'adresse privé de notre machine hebergeant notre site.

Petit problème, le routeur de l'ecole bloque l'accés de trompettedelamort (193.48.57.188) vers la machine hebergeant notre site (172.26.189.23). La solution consiste donc à s'attribuer une adresse sur le vlan des ZABETH et d'ajouter une route statique vers le réseau de la machine hebergeant notre site:

up ip address add dev eth1 172.26.145.241/24
up ip route add 172.26.188.0/22 via 172.26.145.254
down ip address del dev eth1 172.26.145.241/24
down ip route del 172.26.188.0/22 via 172.26.145.254

===Mise à jour suite aux remarques===

Premièrement, la structure des trams a été modifiée pour être réduite à son minimum, à savoir 4 octets. Désormais ces octets contiennent uniquement les valeurs des capteur, l'id est récupéré directement dans la requête POST:
$json = file_get_contents("php://input");
$obj = json_decode($json);
$id = bin2hex(base64_decode(json_encode($obj->devEUI)));

Deuxièmement, les id de balises qui s'auto-incrementés en base ne fonctionnent plus comme ça. L'id de la balise étant directement récupéré dans la requête POST, celui-ci est donc devenu la clef primaire de la table balises.

Troisièmement, la table historique balise a été modifié, elle stocke désormais les relevés avec la date mais aussi avec l'heure du relevé. Dans l'ancien système des mesures étaient envoyés par les balises de manière périodique, maintenant un deuxième mode est possible (et c'est celui retenu) qui permet d'envoyer une mesure uniquement quand un niveau change, le reste du temps le capteur est en mode low_power, permettant ainsi d'economiser grandement la batterie. Ainsi le nombre de relevés étant moindre, ceux-ci sont tous stockés en base.

IMA5 2020/2021 P1

2021-01-07T17:52:28Z

Egury : /* Mise à jour suite aux remarques */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affichage sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

====Gestion utilisateur====

Premièrement, la gestion utilisateur ne doit être accessible qu'aux personnes en ayant les droits, il est donc nécessaire de mettre en place un système de login. Tout se joue avec la fonction session_start(), avant d'envoyer la page concernant le gestion des capteurs au client, on verifie d'abord si ce dernier est connecté, i-e si la variable $_SESSION['login'] existe, sinon on redirige ce dernier vers l'ecran de connexion.

L'utilisateur entre login et mot de passe et on compare ces derniers a ce qui est stocké dans la base de données. Par mesure de sécurité des données de l'utilisateur et en cas de faille de la base, le mot de passe est stocké en hashé.
Une fois connecté l'utilisateur à trois actions possibles, il peut ajouter une balise, modifier une balise et enfin supprimer une balise. En cas d'erreur de saisie, cette dernière est notifiée à l'utilisateur.

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes) FAIT
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs) FAIT
gerer sur la carte l'affichage des balises et l'etat de la route FAIT
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique) FAIT
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down) FAIT

====Connexion à l'application====

Pour rendre l'application accessible depuis l'extérieur et sans passer par le proxy de l'école, j'ai réutilisé la marchine virtuelle deployé en PRA, a savoir trompettedelamortdans mon cas, avec comme ip public 193.48.57.188

Dans bind9, j'ai ajouté un nouvel enregistrement dans /etc/bind/db.trompettedelamort.site
pfe IN CNAME ns1

En faisait cela, le nom pfe.trompettedelamort.site nous retourne bien l'adresse vers le site.

Ensuite, il reste juste a rediriger l'utilisateur vers le bon site lorsqu'il saisie pfe.trompettedelamort.site. Pour cela, la machine trompettedelamort fait office de reverse proxy, dans /etc/apache2/sites-availables ilfaut donc ajouter une nouvelle configuration:

<VirtualHost *:80>
ServerName pfe.trompettedelamort.site
ProxyPreserveHost On
ProxyPass / http://172.26.189.23:80/
ProxyPassReverse / http://172.26.189.23:80/
</VirtualHost>

Ainsi lorsqu'un utilisateur souhaite accéder à pfe.trompettedelamort.site, ce dernier est résolue en 193.48.57.188:80 qui lui même redirige vers 172.26.189.23:80 qui correspond bien à l'adresse privé de notre machine hebergeant notre site.

Petit problème, le routeur de l'ecole bloque l'accés de trompettedelamort (193.48.57.188) vers la machine hebergeant notre site (172.26.189.23). La solution consiste donc à s'attribuer une adresse sur le vlan des ZABETH et d'ajouter une route statique vers le réseau de la machine hebergeant notre site:

up ip address add dev eth1 172.26.145.241/24
up ip route add 172.26.188.0/22 via 172.26.145.254
down ip address del dev eth1 172.26.145.241/24
down ip route del 172.26.188.0/22 via 172.26.145.254

===Mise à jour suite aux remarques===

Premièrement, la structure des trams a été modifiée pour être réduite à son minimum, à savoir 4 octets. Désormais ces octets contiennent uniquement les valeurs des capteur, l'id est récupéré directement dans la requête POST:
$json = file_get_contents("php://input");
$obj = json_decode($json);
$id = bin2hex(base64_decode(json_encode($obj->devEUI)));

Deuxièmement, les id de balises qui s'auto-incrementés en base ne fonctionnent plus comme ça. L'id de la balise étant directement récupéré dans la requête POST, celui-ci est donc devenu la clef primaire de la table balises.

Troisièmement, la table historique balise a été modifié, elle stocke désormais les relevés avec la date mais aussi avec l'heure du relevé. Dans l'ancien système des mesures étaient envoyés par les balises de manière périodique, maintenant un deuxième mode est possible (et c'est celui retenu) qui permet d'envoyer une mesure uniquement quand un niveau change, le reste du temps le capteur est en mode low_power, permettant ainsi d'economiser grandement la batterie. Ainsi le nombre de relevés étant moindre, ceux-ci sont tous stockés en base.

IMA5 2020/2021 P1

2021-01-07T17:38:09Z

Egury : /* Partie serveur d'application */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affichage sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

====Gestion utilisateur====

Premièrement, la gestion utilisateur ne doit être accessible qu'aux personnes en ayant les droits, il est donc nécessaire de mettre en place un système de login. Tout se joue avec la fonction session_start(), avant d'envoyer la page concernant le gestion des capteurs au client, on verifie d'abord si ce dernier est connecté, i-e si la variable $_SESSION['login'] existe, sinon on redirige ce dernier vers l'ecran de connexion.

L'utilisateur entre login et mot de passe et on compare ces derniers a ce qui est stocké dans la base de données. Par mesure de sécurité des données de l'utilisateur et en cas de faille de la base, le mot de passe est stocké en hashé.
Une fois connecté l'utilisateur à trois actions possibles, il peut ajouter une balise, modifier une balise et enfin supprimer une balise. En cas d'erreur de saisie, cette dernière est notifiée à l'utilisateur.

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes) FAIT
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs) FAIT
gerer sur la carte l'affichage des balises et l'etat de la route FAIT
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique) FAIT
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down) FAIT

====Connexion à l'application====

Pour rendre l'application accessible depuis l'extérieur et sans passer par le proxy de l'école, j'ai réutilisé la marchine virtuelle deployé en PRA, a savoir trompettedelamortdans mon cas, avec comme ip public 193.48.57.188

Dans bind9, j'ai ajouté un nouvel enregistrement dans /etc/bind/db.trompettedelamort.site
pfe IN CNAME ns1

En faisait cela, le nom pfe.trompettedelamort.site nous retourne bien l'adresse vers le site.

Ensuite, il reste juste a rediriger l'utilisateur vers le bon site lorsqu'il saisie pfe.trompettedelamort.site. Pour cela, la machine trompettedelamort fait office de reverse proxy, dans /etc/apache2/sites-availables ilfaut donc ajouter une nouvelle configuration:

<VirtualHost *:80>
ServerName pfe.trompettedelamort.site
ProxyPreserveHost On
ProxyPass / http://172.26.189.23:80/
ProxyPassReverse / http://172.26.189.23:80/
</VirtualHost>

Ainsi lorsqu'un utilisateur souhaite accéder à pfe.trompettedelamort.site, ce dernier est résolue en 193.48.57.188:80 qui lui même redirige vers 172.26.189.23:80 qui correspond bien à l'adresse privé de notre machine hebergeant notre site.

Petit problème, le routeur de l'ecole bloque l'accés de trompettedelamort (193.48.57.188) vers la machine hebergeant notre site (172.26.189.23). La solution consiste donc à s'attribuer une adresse sur le vlan des ZABETH et d'ajouter une route statique vers le réseau de la machine hebergeant notre site:

up ip address add dev eth1 172.26.145.241/24
up ip route add 172.26.188.0/22 via 172.26.145.254
down ip address del dev eth1 172.26.145.241/24
down ip route del 172.26.188.0/22 via 172.26.145.254

===Mise à jour suite aux remarques===

IMA5 2020/2021 P1

2021-01-07T17:34:33Z

Egury : /* Partie serveur d'application */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affichage sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

====Gestion utilisateur====

Premièrement, la gestion utilisateur ne doit être accessible qu'aux personnes en ayant les droits, il est donc nécessaire de mettre en place un système de login. Tout se joue avec la fonction session_start(), avant d'envoyer la page concernant le gestion des capteurs au client, on verifie d'abord si ce dernier est connecté, i-e si la variable $_SESSION['login'] existe, sinon on redirige ce dernier vers l'ecran de connexion.

L'utilisateur entre login et mot de passe et on compare ces derniers a ce qui est stocké dans la base de données. Par mesure de sécurité des données de l'utilisateur et en cas de faille de la base, le mot de passe est stocké en hashé.
Une fois connecté l'utilisateur à trois actions possibles, il peut ajouter une balise, modifier une balise et enfin supprimer une balise. En cas d'erreur de saisie, cette dernière est notifiée à l'utilisateur.

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes) FAIT
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs) FAIT
gerer sur la carte l'affichage des balises et l'etat de la route FAIT
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique) FAIT
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down) FAIT

====Connexion à l'application====

Pour rendre l'application accessible depuis l'extérieur et sans passer par le proxy de l'école, j'ai réutilisé la marchine virtuelle deployé en PRA, a savoir trompettedelamortdans mon cas, avec comme ip public 193.48.57.188

Dans bind9, j'ai ajouté un nouvel enregistrement dans /etc/bind/db.trompettedelamort.site
pfe IN CNAME ns1

En faisait cela, le nom pfe.trompettedelamort.site nous retourne bien l'adresse vers le site.

Ensuite, il reste juste a rediriger l'utilisateur vers le bon site lorsqu'il saisie pfe.trompettedelamort.site. Pour cela, la machine trompettedelamort fait office de reverse proxy, dans /etc/apache2/sites-availables ilfaut donc ajouter une nouvelle configuration:

<VirtualHost *:80>
ServerName pfe.trompettedelamort.site
ProxyPreserveHost On
ProxyPass / http://172.26.189.23:80/
ProxyPassReverse / http://172.26.189.23:80/
</VirtualHost>

Ainsi lorsqu'un utilisateur souhaite accéder à pfe.trompettedelamort.site, ce dernier est résolue en 193.48.57.188:80 qui lui même redirige vers 172.26.189.23:80 qui correspond bien à l'adresse privé de notre machine hebergeant notre site.

Petit problème, le routeur de l'ecole bloque l'accés de trompettedelamort (193.48.57.188) vers la machine hebergeant notre site (172.26.189.23). La solution consiste donc à s'attribuer une adresse sur le vlan des ZABETH et d'ajouter une route statique vers le réseau de la machine hebergeant notre site:

up ip address add dev eth1 172.26.145.241/24
up ip route add 172.26.188.0/22 via 172.26.145.254
down ip address del dev eth1 172.26.145.241/24
down ip route del 172.26.188.0/22 via 172.26.145.254

IMA5 2020/2021 P1

2021-01-07T17:13:07Z

Egury : /* Gestion utilisateur */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affichage sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

====Gestion utilisateur====

Premièrement, la gestion utilisateur ne doit être accessible qu'aux personnes en ayant les droits, il est donc nécessaire de mettre en place un système de login. Tout se joue avec la fonction session_start(), avant d'envoyer la page concernant le gestion des capteurs au client, on verifie d'abord si ce dernier est connecté, i-e si la variable $_SESSION['login'] existe, sinon on redirige ce dernier vers l'ecran de connexion.

L'utilisateur entre login et mot de passe et on compare ces derniers a ce qui est stocké dans la base de données. Par mesure de sécurité des données de l'utilisateur et en cas de faille de la base, le mot de passe est stocké en hashé.
Une fois connecté l'utilisateur à trois actions possibles, il peut ajouter une balise, modifier une balise et enfin supprimer une balise. En cas d'erreur de saisie, cette dernière est notifiée à l'utilisateur.

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes) FAIT
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs) FAIT
gerer sur la carte l'affichage des balises et l'etat de la route FAIT
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique) FAIT
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down) FAIT

IMA5 2020/2021 P1

2021-01-07T17:12:56Z

Egury : /* Affichage sur la carte */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affichage sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

====Gestion utilisateur====

Premièrement, la gestion utilisateur ne doit être accessible qu'aux personnes en ayant les droits, il est donc nécessaire de mettre en place un système de login. Tout se joue avec la fonction session_start(), avant d'envoyer la page concernant le gestion des capteurs au client, on verifie d'abord si ce dernier est connecté, i-e si la variable $_SESSION['login'] existe, sinon on redirige ce dernier vers l'ecran de connexion.

L'utilisateur entre login et mot de passe et on compare ces derniers a ce qui est stocké dans la base de données. Par mesure de sécurité des données de l'utilisateur et en cas de faille de la base, le mot de passe est stocké en hashé.
Une fois connecté l'utilisateur à trois actions possibles, il peut ajouter une balise, modifier une balise et enfin supprimer une balise. En cas d'erreur de saisie, cette dernière est notifiée à l'utilisateur.

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes) FAIT
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs) FAIT
gerer sur la carte l'affichage des balises et l'etat de la route FAIT
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique) FAIT
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down) FAIT

IMA5 2020/2021 P1

2021-01-07T16:33:58Z

Egury : /* Affiche sur la carte */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affichage sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes)
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs)
gerer sur la carte l'affichage des balises et l'etat de la route
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique)
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down)

IMA5 2020/2021 P1

2021-01-07T16:33:45Z

Egury : /* Affiche sur la carte */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affiche sur la carte====

En passant par l'API google maps il est possible d'affichir une carte sur l'appplication web et d'apporter des modifications à cette dernière

A l'aide de JavaScript, je peux afficher sur ma carte les balises ainsi que leur etat sur la carte. Pour se faire, avant que le code JS soit executé par le client, ce dernier est preparé par un code PHP permettant de parcourir la base et de recupérer les balises, leur état et leur coordonnées avant de les afficher avec un indice couleur selon leur niveau d'inondation:

<?php
$reponse=$bdd->query('SELECT COUNT(*) FROM balises');
$nbMarqueur=$reponse->fetch();
?>
var nbMarqueur=<?php echo $nbMarqueur['count'];?>;
var locations = new Array(nbMarqueur);
var coordonnees, coord1, coord2;
var heatMapData = new Array(nbMarqueur);
<?php
$reponse=$bdd->query('SELECT localisation, coordonnees, niveau FROM balises');
?>
var infos =JSON.parse('<?php echo json_encode($reponse->fetchAll(), true); ?>');
console.log(nbMarqueur);
for(var i=0; i<nbMarqueur; i++){
locations[i]=new Array(4);
locations[i][0]=infos[i]['localisation'];
coordonnees=infos[i]['coordonnees'];
var pos=coordonnees.indexOf(",");
coord1=coordonnees.slice(0,pos-1);
coord2=coordonnees.slice(pos+1);
locations[i][1]=coord1;
locations[i][2]=coord2,
locations[i][3]=i;
heatMapData[i]={location: new google.maps.LatLng(coord1, coord2), weight: infos[i]['niveau']};
}

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes)
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs)
gerer sur la carte l'affichage des balises et l'etat de la route
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique)
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down)

IMA5 2020/2021 P1

2020-12-10T19:32:37Z

Egury : /* Partie serveur d'application */

__TOC__
 

=Présentation générale=

==Description==

Dans le cadre des projets de fin d'étude, j'ai choisi le projet "Réseau de capteurs autonomes pour mesures aquatiques". Ce dernier à pour but de mesurer le niveau d'eau dans une zone, de mettre en forme l'information et de l'envoyer sur un serveur réseau via la technologie LoRa. A l'aide d'un serveur applicatif et d'une application, l'information sera disponible à l'utilisateur sous diverses forme (information diverses sur la balise, affichage sur une carte...).

==Objectifs==

Le projet va se découper en quatre partie. Premièrement il va falloir concevoir un capteur permettant de mesurer le niveau de l'eau et aussi le système permettant d'envoyer l'information via un réseau LoRaWAN. Dans un second temps, une machine virtuelle est mis à ma disposition afin de deployer le serveur réseau, il est donc nécessaire de configurer ce dernier. Dans un troisième temps sur le même principe que le serveur reseau, une machine virtuelle est mise à ma disposition afin de deployer le serveur applicatif. Enfin pour la quatrième partie, une application web devra être mise au point afin de données l'accés aux informations à l'utilisateur.

=Réalisation du Projet=

==Projet de fin d'étude==

===Début projet===

Les semaines 1 et 2 ont été très limité en terme de travail à cause du Covid, cependant lors de la première semaine et apres rendez vous avec Mr Boé, j'ai pu dresser le cahier des charges et concernant la seconde semaine après un second rendez vous j'ai pas récuperer le matériel LoRaWAN et des microcontroleurs Mbed pour m'aider dans la première partie du projet mais aussi rédiger le cahier des spécifications.

===Mise en place du réseau===

Grâce à l'aide du binôme Loic Ringot et Théo Evrard, le serveur réseau à été configuré sur la machine virtuelle. Pour se faire dans un premier temps nous avons installé un serveur DHCP sur la machine virtuelle afin de pouvoir s'adresser aux différents équipements du réseau. Le serveur DHCP a été configuré de tel manière à attribuer des adresses allant de 192.168.42.1 à 192.168.42.9. Pour se faire, il a fallu dans un premier se connecter au serveur réseau en ssh puis de modifier configurer le serveur DHCP (/etc/dhcp/dhcpd.conf) et d'ajouter les lignes suivantes :
subnet 192.168.42.0 netmask 255.255.255.0{
range 192.168.42.1 192.168.42.9
}

La configuration du serveur réseau s'effectue en se connectant à ce dernier en ssh:
root@192.168.42.10
Il faut installer le "gateway bridge", le "network server" ainsi que "l'application server" disponible sur ChirpStack. Pour se faire nous avons suivi un tutoriel à l'adresse suivante:
https://www.youtube.com/watch?v=FnTP7t47DlI
ainsi que la documentation fournie par ChirpStack

Pour accéder au serveur réseau, nous passons par l'interface web en se connectant à l'adresse suivante (en passant par une zabeth):
172.26.189.22:8080 id: admin mdp: admin

A partir de l'interface web, nous pouvons configurer de nombreux éléments:

-Création d'un nouveau projet

-Ajouter des équipements aux réseau à l'aide des clefs

-Surveiller les informations qui circulent sur notre réseau

-...

Enfin, en nous connectant en ssh sur les deux gateways:
antenne: 192.168.42.1 mdp:pdmk-062E7A
passerelle intérieur: 192.168.42.2 mdp:pdmk-030970
Nous avons pu mettre à jour ces dernieres en suivant le wiki Kerlink
La connexion au wiki Kerlink s'effectue avec:
Login : univlille
Mot de passe : IYBlN7QF06

===Test du réseau===

Pour tester le fonctionnement de notre Network Server nous avons utilisé un module GPS LoRa du commerce. En se connectant a notre Network Server (172.26.189.22:8000) nous avons pu créer une nouvelle application et ajouté un nouvel équipement. Se faisant notre Network Server génère deux clefs, une "application key" et une "Network Key". Ces deux clefs doivent être renseigné manuellement dans notre équipement. Pour se faire on peut le connecter à un ordinateur et y ajouter les clefs via son logiciel dédié. L'équipement possédant déjà un EUI permettant de reconnaître l'équipement, nous avons du renseigner ce dernier dans l'ajout de l'équipement sur le Network Server. Suite à ce test nous avons bien pu observer la circulation de nos trames et le bon fonctionnement de notre Network Server.

===Fabrication du End-device===

Pour le end-device je dispose d'une carte STM32F411RE, d'un shield SX1276MB1MAS et d'un capteur ultrason HC-SR04.
Le développement du programme se fait sur STM32Cube.
Un premier programme à été mis en place sans difficultés pour récupérer les valeurs du HC-SR04 en s'appuyant sur l'exemple proposé par Arduino.
En revanche les problèmes sont arrivés lors du développement concernant la partie LoRaWAN. En effet STM32 propose un package LoRaWAN pour faciliter le développement d'application, le problème étant que ce package concerne seulement les cartes STM32LXXX. J'ai essayé longuement d'adapter ce package pour ma carte STM32F411RE en modifiant notamment le Makefile, les .flash mais aussi les fichiers d'inclusion sans succès malheureusement. La solution envisagée est donc un changement de carte au profit d'une STM32LXXX.

Après changé notre carte pour une STM32L152RE, j'ai repris le package proposé par STM32 et dans le fichier Commissioning.h j'ai rensigné les clefs
LORAWAN_APP_KEY
LORAWAN_NWK_KEY

Il n'y a que ces deux à renseigner étant donné que notre équipement fonctionne sur une version inférieur à la 1.1. A noter que le champ device EUI semble ne pas fonctionner. Nous avons du récuper l'EUI sur une gateway et renseigner ce dernier dans l'équipement que j'ai crée pour mon application sur l'interface web.

Concernant le programme de l'équipement en lui même le programme est relativement simle, en se servant de la bibliothèque HAL je declare 3 PIN en input et je renvoie ainsi l'état des capteurs de manière périodique en me servant de la fonction "Send" du package STM32.

===Partie application WEB===

La principale difficulté de cette partie et l'absence totale de connaissances dans le développement d'application WEB. J'ai donc dû apprendre les langage HTML / CSS / PHP (quelques notions en JS) pour réaliser cette partie. Je disposais de quelques notions en base de données et SQL suit à mon année d'IMA3.

Le but de l'application WEB est de permettre de rendre exploitable pour l'utilisateurs les informations renvoyés par les balises. Pour se faire l'application doit contenir une page de monitoring permettant de surveiller l'état de toutes les balises. De plus elle doit contenir une partie historique permettant d'accéder à l'historique d'une balise en particulier (en effectuant une recherche par id/localisation/date). Enfin elle doit aussi proposer une partie permettant d'afficher une carte avec dessus les balises et leur état.

A l'aide de Bootstrap j'ai mis en place une application WEB avec ces trois partie.

===Partie serveur d'application===

====Mise en place de l'environnement====

Concernant la partie serveur, j'ai mis en place sur une VM (172.26.189.23) un serveur apache et Postgres pour la gestion des bases mais aussi un interpreteur php.
Pour apache j'ai simplement mis tous mes fichiers html/php dans /var/www/html qui est le repertoir par defaut. Celui est configuré pour démarrer au lancement de la VM.
Concernant Postgres j'ai d'abord crée un nouvel utilisateur en me servant de l'utilisateur crée par defaut (su - postgres):
createuser -d -P root (mdp: glopglop)

Puis j'ai créé une nouvelle base:
createdb -O root pfe

Pour se connecter a la base:
psql pfe (depuis l'utilsateur root ou postgres)

Enfin j'y ai ajouté mes tables:

CREATE TABLE balises (ID serial PRIMARY KEY, Pays varchar(50) NOT NULL, Ville varchar(50) NOT NULL, Localisation varchar(50) NOT NULL, Coordonnees varchar(50) NOT NULL,Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

CREATE TABLE historique_balise (ID serial PRIMARY KEY, id_balise int NOT NULL, Date date NOT NULL, Niveau int NOT NULL, Inondee varchar(50) NOT NULL);

La base contient deux tables, une première ayant pour clef primaire l'id de la balise et contenant des informations diverses sur cette dernière telles que le pays, la ville, la localisation, les coordonnée, le niveau d'eau mais surtout si cette dernière est sous l'eau ou non. La seconde table concerne l'historique des balises, elle a pour clef primaire l'indice du relevé et contient des informations comme le numéro de balise, la date du relevé etc, l'état de la balise etc..

Pour la communication entre le serveur d'application et le serveur réseau, j'ai dans un premier temps mis en place un script python pour récuperer les relevés des capteurs via l'API REST:
import requests
import json
#on recupere le token
headers = {
'Content-Type': 'application/json',
'Accept': 'application/json',
}
data = '{"email": "admin","password": "admin" }'
response = requests.post('http://172.26.189.22:8080/api/internal/login', headers=headers, data=data)
resp=response.json()
#print(resp['jwt'])
#diverses information sur un capteur
headers = {
'Accept': 'application/json',
'Grpc-Metadata-Authorization': 'Bearer'+resp['jwt'],
}
response = requests.get('http://172.26.189.22:8080/api/devices/0b00f4ff703a8fc5', headers=headers)
resp=response.json()
print(resp)

Ce script permet de un premier temps de récuperer le token pour avoir accés à l'API. Celui ci est a renseigner dans toute les requetes http.
En se connectant à l'API via l'interface graphique (172.26.189.22:8080/api), on peut récuperer toutes les requetes possible en cURL, j'ai donc simplement utilisé un convertisseur cURL vers python pour mettre mes requetes en place.

Malheureusement cette solution permet de récuperer de nombreuses informations concernant l'application mais pas les relevés des capteurs. Pour récupérer ces derniers, je suis passé par l'interface graphique du serveur d'application (172.26.189.22:8080) afin d'ajouter une intégration HTTP. Il faut simplement spécifier le format de l'information (JSON dans mon cas) et l'URL à laquelle doit être envoyé la requête http POST. Dans mon cas cela sera:
http://172.26.189.23/pfe/gestionPOST.php

La base du fichier gestionPOST.php ressemble à cela:
<?php
header("content-type: application/json");
$json = file_get_contents("php://input");
$obj = json_decode($json);
$decoded = base64_decode(json_encode($obj->data));
$fp = @fopen("toto.txt","a");
fwrite($fp,$decoded);
fwrite($fp,"\r\n");
fclose($fp);
?>

Il permet via le flux php://input de récupérer le contenu de la requête POST et de l'afficher.

La prochaine étape concerne la gestion des informations avec notamment l'ajout en base selon le type d'information recu.

====Gestion des trames====

Les trames sont envoyés au format suivant:
id:niveau1:niveau2:niveau3

A travers le script php permettant la gestion des requetes HTTP Post, en se servant de la fonction preg_match avec le regex suivant on peut récuperer toutes les informations necessaires au traitement:
"#^([0-9]+):([0-1]{1}):([0-1]{1}):([0-1]{1})$#"

Chaque nouvelle mesure envoyée sur le serveur d'application est renseignée en base grace à la requêtes SQL suivante:
UPDATE balises
SET inondee=:in, niveau=:niv
WHERE id=:id;

Les requêtes en php sont réalisées par le biais des fonctions query, prepare et execute.

Toutes les requêtes SQL sont regroupés dans un même fichier par soucis de clarté.

Dès qu'une nouvelle mesures est transmise au script php, on récupère la date actuelle et on la compare avec le dernier relevé de cette balise enregistré dans la table historique, si le dernier relevé date de la veille on ajoute une nouvelle entrée dans la table historique_balise:

$ajrd=date("Y-m-d");
$requete=$bdd->prepare('SELECT MAX(date) AS max_date
FROM historique_balise
WHERE id_balise=:id');
$requete->execute(array('id' => $id));
$resultat=$requete->fetch();
if($ajrd>$resultat['max_date'] || $resultat==FALSE){
$requete=$bdd->prepare('INSERT INTO historique_balise
VALUES (DEFAULT,:id,:d,:niv,:in)');
$requete->execute(array('id'=>$id,'d'=>$ajrd, 'niv'=>$niveau, 'in'=>$inondee));
}

Lors d'une première entrée, la condition $resultat==false permet d'ajouter pour la première fois la balise dans l'historique

====Affiche sur la carte====

En passant par l'API google maps il est possible d'affichier une carte sur l'appplication web et d'apporter des modifications à cette dernière

Note a moi même: travail a effectuer en priorité:

gerer la partie historique des balises en base (quasi fini, gérer les heures pour ajouter de manière plus fréquentes)
mettre en place un mode administrateur sur l'appli pour par exemple ajouter ou retirer des balises (a voir si utile avec les profs)
gerer sur la carte l'affichage des balises et l'etat de la route
mettre toutes les requetes SQL dans un même fichier (fait pour la recherche historique)
mise en place d'une appli android
concevoir le capteur
gestion ajout nouveau capteur (voir message down)

IMA5 2020/2021 P1

2020-12-09T17:45:03Z

Egury : /* Gestion des trames */

IMA5 2020/2021 P1

2020-12-09T15:05:13Z

Egury : /* Gestion des trames */

IMA5 2020/2021 P1

2020-12-09T15:04:28Z

Egury : /* Gestion des trames */

IMA5 2020/2021 P1

2020-12-09T15:03:48Z

Egury : /* Gestion des trames */

IMA5 2020/2021 P1

2020-12-09T15:03:02Z

Egury : /* Gestion des trames */

IMA5 2020/2021 P1

2020-12-09T15:02:16Z

Egury : /* Gestion des trames */

IMA5 2020/2021 P1

2020-12-07T17:48:48Z

Egury : /* Gestion des trames */

IMA5 2020/2021 P1

2020-12-07T17:39:29Z

Egury : /* Partie serveur d'application */

IMA5 2020/2021 P1

2020-12-07T17:38:56Z

Egury : /* Partie serveur d'application */

IMA5 2020/2021 P1

2020-12-07T17:38:19Z

Egury : /* Partie serveur d'application */

IMA5 2020/2021 P1

2020-12-07T17:37:14Z

Egury : /* Partie serveur d'application */

IMA5 2020/2021 P1

2020-12-07T13:57:10Z

Egury : /* Partie serveur d'application */

IMA5 2020/2021 P1

2020-11-26T17:17:08Z

Egury : /* Partie serveur d'application */

IMA5 2020/2021 P1

2020-11-26T17:14:06Z

Egury : /* Projet de fin d'étude */

IMA5 2020/2021 P1

2020-11-26T17:13:49Z

Egury : /* Projet de fin d'étude */

IMA5 2020/2021 P1

2020-11-25T16:44:37Z

Egury : /* Partie application WEB */

IMA5 2020/2021 P1

2020-11-25T10:28:42Z

Egury : /* Projet de fin d'étude */

IMA5 2020/2021 P1

2020-11-24T17:19:23Z

Egury : /* Fabrication du End-device */

IMA5 2020/2021 P1

2020-11-24T11:37:44Z

Egury : /* Mise en place du réseau */

IMA5 2020/2021 P1

2020-11-24T11:37:08Z

Egury : /* Mise en place du réseau */

IMA5 2020/2021 P1

2020-11-24T11:32:37Z

Egury : /* Mise en place du réseau */

IMA5 2020/2021 P1

2020-11-09T21:51:56Z

Egury : /* Projet de fin d'étude */

IMA5 2020/2021 P1

2020-11-09T21:12:39Z

Egury : /* Semaine 3 */

IMA5 2020/2021 P1

2020-10-08T16:03:26Z

Egury : /* Semaine 3 */

IMA5 2020/2021 P1

2020-10-08T16:01:00Z

Egury : /* Semaine 3 */

IMA5 2020/2021 P1

2020-10-08T15:51:14Z

Egury : /* Semaine 3 */

IMA5 2020/2021 P1

2020-10-08T13:51:56Z

Egury : /* Semaine 3 */

IMA5 2020/2021 P1

2020-10-05T16:46:24Z

Egury : /* Présentation générale */

IMA5 2020/2021 P1

2020-10-05T16:26:00Z

Egury : /* Présentation générale */

IMA3/IMA4 2018/2020 P4

2020-05-03T14:28:18Z

Egury : /* Semaine 13 */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
*Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à un câble défectueux (Problème de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Le boitier comporte 3 potentiomètres, un pour la valeur du I, un autre pour la valeur du P et le dernier pour la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour appliquer la régulation uniquement sur deux moteurs.

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop (fonction permettant de prendre en compte la décharge de la batterie dans le calcul de la correction) était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre programme. Cependant la fonction est resté un certains temps dans notre programme, notamment pendant des tests, et nous pensions alors que la tension étant stable, cette fonction n’influençait pas sur le bon fonctionnement du programme. Cependant un pin était utilisé dans cette fonction pour récupérer la tension, et ayant laissé tombé cette fonction, nous avons aussi ignoré l'utilisation de ce pin et de ce fait nous avons faussait les calculs de correction. Finalement cette suppression nous a permis, de constater une nette amélioration de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe. Malheureusement nous somme tombé à court de batterie (nous nous rechargions à Robotech) et nous ne disposons pas d'alimentation 12V pouvant supporter le courant demandé par les moteurs. Il reste donc encore l'axe pitch à réguler. Le roll est régulé avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T14:24:00Z

Egury : /* Semaine 14 et 15 : coupure pédagogique */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
*Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à un câble défectueux (Problème de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Le boitier comporte 3 potentiomètres, un pour la valeur du I, un autre pour la valeur du P et le dernier pour la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop (fonction permettant de prendre en compte la décharge de la batterie dans le calcul de la correction) était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre programme. Cependant la fonction est resté un certains temps dans notre programme, notamment pendant des tests, et nous pensions alors que la tension étant stable, cette fonction n’influençait pas sur le bon fonctionnement du programme. Cependant un pin était utilisé dans cette fonction pour récupérer la tension, et ayant laissé tombé cette fonction, nous avons aussi ignoré l'utilisation de ce pin et de ce fait nous avons faussait les calculs de correction. Finalement cette suppression nous a permis, de constater une nette amélioration de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe. Malheureusement nous somme tombé à court de batterie (nous nous rechargions à Robotech) et nous ne disposons pas d'alimentation 12V pouvant supporter le courant demandé par les moteurs. Il reste donc encore l'axe pitch à réguler. Le roll est régulé avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T14:02:26Z

Egury : /* Semaine 9 */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
*Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à un câble défectueux (Problème de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Le boitier comporte 3 potentiomètres, un pour la valeur du I, un autre pour la valeur du P et le dernier pour la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T14:01:17Z

Egury : /* Semaine 9 */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
*Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à un câble défectueux (Problème de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T13:59:28Z

Egury : /* Semaine 6 */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
*Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à un câble défectueux (Problème de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Nous avons créé un programme, permettant de prendre en entrée le boitier PID, et de lire la valeur des potentiomètres pour modifier en instantané les valeurs du PID numérique.
*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T12:22:48Z

Egury : /* Semaine 4 */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
*Mise en place d'une maquette à base de potentiomètres et d'interrupteurs pour régler le PID.
*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à une division par 0 (Probleme de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Nous avons créé un programme, permettant de prendre en entrée le boitier PID, et de lire la valeur des potentiomètres pour modifier en instantané les valeurs du PID numérique.
*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T12:21:36Z

Egury : /* Semaine 4 */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.
*Possibilité de faire fonctionner le drone en mode normal ou en mode réglage PID par simple utilisation d'un interrupteur.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à une division par 0 (Probleme de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Nous avons créé un programme, permettant de prendre en entrée le boitier PID, et de lire la valeur des potentiomètres pour modifier en instantané les valeurs du PID numérique.
*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T12:18:49Z

Egury : /* Semaine 3 */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Finalisation du programme, y compris la partie régulation PID
*Reste encore à régler les coefficients du PID
*Mise en relation du programme avec l'équipe 1

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à une division par 0 (Probleme de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Nous avons créé un programme, permettant de prendre en entrée le boitier PID, et de lire la valeur des potentiomètres pour modifier en instantané les valeurs du PID numérique.
*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T12:15:22Z

Egury : /* Liste des tâches à effectuer */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglage de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps dont on disposera)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Mise en relation du programme avec l'équipe 1
*Finalisation du programme total, y compris la partie régulation PID

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à une division par 0 (Probleme de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Nous avons créé un programme, permettant de prendre en entrée le boitier PID, et de lire la valeur des potentiomètres pour modifier en instantané les valeurs du PID numérique.
*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-03T12:13:14Z

Egury : /* Liste des tâches à effectuer */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Mise en place et réglages de la régulation PID:
**Calcul de la consigne
**Calcul des erreurs
**Calcul des consignes à appliquer aux moteurs après correction
**Application des consignes

*Implémenter un système de guidage GPS (à voir avec le temps que l'on dispose)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Mise en relation du programme avec l'équipe 1
*Finalisation du programme total, y compris la partie régulation PID

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à une division par 0 (Probleme de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Nous avons créé un programme, permettant de prendre en entrée le boitier PID, et de lire la valeur des potentiomètres pour modifier en instantané les valeurs du PID numérique.
*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-05-02T15:19:04Z

Egury : /* Semaine 14 et 15 : coupure pédagogique */

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

L'objectif ici est d'implémenter notre propre contrôleur de vol (software et hardware) à l'aide de composants individuels, principalement d'une centrale inertielle 3 axes ainsi que d'un accéléromètre 3 axes.

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|400px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Tests et réglages de la régulation PID
*Implémenter un système de guidage GPS (à voir avec le temps que l'on dispose)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Mise en relation du programme avec l'équipe 1
*Finalisation du programme total, y compris la partie régulation PID

===Semaine 4===

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.

===Semaine 5===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à une division par 0 (Probleme de maquette avec le MPU 6050).

[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|center|thumb|Test des valeurs de courant reçues par les ESC]]

===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

*Nous avons créé un programme, permettant de prendre en entrée le boitier PID, et de lire la valeur des potentiomètres pour modifier en instantané les valeurs du PID numérique.
*Le boitier comporte 3 potentiomètres, un pour chaque la valeur du I, la valeur du P et la valeur du D.
*Les valeurs du PID varient entre des plages bien précises: P: I: D:

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Régulation avec 2 ESCs (Lukas) :'''

* Test du boîtier permettant le contrôle des différents coefficients du PID. En effet, lors de sa conception, un faux contact avait été constaté : problème résolu.

[[Fichier: Pid_controller_P4.jpg|300px|center|thumb|Boîtier de contrôle du PID]]

'''Application mobile :'''

* Début de l'apprentissage de la création d'une application Android à l'aide de ANDROID STUDIO

===Semaine 12===

[[Fichier: regulation_4_esc.mp4|300px|left|thumb|Régulation presque adaptée sur 4 ESCs]]

'''Application mobile :'''
*Réalisation d'une application Android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les joysticks envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer les signaux PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais à programmer la partie concernant l'ESP-32.
[[Fichier: applicationAndroid.mp4|520px|center|thumb|Présentation de l'application]]

'''Régulation avec 2 ESCs'''
*Test de régulation sur le banc d'essai avec les valeurs du PID testée sur les derniers tests à 4 ESCs : vidéo ci-contre
*Test du programme utilisant le boitier PID permettant de modifier nos valeurs en direct

===Semaine 13===

* Reception d'un ESP32 et debut de la programmation. Création d'un Serveur WIFI, il reste à faire communiquer l'application et l'ESP32.

* Modification du code pour réguler deux moteurs

===Semaine 14 et 15 : coupure pédagogique===

* Communication telephone-ESP32 fonctionnelle à partir d'un serveur WEB. Communication de l'application vers ESP32 impossible. Nous n'avons pas réussi à nous connecter à la socket créé sur l'esp32.

* La communication entre l'application mobile et l'ESP32 est fonctionnelle, nous envoyons ainsi un message formé des consignes sur la socket.

'''Régulation avec deux moteurs'''

Après avoir constaté que la fonction compensateBatteryDrop() était devenue obsolète en raison de l'ajout de notre PDB (Power Distributor Board), nous avons décidé de l'enlever de notre boucle (void loop()) améliorer les performances de notre programme. De plus, un pin était utilisé et faussait les calculs. Cette suppression nous a permis, effectivement, de constater une nette amélioration dans la gestion de la régulation.

Lukas a alors pu réguler le drone avec deux moteurs sur un axe (Roll). Cette régulation a été menée à bien et le drone se stabilise sur un axe jusqu'à ce que nous soyons à court de batterie (nous nous rechargions à Robotech) avec les valeurs suivantes :
*kp Roll = 1.25 ki Roll = 0.05 kd Roll = 22.00

L'objectif maintenant est, dès qu'on le pourra, après la fin du semestre de se réunir, d'installer les 4 nouveaux ESC et d'effectuer une régulation complète afin de finir complètement la conception de notre drone.

===Documents Rendus===

IMA3/IMA4 2018/2020 P4

2020-03-31T22:59:13Z

Egury :

<include nopre noesc src="/home/pedago/pimasc/include/video-ConstructionDroneIMA32018-iframe.html" />
__TOC__
 

=Présentation générale=

==Description==

Dans le cadre du projet IMA3/4, nous avons choisi le sujet P4 : '''Construction d'un drone volant'''. Notre groupe se compose de Maxime CLAUDEL, Lukas FAUCHOIS, Evan GURY et Richard Simonin.
Nous avions dans un premier temps décidé de réaliser notre projet autour d'un drone servant à la livraison de petit colis, cependant dans un souci concernant la matériel mis à notre disposition et de budget, nous avons finalement opté pour un drone "loisir".
Ce dernier sera destiné à un public amateur, dans un but d'apprentissage et/ou d'amusement et sera ainsi plus en adéquation avec nos contraintes et compétences, de plus amples informations sont décrites ci-dessous dans la partie '''Objectifs''' de notre présentation.

==Objectifs==

A terme, l'objectif principal de ce projet est de concevoir et construire entièrement un drone "made in Polytech Lille"

Nous allons alors répartir notre travail en deux sessions, une première réalisée en IMA (S6) et une seconde en IMA4.

Pour la fin de cette première session de projet, nous avons pour objectif de faire voler notre drone. Pour ce faire, nous n'avons évidemment pas le temps de nous occuper de la partie concernant le vol nous-mêmes, c'est pour quoi nous avons opté pour l'utilisation d'un contrôleur de vol n'ayant qu'à être configuré.

Parallèlement à cela, nous comptons réaliser nous-mêmes la commande permettant de communiquer avec ce dernier pendant qu'une autre partie des membres du projet s’attellera à la partie mécanique et électrique du drone.

Ce faisant et si tout se passe bien, nous pourrons avoir pour débuter l'année prochaine une base solide pour concevoir nous-mêmes notre contrôleur de vol. Ce qui nous amène à notre second point, puisque nous comptons dans un second temps réaliser notre propre contrôleur de vol, une fois le premier objectif atteint.

=Analyse du projet=

==Positionnement par rapport à l'existant==

[[Fichier:parrot.jpg|right|thumb|PARROT AR.DRONE 2.0]]
[[Fichier:udi.jpg|right|thumb|UDI U818S]]

===Analyse du premier concurrent : PARROT AR.DRONE 2.0===

Le [https://www.parrot.com/fr/drones/parrot-ardrone-20-elite-edition PARROT AR.DRONE 2.0], tout comme le notre, est destiné à un usage ludique. En dehors de la camera que nous n'envisageons pas d'intégrer à notre drone pour le moment, il dispose de toutes les caractéristiques que nous souhaiterions obtenir. A savoir une portée d'environ 100m, une autonomie de plus de 10min et une vitesse moyenne d'environ 20 km/h pour un prix avoisinant les 100 euros.

Notre avantage peut se jouer sur la camera, en effet, en enlevant cette dernière nous pouvons réaliser des économies. De plus, si une personne recherche un drone simplement pour prendre du plaisir à le faire voler, il ne souhaitera pas forcément gaspiller son argent dans une camera qu'il n'aurait surement de base pas voulu.

===Analyse du second concurrent : UDI U818S===

Fabriqué par la marque UDI, le [https://www.maisondudrone.com/prod/udi-u818s-avec-camera-hd-2-0mp-blanc-1400.html UDI U818S] est un drone au caractéristiques similaires au précédent, à l'exception de la camera.
En effet, cette fois nous sommes face à un concurrent qui tout comme nous, propose simplement la fonctionnalité de base d'un drone, à savoir voler et cela se fait ressentir sur le prix puisque nous passons sur un prix d'environ 50 euros.
Face à un concurrent proposant un produit similaire au notre et à un prix au plus bas pour ces caractéristiques, difficile de faire mieux sur le plan technique. Peut être serait il alors plus judicieux de proposer un produit plus haute gamme, plus chère, mais destiné à un public désireux de s'amuser avec un produit de qualité.

==Scénario d'usage du produit ou du concept envisagé==

'''A qui notre drone peut-il servir ?'''

Le drone "made in Polytech Lille" s'adresse à tout public n'ayant que pour objectif l'amusement''

Toute personne souhaitant débuter avec un drone de qualité, sans s'encombrer de fonctionnalité ne s'avérant pas utiles peut être amenées a utiliser notre drone.

'''Pour quel type d'utilisation ?'''

Nombre de notre génération ont déjà reçu comme cadeau une voiture RC. Cette dernière n'avait que pour objectif de rouler à toute vitesse pour nous satisfaire. Nul besoin d'embarquer des caméras, stabilisateurs et nombres d'autres gadgets inutile à la vocation initiale de notre voiture, rouler.

Avec notre drone, nous voulons remettre cela en avant, le simple plaisir de piloter une voiture RC appliqué aux drones. Alors enfant, adultes et nostalgiques pourront par le biais de notre produit découvrir ou redécouvrir le plaisir de piloter un engin motorisé, qui plus est cette-ci fois dans les airs.

==Réponse à la question difficile==

'''Qu'en est-il du dimensionnement des composants pour permettre à votre drone de porter une telle charge ?'''

Nos contraintes et objectif ayant totalement changé, la question ne se pose plus vraiment. En effet nous avons suites à notre présentation réalisé des calculs en terme de puissance et nous nous sommes très vite rendu compte de l'impossibilité à réaliser notre projet.

En effet, au vu de notre budget, l'achat d'un seul des quatre moteurs nécessaire à l'atteinte des chiffres que nous avions avancés était déjà impossible. Nous avons donc totalement changé d'objectif et avons récupéré du matériel déjà présent à Polytech, à savoir quatre moteurs et leur ESC. Nous avons pris le problème à l'envers et avons réfléchi à ce que nous pouvions réaliser avec le budget et le matériel à disposition.

C'est de cette manière que nous avons eu l'idée d'un drone "loisir", effaçant ainsi la question de la charge.

==Bibliographie et webographie==

===Arducopter===

https://www.digi.com/resources/documentation/digidocs/PDFs/90000976.pdf
http://jeromeabel.net/wiki/xbee/xbee-arduino.pdf
https://www.digi.com/resources/documentation/digidocs/pdfs/90001942-13.pdf
https://www.arduino.cc/en/Reference/Servo

* Manuel d'utilisation
http://ardupilot.org/copter/index.html

* Tutoriels vidéos
Première installation et setup : https://www.youtube.com/watch?v=30cCs4aHdB0&t=754s
Alimentation de l'Ardupilot : https://www.youtube.com/watch?v=TS4OWAcfAQY&t=270s
Calibration des ESC : https://youtu.be/gYoknRObfOg

=Préparation du projet=

==Cahier des charges du groupe==

'''Diagramme bête à cornes'''

Le diagramme bête à cornes nous permet de faire une analyse fonctionnelle du besoin. Notre drone permet à utilisateur de découvrir l'aéronautique à travers une activité ludique à l'aide d'une télécommande.

[[Fichier:Bete_a_cornes.png | center]]

'''Diagramme en pieuvre'''

Le diagramme en pieuvre permet quant à lui de répertorier toutes les fonctions (principales et de service) et d'analyser l'importance des besoins de notre projet

[[Fichier:pieuvredrone.png | center]]

'''Tableau de fonctions'''

Le tableau ci-dessous liste les fonctions principales (FP) et les fonctions contraintes (FC), dans l'orde d'importance, les accompagnant d'une petite description.

[[Fichier:tableau_fonctions.jpeg | 500px | center]]

==Cahier des charges des équipes==
===Equipe 1 : Gestion de la commande (Evan Gury et Richard Simonin)===

L'objectif de cette partie, est de créer une télécommande ainsi que le récepteur. Nous devons lire les valeurs des potentiomètres, créer des trames, envoyer les trames et analyser les trames reçus. Notre système doit être performant en matière de vitesse ainsi qu'en précision.

===Equipe 2 : Contrôleur de vol (Maxime Claudel et Lukas Fauchois)===

L'objectif de l'équipe est d'utiliser une carte de contrôle pouvant être liée à un logiciel de contrôle de vol. Etant donné notre projet, la carte doit respecter certaines contraintes : être adaptée à un drone à quatre hélices (quadcopter), fonctionner sur batterie (car positionnée sur le chassis du drone), être déjà programmée et relativement simple d'utilisation. Le logiciel doit quant à lui nous permettre de gérer le vol du drone et de calibrer les commandes.

==Choix techniques : matériel et logiciel==
===Equipe 1===

'''Émetteur'''

Pour la réalisation de l'émetteur, nous avons choisi de travailler avec une Arduino ainsi que '''deux joysticks''' et un '''émetteur Xbee'''. Nous voulons une télécommande petite c'est pourquoi nous avons pris avec une '''Arduino NANO'''. Le drone a besoin de deux joysticks pour être dirigé selon 3 axes.

'''Récepteur'''

Pour la réalisation du récepteur, qui sera situé sur le drone nous avons commencé par utiliser une '''Arduino UNO''' mais nous souhaitons changer pour une NANO afin d'optimiser le poids ainsi que l'espace. Nous avons aussi besoin d'un '''récepteur Xbee''' afin de recevoir les trames.

===Equipe 2===

Nous avons choisi pour notre carte de contrôle un '''Ardupilot 2.8''', son prix est raisonnable (une trentaine d'euros) et nous trouvons beaucoup de tutoriels l'utilisant sur YouTube.

Pour le logiciel, deux choix relativement similaires s'offraient à nous : Mission Planner ou APM Planner. Les deux logiciels ont à peu près la même interface et permettent tous les deux d'effectuer les mêmes étapes de calibrage de l'Ardupilot et des commandes avant le premier vol.

Nous avons d'abord commencé sur Mission Planner mais des problèmes de mises à jour du firmware de l'Ardupilot nous ont empêché de calibrer les '''ESC du drone'''. Nous sommes donc ensuite passés sur '''APM Planner''' car il permet d'éviter ce problème de mises à jour.

===Bilan===

[[Fichier:materieldrone.jpg|right|thumb|Matériel nécessaire à la conception]]

* '''Matériel''' :
**2 joysticks
**Emetteur Xbee
**Récepteur Xbee
**Arduino NANO
**Arduino UNO
**Ardupilot 2.8
**Câblage

* '''Logiciels''' :
**Arduino
**Mission Planner
**APM Planner 2.0

==Liste des tâches à effectuer==
===Equipe 1===

Pour pouvoir réaliser la partie gestion de la commande, nous devons réaliser les tâches suivantes
* Analyse du projet
* Découverte Xbee
* Prise en main Xbee
* Envoi de trames
* Réception de trames
* Optimisation de la programmation
* Test sur maquette
* Réalisation du PCB
* Mise en œuvre sur notre drone

===Equipe 2===

Pour pouvoir réaliser la partie contrôleur de vol, nous devons réaliser les tâches suivantes
* Analyse du projet
* Choix d'une carte de contrôle
* Documentation, recherche d'un software
* Calibration de la carte
* Réalisation des branchements
* Mise en application sur la maquette
* Mise en relation avec la partie commande

==Calendrier prévisionnel==
Nous avons décidé de réaliser un diagramme de GANTT pour chacun des calendriers prévisionnels (un par équipe). Sur chaque tâche, nous avions prévu un temps de travail en bleu dans les diagrammes et le temps réel consacré en jaune.
===Equipe 1 : Calendrier prévisionnel pour la gestion de la commande===

[[Fichier:equipe1cal.jpg|500px|center|"Calendrier de l'Equipe 1"]]

===Equipe 2 : Calendrier prévisionnel pour le contrôleur de vol===

[[Fichier:equipe2cal.jpg|500px|center|"Calendrier de l'Equipe 2"]]

=Réalisation du Projet=

==Projet S6==

===Semaine 5 et 6===

Avant de scinder le groupe en deux équipes, nous avons passés les deux premières séances à évaluer les besoins de conception de notre projet pour pouvoir ensuite réaliser un cahier des charges et établir un calendrier prévisionnel des tâches à effectuer.

===Semaine 7===

[[Fichier:xbeedrone.jpg|200px|thumb|Xbee]]

'''Equipe 1'''

Etant donné que nous avons décidé d'utiliser des modules XBee, nous avons consacrés cette semaine à la documentation, afin de comprendre comment configurer et utiliser ces derniers.

===Semaine 8===

[[Fichier:ardupilot28.jpeg|300px|right|thumb|Ardupilot 2.8]]

'''Equipe 1'''

Sur le principe de la semaine 7, nous nous sommes documentés sur les XBee afin de comprendre comment les configurer et les utiliser.

Pour la configuration, nous avons retenu le logiciel XCTU qui est celui recommandé pour configurer les XBee. Cependant, nous gardons quand même de côté Legacy XCTU qui est l'ancienne version XCTU mais qui reste tout de même viable.

'''Equipe 2'''

Nous avons consacré cette séance de documentation à la recherche d'une carte de contrôle de vol satisfaisant nos exigences. Nous cherchions donc une carte facilement connectable avec un Arduino Uno/Micro. Nous avons opté pour l'Ardupilot 2.8. Il comprend tout le nécessaire pour diriger un drone quadcopter, centrale gyroscopique, accéléromètres, interface de radiocommande.
Nous avons donc commandé l'Ardupilot via le site Alibaba.com (30€) et nous l'avons reçu trois semaines plus tard.

===Semaine 9===

'''Equipe 1'''

Après avoir effectués diverses recherches sur les modules XBee et effectué de nombreux tests (XCTU, legacy XCTU), nous avons abandonné l'utilisation du logiciel XCTU, étant donné que nous n'utilisons que deux XBee, nous pouvons les initialiser directement dans le programme avec le programme suivant:

[[Fichier:inixbeedrone.png]]

'''Equipe 2'''

En attendant la réception du colis de l'Ardupilot, nous nous sommes documentés sur les différents logiciels de contrôle de vol à notre disposition. L'objectif étant de trouver un logiciel compatible avec l'Ardupilot 2.8 et avec suffisamment de documentation et tutoriels d'utilisation. Les deux logiciels qui sont ressortis le plus dans nos recherches sont Mission Planner et APM Planner 2. Ces deux logiciels sont très similaires au niveau de l'interface et des options de calibration de la carte de vol à laquelle ils sont connectés.

[[Fichier:apm20.png|300px|center]][[Fichier:missionplanner.jpg|300px|center]]

En connectant l'Ardupilot via un câble USB, le logiciel le reconnait et une démarche de calibration peut être entamée : boussole, accéléromètres, radiocommande, ESC.

===Semaine 10===

'''Equipe 1'''

Nous avons travaillé sur la transmission, la réception et le traitement des trames.

Pour la transmission, nous avons mis en place le système suivant:

*On lit la valeur des potentiomètres
*On convertit la valeur en une chaîne de caractère et on lui attribue un indice qui est propre à chaque position des joysticks.
*On envoie la chaîne de caractère par liaison série.

Pour la réception, nous avons mis en place le système suivant:

*On reçoit un tableau de caractère qui contient la consigne entre 0 et 1023 et un indice pour dire à quel joystick et quelle position la consigne correspond.
*On converti le tableau en entier et à l'aide de la fonction map on adapte la consigne pour qu'elle est une valeur entre 0 et 180.
*On transmet la consigne à l'ardupilot.

'''Equipe 2'''

Idem semaine 9.

===Semaine 11===

'''Equipe 1'''

Débogage de la communication entre les modules XBee et l'ardupilot.

En utilisant deux terminaux, la communication était réalisé entre les deux XBee cependant une fois branché sur l'ardupilot nous avons eu des difficultés à traiter les trames, du au fait d'une transmission trop rapide.

De plus nous avons passé un certains temps à vouloir utiliser une arduino micro mais avons finalement décidé de laisser tomber, puisque nous n'avons pas réussi à réceptionner les trames XBee.

'''Equipe 2'''

Idem semaine 9.

===Semaine 12===

'''Equipe 1'''

Optimisation du format des trames et réglage de la vitesse de transmission.

Passage d'une Arduino UNO à une Arduino Nano pour l'envoie des trames dans l'optique de réaliser un PCB pour la commande.

'''Equipe 2'''

A ce stade du projet nous ne pouvions qu'expérimenter les calibrations de la boussole et des accéléromètres de l'Ardupilot car la partie commande n'était pas terminée.

La calibration de la boussole s'effectue en bougeant l'Ardupilot selon tous ces axes pendant une période de temps donnée jusqu'à ce que les informations nécessaires soient récoltées.
La calibration des accéléromètres s'effectue en positionnant l'Ardupilot dans des positions définies (sur le côté gauche, sur la face avant, etc.). (cliquer sur l'image ci-dessous pour lancer le GIF)

[[Fichier:compasscalib.gif|300px|center]][[Fichier:compasscalib.png|300px|center]]

===Semaine 13===

'''Equipe 1'''

Réglage des trames pour la commande du prototype.

Nous avons rencontré quelques problème de sensibilité au niveau des joysticks et du traitement du signal de commande transmis à l'ardupilot.

En effet, ayant trouvé très peu de documentation sur l'ardupilot, nous avons eu du mal à générer les bons signaux de commande.

'''Equipe 2'''

Nous nous sommes ensuite consacrés à la partie alimentation de l'Ardupilot et du drone. En se documentant sur le site servant de manuel d'utilisation d'Ardupilot et des logiciels Mission Planner et APM Planner 2, nous avons trouvé que l'Ardupilot pouvait être alimenté via les ESC.
Une batterie LiPo alimente les ESC qui elles-mêmes alimentent l'Ardupilot via les broches Output. L'Ardupilot alimente ensuite l'Arduino qui réceptionne les trames reçues par le récepteur Xbee. Sur les sorties (Output) de l'Ardupilot sont aussi branchés les fils permettant la réception du signal envoyé aux moteurs.
Ainsi, tous les composants nécessaires au drone sont alimentés.

===Semaine 14===

'''Equipe 1'''

Conception du PCB pour la commande en essayant de limiter le plus possible les vias.

[[Fichier:pcbdrone.png|400px|PCB]]

Vérification de l'envoie des trames à l'aide de l'ordinateur et test de réception sur l'Ardupilot.

'''Equipe 2'''

Branchements comme indiqués à la semaine précédente, alimentation et tests de bon fonctionnement des moteurs, Ardupilot et Arduino.

[[Fichier:branchementesc.jpg|300px]][[Fichier:branchementardu.jpg|300px]]

===Semaine 15===

'''Equipe 1'''

Fabrication de la manette

[[Fichier:manettedrone.jpg|400px|PCB]]

Modification de l'envoie des trames. Tests de transmission.
Implémentation du programme sur le prototype.

Les deux équipes ont passé la semaine à réunir leur travail, nous avons ainsi tous pu réaliser de nombreux tests du prototype, avec réussite, hormis un léger accident qui à entraîné la destruction de deux hélices.

'''Equipe 2'''

A ce stade, la commande étant terminée et nous avons pu nous lier à l'équipe 1 pour mettre en relation la télécommande et l'Ardupilot. Après avoir utilisé Mission Planner pendant plusieurs semaines, un problème de mise-à-jour du software de l'Ardupilot nous empêchait toujours d'effectuer la calibration de la radiocommande. Nous sommes donc passés sur APM Planner 2 et la mise-à-jour n'était plus demandée, nous avons donc enfin pu terminer l'intégralité de la phase de calibration. Comme expliqué ci-dessus, nous avons effectué de nombreux tests pour atteindre notre objectif.

===Documents Rendus===

Rapport : [[fichier:rapport_groupe_4.pdf]]

==Projet S7==

===De nouveaux objectifs===

Durant le semestre 6, nous avons réussi à concevoir un drone volant fonctionnel régulé à l'aide d'une carte de contrôle OpenSource '''Ardupilot 2.8'''. Concernant la commande, nous avions fait le choix d'utiliser une carte communication Xbee ainsi qu'une Arduino NANO et des joysticks.

Cette année, nous avons décidé de développer plus amplement notre projet et de pratiquement repartir du point de départ. En effet, nos objectifs cette année sont :
*'''d'utiliser de nouveaux composants dont nous connaissons les propriétés (moteurs, ESCs, etc)'''
*'''d'utiliser une télécommande de modélisme ainsi qu'un récepteur adapté à des portées plus élevées que celles que permettait l'Xbee'''
*'''de concevoir notre propre contrôleur de vol'''
*'''Bonus''' : d'intégrer une régulation GPS et un mode automatique en cas de perte de signal

===Reprise du cahier des charges===

'''Equipe 1 : Gestion de la commande et initialisation (Richard Simonin & Lukas Fauchois)'''

L'objectif de la nouvelle gestion de la commande est d'utiliser une télécommande de modélisme capable de transmettre les différentes données nécessaires (Throttle, Yaw, Pitch) à un récepteur relié à une Arduino UNO, ce qui nous permettra d'être performant en terme de vitesse et de précision. De plus, cette partie de la conception consiste également à calibrer les quatre ESCs que nous utilisons.

'''Equipe 2 : Contrôleur de vol (Evan Gury & Maxime Claudel)

A compléter

===Nouveaux choix techniques===

'''Equipe 1 :'''

Pour réaliser la commande du drone, nous avons décidé d'utiliser une télécommande [https://fr.banggood.com/Flysky-FS-i6X-2_4GHz-10CH-AFHDS-2A-RC-Transmitter-With-X6B-i-BUS-Receiver-p-1090406.html?rmmds=myorder&ID=42482530817&cur_warehouse=CN '''Flysky FS-I6X'''] accompagnée de son récepteur '''FS-X6B''' qui possède une portée assez élevée pour la réalisation de notre projet. Ce récepteur sera alors relié à une carte '''Arduino UNO''' (qui servira également au contrôleur de vol).

'''Equipe 2 :'''

Concernant la réalisation du contrôleur de vol, nous choisissons d'utiliser une centrale inertielle [https://fr.banggood.com/3pcs-6DOF-MPU-6050-3-Axis-Gyro-With-Accelerometer-Sensor-Controller-Module-For-Arduino-p-1430733.html?rmmds=search&cur_warehouse=CN '''MPU6050'''] possédant un accéléromètre 3 axes ainsi qu'un gyroscope 3 axes, ce qui convient parfaitement à l'utilisation que l'on veut en faire. De plus, c'est une centrale qui est documentée et à coût raisonnable, elle dispose de son propre processeur, ce qui réduit considérablement la quantité de calculs à effectuer par notre micro-contrôleur. Nous relierons également cette centrale inertielle à la carte '''Arduino UNO'''.

'''Conception générale du drone :'''

Comme évoqué précédemment, pour le coeur d'une drone, nous utiliserons une carte '''Arduino UNO''' qui possède un nombre suffisant de ports d'interruptions, de ports PWM et d'une puissance de calcul suffisante pour traiter toutes les informations des différents capteurs.

Nous avons également décidé de fabriquer notre propre chassis basé sur le design du précédent et d'utiliser de nouveaux ESCs dédiés spécialement au drone volant ([https://fr.banggood.com/EMAX-BLHeli-Series-6A-12A-20A-30A-ESC-p-963634.html?rmmds=search&ID=45170&cur_warehouse=CN '''EMAX BLHELI SERIES 20A''']). Nous avons également choisi de nouveaux moteurs brushless : les [https://fr.banggood.com/1000KV-Brushless-Motor-3_17mm-Shaft-Electric-Motor-p-1102054.html?rmmds=search&cur_warehouse=CN '''A2212/13T'''].

'''Bilan'''
*'''Matériel'''
**Chassis
**4 ESCs EMAX BLHELI 20A
**4 moteurs A2212/13T
**Batterie LI-PO 11,1V - 2700mAh
**Arduino UNO
**Télécommande Flysky FS-I6X
**Récepteur FS-X6B
**Centrale inertielle MPU6050
*'''Logiciel'''
**Arduino

'''Note''' : grâce au travail d'Evan Gury, nous avons pu acquérir tout ce matériel et il a pu concevoir le chassis avant même le commencement du semestre 7, ce qui nous a permis de nous avancer sur le travail à réaliser.

===Liste des tâches à effectuer===
'''Equipe 1'''

Pour pouvoir réaliser la nouvelle gestion de la commande et l'initialisation, nous devons réaliser les tâches suivantes
* Découverte télécommande Flysky FS-I6X et son récepteur FS-X6B
* Configurer la télécommande
* Lecture des joysticks par Arduino
* Initialiser les extremums des joysticks
* Optimisation de la programmation
* Test de transmission sur les ESCs
* Mise en œuvre sur notre drone

'''Equipe 2'''

Pour pouvoir réaliser le contrôleur de vol, nous devons réaliser les tâches suivantes
* Découverte du MPU6050
* Configuration des registres du MPU6050
* Récupération des mesures angulaires en °/s
* Intégration des mesures pour récupérer les positions en degrés
* Calcul de la consigne
* Calcul de l'erreur
* Calcul du correcteur
* Application de la correction aux ESCs

===Semaine 45===

[[Fichier: flyskyFSI6X.jpg|200px|right|thumb|Flysky FS-I6X et FS-X6B]]

'''Equipe 1 :'''

*Lors de la première semaine, nous avons fait le choix d'utiliser un mode de transmission existant et d'abandonner la télécommande conçue au semestre précédent. Nous avons alors choisi d'utiliser la télécommande de modélisme Flysky FS-I6X et son récepteur FS-X6B.

*Nous avons dû dans un premier temps configurer la télécommande et comprendre comment transmettre les informations des deux joysticks.

'''Equipe 2 :'''

*Nous avons passé la première séance à nous documenter le plus possible sur le MPU6050 qui est le cœur de notre contrôleur de vol.
*Nous avons ainsi pu trouver de nombreux documents concernant la configuration des différents registre du MPU6050, de manière à avoir une utilisation correspondant au mieux à un drone volant.

===Semaine 46===

'''Equipe 1 :'''

*Pour la réception des informations et le traitement des données, nous avons branché le récepteur sur une carte Arduino. Deux choix s'offraient à nous, utiliser des broches PWM ou une broche PPM. Le PPM a pour avantage d'utiliser un unique câble, tous les canaux sont transmis à la suite contrairement au PWM, un câble est nécessaire à chaque canal. L'Arduino UNO ne nous limitant pas pour l'utilisation de 1 broche ou 4 broches, nous avons décider d'utiliser le PWM.

*Nous avons programmé notre Arduino UNO afin de récupérer les informations sur nos canaux.

'''Equipe 2 :'''

*Nous avons passé tout notre temps à tenter de récuperer les coordonnées YAW-PITCH-ROLL du mpu6050 et ce de la manière la plus rapide possible afin d'optimiser au mieux la régulation.

===Semaine 47===

'''Equipe 1 :'''

*Nous avons finalisé la conception de notre drone, nous avons finalisé le câblage et ainsi pu faire des tests sur le prototype.

*Pour commander les moteurs, les ESCs sont nécessaires. L'utilisation est plutôt simple car ils s'utilisent comme des servomoteurs, ainsi la bibliothèque ''servo.h'' d'Arduino nous a permis de les initialiser et donc de faire tourner les moteurs.

*Le projet avance vite et nous avons beaucoup d'ambition et d'idées pour la suite.

'''Equipe 2 :'''

*Même si le MPU6050 est très bien documenté nous avons passé de nombreuses heures a tenter de récupérer les coordonnées YAW, PITCH et ROLL pour notre drone mais sans succès. Le principal problème était que deux des trois MPUs que nous avions commandés sur Banggood ne marchaient pas correctement.
*Au final nous arrivons désormais à récupérer ces informations suffisamment vite pour pouvoir espérer effectuer une correction correcte.

===Semaine 48===

'''Equipe 1 :'''

*Correction du calibrage des ESCs à travers l'Arduino.
*Début de la commande des moteurs grâce à notre télécommande Flysky. Cependant, nous avons rencontré quelques soucis dans notre programme, il nous faut alors revoir ce code Arduino pour réussir cette étape.

'''Equipe 2 :'''

*Mise en commun de la partie programmation Arduino avec l'équipe 1.
*Première prise de renseignements sur les GPS dans l'optique d'en utiliser un pour commander le drone s'il nous reste du temps en fin de projet.

===Documents Rendus===

Soutenance : [[fichier:soutenance_S7_P4.pdf]]

==Projet S8==

[[Fichier: pcb_drone_p4.png|500px|right|thumb|PCB réalisé sur Altium]]

===Liste des tâches à effectuer===
'''Equipe 1'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Conception d'un PCB (pour l'ensemble du système)
*Optimiser la distribution de la puissance (esthétiquement)
*Finition de la partie communication envoie/reception de trame validé

'''Equipe 2'''

Après analyse du travail réalisé au S7, nous devons désormais réaliser les tâches suivantes :
*Tests et réglages de la régulation PID
*Implémenter un système de guidage GPS (à voir avec le temps que l'on dispose)

===Semaine 3===
'''Equipe 1 :'''

*Réflexion et réalisation du PCB sur ''Altium Designer''
*Mise en relation des différentes variables de notre programme avec celui de l'équipe 2
*Choix et commande d'un distributeur de puissance (PDB) pour câbler plus proprement les ESCs

'''Equipe 2 :'''

*Mise en relation du programme avec l'équipe 1
*Finalisation du programme total, y compris la partie régulation PID

===Semaine 4===

[[Fichier: testregubar.mp4|350px|right|thumb|Essai de calibration sur deux axes avec le premier dispositif (drone fixé par le haut et le bas grâce à des câbles)]]
[[Fichier: calibration-un-axe.mp4|250px|right|thumb|Essai de calibration sur un axe avec le deuxième dispositif]]

'''Equipe 1 :'''

* Finition du PCB sur altium et création du même PCB sur Fritzing.
* Reprise de l'ancienne maquette pour effectuer la régulation

'''Equipe 2 :'''

*Réalisation d'un programme Arduino permettant de lire la valeur de 3 potentiomètres afin de pouvoir régler les coefficients du PID.

===Semaine 5===

'''Equipe 1 :'''

*Impression du PCB et branchement sur la maquette (2)
*Début des tests de régulation en mode suspendu (sans grande réussite pour le moment)

'''Equipe 2 :'''

*Tests de régulation en mode suspendu (avec l'équipe 1)
*Début de conception d'un PCB permettant de fixer l'ensemble des composants (les nombreux fils commencent à devenir trop gênants pour les tests)

===Semaine 6===

'''Equipe 1 :'''

*Modification du programme afin de détecter l'arrêt du microcontrôleur Atemega 328P.
* Resolution de l'erreur lié à la carte et au programme, suspicion de l'ISR mais le problème était du à une division par 0 (Probleme de maquette avec le MPU 6050).

'''Equipe 2 :'''

*Mise en place de support en PVC (voir photo) afin de ne laisser au drone qu'un seul degrés de liberté et ainsi permettre de le réguler plus facilement, suite à l'échec de la régulation suspendue.
*Problème sur un moteur ou un ESC de notre nouveau drone, un des moteurs ne tourne pas lorsque nous montons l'hélice dessus.
*Problème sur un moteur du nouveau drone qui se coupe totalement à une consigne bien précise et redémarre ensuite.

[[Fichier: testesc.jpg|400px|right|thumb|Test des valeurs de courant reçues par les ESC]]
===Semaine 7 : coupure pédagogique===

===Semaine 8===

'''Equipe 1 & 2 :'''

* Lors de cette semaine, nous nous sommes penchés sur les problèmes physiques rencontrés précédemment.
Pour cela nous avons utilisé un oscilloscope équipé d'une sonde afin de relever les valeurs clés de tension et de courant.
Nous utilisons un programme qui envoie la même consigne aux 4 moteurs afin de comparer les vitesses de rotation.
Nous nous sommes aperçu que sur la maquette n°1, les 4 moteurs fonctionnent correctement mais qu'un ESC (Contrôleur moteur) est défaillant.
Sur la maquette n°2, un moteur et un ESC sont obsolètes.
Nous avons essayé de mixer les deux maquettes pour faire fonctionner un drone.

===Semaine 9===

'''Equipe 1 & 2 :'''

* Commande et attente des ESC pour finaliser la régulation.
* Création d'un boitier PID pour simplifier la régulation. Ce boiter va nous permettre de modifier facilement les valeurs des coefficients de notre PID numérique.

===Semaine 10===

Re-structuration du projet suite aux événements du COVID-19:

* Régulation sur deux ESCs : Lukas (dispose de tout le matériel)
* Création application mobile, communication entre téléphone et le drone. (Richard et Evan)
* Simuler le drone en C. (Maxime)

===Semaine 11===

'''Regulation avec 2 ESC :'''

*

'''Application mobile :'''

* Debut de l'apprentissage de la creation d'une application Android à l'aide de ANDROID STUDIO

'''modélisation drone en C :'''

*
*

===Semaine 12===

*Réalisation d'une application android, sous Android Studio, permettant de simuler une commande afin de piloter le drone.
*Les JoyStick envoient une consigne variant de 1000 à 2000 pour le throttle et les axes Yaw, Pitch, Roll, valeurs attendues par le drone afin de générer la PWM pour les ESCs.
*L'interface de l'application est terminée, il reste désormais a programmer la partie concernant l'ESP32.

[[Fichier: applicationAndroid.mp4|500px|left|thumb|Presentation de l'application]]

===Semaine 13===

'''Equipe 1 :'''

*
*

'''Equipe 2 :'''

*
*

===Semaine 14 et 15 : coupure pédagogique===

===Semaine 16===

'''Equipe 1 :'''

*
*

'''Equipe 2 :'''

*
*

===Documents Rendus===