La mascote du fablab arrive !

Un premier projet collaboratif a été débuté au fablab Moebius. Il s’agit de la conception d’un robot à commandes vocales qui répondra (bientôt) au petit nom de « Mobee.One ».

Ce projet a pour première mission de fédérer les membres du fablab Moebius autour d’un projet collaboratif et pluri-disciplinaire, touchant aussi bien à l’électronique (via l’utilisation de micro-controleurs arduino) qu’à la modélisation 3D, ou encore à l’impression 3D, à la programmation …

Le second objectif de ce projet est d’éprouver l’organisation en équipe au fablab, à travers l’usage du nouvel outil de gestion de projet « Wekan », récemment mis en place sur le site du fablab Moebius. Ici, la méthode AGILE / SCRUM est privilégiée (fortement édulcorée), permettant rapidement d’obtenir un résultat concret, un prototype fonctionnel, évitant la lourdeur d’un trop classique cahier des charges fonctionnel. Il aura ainsi suffit de quelques jours de travail individuel et collectif pour obtenir au bout d’un mois la première version fonctionnelle de « Mobee.One ».

Ce premier robot a donc pour ambition de devenir la mascotte interactive du fablab lors des diverses présentations au public des activités de l’association (stands de démo, portes ouvertes), dans un esprit ludique et innovant.
Une mise en route rapide :
Quelques croquis suivis d’une petite liste de fonctionnalités de base, et voilà lancée la première phase du projet, mais on parlera plutôt ici du premier « sprint » (dans le jargon de la méthode SCRUM).

Un sprint, dans l’utilisation que l’on en fait ici, commence par une liste de fonctionnalités attendues (nos spécifications) et se termine par un prototype fonctionnel dont on peut faire la démonstration.

Pour ce Sprint #1, nous voulions donc un robot qui puisse :

  • se déplacer : avancer, tourner, reculer (via un châssis à roues électriques)
  • être commandé depuis un smartphone, via des commandes vocales Bluetooth
  • avoir des yeux expressifs (via l’utilisation de 2 mini écrans OLED)
  • proposer un look soigné, à la couleur et aux « armoiries » du fablab.

La petite équipe de départ s’est divisée la tâche en 3 pôles :

  1. motorisation & alimentation
  2. modélisation 3D & impression 3D
  3. électronique & programmation

Le tableau « Wekan » du projet « Mobee.One » s’est vite rempli de diverses tâches, qui ont été affectées aux divers membres impliqués dans ce projet.

Voici à quoi ressemble un tableau Wekan :

exemplewekan

Certains de nos makers, par manque de temps, n’ont cependant pas pu participer activement cette première phase de conception, mais nous les attendons au tournant pour les sprints suivants, car la robotique n’a pas de limite en terme d’évolution, et il y aura du travail pour tout le monde, en fonction des aspirations, des idées et des compétences de chacun.


 

Carte Arduino : La gamme des cartes « Arduino », à largement démocratisé l’usage des micro-contrôleurs. Via une simple interface de programmation en langage C, il est ainsi possible de programmer une carte Arduino, via un cable USB, pour qu’elle exécute une série d’actions en boucle infinie.

La forceArduino316 d’un tel système, c’est d’être accessible à n’importe qui, sans aucune connaissance préalable ni en électronique, ni en programmation. Il suffit de suivre quelques tutoriels sur internet, ou mieux, de venir assister à l’un des cours « Arduino » proposés par le fablab Moebius, pour apprendre à réaliser des petits projets électroniques interactifs ou domotiques (sonnette, alarme, commande de porte, station météo …)

 

 


Pour la partie motorisation du robot :
@Henry s’est occupé de réaliser un système d’essieu imprimé en 3D pour accueillir les petits moteurs à courant continu (D.C. motors en anglais) couplés à un « shield moteur » de type Adafruit V1.

Dans le jargon « Arduino », un shield (ou bouclier en français) est une carte électronique qui s’empile sur la carte Arduino, et qui propose des fonctions dédiées (ici donc ce bouclier « moteurs » permet de simplifier la gestion et le raccordement électrique des moteurs électriques).

Une carte Arduino UNO coiffée d’un shield moteur Adafruit V1 :

Arduino_and_Motor_Sheild_preview_featured

 

Le shield moteurs répond à plusieurs attentes :

  • simplifier le raccordement des moteurs à une carte arduino
  • isoler l’alimentation électrique des moteurs vis à vis de l’Arduino (et donc protéger l’arduino des pics de tension).
  • permettre l’inversion du courant des moteurs DC (pour pouvoir avancer et reculer, en inversant simplement la polarité du courant via des ponts en H gérés électroniquement par des puces dédiées à cette tâche, ici des H-bridge L293D).

définition : le pont en H (ou H-Bridge en anglais) est un schéma électrique particulier, qui tient son nom de sa forme en H, permettant d’inverser le sens du courant entre un générateur de courant continu et un récepteur électrique (ici un moteur).


L293D Double Driver Moteur

Un chipset L293D

Ici, notre Shield moteur intègre donc 2 puces H-bridge L293D, pouvant chacune gérer 2 moteurs, et inverser les polarités de chacun à volonté; bien plus qu’il n’en faut à notre projet.

