Aspiro est un projet visant à créer un aspirateur autonome. Dans le commerce, il existe déjà bon nombre d’aspirateurs de ce type. On peut citer par exemple la série des Dyson 360 Eye avec des prix pouvant avoisiner les 1000 euros. Il existe des robots aspirateur moins chers tel que le Dirt Devil ou ILIFE autour des 100-200 euros. Notre objectif était de faire un robot aspirateur peu coûteux à produire (moins de 200 euros) mais équipé de bon nombre d’instruments pour pouvoir naviguer facilement dans une pièce. Il est à noter que pour ce projet, nous sommes partis de zéro. Ce projet a donc inclus à la fois la construction pièce par pièce du robot (conçu en bois), le branchement et la programmation de celui-ci. Il était donc ambitieux. L’état actuel de l’aspirateur est certes fortement améliorable mais beaucoup d’éléments sont déjà présents pour concrétiser ce projet.

I. Aspect général

Le robot aspirateur consiste en deux principaux éléments. Tout d’abord, l’aspirateur lui-même qui n’est ni plus ni moins qu’un aspirateur qu’on pourrait trouver dans le commerce. Il s’agit plus précisément d’un aspirateur sans sac OCEANIC VC10WBAX2 qu’on peut trouver à bas prix. Le second élément important est le socle. L’aspirateur est posé sur un socle mobile. Ce socle est motorisé de deux moteur à courant continu 12V et est muni de chenilles tel un char. Il doit pouvoir se déplacer dans une pièce en toute autonomie et sur tous types de surface. Des capteurs à ultrasons ont été installés sur tout le pourtour du plateau sur lequel est posé l’aspirateur. Ils permettent de détecter les obstacles à courtes distance. Une tour supportant à son sommet une tourelle sur laquelle est fixé un Lidar enjambe l’aspirateur. Il est a noter ici que tout le projet c’est effectué sans aspirateur, par manque de temps il a été impossible de l’installer et de faire fonctionner le robot avec l’aspirateur.

Contrairement aux roues les chenilles permettent une meilleure adhésion, donc une plus grande précision lors des rotations. Aussi elles adhèrent à tous les types de sol(carrelage, béton vibré, parquet, tapis, moquette, etc…).

II. Le châssis et l’armature

Le socle est conçu en bois, il s’agit d’un plateau sur lequel est collée la tour supportant la tourelle du Lidar et en dessous les plaques où sont fixées les roues supportant des chenilles ainsi que les moteurs. On s’éloigne ici évidemment de ce qui se fait dans le commerce. C’est en effet un socle volumineux et peu pratique pour parcourir une pièce. Néanmoins, une s’agit d’une première version qui n’a pas pour ambition d’atteindre les standards de qualité du commerce, il s’agit juste d’un prototype.

La tour, en bois elle aussi, est posé sur ce châssis elle permet de pouvoir glisser l’aspirateur en dessous. La tourelle mobile supportant le Lidar est fixée à son sommet et en son milieu. La fourchette optique permettant d’avoir une référence pour les angles de rotation est aussi vissée à cet endroit.

En dessous du plateau sont fixées deux plaques supportant le système de chenille permettant au robot de se déplacer.

II.a. Le système de motorisation à chenilles

Le robot se déplace grâce à deux moteurs entraînant un système de chenilles. Celle-ci permettent au robot de pouvoir se déplacer sur tout type de surface notamment sur des surface où des roues auraient du mal à adhérer, de la moquette ou des tapis par exemple. Ce système permet également au robot de pouvoir tourner sur place. Ce qui aurait été impossible avec un système de roue.

Les chenilles sont entraînées chacune par une roue motrices et tendues et soutenues par deux roue folles découpée à la découpeuse laser et fixées avec des boulons. Une petite roue est prise en sandwich entre deux grandes. Les roues motrices quand à elles ont été imprimées à l’imprimante 3D, elles ont chacune un méplat pour être entraînées par les moteur. C’est la tension dans les chenilles qui les maintient en place.

Les moteurs sont alimentés en 12V et sont réversibles en tension et courant. Ils sont commandés par une carte ArduinoUno émettant une PWM pour régler la vitesse de déplacement, ce via un shield de puissance permettant une alimentation adéquate.

II.b. Le système de repérage spatiale

Ce robot ne va évidemment pas se déplacer à l’aveugle. De nombreux capteurs sont installés dans cet optique. Ainsi, cinq capteurs ultrasons ainsi qu’un Lidar monté sur une tourelle tournant à 180° ont été utilisés.

