Version actuelle datée du 13 mars 2018 à 17:47

Introduction

Etude du robot

Phase de l'inventaire matériel

Dès la première séance nous avons vu que les batteries du robot étaient hors d'usage. Nous avons donc noté les références et demandé à Polytech'Lille de passer la commande de nouvelles batteries, afin de ne pas être bloqué par le problème de l'alimentation trop longtemps. Le robot nécessite également de nombreuses réparations, vu le temps d'inactivité de celui-ci, pour qu'il soit de nouveau utilisable. Nous allons enlever les capteurs qui sont jugés inutiles à la réalisation de notre projet, et recâbler les capteurs essentiels.

Résumé du matériel à acheter:

- 2 batteries 12V et 24Ah.

- Shield Sensor v4 pour Arduino.

- Connecteurs de type FUTABA.

- Gaine thermorétractable.

- Boussole.

- Gaine à câbles.

Résumé des changements à envisager :

- Nettoyage total du robot.

- Câblage des capteurs avec des câbles fins.

- Réparation des supports des capteurs endommagés.

Robot Centaure

L'inventaire du travail à réaliser, constaté à la première séance

- Réparation de certains supports de capteurs.

- Recâblage des capteurs et actionneurs.

- Faire un bilan des éléments à acheter pour avoir une solution de câblage propre.

- Choisir et programmer un microcontrôleur permettant d'être évolutif (choix d'un Arduino Mega).

- Trouver une solution viable et propre de connectique sur l'Arduino.

intérieur du robot Centaure

Bilan des séances

1er et 2ème séances

La Kinect

Nous avons dans un premier temps pris en main la bibliothèque (Freenect) permettant de gérer la Kinect. Nous avons commencé par analyser et modifier un exemple de programme livré avec la bibliothèque (glview.c).

Nous avons toutefois relevé un problème inhérent à la Kinect : la projection des infrarouges projette des ombres sur l'arrière plan. Ceci risque de poser des problèmes pour l'algorithme de décision de la trajectoire. Un problème similaire est observé sur les surfaces vitrées.

Notre première tâche a donc été de développer un premier algorithme permettant de récupérer ces zones d'ombres.

Nous avons pu ensuite jeter les premières bases de l’algorithme de décision de la trajectoire.

Le robot

Nous avons, lors de la première séance, examiné le robot pour comprendre son fonctionnement. A partir de là, nous avons remarqué que le changement des batteries était notre priorité, vu l'état dans lequel celles-ci se trouvaient. Nous avons donc tout démonté pour prendre les références et en commander de nouvelles. Lors de la seconde séance, nous avons listé les éléments à changer pour que le robot soit fonctionnel. Nous devons donc :

- Refaire le câblage des capteurs

- Nous avons choisi un Arduino pour réaliser la liaison Capteur / Actionneur ainsi que la liaison avec le PC. Le choix d'un Arduino Méga est la solution qui semble la plus adaptée, afin de rendre le robot évolutif. Sinon le nombre d'entrées / sorties risque d'être un élément bloquant, pour l'évolution du projet.

Nous avons aussi réfléchi à la nouvelle connectique, qui sera de type prise "JR" utilisée dans le modélisme. Chaque prise correspondra à un capteur. Pour ce qui est de l'Arduino, nous voulons lui ajouter un Shield "Sensor" qui permet une gestion de la connectique des capteurs beaucoup plus simple. Il en existe 2 modèles, un limité à 300mA pour ce qui est de l'alimentation (ce qui peut être suffisant pour les capteurs) et un avec une alimentation externe permettant l'ajout de puissance. N'ayant pas besoin de puissance pour l'envoi ou la réception de signal, nous choisirons la première version.

Connectique choisie

Shield Arduino facilitant la connectique

3ème et 4ème séances

La Kinect

Nous avons finis l'algorithme permettant de "reconstruire" les zones d'ombres.

L'algorithme que nous avons confectionné est relativement simple : il balaye l'image ligne par ligne, puis à chaque fois qu'il détecte une ombre il se procure la valeur de la profondeur à gauche et à droite de l'ombre. La valeur la plus lointaine sera utilisée pour remplir l'ombre, ce qui correspond à une bonne approximation.

Voici un comparatif sans et avec l’algorithme de récupération des ombres :

Sans récupération des ombres. Les 3 lignes rouges délimitent les zones en dehors du champs de considération du robot.

Avec récupération des ombres

Nous pouvons constater que l'image ainsi obtenue n'est pas très esthétique, mais cela permettra à l’algorithme de décision de la trajectoire de travailler sur des valeurs de profondeurs quasiment correctes. De plus, la simplicité de l'algorithme permettra de ne pas utiliser trop de ressource processeur.

