IMA3/IMA4 2018/2020 P13

De Wiki de Projets IMA
Révision datée du 29 janvier 2020 à 15:22 par Vdubois- (discussion | contributions) (Semaine3 (27/01-02/02))


Vidéo HD

Sommaire


Présentation générale

Description

Sur le marché actuel, on trouve très peu de robots amphibies. En effet, les systèmes de propulsion traditionnellement utilisés ne sont pas adaptés pour fonctionner dans différents environnements. Cependant, de nouvelles techniques voient le jour notamment grâce à l’émergence de la robotique molle (Soft Robotic). Ce nouveau domaine s'inspire fortement de la manière dont les organismes vivants se déplacent et s’adaptent à leur milieu. L'un des objectifs de la robotique déformable est notamment d’accroître la mobilité des systèmes en utilisant des matériaux hautement déformables.

Ce projet consiste donc en la réalisation d'un robot amphibie pouvant se déplacer aussi bien sur la terre ferme qu'en milieu aquatique. Pour ce faire, nous nous inspirons du déplacement de la raie et du serpents. Ces deux animaux se déplacent par ondulation (verticale pour la raie et horizontale pour le serpent). Le robot sera donc munie de deux nageoires ondulantes dont on peut changer l'inclinaison afin de s'adapter a son environnement.

Objectifs

L'objectif est dans un premier temps de concevoir le système de propulsion a l'aide de matériaux déformables. Le mouvement des nageoires sera sinusoïdale contrairement a la raie dont le mouvement serai trop complexe a reproduire étant donne le temps consacré au projet. Le contrôle du robot se fera en boucle fermé donc de manière autonome.

Dans sa globalité, le projet comprend:

-la conception du système de propulsion par ondulation

-la fabrication de l'enveloppe hermétique

-la conception de la carte électronique

-l’intégration des différents capteur nécessaires au fonctionnement autonome

-le développement du programme de navigation (avec reconnaissance du milieu?)

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent

Salamandra robotica II (École polytechnique fédérale de Lausanne)


Salamandra robotica II.jpg Salamandra robotica II2.jpg


Ses concepteurs se sont inspiré de la salamandre pour fabriquer un robot amphibie capable d’évoluer dans l'eau comme sur terre. Cet amphibien utilise deux modes de locomotion différents en fonction du milieu dans lequel il se trouve. Dans l'eau, son corps ondule: l'animal nage alors à la manière d'une anguille. En revanche, il utilise ses pattes pour se mouvoir sur la terre ferme.

Le robot se compose de dix modules articulés pouvant réaliser des mouvements latéraux. Les neuf premiers ont une forme rectangulaire et intègrent des circuits électriques et des microcontrôleurs. Quant au dernier, il ressemble à une palette natatoire. Les modules 3 et 6 sont en plus équipés d'une paire de pattes repliables.

Les mouvements sont donc coordonnés par un ordinateur principal faisant tourner la modélisation du réseau neuronal des salamandres. Une simple commande pouvant être émise à distance suffit pour changer le mode de locomotion du robot. La vitesse de nage comme sa direction sont également gérées par l'ordinateur central.

Analyse du second concurrent

Velox (PLIANT ENERGY SYSTEMS llC) https://www.pliantenergy.com/

Pliant energy robot.jpg Pliant energy robot2.jpg Pliant energy robot3.jpg

Le robot Velox cumule plusieurs modes de locomotion empruntés au monde du vivant. Équipé d’une seule paire d’ailettes latérales souples qui changent de position selon l’environnement, l’engin est capable « de nager comme une raie, de ramper comme un mille-pattes, de jaillir comme un calamar et de glisser comme un serpent ».

Le secret de ses déplacements réside dans ses appendices ondulatoires. Lorsqu’ils sont alignés à l’horizontale, la machine peut se déplacer sous l’eau. En mode tout-terrain, ses ailettes se positionnent perpendiculairement au sol pour ramper, par exemple, sur des sables mouvants. Ses pédicules caoutchouteux lui permettent également de patiner sur la glace et de slalomer entre les obstacles sur la neige.