Les capteurs à ultrasons sont utilisés plutôt pour détecter les obstacles proches à une distance de l’ordre de 30 cm. Ceux sur le devant détectent les obstacle sur le devant ceux sur l’arrière détectent les obstacles sur l’arrière. Les capteurs situés sur les cotés ont été installés à cet endroit dans l’optique de faire longer les murs au robot et ainsi nettoyer au plus près des murs. Ces capteurs était là dans l’optique de faire un asservissement de distance vis-à-vis du mur longé afin de rester au plus proche.

Le Lidar quand à lui est utilisé pour cartographier la pièce et les obstacles à longue distance environ 1m. Il est fixé sur une tourelle tournant à 180°. L’objectif de départ était d’utiliser le mode de cartographie SLAM mais ceci est encore à mettre en oeuvre. Il a été fixé sur un servo-moteur via une plaque de fixation monté sur un support imprimé en 3D.

II.c. La fourchette optique

Au fil du projet, nous avons remarqué que l’orientation du lidar ne pouvait être connue au démarrage du robot. Le moteur utilisé ne permet pas de connaître cette position. Ainsi, une position initiale devait être ajoutée. Nous avions réfléchis à plusieurs solutions dont une « cale ». Finalement, un système de fourchette optique intégrant LED infrarouge et capteur infra-rouge a été mis en oeuvre. Il a été réalisé via des module arduino émetteur IR et récepteur IR. Le moteur du lidar fait aussi tourner deux barre de détection en bois sur les cotés du lidar. La LED infra rouge est toujours allumée. Ainsi, le capteur renvoi toujours une valeur positive. Or, lorsque le moteur du lidar tourne il finit inexorablement par mettre une barre de détection entre la LED infra-rouge et le capteur. Ce dernier retourne alors une valeur négative. Cette orientation du lidar est ainsi utilisée comme orientation à l’initialisation. A partir de cette position, l’orientation du lidar est calculée à chaque manipulation du moteur du lidar. Plus simplement, ceci sert de référence et nous permet à tout moment de connaître quelle est l’orientation du lidar. La LED infrarouge est gérée par la carte Arduino gérant les capteurs infrarouge (elle ne fait qu’allumer la LED). Le capteur infrarouge est, lui, géré par l’Arduino manipulant le moteur du lidar. Ceci nous permet ainsi d’initialiser facilement l’orientation du lidar au démarrage d’Aspiro.

II.d. la création du socle, de l’armature et leur assemblages

Le montage du robot s’est fait en plusieurs phases. Tout d’abord, il a bien fallu créer l’armature du socle. Pour cela, nous avons utiliser des plaques de bois. Chaque plaque a été découpée à la découpeuse laser. Pour cela, nous avons conçu des plans que la découpeuse a suivi. Une fois les différentes parties découpées elles ont été assemblées en étant collées au pistolet à colle chaude ou vissées. Bien que courte à expliquer, la phase de conception des pièces a demandé du temps. Quelle forme donner au robot ? En effet, celle-ci devait pouvoir servir l’aspect logique. Cet aspect étant que le robot devait pouvoir aspirer dans les coins. Ainsi, une « tour » a été conçue pour supporter le lidar et le placer au point le plus haut du robot. Il a été également voulue qu’il soit au centre du châssis pour pouvoir guider au mieux le robot dans ses rotations. Un espace à l’avant, à l’arrière et sur les côtés a été réservé pour les capteurs ultrasons. Enfin, de la place était aussi présent en dessous pour les moteurs.
La plupart des éléments ont été collés, a cet effet des dentelures droites ont été crées pour un assemblage plus solide notamment l’assemblage de la plateforme qui soutient la tourelle du lidar.

II.e. Le circuit d’alimentation

L’alimentation se fait par une batterie 12V. Il y a besoin de deux tensions différentes pour alimenter les différentes parties du robot Aspiro, du 12V pour les moteurs et du 5V pour les cartes. A savoir les cartes Arduino peuvent être alimentées en 12V via leur prise jack ou la pin Vin mais ici elles sont directement alimentées en 5V. Pour abaisser la tension de 12V à 5V un régulateur de tension LM7805 a été utilisé selon le schéma suivant :

Un boitier de connection usb a été utilisé comme boite de dérivation :