Nous avons également quasiment finalisé l'algorithme de décision de la trajectoire. Tout d'abord, il faut savoir que l'algorithme ne travaille que sur une certaine zone de l'image. En effet un objet situé trop à gauche (ou trop en haut ou à droite) ne gênera pas le robot. Du coup seul une partie du champ de vision de la Kinect est utilisée. Pour régler ces constantes nous avons affiché 3 lignes délimitant l'espace de considération du robot.

L’algorithme en lui-même consiste à calculer la moyenne des profondeurs de la partie gauche et droite de l'image. Ensuite, nous calculons la différence entre ces 2 valeurs. Avec cette différence nous pouvons distinguer 3 cas :

• différence < -C => tourner à gauche
• -C <= différence <= C => continuer tout droit
• différence < -C => tourner à droite

(avec C une constante)

Par ailleurs, la décision de la trajectoire est prioritairement influencée par la présence d'objets très proches :

• Si un objet très proche est détecté à gauche et à droite le robot s'arrêtera
• Si un objet très proche est détecté à gauche le robot ira à droite dans tout les cas
• Si un objet très proche est détecté à droite le robot ira à gauche dans tout les cas

Le robot

La 3ème séance avait un but purement informatif et explicatif pour nous. Nous avons pu rencontrer notre tuteur pour ce projet, Mr. LITWAK, afin de relater nos premières impressions, notre envie commune de voir le Centaure se mouvoir dans un premier temps, et remplir le cahier des charges qu'il nous est demandé de remplir par la suite. Nous avons évoqué avec lui le choix que nous avions décidé de prendre pour l'évolution de notre projet (solution Shield + Arduino Mega), ainsi que notre volonté de rendre le tout le plus esthétique possible (utilisation de nappes envisagée mais pas encore confirmée). Nous définissons ensemble un plan de route :

1) Dégager les éléments inutiles.

2) Restaurer l'alimentation et refaire les câblages nécessaires.

3) Être capable de contrôler la direction de notre robot (asservissement en vitesse et en position nécessaires).

4) Pouvoir joindre le côté commande et le côté Kinect.

Une boîte à outils nous est fournie pour nos travaux sur le Centaure, ainsi que toute la documentation nécessaire au bon déroulement de notre projet (la documentation sur les capteurs SHARP avant et arrière en particulier).

La 4ème séance consiste à vider le Centaure de ses composants, dresser le bilan des éléments utiles et de ceux dont l'utilisation n'est pas envisagée.

Au final, lors de cette semaine de projet, nous avons défini notre plan d'action, commencé le gros oeuvre sur le Centaure, puis noté les éléments de câblage à utiliser lorsque la phase de nettoyage sera terminée. Nous attendons pour la reprise l'arrivée des 2 batteries nécessaires à l'alimentation du robot, le Shield sensor ainsi que les connecteurs FUTABA/JR (les deux étant compatibles).

Nous avons posé les bases du système et imaginé l'architecture finale du système, représentée par la figure ci-dessous, mais omettant certaines parties servants de liaisons.

Schéma simplifié du système

5ème, 6ème et 7ème séances

La Kinect

L'algorithme de décision de la trajectoire par la Kinect étant fait, nous nous sommes penchés sur la capacité des PC embarqués disponibles à pouvoir exécuter le code de la Kinect. Les premiers essais se sont révélés infructueux, les 2 PC embarquants pour exécuter le code.

Nous nous sommes alors lancés dans une phase d'optimisation importante du code de gestion de la Kinect. Voici la liste des optimisations apportées :

• Suppression des fonctionalités non utilisé, tel que l'accéléromètre.
• Optimisation de Freenect, en configurant la capture de la vidéo et de la profondeur en qualité "low"
• Compilation de gcc optimisé avec l'option -O3

Cependant, malgré toutes ces optimisations, le PC embarqué utilisé n'a pas réussis à exécuter le code. En effet, la totalité des paquets transitant sur USB sont perdus.

Nous avons alors entrepris de monter un nouvel ordinateur embarqué. Plus puissant tout en restant basse consommation. Voici la liste des composants utilisés :

• Carte mère : ASRock H61M-ITX MAJ du BIOS obligatoire [1]
• Processeur : Intel Core i3­3220T (2.8 GHz, 35W)
• Disque dur : Samsung SSD 840 120 Go
• Boîtier CUBE mini­ITX ­ Rouge
• Nous avons rajouté une alimentation PICOPSU permettant une alimentation direct en 12V.

Le Robot