Il n’est en effet pas possible de relier électriquement des moteurs aux sorties électriques Arduino, pour plusieurs raisons :
– les entrées/sorties de la carte arduino sont fragiles, car reliées directement à la puce centrale et non protégées des pics de tension envoyés par le moteur lorsqu’il se comporte comme un « générateur de courant », au moment de ses accélérations, décélérations.
– les broches d’un arduino ne peuvent pas fournir plus de 50mA de courant (individuellement), et pas plus de 400mA au total pour la carte dans son ensemble, disqualifiant d’entrée ce type de raccordement direct pour alimenter des moteurs, qui ne tourneraient tout simplement pas (sauf peut être de tout petits SERVO moteurs, à très faible couple moteur).

Pour la partie alimentation du robot :batteriesX6
Pour le moment, nous avons retenu l’utilisation d’une seule et même batterie pour l’ensemble du robot, disposant d’un embout JACK s’enfichant directement dans la carte Arduino (voir visuel ci-contre). C’est la solution de loin la plus simple, car le courant fourni passe par le régulateur interne de voltage de la carte Arduino. Il est cependant conseillé, sur de plus gros projets, de séparer l’alimentation côté Arduino (la carte et ses modules de faible consommation), de celle des moteurs (nécessitant des puissances plus importantes).

Nous obtenons donc au total une tension de 7.2V avec 6 piles rechargeables de 1.2 V chacune.

 

Pour la partie modélisation & impression 3D :
Naimeric, notre fabmanager en chef, s’est occupé du design (modélisation 3D sous Autodesk Fusion 360), qu’il a ensuite imprimé en 3D.

Plusieurs éléments ont été conçus pour être imprimés et assemblés séparément :
– la tête, divisée en 5 éléments
– le buste : 1 élément, suffisamment volumineux pour accueillir l’électronique embarquée sans trop de soucis d’intégration.
– le châssis inférieur (pour l’accueil de l’essieu, des roues, des moteurs).

Corps Mobee One Mobee One Interieur

Pour la partie électronique :
Outre la carte Arduino et son shield moteur, nous avons intégré dans ce premier robot, les éléments nécessaires aux fonctions requises :

  • un module de communication Bluetooth
  • un gyroscope 3 axes (un seul axe sera utilisé pour pouvoir tourner selon un angle précis)
  • 2 écrans OLED pour les yeux
  • un SONAR pour détection d’obstacles
  • le réceptacle pour 6 piles AA rechargeables 1.2V (soit une alim DC de 7.2V au total).

Pour la partie Programmation (côté Arduino) :
Le but du programme écrit en langage C, est ici de faire réagir l’électronique de manière à ce que les comportements demandés soient réalisés :

  • afficher l’animation des yeux sur les écrans OLED
  • gérer l’arrivée de nouvelles commandes en bluetooth
  • détecter les obstacles via le SONAR
  • faire réagir les moteurs en conséquence des ordres reçus et des obstacles
  • au bout d’un moment sans ordre reçu, passer dans un état de comportement pseudo aléatoire (pour que le robot semble s’occuper de lui même pendant qu’on ne lui demande rien à faire de précis).

Le code (susceptible d’être modifié ou en cours de modification) est visible à l’adresse suivante : https://codebender.cc/sketch:315121

pour la partie programmation (côté smartphone) :
une application a été développée sous Android, pour créer une télécommande bluetooth pour le robot. Le programme développé sera partagé lorsqu’il sera plus abouti, via la galerie officielle d’APP INVENTOR. En voici pour le moment un aperçu :

Concepteur d'interface App Inventor

Concepteur d’interface d’App Inventor pour la télécommande bluetooth Android.

Extrait de code App Inventor

Exrtrait du code App Inventor pour la télécommande Android du Mobee.One

Encore une fois, par soucis de simplicité, nous avons opté pour un environnement de « programmation sans code », proposé en ligne par le MIT (Massachusets Institute of Technology). Tout se fait graphiquement, par assemblage à la souris de blocs d’instructions logiques.

On peut avoir un aperçu ici d’un algorithme simple, permettant d’associer à une action donnée (par exemple « GAUCHE » pour tourner à gauche), une série de phrases type « tourneàgauche », »tourneràgauche », »vaàgauche », »alleràgauche » … Ce code permet une certaine souplesse dans l’exécution des ordres. L’opérateur humain pourra dicter simplement son ordre, sans avoir à réfléchir à une façon particulière de le prononcer. Le robot comprendra tout de même l’ordre générique « GAUCHE », qui lui indique simplement qu’il faut tourner de 90°C vers la gauche (chose qui sera par contre codée du coté arduino en C). On donne ici simplement l’illusion que le robot comprend le langage naturel, de manière simple et efficace. Si jamais une façon particulière de prononcer l’ordre n’est pas encore implémentée (par exemple « regardeàgauche » qui équivaut pourtant à la même action), il suffira de l’ajouter à la liste des expressions listées, sans avoir à changer ni complexifier la logique du programme.

Evolutions possibles : on pourrait d’ailleurs demander à l’application Android de mémoriser dans une base de donnée toutes les commandes vocales qui n’ont pas été comprises, dans une but d’analyser les tendances (les demandes les plus fréquentes), et d’en profiter pour transformer les plus récurrentes d’entre elles  en nouvelles actions, ou simplement de rattacher ces « nouvelles » expressions à des actions existantes.

Premiers résultats, intégrés dans une « coque » improvisée :

MobeeOne Prototype MobeeOne Prototype Corps

Bientôt un article sur la finalisation du robot, affaire à suivre …

Posted in:

Laisser un commentaire