Enfin un radiateur artisanale découpé dans une cornière d’aluminium à été boulonné au régulateur LM7805 afin
d’évacuer la chaleur extrême qui se dégage du composant.

Les différents capteurs quand à eux sont alimentés en 5V via les cartes Arduino et le bloc de connexion :

II.f. La répartition des cartes

Deux cartes Arduinos ainsi que la Raspberry Pi2 model B ont été fixées sur chaque côté de la tour. Le choix de l’emplacement s’est fait par rapport aux branchements. En effet, il fallait aussi éviter que les câbles viennent gêner. Sur un des côté a été installé le bus de communication i2c. Enfin, la Raspberry a été installée du côté du bus i2c pour un branchement plus simple.

II.g. Les connexion et le système de contrôle

Il a bien fallu brancher tout ceci. Pour mieux comprendre le branchement, il est important de connaître un minimum ce qu’est un bus i2c. Un bus i2c consiste en deux câbles pour chaque équipement branché sur le bus. Un des câbles permet de gérer la cadence, la fréquence. Ainsi, il permet de déterminer quand considérer qu’un bit est à un ou à zéro. Le second câble permet d’envoyer les données. L’envoi se fait via une succession de variation de tension et la cadence permet de savoir quand les interpréter en 1 ou en 0. Simplement, il faut deux câbles par équipement minimum qui communique sur ce bus. Dans notre cas, nous avons quatre hôtes sur ce bus: une Raspberry, les deux Arduinos et le lidar. Dans un bus i2c, nous avons toujours un « maître » et des « esclaves« . Le maître est le chef d’orchestre. Il s’agit de celui qui prend l’initiative d’envoyer des données mais aussi celui qui demande aux esclaves d’envoyer des données. Ici, le chef d’orchestre est la Raspberry. La communication dans un bus i2c ne se fait que maître à esclave. Ainsi, la Raspberry est le centre du système. Les ultrasons eux sont pas branchés sur le bus i2c. Ils sont branchés directement à une des cartes Arduino. Cette carte gère donc principalement ces capteurs. Elle envoi leur valeur à la Raspberry sur demande. L’autre carte Arduino gère les moteurs pour les déplacements. Elle gère aussi le moteur sur lequel est installé le Lidar. Ainsi, sur demande de la Raspberry, elle peut changer la direction pointée par le lidar ou déplacer « Aspiro ». De même, la Rasberry peut aussi à tout moment demander à démarrer les moteurs. L’objectif de cette installation est de mettre un code minimal « bas niveau » sur les Arduinos pour le contrôle d’Aspiro et de laisser la Raspberry orchestrer l’ensemble avec un code plus « haut niveau ».

III. La programmation

Le robot en question avait donc besoin d’un chef d’orchestre et d’assistants pour ce dernier. Le chef d’orchestre est ici une Raspberry Pi 2 model B. Il s’agit du modèle deux suffisant pour notre usage. Les assistants sont des cartes ArduinoUno. Chaque Arduino gère un ensemble de périphériques. Mais un chef d’orchestre doit pouvoir communiquer avec ses assistants, c’est pourquoi nous avons introduit un bus de communication, plus précisément un bus i2c que nous avons déjà détaillé précédemment.

III.a. Arduino A

Le premier Arduino est celui qui gère les capteurs infra-sons et la LED infra-rouge. Cet Arduino est simple à programmer. En effet, la seule chose qu’il a à faire est d’allumer cette LED et de recueillir la valeur des capteurs. Pour cela, un mini-protocole a été élaboré. Un protocole très simple. La Raspberry doit faire une demande de valeur comme elle ferait un appel de fonction. Cela implique de passer des paramètres et d’avoir une valeur de retour; tout ça via le bus i2c. Ainsi, lorsque la Raspberry a besoin de la valeur d’un capteur elle envoie à l’adresse de cet Arduino (0x14 défini arbitrairement) un entier. Cet entier est le paramètre correspondant à un capteur. A chaque capteur correspond un entier. Puis, l’Arduino retourne simplement la valeur de ce capteur. Si la valeur de ce capteur est en dessous d’une certaine valeur (définie arbitrairement à 20cm), alors l’arduino retourne à la place la valeur 0. Cette valeur est interprétée par la Raspberry comme la présence d’un obstacle très proche de l’aspirateur. Ceci nous permet de détecter les obstacles autour de l’aspirateur.

III.b. Arduino B