Nous avons reçu, pendant les vacances, les éléments que nous avions commandé, et qui étaient nécessaires au bon déroulement de notre projet. Ainsi, le Shield Sensor pour Arduino, ainsi que les connecteurs, nous sont parvenus. Nous avons également reçu les deux batteries (12V, 24Ah), pour venir en remplacement des anciennes, qui étaient totalement Hors-Service. Ces séances de la semaine nous ont permis de pouvoir (re)faire les câblages de tous nos capteurs (4 capteurs avant SHARP 2Y3A003 - portée de 40 à 300 cm ; 2 capteurs arrières SHARP 2Y0A02 - portée de 20 à 150 cm) avec les nappes fournies, de manière à les brancher directement sur le Shield. Nous avons également installé les nouvelles batteries, et ainsi remettre en état de marche l'alimentation du robot (l'écran du Centaure s'allume). Grâce à un mini-programme, nous avons pu vérifier le bon état des capteurs. Ainsi, 3 des capteurs avant et 1 capteur arrière répondent convenablement, les deux autres capteurs normalement utilisés étant HS. Un autre programme a été mis au point sur l'Arduino, demandant une simple marche avant au Centaure. Nous vérifierons son fonctionnement la semaine prochaine, tout en nous penchant également sur le rétablissement de l'arrêt d'urgence et du coupe-batterie, primordiaux avant de faire se mouvoir le robot.

Connecteurs des capteurs IR

8ème, 9ème et 10ème séances

La Kinect

INCORPORATION DE LA GESTION DE LA KINECT AU PROJET EXISTANT

La gestion de la Kinect est opérationnelle. Cependant il nous a fallu implanter cette gestion au reste du programme existant. Le code qui nous a été légué ne compilait plus. Il nous a fallu alors effectuer un important travail

Le Robot

La commande de deux capteurs AV, de même référence que ceux déjà utilisés, ainsi que 4 relais, est lancée. Pour la partie pratique, le variateur nous donne du fil à retordre, dans la mesure où toutes les sécurités de ce dernier ne sont pas indiquées dans la documentation technique. Nous nous sommes donc renseignés auprès de nos tuteurs, et nous nous sommes également référencés aux travaux antérieurs sur le Centaure. Le variateur nécessite une tension d'excitation de 60mV pour le faire démarrer. Le fonctionnement du variateur repose sur des interrupteurs. Ceux-ci doivent être dans des état complémentaires afin d'assurer la marche avant ou la marche arrière. Enfin, les moteurs étant commandés en tension, aucun retour à une tension nulle n'est permis, auquel cas la sécurité sera réactivée. L'implantation d'un code Arduino pour une marche avant, arrière, ainsi qu'un arrêt, donne des résultats probants sur l'une des roues. La connexion du second variateur réalisée, ainsi que la conception d'un code permettant le virage à gauche, puis à droite, nous permettent de faire "vadrouiller" le Centaure - définitivement vivant - dans le Hall de l'école, via l'interface Arduino sur un ordinateur portable (i: initialisation, a: marche avant, s: arrêt, r: marche arrière, v: virage gauche, t: virage droite).

Test sur plaque LABTEC avec relay, les transistors laissant passer un faible courant les variateurs ne fonctionnent pas. Nous utiliserons donc des relais.

Conception de la carte, elle fut envisagée et concu mais une carte préfaite pour un prix modique a été trouvée. Ce qui rend le montage bien plus propre.

Schéma de principe de la carte de commande des variateurs

PCB de la carte de commande

Vu 3D

11ème séances

La Kinect

Afin de moderniser la commande du robot via le web, nous avons revu certaines bases. Nous avons restructuré en grande partie le fichier .c gérant le serveur web afin de l'optimiser. Nous avons également supprimer la fonctionnalité qui empêcher 2 utilisateurs à se connecter à l'interface de commande simultanément, en effet elle ne fonctionnait malheureusement pas. Enfin, nous envoyons à présent les commandes au robot en faisant appel à l'Ajax, ceci permet d'améliorer l'expérience utilisateur.

Ce lot de modification s'incorpore au site web existant.

Une refonte graphique total du site est à l'étude et sera intégré au projet dans le cas ou ce nouveau site est fonctionnelle.

Le Robot

Test du code de l'Arduino pour voir les fonctions de base.

Manque 1 relais donc pas de marche arrière possible.

Principales fonctions OK

Il faut rajouter un indicateur de niveau de batterie, qui sera conçu de la manière suivante : Relais + Pont diviseur de tension (le relais permet de désactiver le pont, ainsi nous consommons moins).

PCB de la carte du capteur batterie