Ce robot n’est pour l’instant qu’un prototype mais intéresserait cependant le bureau de la recherche navale américaine pour ravitailler en armes et en matériel des troupes lors d’un débarquement.

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

Le robot est capable de détecter la nature de son milieu et d'adapter l'inclinaison de ses nageoires en fonction. Il peut donc évoluer dans des milieux complexes et variés tel que des zones sinistrées, inondées, marécageuses, sableuses, aquatiques,... L'avantage qu'il possède, comparé au véhicules traditionnels, est son changement de locomotion rapide en cours de déplacement. En fonction de l'objectif de sa mission, le robot se déplace de manière autonome jusqu’à atteindre sa cible ou peut être piloté manuellement par un utilisateur. Du fait de ses propriétés, il peut servir dans les scénario suivants:

  • Reconnaissance et recherche de survivants suite à un tremblement de terre.
  • Navigation dans des zones marécageuse/sable mouvants.
  • Reconnaissance dans conduite d'eau
  • Exploration de fonds marins (Résistant à l'enchevêtrement dans les plantes ou autres débris aquatiques).

Réponse à la question difficile

Bibliographie et webographie

  • Magazine Pour La Science n 402 p66 "Onduler pour avancer"

Préparation du projet

Cahier des charges du groupe

Cahier des charges des équipes

Equipe 1

Damien Tillaux & Vincent Dubois

  • Propulsion:

Le robot est doté de deux nageoires artificielles ondulantes de chaque côté de son châssis. On utilise des servomoteurs alignés pour donner le mouvement d’ondulation aux pales. Le nombre de servomoteurs est défini en fonction de la longueur de la pale, de l’amplitude des ondulations ainsi que du nombre de points d’appuis au sol souhaités. Concernant ce dernier points, nous avons fixé à 2 le nombre d’appuis au sol de chaque côté du robot afin que le dispositif soit stable. La jonction entre la nageoire et les servomoteurs se fait via une bielle. La nageoire doit être assez déformable pour pouvoir supporter l’ondulation imposée par les servomoteurs et doit être assez rigide pour supporter le points du bobot. De plus, le matériaux utilisé doit avoir une certaine rugosité pour pouvoir adhérer au sol et permettre au robot d’avancer correctement.

La solution moteur+arbre est d’emblée éliminé car trop compliquée a mettre en place étant donne nos faibles connaissances en mécanique. De plus, la consommation en énergie des servomoteurs est bien moindre comparée a un moteur(DC).

  • Chassie:

Le châssis du robot doit pouvoir accueillir les servomoteurs nécessaires à la propulsions ainsi que la carte électronique, le système d’alimentation (batterie) et les différents capteurs inhérents au fonctionnement autonome du robot. Les dimensions du châssis sont fixées notamment par le nombre de servomoteurs utilisés et par la taille des autres composants électronique. Afin de limiter le poids total de la structure nous utilisons l’impression 3D qui permet de fabriquer des objets à la fois creux et résistants. Enfin, l’appareil étant amené à se déplacer dans l'eau, le chassie doit donc être étanche. Étant donnée que le projet porte en premier lieu sur les compétences IMA, l’étanchéité du robot fera l'objet d'une étude secondaire avec l'aide d'étudiants en Conception Mécanique.

  • Contrôle:

Le dispositif a pour but final d'être complètement autonome. Pour cela nous implémentons un algorithme qui permet de reconnaître son milieu et d’adapter son déplacement en fonction. Pour ce faire, le robot doit intégrer des détecteurs d'obstacles ainsi qu’un système permettant la reconnaissance de milieu aquatique. L'appareil doit également être télécommandable pour que l'utilisateur puisse prendre la main sur son déplacement. Nous proposons pour cela d’intégrer une télécommande infrarouge au projet ainsi qu'une caméra.

Equipe 2

Eric Agbodjan

L'avantage de fabriquer sa propre carte électronique est de pouvoir utiliser uniquement les entrées/sorties du microprocesseur dont on a besoin et de ne pas surcharger la carte de fonctions inutiles au projet . De plus, cela nous permet d’adapter la disposition des pins de connexion des servomoteurs et des différents capteurs et donc de gagner énormément de place. La principale contrainte pour cette carte est que le microprocesseur utilisé doit pouvoir générer assez de signaux PWM pour accueillir au moins 10 servomoteurs. De plus, la carte doit pouvoir adapter la tension d’alimentation de la batterie aux différents besoins des composants.

Choix techniques : matériel et logiciel

Equipe 1

  • Servomoteurs:

Nous avons tout d’abord commencé par réfléchir au nombre optimal de servomoteurs pour avoir un appuis stable avec le sol lorsque la pale est à l'horizontale. Etant donné sa forme ondulée, il faut au moins deux points d’appuis de chaque côté pour assurer la stabilité. On en a donc conclu qu’il fallait au moins 5 servomoteurs de chaque côté:

Schema stabilite.png

Pour limiter la longueur du robot nous avons cherché des modèles de servomoteur de petites tailles toute en faisant un compromis sur le couple développé par ce dernier. Le SG90 est le modèle le plus facile à trouver et aussi celui que nous avions sous la main.

estimation de la masse total du robot ~ 0,5kg.

Tableau des masses
Masse (kg) Quantité Total
PCB 0,03 1 0,03
Batterie 0,2 1 0,2
SG90 0,009 10 0,09
Boitier 0,2 1 0,2
Pales 0,01 2 0,02
Capteurs 0,005 1 0,005
0,54


D’après sa datsheet, le SG90 peut développer un couple de 1800g/cm:

Sg90.jpg SG90specifications.png

Dans le cas le plus défavorable le poids est repartie sur 4 points d'appuie (125g chacun).

Schema couple.png

On a donc un couple appliqué sur chaque servomoteur C = 125xL g.cm On calcule une largeur de pale L = 1800/125 = 14,4 cm maximal pour ne pas dépasser le couple max développé par les SG90. Etant donné l'estimation de la taille du châssis (~300mm*200mm), la largeur max de nageoire calculée est largement supérieur a l'estimation faite en amont. Validation du choix du servomoteur.

Par la suite nous avons remarque que ce modèle n’était pas viable (voir semaine bonus dans la suite du wiki)

  • Nageoire:

Le caoutchouc est un matériaux déformable et rugueux et paraît être parfaitement adapté à notre problème. De plus, ce matériaux est facile a découper (manuellement/découpe laser). Le positionnement et les dimensions de la pale seront déterminé de manière expérimentale. Nous avons pensé a plusieurs solutions: la première consiste a placer la nageoire de manière longitudinale dans l'axe des bielles. De ce fait, le mouvement d'ondulation suit parfaitement le mouvement des servomoteurs. La deuxième solution est donner une forme ondulée aux nageoires; c'est a dire que lorsque les bielle sont toutes alignées sur le même plan, la nageoire est deja ondulée. Enfin on peut egalemment decouper les pales de maniere incurvee afin que la pale soit ondulee a l'exterieur et non au niveau de la fixation des bielles. Le dimensionnement des nageoires dépend donc de la configuration choisie. A l’issue des ses expérimentations, nous pourrons définitivement valider le choix du matériau et nous concentrer davantage sur le contrôle du robot. Le seul inconvénient que nous avons anticipé avec le caoutchouc est qu'il a une masse volumique importante et donc demande plus de puissance au servomoteurs lors du délassement. Pour palier à ce problème, nous avons pensé à l'impression 3D avec un matériau déformable tel que le TPU (polyuréthane thermoplastique). L’intérieur de la nageoire serait donc remplie sous forme de mésostructure a la fois rigide, déformable et de faible masse. (logiciel ICE SL)

  • Contrôle:
    • Détection d'obstacles:

Les capteurs ultrasons généralement vendus avec les cartes Arduino permettent de mesurer une distance et sont souvent utilisés pour la détection d'obstacle. Cependant, d’après notre expérience personnelle, leur fonctionnement ainsi que la précisions des mesures sont douteux. Les capteurs de distance infrarouges paressent être une alternative plus fiable(https://www.phidgets.com/?tier=3&catid=5&pcid=3&prodid=396). Deux capteurs seront disposés a l'avant du robot et seront inclines l'un par rapport a l'autre afin de couvrir un angle plus important. Meme si théoriquement le robot est capable d'effectue une marche arrière, nous n'avons pas juge nécessaire de positionner un autre capteur a l’arrière du châssis.

    • Détection milieux aquatique:

Nous avons d'abord pense a un capteur d’humidité. Cependant la mesure du taux d’humidité ne caractérisé pas si on est dans un milieu aquatique ou non: on peut par exemple avoir un taux de 100% dans l'air. Il a donc fallu trouver un système tout ou rien pour détecter la présence d'eau. Pour cela, on place deux électrode a l’extérieur du châssis et on applique une tension sur l'une des deux. Si le robot est bel et bien dans l'eau, on peut détecter une tension sur la deuxième électrode.

Test detection eau.jpg
    • Pilotage manuel ou autonome:

Afin de prendre le contrôle manuellement sur le robot nous avons décidé de fabriquer une télécommande infrarouge capable de communiquer avec la carte électronique. Pour cela nous souhaitons concevoir entièrement une carte électronique permettant à l’utilisateur de diriger le robot, d’adapter sa vitesse et de changer l’inclinaison des pales. Néanmoins, l’utilisateur doit pouvoir se rendre compte de l'environnement qui entoure l’appareil. C’est pourquoi nous avons décidé d'intégrer une caméra au robot. Du fait que récupération des images de la caméra à distance est impossible à mettre en oeuvre avec une simple carte basée sur l'ATmega, on utilise une carte Raspberry Pi capable d’interagir avec un ordinateur via le réseau wifi. L’objectif final du projet est que l’appareil soit totalement autonome et qu’il accomplisse seul la mission pour laquelle il est programmé. En fonction du cas d’utilisation, nous aimerions développer un algorithm de reconnaissance d’objet permettant au robot de détecter la cible qu’il doit atteindre sans intervention humaine.

Equipe 2

Réalisation du PCB:

matériel a intégrer : - 12 servomoteurs (type : SG90) - 2 TSOP - 2 capteurs de distance IR - Capteur d’humidité - Bouton reset - led de contrôle - Communication USB ( microprocesseur FT232R ) - programmateur ( prog spi avr)


Nous avons choisi de prendre un microcontroleur atmega2560 pour effectuer notre carte programmable. Ce microprocesseur possède 16 broches PWM ( 12 seront utilisés pour le servomoteurs). Ceci est un avanatge car le robot va devoir porter le chassis donc cela va permettre d'aléger de quelques grammes les palmes.

Le bouton va permettre de rénitialiser la carte s'il y a un problème dessus.

Les leds de controles vont être très utiles car avec ça, nous allons pouvoir repérer les éventuelles problèmes d'alimentation.

Le capteur infrarouge va nous permettre de télécommander le robot via une télécommande.

La carte raspberry pi zéro va servir pour la caméra car nous ne pouvons pas brancher directement la caméra à un arduino. Nous avons choisi cette car elle est petite, pas cher et assez puissante pour faire fonctionner une caméra.

Niveau logiciel, j'ai choisi d'utiliser Altium Designer car on va l'utiliser tout au long du cursus.

Liste des tâches à effectuer

Equipe 1

  • 1.1 Choix des capteurs/servomoteurs.
  • 1.2 Premier prototype de châssis (un seul cote = 5 servomoteurs).
  • 1.3 Algorithme de déplacement (avec 5 servomoteurs seulement).
  • 1.4 Design des nageoires.
  • 1.5 Tests et ajustements algorithme/pale avec 5 servomoteur.
  • 1.6 Conception et impression du châssis final.
  • 1.7 Algorithme de déplacement complet (10 servomoteurs).
  • 1.8 Télécommande IR.
  • 1.9 Camera + RaspberryPi.
  • 1.10 Algorithme de pilotage automatique avec intégration des capteurs.
  • 1.11 Châssis étanche.

Equipe 2

  • 2.1 Recherche sur les différents composants (descriptions des pins, alimentation,...)
  • 2.2 Conception du schéma électrique du circuit
  • 2.3 Routage du PCB
  • 2.4 Impression et implantation des composants
  • 2.5 Tests
  • 2.6 Choix de la batterie adaptée

Calendrier prévisionnel

Planningp13.png

Réalisation du Projet

Projet S6

Semaine 4

Lors de la séance du 12/02, nous avons défini un premier jet du cahier des charges. En fonction des éléments que nous voulons inclure sur le véhicule, nous avons mis en prévision un masse total des composants (environ 500 gramme).

Pour la méthode de déplacement, nous avons décidé d'utiliser des servomoteurs mais nous devons définir le nombre à inclure sur le robot. Le nombre de servomoteur sera défini à partir de la masse qu'ils devront soulevé en fonction de la longueur des pâles. Nous sommes allé voir M Astori pour savoir si l'idée de mettre 5 servomoteurs de chaque côté était envisageable. Après étude du caractéristique couple/distance de l'arbre des servomoteurs SG90, nous devrions pourvoir réussir à soulever cette masse sans problème. Théoriquement, avec un SG90 qui a un couple de 1.8kg.cm, quand nous sommes au point critique de, donc 4 appuis, chaque servomoteur devra soulever une masse de 125 gramme. Si nous considérons la masse réparti équitablement, avec cette configuration, les pales devrons, au maximum être d'une largeur de 14.4 cm. Toutes ses informations seront retranscrites dans les choix techniques.

Semaine 5

Cette séance était très fortement consacrée à un brainstrorming du groupe de projet pour savoir qu'elle serait les choix techniques au niveau matériel.

  • servomoteurs: nous partons sur un model de servomoteur FS90. Ce sont les sevomoteur plus basique que les SG90
  • chassi: nous partons dans un premier temps sur la conception d'une moitiée latérale du chassi pour les premiers test à effectuer
  • pale du véhicule imprimé par imprimante 3D, avec une structure souple permettant son ondulation.
  • capteurs utilisés: au niveaux des capteurs à utiliser nous sommes parti sur une liste simple qui pourra être modifié par la suite
    • tsop et led infra-rouge pour une communication infra-rouge
    • 3 sonnar à l'avant du véhicule pour repérer les obstacles en mode autonome
    • une rasberry Pi pour une communication direct avec l'utilisateur s'il veut passer en mode télécommandé

Semaine 6

La séance fut principalement réservée pour la remplissage du wiki: rédaction propre du cahier des charges et définitions des taches. Début de conceptions d'un premier prototype de chassie (finis a la maison)

Semaine 7

Equipe 1:

Durant cette séance, nous avons commencé à programmer les servomoteurs pour avoir une base pour les premiers tests lorsque le chassis sera imprimé.

Pour le chassis, un modèle 3D à été fait est devrait être imprimé pour la semaine prochaine.

Modification des choix techniques: nous avons décidé de changer les sonars par des détecteurs de distance infra-rouge. Ce changement est dû à la différence d'efficacité entre les 2 composants. Les détecteurs infra-rouge on une meilleure précision et un meilleur fonctionnement.

Equipe 2:

Pendant la séance j'ai effectué des recherches sur le branchement des différents composants ( capteurs de distances, servomoteurs ...) sur l'arduino afin de réaliser le schéma électrique.

Semaine 8

Equipe 1:

Impression du premier châssis et premiers test avec les servomoteur.

Test1 P13.gif

Equipe 2:

J'ai effectué la réalisation du PCB (schéma électrique) sur Altium. J'attends la validation de M.Boé pour passer au routage et voir les éventuelles modifications à effectuer.

Semaine 9

Equipe 1:

Adaptation du code pour faire des ondulations. Dimensionnent théoriques des nageoires et des bielles. Commande des feuilles de caoutchouc.

Equipe 2:

Modification du schéma électrique

Recherche pour créer un régulateur 6V pour les servomoteurs

Semaine 10

Equipe 1:

Nous avons finis le design des bielles en fonction de l’épaisseur du caoutchouc et de l'amplitude du mouvement. En attente des feuilles de caoutchouc pour découper les nageoires et effectuer les premiers tests.

Equipe 2:

En attente de validation du shematic. Recherche pour la batterie: nous partons sur une 'Powerbank' de 5V donc plus besoin de régulateur. Recherches sur consommation total du système.

Semaine 11

Equipe 1:

A Défaut d'avoir reçu le caoutchouc, nous commençons la modélisation d'un deuxième prototype de châssis permettant d’intégrer les 10 servomoteurs ainsi que les capteurs. Réflexion sur l'algorithme de déplacement: nous avons décidé de ne plus utiliser l’environnement Arduino IDE et de programmer directement en C d'utiliser le compilateur AVR prévu a cet effet.

Réflexion de groupe sur le dimensionnement du PCB et la dispositions de des différents éléments.

Equipe 2:

Semaine 12

Equipe 1:

Changement de stratégie concernant la détection du milieux aquatique: capteur d’humidité inappropriée. Nous partons sur une solution beaucoup plus simple: on détecte une tension si l'eau fait le lien entre deux électrodes. Conception et modélisation du châssis. Premiers tests d'ondulation avec du lino a la place du caoutchouc afin de mieux comprendre le comportement des nageoires.

Equipe 2:

Finition du shematic.

Commencement du routage.( ils manquent 2 capcacités de découplages)

Capture1.png C2.png

Semaine bonus

Equipe 1:

  • 1er test avec une seul nageoire: la pale est ondulée et décrit un arc de cercle parfait entre chaque servomoteur. Deux problèmes se posent lors de ce test. Le premier concerne la nageoire: la forme de la pale impose trop de contrainte au servomoteurs et le matériau (lino) est trop déformable donc on ne retrouve pas le mouvement d'ondulation commandé par les servomoteurs. Le deuxième problème provient de la bielle qui lie l'arbre des servomoteurs a la nageoire. Nous n'avons pas réussi a reproduire les stries permettant de maintenir la bien en phase avec la tete du servomoteur du coup cette dernière tourne parfois dans le vide. Nous avons donc conçue une nouvelle bielle qui vient se colle directement sur la bielle fournie avec le servomoteur.
Bielle1.png Bielle2.1.png Bielle2.2.jpg
  • 2e test avec une seul nageoire: cette fois si on redimensionne la pale avec une forme ondulée mois prononcée que précédemment. On se fixe une amplitude du mouvement des servomoteurs a 20deg et on calcule la longueur nécessaire de la pale entre chaque bielle.

Test2.1.gif

On se rend compte que l’algorithme d'ondulation comme nous l'avions implémenté ne permet pas de faire onduler la nageoire. En effet, l'algorithme était prévue pour alterner entre 2 et 3 points d'appuis au sol afin de garder une certaine stabilité. Ce modèle fonctionnerait potentiellement si on augmentait la distance entres les servomoteurs. Nous somme donc passé sur un deuxième modèle a 6 servomoteurs même si le châssis ne peut en accueillir que 5. Dans ce cas les servomoteur son deux a deux en phase se qui permet d'avoir 2 points d'appuis au sol en permanence.

Test2.2.gif

  • Impression du châssis final en deux parties pour pouvoir faire des test de déplacement avec les 2 nageoires.

Problèmes d'impressions de la partie avant mais pas dérangeant pour faire les tests.

  • Test avec les deux nageoires sur le châssis final:

Test.gif

En plaçant les nageoire a la verticale on constate que le robot n'avance toujours pas. Cela vient surement du fait que le lino est trop flexible pour supporter le poids total du robot et n’adhère pas assez au sol (ce qui aurait surement été différent avec du caoutchouc

Test vertical.gif

  • Test avec nageoire incurvée
Incurve.jpg

L'angle choisi est trop important donc l'ondulation impose trop de contraintes mécaniques aux servomoteurs. Test non concluant: réessayer avec un plus petit angle.

Equipe 2:

Documents Rendus

Projet S7

Redéfinition des objectifs

  • Finir la partie mécanique
    • Ajout d'un 6ème servomoteur par côté
    • Impression d'un châssis plus adapté aux tests
    • Test des pâles en caoutchouc
  • Réalisation de la commande du déplacement du robot
    • Commande manuelle/autonome: récupération des données des donné (caméra + LIDAR), traitement par un ordinateur de controle (algorithme de machine learning ou commande manuelle)et envoi des ordres de direction a la carte de commande du robot.
  • Rendre le robot indépendant énergiquement: batterie et commande sans fil (Semestre 8)

Nouveaux choix techniques

  • Servomoteurs : Le type de servomoteur reste le même (SG90) sauf dans le cas ou la nageoire en caoutchouc engendre trop de frottements avec le sol et donc demande plus de puissance. Cependant, comme expliqué dans le compte rendu du S6, l'algorithme de propulsion change: on passe à un modèle à 6 servomoteurs de chaque côté du robot.
  • Nageoires : L'idée des nageoires en caoutchouc reste valable. Il s'agit désormais de mettre en pratique cette idée en découpant les nageoires dans des feuilles de caoutchouc. Concernant la forme de ces dernières, les différentes géométries vue au S6 seront reproduite avec le nouveau matériaux pour en tirer la meilleur. Nous avons également pensé, dans le cas ou la rigidité du caoutchouc serait insuffisante, a utiliser des feuilles d'aluminium pour le design des pales.
  • Contrôle :
    • Contrôle de la propulsion : Une première carte électronique de contrôle type Arduino (avec shield ou non) permet de gérer les 12 servomoteurs et ainsi de contrôler le déplacement du robot.
    • Détection de milieux extérieurs : Pour la détection d'obstacle, on garde toujours les 2 sonars qui donnent une première idée de la distance aux obstacles de l’environnement extérieur. On utilise deux caméras (webcams) pour mieux rendre compte de l’environnement extérieur. La combinaison des deux images permettra de donner une notion de profondeur que l'on pourra étalonner avec un LIDAR 2D. L'acquisition des donnés sera géré par une deuxième carte électronique (type Raspberry Pi). Il reste a définir si les informations seront envoyé a un ordinateur de contrôle pour être traiter ou si la Raspberry est assez puissante pour traiter l'image par elle même.
    • Pilotage manuel : Il sera possible de piloter le robot grâce une télécommande (sur la Raspberry en point d'accès)
    • Pilotage autonome : Création d'un algorithme de machine learning permettant au poste de contrôle (ou Raspberry) de faire ses propres choix de déplacement pour trouver et suivre une cible.

Liste des tâches à effectuer

  • Impression/découpe d'un nouveau modèle de châssis.
  • Découpe des pales en caoutchouc.
  • Firmware de contrôle sur Arduino (avec réception des commandes via liaison série).
  • Conception d'un Shield Arduino pour faciliter la connectique
  • Configuration de la carte d'acquisition (configuration en point d'accès)
  • Création d'une télécommande sur la RaspberryPI et envoie des information à Arduino via liaison série
  • Choix du LIDAR et caméras.
  • Code d'acquisition des Images/données.
  • Algorithme de traitement des données et pilotage automatique (Machine Learning)

Semaine 1 (07/11/2019 - 14/11/2019)

  • Redéfinition du cahier des charges et des taches
  • Réunion de validation du projet avec les enseignants
  • début configuration Raspberry Pi
  • Réalisation des modèle 3D du châssis

Semaine 2 (14/11/2019 - 21/11/2019)

  • Configuration Raspberry Pi en point d’accès

Semaine 3 (21/11/2019 - 28/11/2019)

  • Choix camera/Lidar : Trouver un capteur permettant améliorer la vision du robot (en complément de la caméra). Solutions envisagées:
    • Caméra 3D : trop chère + trop d'information à traiter pour la Raspberry. Il aurait fallu réduire la résolution de l'image ou ne prendre que quelques images par secondes.
    • Lidar 3D + camera : Trop chère + Le temps de balayage du lidar est trop long. Le Lidar 3D utilise 2 moteur pour diriger le laser sur 2 axes. La fréquence de fonctionnement du Lidar est trop faible comparé a la caméra. On aurait donc eu un décalage entre l'information donné par le Lidar et celle donné par la Caméra.
    • Lidar 2D + 2 cameras : Les deux caméras espacées de quelques cm permettent d'avoir une vision en 3D. On choisi délibérément une faible résolution pour les camera de manière à réduire la quantité d'information à l'ordinateur de contrôle. Le LIDAR permet d’étalonner la profondeur (de l'image 3D reconstituée) sur un axe donné.
  • Impression parties châssis
  • Commencement de la migration des codes en .ino vers .c.