Le second Arduino, lui, gère les moteurs (chenilles et Lidar) et le capteur infra-rouge. C’est celui qui abrite le code le plus complexe. Tout d’abord, son code comporte le même type de protocole que l’Arduino A. Ici, il s’agit d’une autre adresse sur le bus i2c mais la manière de communiquer est la même. La Raspberry envoie d’abord un numéro correspondant à un numéro d’action (faire tourner le lidar, faire tourner l’aspirateur, etc …). Puis, elle envoie une autre valeur correspondant à un paramètre. Celui-ci est utilisé ou non par l’Arduino B mais le protocole reste toujours le même. Ensuite, l’Arduino exécute l’action et retourne une valeur; soit une valeur quelconque soit une valeur particulière. Le fait de retourner une valeur même quand aucune valeur particulière n’est attendue n’est pas anodin. En effet, cela force la Raspberry a attendre la confirmation que l’action est bien effectuée. Ainsi, le programme de la Raspberry ne continue pas tant que l’action demandée n’est pas terminé ce qui peut être très utile. Cet Arduino peut ainsi changer l’orientation du Lidar en contrôlant le moteur sur lequel ce dernier est posé. La Raspberry envoie ainsi un angle et l’Arduino change l’orientation du Lidar selon cet angle. Ils peut aussi contrôler les moteurs des chenilles. La Raspberry envoie une action: tourner ou avancer. Ensuite, elle envoie une valeur correspondant à la force de rotation ou la vitesse. Enfin, l’Arduino exécute la demande. Parmi les demandes possibles, il y a aussi celle permettant d’initialiser le Lidar dans une orientation par défaut. Ainsi, pour cela cet Arduino gère aussi le capteur infrarouge.

III.c. La Raspberry

La Raspberry est le cerveaux de l’ensemble. C’est elle qui envoie les ordres (tourner, s’arrêter, …). Elle intègre aussi un algorithme de parcours rudimentaire pour tenter de donner à Aspiro un comportement logique. Ainsi, elle intègre le nécessaire pour les commandes de base: tourner, avancer, reculer, prendre des mesures etc … . Ces dernières sont exploitées par l’algorithme de parcours. Cet algorithme tente de maintenir une grille représentant la pièce dans laquelle se trouve Aspiro en mémoire. Aspiro va, en boucle regarder autour de lui (grâce à Lidar) pour déterminer dans quelle direction aller. Il regarde pour cela dans uniquement trois directions (gauche, droite et devant lui). Pour chacune des directions, il interroge la grille en mémoire pour chercher dans quelle direction il y-a le plus de « cases » sur lesquelles il n’est pas encore passé. Ensuite, il va logiquement dans la direction la moins nettoyée. Il se peut qu’il ait nettoyé chacune des directions. Dans ce cas, il va tout de même aller dans une direction, soit celle qu’il n’a pas empruntée la dernière fois qu’il était à cette position, soit une direction aléatoirement. Une fois que toutes les positions disponibles (qu’il a pu détecter avec le Lidar) ont été empruntées, l’algorithme s’arrête. Il se peut qu’Aspiro ait pendant son parcours détecté un mur ou un obstacle. Il est informé de cela par l’Arduino A qui gère les capteurs umtrasons. Si tel est le cas, Aspiro s’arrête face à l’obstacle. Il va chercher à se positionner perpendiculairement à l’obstacle puis va tourner à droite jusqu’à rencontrer un autre obstacle et faire demi-tour. Il ne cherche pas à faire le tour de l’obstacle (chose à améliorer). Une fois cela fait, il continue l’algorithme classique.

IV. Encore imparfait