PCB 3D de la carte du capteur de batterie

  R1 = 62Kohm
  R2 = 15Kohm

Etape importante

Petit récapitulatif à mi-projet:

- Reste a définir les éléments de communication PC <--> Arduino

- Intégrer une gestion progressive de la vitesse dans l'Arduino

- Faire la carte Relais

- Créer la "mini-carte" permettant l'indication du niveau de batterie

12 et 13ème séances

La Kinect

Les 2 séances ont permis de rendre la communication entre la partie "robotique" (arduino) et "informatique" (programme tournant sur un PC) fonctionnelle. La communication et la répartition des tâches entre les 2 parties étant relativement complexe, cela à donné lieu à de nombreuses modifications.

Le Robot

La séance est principalement consacrée à l'établissement d'un cahier des charges fonctionnel, de manière à ce que l'on puisse expliquer le plus clairement possible ce que l'on attend de nous, et ce que nos tuteurs souhaitent voir en fin de projet. C'est une manière de nous plonger dans le monde du travail, où l'on nous fait comprendre que le cahier des charges fonctionnel est un accord entre le maître d'oeuvre et le maître d'ouvrage, et que le non respect de celui-ci peut nuire au maître d'oeuvre. Bien que le cahier des charges sera rendu avec la totalité des éléments demandés pour le projet, voici un petit récapitulatif des fonctions à intégrer au Centaure :

--> Direction automatique du robot par Kinect --> Direction manuelle par infrarouge --> Contrôle via site web (adaptabilité pour support tablette, PC, smartphones)

Suite aux gros écarts de direction entraînés par la roue flottante avant, il a été décidé d'intégrer au centaure un module HMC6352, boussole pour Arduino, qui permettra la correction de trajectoire en cas de grosse déviation (en phase de test, les oscillations de la roue flottante sont difficilement contrôlables, donc nous envisageons de la bloquer, en plus de l'utilisation de la boussole, estimant que la puissance des moteurs est suffisante pour vaincre les frottements entraînés par un tel blocage lors d'un virage).

 'S' signifie port pour prise du Shield
 'G' signifie port de gauche (bouclé avec le port M) pour 1 relais
 'M' signifie port milieu pour 1 relais
 'D' signifie port de droite pour 1 relais

Carte relais des variateurs

14, 15ème et 16ème séances

La Kinect

La partie du programme gérant la télécommande infrarouge a été optimisée et épurée.

De même pour la partie gérant le protocole série. Par ailleurs, à présent le PC n’envoie l'ordre à l'arduino que si et seulement si l'ordre est différent de l'ordre précédent. Ceci permet d'éviter les conflits et de ne pas submerger la liaison série.

Le Robot

Mise en place Boitier Robot

Connexion kinect sur PC, bug de liaison entre PC et arduino

Création alimentation Kinect

Connexion boussole par I2C, mais précision erronée...

Bug programme arduino, comme problème boussole, alors ne s'arrête pas de tourner. Il faut une condition d'arrêt en plus.

+ A chaque nouveau "avancer", faire nivélation de la vitesse !!!!!!!!!!!!!!!!

Boitier rangement

kinect sur le Robot pour test

Commande manuelle

L'objectif est de pouvoir commander le robot par divers moyens. Une partie automatique avec la kinect (cf ci-dessus) est mise en place , mais le cahier des charges demande une partie manuelle où il est possible, grâce à divers moyens, de faire se mouvoir le robot.

Une télécommande infrarouge est dès lors mise dans le programme où il est possible de faire avancer, reculer ou tourner le robot.

Une autre option de commande manuelle est aussi viable, la commande via serveur embarqué. De ce fait, il est possible de contrôler son robot via une tablette android, Iphone/Ipad, smartphone. Le site http://www.lamconcept.fr/CENTAURE/ est fonctionnel et demande des mots de passe afin de se connecter et diriger le robot.

Séances Vacances

Commandes Manuelles

Le programme C prend en compte la Commande Via infra-rouge. La dernière de la commande manuelle réside dans l'interface Php. La connexion par LDAP ne fonctionnant pas, une page de connexion simple a été faite. LOGIN : Centaure2013 MDP:LV2R Les pages PhP seront implantés dans le PC embarqué qui aura apache installé dessus. L'utilisateur se connectera directement sur le PC et sélectionnera l'interface php. Après s'être identifié, l'utilisateur accédera directement à la vidéo de la kinect et aux commandes du robot.

Documents

Sources Arduino : [2]

Sources du programme du PC et de l'interface web : [3]

Application Androïd : [4]

Rapport Partie Robot : [5]

Rapport Partie Informatique : [6]