Semaine 4 (28/11/2019 - 05/12/2019)

  • Adaptation du code Arduino pour déplacement avec 6 servomoteurs (avec AVR, plus d'Arduino IDE). Meilleur contrôle des Timers utilisés.
  • Configuration RaspberryPI en point d’accès pour piloter faire une télécommande (172.26.145.42) -> A refaire (merci carte microSD made in China)

Semaine 5 (05/12/2019 - 06/01/2020)

  • Communication entre la RaspberryPi et l'Arduino

On envoie un message sur le port série d'une carte a l'autre. Le message a envoyé est choisie par l'utilisateur sur un téléphone connecté au point d’accès de la RaspberryPI sur robot.P13.org. Problème d’envoi sur la liaison série: On arrive bien a envoyer quelque chose de la RaspberryPI à l'Arduino mais on ne sait pas vraiment quoi.

Documents Rendus

Projet S8

Liste des taches https://trello.com/b/VHCWut1Y/p13

Semaine1 (13/01-19/01)

  • Shield pour l'arduino MEGA sur Fritzing (12 sorties servomoteur + 8 LED/resistances + entrée alimentation).
  • Essais résolution problèmes liaison série entre RaspberryPI et Arduino.

Semaine2 (20/01-26/01)

  • résolution du problème d'envoie de données entre la raspberry et l'ATmega: le problème venait de la fonction websocket.send() dans /var/www/html/index.php dans laquelle nous mettions en paramètre un caractère comme '1'. A l'envoie vers l'ATmega2560 le caractère était transformé par son code ASCII que nous n'arrivions pas à comprendre. Nous avons alors essayer de passer en paramètre un code en hexadécimal pour voir ce qui arriverez sur l'ATmega2560. En mettant bien websocket.send(0x01) l'ATmega a bien reçu via le port série le caractère 0x01 qui pourra alors être interprété plus tard pour la commande du véhicule.
  • Sheld ArduinoMEGA : impression/soudure/tests -> tout est OK

Fichier:P13shieldMEGA.zip

Shield1.png Shield2.png
  • Design du nouveau chassis (Plexiglas), en attente de la découpe laser.
  • Configuration des webcams
    • Récupération d'une commande permettant de prendre une capture d'image des webcam, nous l'utiliserons pour récupérer les données.
    • Nous avons utilisé le code fourni par Omar Padierna que nous avons récupéré sur https://github.com/OmarPadierna/3DReconstruction et effectué les premier test de configuration pour la construction d'une image 3D à partir d'OpenCV.
    • Nous avons sélectionné 2 webcam ayant une basse qualité d'image pour que les calculs soient plus rapide. Le problème c'est que les images sont de trop mauvaise qualité ce qui ne permet pas pour le moment de faire la configuration des webcams avec OpenCV.

Semaine3 (27/01-02/02)

  • Récupérer les paramètres de la camera (Damien)

Essais avec plusieurs webcams...blablabla expliquer le principe de fonctionnement

  • Reconstruction image 3D (Vincent)

inclure schéma de fonctionnement Attention il faut que les deux photos soient prisent sur le même plan horizontale

Semaine4 (03/02-09/02)

Semaine5 (10/02-16/02)

Semaine6 (17/02-23/02)

Vacances Hiver (24/02-01/03)

Semaine7 (02/03-08/03)

Semaine8 (09/03-15/03)

Semaine9 (16/03-22/03)

Semaine10 (23/03-29/03)

Semaine11 (30/03-05/04)

Semaine12 (06/04-12/04)

Vacances Pâque (13/04-26/04)

Semaine13 (27/04-03/05)

Semaine14 (04/05-10/05)

Soutenances

Documents Rendus