Aspiro ne peut prétendre être terminé. Son comportement peut sembler aléatoire et cela pour certaines raisons. La principal raison est que le comportement attendu par les programmes qu’il embarque ne sont pas toujours respecté. En effet, par exemple il peut être attendu qu’il tourne à 90°, mais, pour une raison ou une autre il ne tournera pas forcément à l’angle attendu. La raison peut être un obstacle au moment de tourner, la qualité du sol (un tapis par exemple) ou bien une gêne engendrée par les câbles. Pour contrer cela, un système de vérification a été mis en place. Celui ci prend un ensemble de mesures avant de tourner avec le Lidar puis, une fois que Aspiro a tourné, recherche les mêmes mesures en tournant le lidar à 90°. Cela pourrait fonctionner si le nombre de mesures était suffisant. Or, le Lidar ne permet de prendre qu’une mesure à la fois et prendre suffisamment de mesures peut prendre beaucoup de temps. Cette fonctionnalité a été désactivée pour rendre l’aspirateur plus actif. Le problème se pose aussi lorsque l’aspirateur avance. Une distance est calculée avec d’avancer puis une comparaison est faite avec une distance calculée après avoir avancé. Cependant, si un obstacle se présente devant le robot alors le calcul est faussé. Dans ce cas là, la distance parcourue est calculée par rapport à la vitesse supposée du robot mais donne ainsi un avancement et une position approximative du robot. Or, la position du robot est importante du point de vue de l’algorithme de parcours.
Ainsi, le robot est loin d’être terminé. Néanmoins, en partant de rien, il a été possible de le monter, de le faire avancer, tourner et de le contrôler. Les éléments de base sont présents pour en faire un robot autonome. Peut être qu’un algorithme ne dépendant pas de mesures exactes comme un algorithme aléatoire pourrait permettre de mieux gérer le robot.

V. Piste d’améliorations matériel

En vue de faire un robot plus compacte il serait judicieux de rabaisser l’ensemble du robot afin qu’il puisse au moins passer sous les chaises. Les roues folles peuvent être remplacé par des roues folles en bois ou imprimées en 3D mais pouvant contenir des roulements car il y a trop de frottement entre les grandes roues et la petite. Les cartes peuvent être remplacées par une carte NUCLEO pouvant faire du parallélisme et pouvant recevoir des shields Arduino. Le faisceau électrique pourrait être refait de façon plus solide en soudant les connexions sur laptech au lieu de bredboard.

Une vidéo plus parlante

La vidéo ci-dessous montre le robot en fonctionnement. Le socle est ici seul, l’aspirateur n’est pas présent. Il est mis sur batterie et comme on peut le constater a déjà une certaine autonomie. Il détecte les obstacle,; change de direction à la vue d’un obstacle. En revanche, forcé de constater que c’est loin d’être parfait. Il n’avance pas parfaitement droit d’une part mais il se bloque à un moment dans des câbles aussi. Les capteurs ne sont pas suffisamment nombreux pour détecter des petits obstacles de ce type.http://www.youtube.com/embed/hhxaWSjrcyM?&fs=1

L’addition

Le robot nous aura coûté environ 200euros

Robot aspirateur ASPIRO( * matériel nécessaire)

Composants :

Chenilles de rechange MODELCRAFT 949119 *
Raspberry
Lidar
Moteur courant continu 12V x2
Pont H (Arduino board controle moteur) PWM
capteurs ultrason x5
Alim PC transfo 230VAC/12VDC
Aspirateur sans sac OCEANIC VC10WBAX2 *

Mots des membres de l’équipe

Jean-Charles (Electronique)

Ce projet m’a permis de m’initier à la découpe laser et à l’impression 3D. Deux choses auxquelles je voulais me former, qui je pense me seront utiles dans ma carrière professionnelle notamment pour du prototypage je pense. C’est la première fois Ce projet m’a encore permis de travailler en groupe ce qui m’a également permis de développer mon esprit d’équipe.

Julien (Electronique)

Ce projet m’a permis de mieux comprendre le déroulement de projet mélangeant plusieurs disciplines. Cela m’a aussi appris qu’au cours de projet comme celui-ci des problèmes électroniques ou mécaniques arrivent souvent et qu’il est nécessaire de les résoudre rapidement afin que les autres membres de l’équipe puissent avancer en utilisant le robot.
J’ai pu aussi mieux comprendre le travail en équipe et l’importance de la communication entre les membres spécialisés des différentes disciplines.

Pierre (Programmation)

L’architecture globale assez modulaire du robot m’a fait comprendre que les liens entre l’électronique numérique et la programmation orientée objet sont plus étroits que je ne pensais. Travailler sur un projet plus concret que ce dont on a l’habitude en filière informatique fut un expérience enrichissante et nos encadrants ont bien su répondre à nos questions. Le fait d’avoir réalisé un robot aussi fonctionnel « à partir de rien » est un vrai succès.

Yoann (Programmation)

Ce projet m’a permis d’expérimenter le travail dans une équipe multidisciplinaire. Cela m’a aussi fait prendre en compte l’importance de considérer aussi les limites du matériel utilisé pour concevoir le logiciel d’un robot. Enfin, cela m’a aussi fait prendre conscience de la forte dépendance avec tout l’aspect électronique dans lequel j’ai pu acquérir de nouvelles connaissances.