Réalisation d’une brodeuse numérique à partir d’une machine à coudre
Le but de ce projet est de créer un module sur une machine à coudre afin de la transformer en brodeuse numérique. Ce module peut s’ajouter et s’enlever de la machine afin qu’elle puisse garder sa fonction première. Notre travail a donc premièrement été de construire la partie physique du module.
figure 1 : module final
Le tambour, qui permet de tendre le tissu à broder, est relié à un rail denté. Celui-ci est entraîné en translation par un moteur relié à un pignon. Les trois autres pignons permettent au rail de tenir sa trajectoire. Les pignons et le rail reposent sur une plateforme en bois qui est la partie supérieure d’un boîtier.
figure 2 : boîtier et tiges métalliques
Deux tiges métalliques passant dans des roulements à billes traversent ce boîtier. Une courroie est reliée au moteur et permet le déplacement selon la direction perpendiculaire à celle du rail denté. Ce système est contraint à beaucoup moins de frottement que celui à base de rouages et d’une crémaillère en bois, il est donc plus facile pour le moteur d’entraîner le boîtier. Le boîtier abrite la carte Arduino qui est reliée aux moteurs.
La seconde partie du projet a été de convertir une image numérique en commandes pour les moteurs. Nous avons tout d’abord téléversé sur la carte Arduino un code qui permet d’interpréter un G-code, et donc de transformer ce Gcode en commande de rotation des moteurs. Ce code est commun à n’importe quel motif à broder. Il nous a alors fallu convertir le motif à broder en G-code et envoyer ce code à la carte Arduino. Nous pouvons faire cette conversion à l’aide du logiciel Inkscape. Pour ce faire, un certain nombre d’étapes sont à suivre :
- Il faut effectuer une symétrie centrale sur l’image du motif à broder, car le G-code obtenu est celui dans le cas où l’aiguille de la machine à coudre se déplace, or dans notre cas c’est le module qui se déplace tandis que l’aiguille garde une position fixe.
- Il faut choisir des « Points d’orientation », c’est-à-dire fixer un repère sur l’image afin de s’assurer que les déplacements vont s’effectuer dans le sens voulu et à partir du point de départ voulu. Ils servent aussi à gérer les différentes transformations de l’image (symétrie, translations, etc…).
- Une fois cette étape réalisée, Inkscape possède l’outil « Objet en chemin » qui permet de préparer l’utilisation de Gcodetools en posant le chemin à suivre.
- Enfin il faut utiliser « Chemins vers G-code » qui convertit effectivement le chemin calculé en la suite de commandes voulues. Des flèches indiquent le chemin tracé.
Un logiciel permet ensuite d’envoyer le fichier vers la carte Arduino, et les moteurs réagissent instantanément aux commandes reçues.
Elodie Derringer, Charles Rivière et Alexandre Ly
Code téléversé sur la carte Arduino
#code pour une découpeuse laser, l'axe z ne sert à rien.
#include <Servo.h>
#include <AFMotor.h>
#define LINE_BUFFER_LENGTH 512
char STEP = MICROSTEP ;
// Servo position for Up and Down
const int penZUp = 115;
const int penZDown = 83;
// Servo on PWM pin 10
const int penServoPin =10 ;
// Should be right for DVD steppers, but is not too important here
const int stepsPerRevolution = 200;
// create servo object to control a servo
Servo penServo;
// Initialize steppers for X- and Y-axis using this Arduino pins for the L293D H-bridge
AF_Stepper myStepperY(stepsPerRevolution,2);
AF_Stepper myStepperX(stepsPerRevolution,1);
/* Structures, global variables */
struct point {
float x;
float y;
float z;
};
// Current position of plothead
struct point actuatorPos;
// Drawing settings, should be OK
float StepInc = 1;
int StepDelay = 0;
int LineDelay =0;
int penDelay = 50;
// Motor steps to go 1 millimeter.
// Use test sketch to go 100 steps. Measure the length of line.
// Calculate steps per mm. Enter here.
float StepsPerMillimeterX = 100.0;
float StepsPerMillimeterY = 100.0;
// Drawing robot limits, in mm
// OK to start with. Could go up to 50 mm if calibrated well.
float Xmin = 0;
float Xmax = 40;
float Ymin = 0;
float Ymax = 40;
float Zmin = 0;
float Zmax = 1;
float Xpos = Xmin;
float Ypos = Ymin;
float Zpos = Zmax;
// Set to true to get debug output.
boolean verbose = false;
// Needs to interpret
// G1 for moving
// G4 P300 (wait 150ms)
// M300 S30 (pen down)
// M300 S50 (pen up)
// Discard anything with a (
// Discard any other command!
/**********************
* void setup() - Initialisations
***********************/
void setup() {
// Setup
Serial.begin( 9600 );
penServo.attach(penServoPin);
penServo.write(penZUp);
delay(100);
// Decrease if necessary
myStepperX.setSpeed(1000);
myStepperY.setSpeed(1000);
// Set & move to initial default position
// TBD
// Notifications!!!
Serial.println("Mini CNC Plotter alive and kicking!");
Serial.print("X range is from ");
Serial.print(Xmin);
Serial.print(" to ");
Serial.print(Xmax);
Serial.println(" mm.");
Serial.print("Y range is from ");
Serial.print(Ymin);
Serial.print(" to ");
Serial.print(Ymax);
Serial.println(" mm.");
}
/**********************
* void loop() - Main loop
***********************/
void loop()
{
delay(100);
char line[ LINE_BUFFER_LENGTH ];
char c;
int lineIndex;
bool lineIsComment, lineSemiColon;
lineIndex = 0;
lineSemiColon = false;
lineIsComment = false;
while (1) {
// Serial reception - Mostly from Grbl, added semicolon support
while ( Serial.available()>0 ) {
c = Serial.read();
if (( c == '\n') || (c == '\r') ) { // End of line reached
if ( lineIndex > 0 ) { // Line is complete. Then execute!
line[ lineIndex ] = '\0'; // Terminate string
if (verbose) {
Serial.print( "Received : ");
Serial.println( line );
}
processIncomingLine( line, lineIndex );
lineIndex = 0;
}
else {
// Empty or comment line. Skip block.
}
lineIsComment = false;
lineSemiColon = false;
Serial.println("ok");
}
else {
if ( (lineIsComment) || (lineSemiColon) ) { // Throw away all comment characters
if ( c == ')' ) lineIsComment = false; // End of comment. Resume line.
}
else {
if ( c <= ' ' ) { // Throw away whitepace and control characters
}
else if ( c == '/' ) { // Block delete not supported. Ignore character.
}
else if ( c == '(' ) { // Enable comments flag and ignore all characters until ')' or EOL.
lineIsComment = true;
}
else if ( c == ';' ) {
lineSemiColon = true;
}
else if ( lineIndex >= LINE_BUFFER_LENGTH-1 ) {
Serial.println( "ERROR - lineBuffer overflow" );
lineIsComment = false;
lineSemiColon = false;
}
else if ( c >= 'a' && c <= 'z' ) { // Upcase lowercase
line[ lineIndex++ ] = c-'a'+'A';
}
else {
line[ lineIndex++ ] = c;
}
}
}
}
}
}
void processIncomingLine( char* line, int charNB ) {
int currentIndex = 0;
char buffer[ 64 ]; // Hope that 64 is enough for 1 parameter
struct point newPos;
newPos.x = 0.0;
newPos.y = 0.0;
// Needs to interpret
// G1 for moving
// G4 P300 (wait 150ms)
// G1 X60 Y30
// G1 X30 Y50
// M300 S30 (pen down)
// M300 S50 (pen up)
// Discard anything with a (
// Discard any other command!
while( currentIndex < charNB ) {
switch ( line[ currentIndex++ ] ) { // Select command, if any
case 'U':
penUp();
break;
case 'D':
penDown();
break;
case 'G':
buffer[0] = line[ currentIndex++ ]; // /!\ Dirty - Only works with 2 digit commands
// buffer[1] = line[ currentIndex++ ];
// buffer[2] = '\0';
buffer[1] = '\0';
switch ( atoi( buffer ) ){ // Select G command
case 0: // G00 & G01 - Movement or fast movement. Same here
case 1:
// /!\ Dirty - Suppose that X is before Y
char* indexX = strchr( line+currentIndex, 'X' ); // Get X/Y position in the string (if any)
char* indexY = strchr( line+currentIndex, 'Y' );
if ( indexY <= 0 ) {
newPos.x = atof( indexX + 1);
newPos.y = actuatorPos.y;
}
else if ( indexX <= 0 ) {
newPos.y = atof( indexY + 1);
newPos.x = actuatorPos.x;
}
else {
newPos.y = atof( indexY + 1);
indexY = '\0';
newPos.x = atof( indexX + 1);
}
drawLine(newPos.x, newPos.y );
// Serial.println("ok");
actuatorPos.x = newPos.x;
actuatorPos.y = newPos.y;
break;
}
break;
case 'M':
buffer[0] = line[ currentIndex++ ]; // /!\ Dirty - Only works with 3 digit commands
buffer[1] = line[ currentIndex++ ];
buffer[2] = line[ currentIndex++ ];
buffer[3] = '\0';
switch ( atoi( buffer ) ){
case 300:
{
char* indexS = strchr( line+currentIndex, 'S' );
float Spos = atof( indexS + 1);
// Serial.println("ok");
if (Spos == 30) {
penDown();
}
if (Spos == 50) {
penUp();
}
break;
}
case 114: // M114 - Repport position
Serial.print( "Absolute position : X = " );
Serial.print( actuatorPos.x );
Serial.print( " - Y = " );
Serial.println( actuatorPos.y );
break;
default:
Serial.print( "Command not recognized : M");
Serial.println( buffer );
}
}
}
}
/*********************************
* Draw a line from (x0;y0) to (x1;y1).
* int (x1;y1) : Starting coordinates
* int (x2;y2) : Ending coordinates
**********************************/
void drawLine(float x1, float y1) {
if (verbose)
{
Serial.print("fx1, fy1: ");
Serial.print(x1);
Serial.print(",");
Serial.print(y1);
Serial.println("");
}
// Bring instructions within limits
if (x1 >= Xmax) {
x1 = Xmax;
}
if (x1 <= Xmin) {
x1 = Xmin;
}
if (y1 >= Ymax) {
y1 = Ymax;
}
if (y1 <= Ymin) {
y1 = Ymin;
}
if (verbose)
{
Serial.print("Xpos, Ypos: ");
Serial.print(Xpos);
Serial.print(",");
Serial.print(Ypos);
Serial.println("");
}
if (verbose)
{
Serial.print("x1, y1: ");
Serial.print(x1);
Serial.print(",");
Serial.print(y1);
Serial.println("");
}
// Convert coordinates to steps
x1 = (int)(x1*StepsPerMillimeterX);
y1 = (int)(y1*StepsPerMillimeterY);
float x0 = Xpos;
float y0 = Ypos;
// Let's find out the change for the coordinates
long dx = abs(x1-x0);
long dy = abs(y1-y0);
int sx = x0<x1 ? StepInc : -StepInc;
int sy = y0<y1 ? StepInc : -StepInc;
long i;
long over = 0;
if (dx > dy) {
for (i=0; i<dx; ++i) {
myStepperX.onestep(sx,STEP);
over+=dy;
if (over>=dx) {
over-=dx;
myStepperY.onestep(sy,STEP);
}
delay(StepDelay);
}
}
else {
for (i=0; i<dy; ++i) {
myStepperY.onestep(sy,STEP);
over+=dx;
if (over>=dy) {
over-=dy;
myStepperX.onestep(sx,STEP);
}
delay(StepDelay);
}
}
if (verbose)
{
Serial.print("dx, dy:");
Serial.print(dx);
Serial.print(",");
Serial.print(dy);
Serial.println("");
}
if (verbose)
{
Serial.print("Going to (");
Serial.print(x0);
Serial.print(",");
Serial.print(y0);
Serial.println(")");
}
// Delay before any next lines are submitted
delay(LineDelay);
// Update the positions
Xpos = x1;
Ypos = y1;
}
// Raises pen
void penUp() {
penServo.write(penZUp);
delay(penDelay);
Zpos=Zmax;
digitalWrite(15, LOW);
digitalWrite(16, HIGH);
if (verbose) {
Serial.println("Pen up!");
}
}
// Lowers pen
void penDown() {
penServo.write(penZDown);
delay(penDelay);
Zpos=Zmin;
digitalWrite(15, HIGH);
digitalWrite(16, LOW);
if (verbose) {
Serial.println("Pen down.");
}
}
Réparation et remise en fonctionnement d’imprimantes 3D
Dans le contexte du projet développement du deuxième semestre de la formation d’ingénieur généraliste d’IMT Atlantique, nous avons réparé puis remis en fonctionnement deux imprimantes 3D.
Imprimantes 3D – Projet DEV – FIG S2
Ces imprimantes, commandées par la mairie de Brest, seront installées dans des lieux publiques et à destination du grand public. Ainsi il faut qu’elles soient simples d’utilisation et facilement réparables par un personnel qualifié. Elles ont fait l’objet d’une première tentative de montage il y a plusieurs années, au Fablab de l’école, mais celui-ci n’a jamais été finalisé. Depuis, elles ont été entreposées dans un coin du Fablab, et ont souffert de pillage, les utilisateurs se servant dans ses composants pour leurs activités. Notre projet se place donc dans la lignée de ce qui a été fait précédemment sur ces machines.
Les imprimantes ayant été commandées par la ville de Brest, la mairie est le client du projet. Cependant le Fablab de l’école, et ses responsables, ont été nos interlocuteurs durant le déroulé du projet. Ainsi c’est avec eux que nous avons pu définir dans un premier temps un cahier des charges. Ce document nous a permis de définir clairement les tâches à accomplir.
Nous avons commencé par démonter les deux imprimantes, afin de ne garder que leur ossature. Un inventaire détaillé des pièces présentes à pu être ainsi fait. En parallèle de cette tâche, dès qu’une pièce électronique était jugée défectueuse, nous la réparions, en utilisant le plus possible le matériel déjà existant. Une fois ces deux tâches terminées, nous nous sommes attaqués au remontage d’une première imprimante. Lors de celui-ci, nous nous sommes aperçus que les pièces supportant les moteurs souffraient d’un défaut d’impression conduisant à une déformation de celles-ci. Nous avons donc décidé de les réimprimer en utilisant les imprimantes 3D du Fablab. Cette partie a été la plus longue car nous avons été confrontés à de nombreux problèmes techniques qui nous ont empêchés d’imprimer correctement ces pièces. Nous avons donc décidé de contacter des connaissances à l’EESAB, l’UBO et aux Petits Débrouillards, afin de savoir de leur demander de l’aide sur l’impression de nos pièces. En parallèle, nous avons décidé de remonter entièrement une imprimante avec les pièces défaillantes, dans la mesure du possible, en attendant de pouvoir résoudre nos problèmes. La seconde imprimante a été remontée depuis le début, ossature comprise, afin de permettre la prise de photos pour la documentation que nous avons fourni.
Une vidéo à été réalisée lors du test de l’imprimante remontée. Elle est disponible ici : test_imprimante_3D.
Nous nous sommes de plus engagés à rédiger un manuel. Celui-ci a pour but de permettre le montage et la réparation des imprimantes. Nous sommes entre-temps tombés sur une page de wiki suffisamment complète, détaillant pas à pas les étapes du montage pour la version 2.5 des imprimantes Foldarap. Cette page de wiki est disponible sur le site du wikifab. Notre manuel de montage renvoie donc vers cette dernière page. Le reste de son contenu consiste en un inventaire complet des pièces nécessaires aux montage de l’imprimante RepRap FoldaRap 2.5, celui-ci se découpant en deux sous-parties : un inventaire des composants regroupés par catégories et un inventaire sectionné selon les différentes parties de l’imprimante. Les deux sous-inventaires avaient été rédigés en anglais pour être compréhensibles par tous les membres de l’équipe. Seul le deuxième, l’inventaire par parties, a été traduit en français dans sa quasi-totalité. Le reste du document est composé de méthodes que nous avons mises en œuvre lors du montage et de la réparation des imprimantes. Nous les avons pensé utiles pour toute personne novice dans l’utilisation des outils que nous avons pu employer.
Détection de mouvement 3D appliquée à un jeu vidéo
Notre projet [1] consiste en la création d’un système de détection de mouvements 3D appliqué à un jeu vidéo avec le mouvement de la main.
Nous avons constaté que les technologies Kinect sont couteuses et complexes pour beaucoup. Nous avons donc souhaiter dans notre projet, modéliser notre propre système de détection de mouvement. Le montage a ainsi l’avantage d’être facilement réalisable. et nous avons codé un jeu vidéo comme 1ère application de ce système.
Figure 1 – Le projet (interface du jeu vidéo à gauche et montage à droite avec la main d’un joueur)
Pour réaliser le montage [2], on a besoin de :
– 6 résistances : 3 x 220K , 3x10K
– Une carte Arduino
– 3 Pinces Crocodile
– Des files
– 3 Plaques en bois
– Feuilles Aluminium
Figure 2 – Montage physique
Le montage physique consiste en la réalisation du circuit suivant:
PLATE1, PLATE2, PLATE3 correspondent aux plaques de bois couvertes par le papier aluminium et connectées par les pinces crocodiles.
PIN8, PIN9, PIN10 correspondent aux portes de la cartes Arduino.
Nous constituons d’une part la partie création du système de détection de mouvement et d’autre part réalisons la conception et code du jeu vidéo.
Tout d’abord, pour le système de détection de mouvements 3D il faut réaliser le montage physique et électrique. Constitué des plaques de bois et des feuilles d’aluminum, c’est plutôt rapider de réaliser la boite [2]. Nous avons accroché les pinces crocodiles à chacune des plaques avec des files accrochés à ces pinces.
Cela demande un travail plus minutieux pour le montage électrique en effet, nous avions 6 résistances (3 de 220K ohms et 3 de 10K ohms) que nous devions connecter à la carte d’Arduino et aux files connectés à la plaque.
Puis, nous avons codé en Arduino un programme permettant de récupérer les temps de décharge des feuilles d’aluminum selon le mouvement de la main dans la boite en temps réel (temps de réponse de 0,1s). Alors avec un calibrage est réalisé pour faire une analyse des valeurs obtenues en temps réel pour enfin obtenir la positon de la main dans les coordonnées cartésiennes (x, y, z). On a déterminé des valeurs de seuil pour diviser la boite deux parties : une zone haute et une zone basse selon la position de la main.
Ensuite la partie conception du jeu vidéo est réalisée en Python avec le module Pygame. Pour la première application du jeu vidéo , nous voulons un jeu vidéo avec un avatar qui bouge seulement selon un plan horizontal. Le joueur avec sa main peut contrôler la positon verticale de l’avatar qui avance de gauche à droite avec une vitesse qui augmente linéairement.
L’une des plus grosses difficultés est de réaliser la connexion entre les deux parties de notre projet : la carte Arduino qui rend compte des mouvements du joueur et le jeu vidéo. Il est facile de trouver des tutoriels sur internet proposant de coder un script Python permettant d’aller lire les informations sur le port série via lequel la carte Arduino transmet les informations. Cependant dans notre projet nous utilisons aussi une librairie nécessaire pour coder le jeu : Pygame. Il y a une mauvaise interaction entre ces deux parties du code : si une même action peut être réalisée par une frappe de clavier (ceci est un « événement » dans la terminologie Pygame), et par une lecture port série, il y a un conflit et cette dernière s’arrête. La solution (qui nous a pris longtemps à trouver !) tient à simplement supprimer les doublons : une action n’est désormais liée qu’à une seule condition, soit une action sur l’ordinateur, soit un mouvement du joueur. Le simple fait de ne pas proposer deux façons de piloter notre petit Gandalf était donc la meilleure manière de rendre notre
code fonctionnel.
Durant notre projet, nous nous sommes principalement concentrés sur la partie détection. Si à l’avenir un groupe d’élèves souhaiterait continuer le projet, il peut être très facile de ne pas réitérer nos recherches sur cette partie et de l’exploiter directement : le code sera à votre disposition. Il serait donc possible de travailler sur un jeu plus « fin ». En effet, notre système est suffisamment précis pour multiplier les commandes (nous ne proposions que deux positions, haute et basse). L’utilisations de deux modules de détections (un pour chaque main) permettrait de doubler les possibilités de pilotage. Il devient clairement envisageable de piloter un jeu de plateforme. Si le projet vous intéresse et que vous avez des questions, n’hésitez pas à nous joindre !
Vidéo de présentation
Code + explications :
https://github.com/isival/Detection-de-mouvement-3D-appliquee-a-un-jeu-video
Auteurs :
BONAUD Victoire
EL BEJI Sarah
FAVIER Mathis
VALETTE Isidore
Médiation scientifique au collège Kerallan avec Nao le Robot
Sous la supervision de Mathilde Ménoret et Sylvie Kérouedan nous avons, dans le cadre de notre projet de Développement de première année, mené à terme un projet de médiation scientifique auprès d’une classe de cinquième d’un collège local (Kerallan).
Objectif :
L’objectif était de rendre accessible la programmation et la robotique à des enfants qui n’ont pas encore un solide bagage scientifique. Il fallait pour cela vulgariser, voire démystifier, la robotique et la programation, qui passent, à tort, pour difficiles, sinon inaccessibles. Pour cela, nous avions prévu de faire une présentation interactive avec ladite classe de collège. La présentation se devait de mobiliser les élèves, et de les amener à réfléchir pour qu’ils programment, de manière simplifiée, le robot humanoïde Nao.
Aperçu du programme par blocs que nous avions écrit
Déroulement
Dans un premier temps, nous nous sommes familiarisés avec le robot. Pour cela nous avons du apprendre à nous servir de Chorégraphe, le logiciel fourni par le créateur du robot (Aldebaran Robotics), qui permet entre autres de faire de la programmation par blocs.
Après cette phase de prise en main, nous avons entamé une phase de réflexion sur ce que la présentation devant la classe de collège devait contenir. Nous avons donc défini des objectifs pédagogiques précis. Cela s’est traduit par des exercices de niveau progressif, que les élèves allaient devoir résoudre grâce à des cartes représentant les blocs présent dans le logiciel Chorégraphe. Pour introduire ces exercices devant les élèves, nous avons programmé Nao pour qu’il soit capable de se présenter lui-même à l’oral, ainsi que d’expliquer quelques principes sur son fonctionnement mécanique et informatique. En parallèle de la prise de parole de Nao, nous avions préparé un support visuel qui permettait aux élèves de mieux appréhender les différentes parties du robot et ses composants.
Le jour J
Le jour de la présentation, l’important était à notre avis d’être véritablement acteurs de l’enseignement que nous proposions. Nous avions réparti la classe en plusieurs groupes de 4 élèves. Grâce à cela, nous avons pu faire le tour des groupes lors de la résolution des différents exercices, pour expliciter les points qui restaient obscurs, et expliquer des notions plus avancées aux élèves avec des facilités. La phase d’exercices était précédée de phases d’explications des notions algorithmiques de boucle et de conditions. Nous faisions ces explications au tableau, en essayant de prendre des exemples parlants pour les élèves. Chaque exercice était suivi d’une correction, où les élèves pouvaient voir le résultat de leur réflexion s’animer à travers Nao, que nous programmions de manière à effectuer les programmes proposés par les élèves. Lorsqu’une interaction humaine était nécessaire pour tester le robot, les élèves se pressaient pour se porter volontaires et tester grandeur nature le programme qu’ils venaient d’écrire.
Pour plus d’informations, rendez-vous sur notre GitHub : https://github.com/mithridate-lulwat/DEV
Moad Yakoubi, Amine Dassouli, Saïf-Eddine Boukhdir
Élèves ingénieurs généralistes 1A
Projet Développement : Robot suiveur d’utilisateur
Equipe :
Paul PAQUIN, étudiant en 1ère année à IMT Atlantique
Grégoire PICHEREAU, étudiant en 1ère année à IMT Atlantique
Baptiste SCHMITT, étudiant en 1ère année à IMT Atlantique
Ruyi ZHENG, étudiant en 1ère année à IMT Atlantique
I – Contexte
Durant le cursus Ingénieur généraliste de l’IMT Atlantique, les élèves doivent réaliser un projet Développement. C’est dans ce cadre que nous avons proposé notre propre projet : Construire un robot capable de suivre de lui même un humain et de porter une charge. L’idée derrière ce projet est de développer une solution pour les personnes à handicap moteur. En effet, ceux ci peuvent se retrouver en difficulté dans beaucoup de situations de la vie courante.
Ainsi, nous avons réalisé un prototype qui grâce à des modules de magnétométrie et de GPS est capable de se localiser. Nous avons ensuite développé une application Android capable de se connecter au robot et de donner sa position. Grâce à ça, le robot peut alors suivre l’utilisateur.
II – Réalisation
– une plaque de contreplaqué de 2 centimètres d’épaisseur pour servir de support
– deux planches de bois 20×5×5 cm
– deux planches de bois 10×5×5 cm
– quatre planches de bois 25×7×1 cm
– deux moteurs de la gamme Maxon Motor A-max Program de 12 V
– deux roues de 10 cm de haut
– une roue non motrice qui se met sous le châssis
– deux adaptateurs moteur-châssis créés à l’aide d’une imprimante 3D
– deux adaptateurs moteur-roue créés à l’aide d’une imprimante 3D
– une batterie lithium-polymère TURNIGY 1000mAh trois cellules de 11.1 v
– une carte Arduino Uno
– une breadboard
– un magnétomètre Adafruit HMC5833l
– un module Parallax PAM-7Q pour le GPS
– un module Bluetooth HC-05
– une carte L298N
– un smartphone Android
– des vis et des câbles
2 ) Plateforme
Nous avons décidé de concevoir un châssis en bois à deux étages. Le premier étage servant au transport du système de positionnement embarqué ainsi qu’à celui des batteries, le second couvrant le premier, ayant lui pour but de servir de support où l’on pourrait déposer la charge.
Pour soutenir le châssis et pour le mettre en mouvement nous avons convenu de fixer sur les côtés avant deux moteurs de la gamme Maxon Motor A-max Program de 12 V chacun reliés à des roues de 10 cm de haut, fixe sur axe ainsi qu’en polypropène et en caoutchouc. Enfin nous avons décidé de placer une dernière roue non motrice, une roulette pivotante en caoutchouc à l’arrière du véhicule.
Pour faciliter la suspension des moteurs au bas du châssis nous avons convenu de modéliser des supports pour moteurs. De même, nous avons choisi de concevoir des adaptateurs entre les moteurs et les roues pour améliorer la transmission. La réalisation de ces parties s’est faite sous SolidWorks. Nous avons aussi pu retravaillé certaines pièces déjà à disposition sur des sites dédiés comme Thingiverse tant les moteurs et les roues que nous avions choisi semblent être des standards dans le milieu de la conception robotique amateur.
Une fois réalisées, les pièces sont alors converties en fichier .stl, format lisible par l’imprimante 3D que nous utilisons, une Ultimaker 2+. Le traitement de ses fichiers s’est fait par le logiciel dédié Ultimaker Cura permettant de visualiser la future impression 3D et ainsi de repositionner la pièce si sa disposition n’est pas optimale, d’ajouter un support pour stabiliser l’impression mais surtout de voir si il est possible ou non de réaliser une impression sans problèmes (les morceaux de la pièce ne pouvant être imprimés s’affichant en rouge dans le logiciel).
On place ensuite les moteurs à courant continus dans les supports en plastique dédiés imprimés par l’imprimante 3D, pour bien fixer les moteurs il est possible de visser les supports pour resserrer le tout. On ajoute alors les adaptateurs entre les moteurs et les roues, eux aussi imprimés en 3D, qu’on visse alors dans les adaptateurs de hub et dans les roues en plastique.
On a alors le premier étage de la maquette qui contiendra tout le matériel nécessaire pour la détection de l’utilisateur et la commande des moteurs. On réalise alors un second étage pour pouvoir disposer la charge. Afin d’observer les composants et de vérifier leur bon fonctionnement durant un essai on opte pour une plaque de plastique en tant que capot pour le premier étage. Une fois installée et vissée on rajoute des plaques de bois tout autour de la plateforme pour servir de rebord de manière à ce que la charge ne puisse pas tomber.
3 ) Code Arduino
Comme le projet contient de nombreuses fonctionnalités, et que beaucoup de composants fonctionnent différemment, nous avons choisi de programmer le code, qui sera téléversé dans le robot, par classe. En effet, cela permet de tester séparément chaque fonctionnalité avant de les mettre ensemble. Ainsi, le code est facilement debuggable et on peut s’y retrouver bien plus facilement.
Pour ce faire, nous avons écrit des classes en langage C++, que l’on a ensuite placées dans le répertoire Librairie du dossier Arduino.
Enfin, un code Arduino va importer les classes nécessaires et va les appeler selon ses besoins.
Le code est présent sur le GitHub ici.
4 ) Electronique
a . Module L298N
Le prototype se déplace à l’aide de 3 roues: 1 roue pivotante et 2 roues motrices. Les moteurs sont alimentés par une batterie lithium-polymère TURNIGY 1000mAh trois cellules de 11.1 v. Etant donné la taille de notre prototype, nous avons décidé d’utiliser un module « Double Pont-H » de type L298N destiné au contrôle des moteurs continus (des Maxon A-motor DC) pour sa facilité d’utilisation et sa compatibilité avec la carte Arduino Uno que nous utilisons.
Cette carte est composée de 3 pins par moteur : 2 pins contrôlent le passage du courant dans les deux fils reliant la carte L298N au moteur et 1 pin PWM qui est utilisée pour contrôler la vitesse du moteur.
Les pins IN1, IN2, ENA sont reliés aux pin de l’arduino 7, 8 et 5; et gèrent le moteur A.
De même, les pins IN3, IN4, ENB sont reliés aux pin de l’arduino 12, 4 et 9; et gèrent le moteur B.
Pour contrôler les moteurs, puis la plateforme, nous avons créé des bibliothèques Arduino spécifique. Nous disposons ainsi d’une classe Moteur qui permet de contrôler facilement les moteurs à partir d’un nouveau sketch Arduino, et d’une classe Plateforme qui permet de contrôler aisément l’interaction entre les deux roues.
A noter que cette Plateforme est la classe mère de PlateformeIntelligente qui permet aussi de rejoindre un point dont on connaît la distance et l’angle entre le vecteur robot-point et la médiatrice du segment joignant les deux roues du robot.
b . Module Adafruit HMC5833l (magnétomètre)
Pour calculer l’angle entre la médiatrice du segment joignant les deux roues arrières du robot et l’utilisateur, nous utilisons un intermédiaire, le pôle nord, dont la mesure est plus précise grâce à l’utilisation du champ magnétique terrestre. Pour ce faire, nous utilisons donc un magnétomètre (module Adafruit HMC5833l).
Ce magnétomètre est posé à l’horizontal au même endroit que l’arduino. Nous avons dû le tester et changer son orientation pour que le magnétomètre donne des mesures cohérentes avec nos calculs. C’est à dire que nous avons placé le magnétomètre de sorte que lorsque le robot soit dirigé vers le pole nord, l’angle mesuré soit égal à 0. Le magnétomètre a ensuite été fixé pour conserver cette cohérence. En effet, toute erreur sur l’orientation de référence de celui-ci entraîne une erreur sur la mesure.
Le magnétomètre est relié aux pins analogiques A4 et A5 de l’arduino par ses pins SCL et SDA. Pour récupérer les mesures du magnétomètre, nous avons créé une classe, MagneticRead, qui renvoie la valeur en degré ou en radian selon la méthode appelée du heading (le heading étant la direction selon laquelle le véhicule est dirigé)
c . Module Parallax PAM-7Q pour le GPS
Le module GPS que nous utilisons pour le projet est le module Parallax PAM-7Q. Il se situe sur la même breadboard que le magnétomètre.
Le gps utilise la pin digital numéro 6 de l’arduino relié à la pin TX du module.
Les mesures du gps sont elles aussi récupérées à l’aide d’une classe que nous avons créée. Au départ, nous comptions utiliser une classe déjà développée pour ces besoins, nommé TinyGPS.
Malheureusement, nous n’avons pas réussi à la faire fonctionner, nous avons donc utilisé la bibliothèque SoftwareSerial pour récupérer les données gps brutes et les traiter dans notre classe GPS (c’est à dire récupérer les informations utiles).
Nous avons aussi testé les conditions de fonctionnement du gps. Nous nous sommes vite rendus compte que le gps ne fonctionne qu’en extérieur. Celui-ci semble de plus continuer de fonctionner en cas de pluie légère et de temps nuageux.
d . Module Bluetooth HC-05
Grâce à la technologie Bluetooth, de nombreuses informations peuvent transiter entre le smartphone de l’utilisateur et le robot.
La pin RX du module est connectée à la pin 11 de l’arduino tandis que la pin TX du module est connectée à la pin 10 de l’arduino.
Une bibliothèque, CommunicationManager, a été développé pour récupérer les informations en provenance du Bluetooth et les interprète selon un protocole de communication.
e . Capteur ultrason HC-Sr04
Nous avons ajouté des capteurs ultrasons HC-Sr04 au robot qui mesurent la distance entre le robot et l’obstacle. Les bornes de « trigger » et d’« écho » sont reliées à la pin digital 13.
Pour contrôler ces capteurs et récupérer les mesures réalisées, nous avons utilisé la classe Capteur présente de base dans la bibliothèque arduino. Les différentes réactions du robot en fonction de la distance avec l’obstacle sont présentes dans la classe plateforme.
Ainsi, toute cette partie n’est pas visible dans le sketch final, mais est présente dans la classe PlateformeIntelligente. C’est d’ailleurs ce fait qui justifie l’écriture de cette classe héritée : le comportement de cette classe, qui arrête le robot dès qu’un obstacle est détecté était nuisible pour notre phase de test. Le robot s’arrête ainsi en cas d’obstacle présent à une distance inférieure à 30 centimètres, fait tourner ses capteurs pour détecter une voie où il n’y a pas d’obstacle et se déplace dans cette direction.
f . Schéma des branchements
5 ) Interface Android
Afin de permettre au robot de suivre automatiquement les mouvements de l’utilisateur, nous avons besoin d’un appareil mobile capable d’envoyer des informations de localisation. Nous avons donc créé une application pour smartphones Android avec Android Studio. Application et robot communiquent via Bluetooth, l’application obtient l’information de la position via GPS, et la direction (heading) de l’utilisateur via la boussole interne du mobile (compass).
Ensuite, l’application envoie les informations au robot via le canal Bluetooth, en même temps le téléphone mobile reçoit également des informations envoyées par le robot. L’application peut analyser le message et afficher la distance et la puissance sur l’interface Androïde. Afin de s’assurer que chaque fonction peut être réalisée, nous allons faire une application distincte pour chaque fonction, y compris la communication Bluetooth, GPS, Boussole.
Ayant rencontré des difficultés pour écrire une application Bluetooth, nous avons décidé de ne pas rechercher la totalité des appareils Bluetooth à proximité. Cependant, la recherche d’autres appareils utilisant Bluetooth effectuée par le téléphone portable permet de trouver le module Bluetooth (HC-05) de la plateforme. Après recherche, nous avons résolu le problème.
Depuis, l’application peut rechercher, se connecter et créer un canal Bluetooth pour échanger des informations.
La plupart des smartphones modernes sont équipés d’un GPS qui fonctionne avec deux modes, le mode réseau et le mode satellite : le mode réseau utilise des méthodes de ciblage et est utilisé en intérieur, car le signal satellite est faible, ce qui impacte la précision de localisation. Or, les méthodes implémentées dans ce mode ont une efficacité indépendante à la qualité de réception. Il est cependant impossible d’obtenir les informations relatives à la direction. Quand il est à l’extérieur, le positionnement par satellite est utilisé. En raison de son positionnement rapide et sa grande précision, des informations importantes telles que la direction et la vitesse peuvent être obtenues.
Comme précédemment mentionné, le GPS ne peut pas obtenir d’informations de direction dans le contexte de positionnement par réseau, d’autres méthodes sont donc nécessaires pour obtenir la direction. Heureusement, la plupart des téléphones mobiles ont une fonction de boussole, et nous pouvons donc obtenir cette information capitale.
Dans le processus de communication Bluetooth, deux canaux (des threads) sont demandés : le premier est utilisé pour envoyer les informations de localisation toutes les trois secondes, le second reçoit les informations envoyées par le robot et affiche l’interface après le traitement. Cela nécessite des capacités de multithreading, malheureusement nous ne disposions pas des connaissances relatives à implémentation de cette technique. Cependant, nous avons trouvé une bibliothèque traitant spécifiquement le multithreading ce qui nous a permis de mettre en place cette fonction.
Afin d’échanger des informations sans problèmes avec le robot, nous avons conçu un protocole de communication pour réguler la structure de l’information.
La plupart de nos fonctions ont été implémentée et deux affichages ont été développés selon que le robot est en mode suivi ou en mode contrôlé par l’utilisateur.
6 ) Protocole de communication
Grâce à la technologie Bluetooth, de nombreuses informations peuvent transiter entre le smartphone de l’utilisateur et le robot. Ces informations ainsi que leurs impacts sur le fonctionnement du robot et de l’application sont très variés. Cela impose que chaque type d’information ait un format reconnaissable parmi les autres.
Cependant, comme les équipes chargées de développer la partie application Android et la partie code Arduino ne sont pas les mêmes, il convient de rédiger un unique protocole de communication respecté par toutes les équipes. Un tel protocole garantit non seulement que les formats d’une information donnée soit les mêmes pour l’émetteur et le récepteur mais il a aussi la capacité d’évoluer si de nouvelles fonctionnalités venaient à être implémentées sur le robot.
La spécification du protocole choisie ne retransmet aucun message perdu ou erroné durant son trajet. En effet, un mécanisme de retransmission pourrait rendre le robot beaucoup moins réactif.
Toutes les informations suivent le format suivant : ‘#’ + type + ’\’ + Données + ‘$’
Les champs ‘type’ et ‘données’ varient selon le type de donnée envoyée tandis que ‘#’ et ‘$’ indiquent respectivement le début et la fin du message. Le récepteur sait alors si le message qu’il a reçu est complet ou non. De plus si le champ ‘données’ contient plus qu’une seul donnée alors celles-ci sont séparées par un symbole ‘\’ pour bien faire la distinction.
Le détail du protocole est présent sur le GitHub ici.
III – Résultats
Notre projet de réalisation d’un robot suiveur d’utilisateur assisté de son application compagnon s’est soldé par la mise en place de systèmes embarqués placés dans une plateforme construite en bois et en plastique et dont les composants sont appairés au smartphone de l’utilisateur.
Un des critères de fonctionnement du robot qui fait défaut au prototype est sa précision, notamment du à l’approximation de l’ordre du mètre des GPS modernes.
En effet la solution technique utilisée semble améliorer la précision de la course du robot cependant on peut rester mitigé sur les déplacements en intérieur tant le GPS voit son efficacité diminuée dans la majorité des bâtiments.
Finalement, il semble que le projet puisse être amélioré en intégrant une alternative au GPS en intérieur et en prenant une Arduino Mega parce qu’elle permet de mettre plus de composants nécessitant des protocoles de communication.
Wieczny Bùshǔ
Présentation du projet
Dans le cadre d’un projet de partage de connaissances, il a été offert aux élèves de l’IMT-Atlantique Brest, en partenariat avec des élèves de 3ème année de l’École Européenne Supérieure d’Art de Bretagne (EESAB) suivant l’option Design, de donner vie à un lieu central du campus de Brest de IMT Atlantique : le Centre-Vie ; ce lieu convivial à la frontière entre espace de travail et espace de détente. Les contraintes étaient telles que nous devions construire une structure « éco-conçue », pour la majeure partie faite de bois de peuplier. Le partage d’idées et notre collaboration nous aura orientés vers la conception d’une lampe évoluant selon la période de la journée.
Le temps imparti était de 9 jours. Tandis que Mathilde Dutilly, Alexandre Nmett et Tyfenn Le Luc, tous trois élèves de l’EESAB, se préoccupaient de mener à bien la partie Design du projet en agençant le squelette de notre lampe évolutive, Zine-Eddine Biad et moi-même (Samuel Rivoal), élèves de 1ère année à l’IMTA, nous sommes attelés à ce que la partie technique du projet soit opérationnelle pour soutenir et mouvoir la structure. L’aboutissement du projet aura notamment reposé sur la grande disponibilité et l’expertise des encadrants de cet inter-semestre, responsables du fablab, que nous remercions d’ailleurs chaleureusement.
Notre cahier des charges
Le cahier des charges que nous nous étions fixé pour ce prototype était d’obtenir une structure qui se déploie le matin (de 8h à 12h) pour se refermer sur elle-même l’après-midi (de 14h à 18h), à la manière d’une fleur, la comparaison étant d’autant plus justifiée que nous avions voulu un déploiement lent, presque invisible sur une courte période de quelques minutes. À cela s’ajoute la fonctionnalité de passer d’une illumination bleue le matin à une lumière orange, 13h sonnant. Ainsi, le visiteur temporaire du Centre-Vie sera surpris, la pause de 16h venue, de tomber sur une lampe toute autre que celle qu’il avait laissée en traversant le Centre-Vie le matin.
La lampe est branchée à l’alimentation secteur et doit être synchronisée via une application Android à chaque allumage pour remplir ses fonctions.
Le matériel utilisé
Afin d’y parvenir, le matériel électronique déployé était le suivant :
- une carte Arduino UNO ;
- un module bluetooth HC-05 ;
- un téléphone sous Android ;
- 3 anneaux de 24 neopixels ;
- une Breadboard (optionnel) ;
- un transformateur électrique de 220V AC -> 12V-1A DC pour le moteur ;
- un pont-H L298N ;
- un moteur bipolaire EM-484 ;
- un set de câbles mâle-mâle et mâle-femelle.
Détails techniques
Les anneaux Néopixel
Les anneaux Neopixel sont chacun reliés à un pin différent de la carte arduino pour permettre une évolution de l’intensité lumineuse de chaque anneau indépendamment des autres. L’intensité lumineuse de chacun se décline entre trois niveaux différents, s’illuminant du niveau d’intensité moindre vers le niveau d’intensité le plus important, et ainsi de suite.
Le système de traction
La question de la traction des pales supérieures aura pris le plus de temps à résoudre. Les 20 pales sont chacune fixée à un fil de pêche en nylon pour une robustesse suffisante. Le promontoire de bois qui se dégage de la partie haute de la structure permet une traction plus facile des pales, et aussi d’amener les pales le plus haut possible. Au centre de la structure, un tuyau de métal abrite la vingtaine de fils de nylon, reliés à un anneau d’environ 1 cm de diamètre, lui-même relié à un simple fil de nylon, ce qui permet d’éviter des nœuds inévitables lorsque l’on a tant de fils à tracter. Au bas du tuyau de métal, ce fil passe enfin dans une petite poulie du type de celles que l’on trouve sur les cannes à pêche. Le problème était alors de faire la jonction entre le moteur et le fil à tracter. Deux jours avant le vernissage, et donc l’échéance du temps imparti pour la réalisation du projet, nous a été suggéré l’idée d’utiliser un système reposant sur le mouvement d’une vis infinie. Le modèle 3D que nous avons ensuite imprimé, à l’échelle proposée, peut se trouver à cette adresse (https://www.thingiverse.com/thing:1607378). Le socle et la manivelle ne nous ont pas servi. Une poulie autour de laquelle va s’enrouler le fil de nylon, celui-ci étant fixé à l’aide d’un clou traversant la poulie, a été imprimée pour être fixée à l’engrenage. Un petit embout placé entre le moteur et la vis infinie permet de transmettre le mouvement du moteur à cette dernière. Ce système ingénieux permet non seulement un moindre effort pour tracter les pales, mais aussi de stopper tout le système lorsque le moteur ne tourne plus, entre 12h et 14h.
Le moteur
Le moteur choisi est un moteur bipolaire, pour un meilleur contrôle de la rotation. Il est piloté par un driver (le pont-H L298N) pour éviter, lors de la rotation du moteur, que la carte Arduino ne reçoive tout le courant emmagasiné dans le moteur, d’où l’intérêt du pont en H et des diodes du driver. Le contrôle du nombre de tour / minute se fait finalement expérimentalement en jaugeant, à partir de l’application Android, la vitesse du moteur et en calibrant à un le temps entre deux changements d’état, permettant ainsi de mesurer la rotation. Le courant transmis au moteur est sous forme de deux valeurs binaires : avec un jeu de paire (oui/non, oui/non), la rotation peut se faire dans un sens ou dans l’autre. Il ne reste donc qu’à calibrer le temps entre deux « steps » consécutifs pour avoir un contrôle en vitesse et en angle.
L’application Android
En addition aux fonctionnalités offertes par notre prototype, l’application permettant la synchronisation horaire (via le bouton « Envoyer l’heure » ) peut aussi permettre de rentrer dans un mode démonstratif des capacités de notre luminaire. Appuyez sur le bouton « Bluetooth » pour voir apparaître une liste détaillée des différents composants auxquels vous pourrez vous connecter, et ainsi choisir le composant utilisé ici. Il suffit d’appuyer sur le cercle chromatique pour voir la couleur de la lampe changer. Lorsque la case à côté de la jauge au bas de l’écran est cochée, vous pouvez régler la vitesse de fonctionnement du moteur, une vitesse positive provocant e soulèvement des pales, tandis qu’une vitesse négative provoque l’affaissement des pales. Le bouton « Stop » au-dessous permet un arrêt précis du moteur.
Ressources et liens
Application android et code arduino
Ces fichiers peuvent être trouvés dans le dossier se trouvant à l’adresse suivante :
https://drive.google.com/open?id=1jDvLkbTmOeljrEiYkG47wVWjnx6dcfgb
La connectique du driver
Lampe T19-8
Dans le cadre de l’intersemestre Design et Fablab, des étudiants de l’IMT Atlantique ainsi que des étudiants de l’École Européenne Supérieure d’Art de Bretagne (EESAB) ont été mis au défi de réaliser différents objets afin de revitaliser et mettre en valeur le patio situé au centre de vie de l’établissement de l’IMT Atlantique. Notre groupe, constitué de Matheus Bueno, Gabriel Canivet, Amélie Jouet et Guillaume Lebeau, a choisi de réaliser la lampe que nous avons nommé T19–8.
Matériel utilisé :
Fonctionnement :
– Arduino Uno
– Module RTC DS1307 alimenté par une pile CR1225
– Capteur de bruit « Sound Sensor »
– Un anneau de 12 néopixels, ainsi que 4 néopixels seuls
Corps de l’objet :
– 3 plaques de contreplaqué peuplier 30x45cm
– 8 aimants
Nous souhaitions que notre lampe présente un certain degré de changement durant la journée, d’éveiller une curiosité et un intérêt chez l’observateur. Des changements plus rapides, rappelant la respiration, animent et donnent vie à la scène, accueillant les visiteurs par une ambiance chaleureuse. Le corps de l’objet a été conçu par découpe laser et assemblé sans fixations particulières et est constitué de cinq modules séparés, pouvant se regrouper à l’aide d’aimants afin de former un tout. Le motif des objets, rappelle à la fois la forme organique des encéphalogrammes, mais aussi une onde s’aplatissant dans l’eau. La séparation en cinq modules, permet de démultiplier l’objet et d’occuper l’espace en lui donnant vie.
Notre lampe réagit aussi selon son environnement. Son intensité lumineuse va varier selon le bruit ambiant dans la pièce, s’affirmant plus le bruit est élevé. Ce changement subtil donne une capacité adaptative à la lampe.
Fonctionnement :
Le contrôle de la lampe est réalisé via Arduino. L’heure actuelle est récupérée à l’aide du module RTC qui est alors convertie en une couleur RGB par moyenne pondérée entre les deux couleurs de références enregistrées dans le programme. Le capteur de bruit « Sound Sensor » va lire le son ambiant afin de changer la luminosité moyenne de la lampe selon le bruit maximum enregistré. Une légère variation de luminosité va ensuite être ajouté sur les trois sources de lumières (centrale, modules intermédiaires et modules extérieurs). Ces petites variations sont indépendantes des la lampe et permettent trois types de variations : des ‘respirations’ synchronisées, un motif de vague se transmettant à travers les modules, et des variations indépendantes à des vitesse différentes.
Notre lampe T19–8 change donc avec le temps, le son ambiant donc avec les humains l’entourant. Les initiale de ces trois concepts forment le mot TSH, et en remplaçant les deux dernières lettre par leur position dans l’alphabet, T19–8.
Lien vers le code : intersemestre_T19_8
Feucenflamme
Projet d’intersemestre : Feucenflamme
Equipe
- Camille HABER, Étudiante en 3eme année de Design à EESAB
- Doriane LGDR, Étudiante en 3eme année de Design à EESAB
- Ivan-Clare NGONG, Étudiante en master 1 à IMT Atlantique
- Nathalie TA, Étudiante en 2eme année à IMT Atlantique
Contexte
Ce projet a été réalisé dans le cadre de l’intersemestre « Défi au fablab » qui avait pour thème cette année : « Economie de lumière : quand le numérique rencontre le design ». Le but de ce projet était de réaliser des points lumineux pour le centre-vie de l’IMT Atlantique (campus Brest).
Ainsi, pour ce défi, nous avons réalisé une structure imitant un feu de camp que nous avons placé dans le jardin du centre-vie. Ce feu de camp devait être en mouvement et lumineux afin d’imiter des flammes. De plus, notre feu était également en interaction avec le public car ce dernier pouvait l’allumer, l’éteindre ou le changer de couleur (rouge, orange et jaune) via notre application téléphone « Feucenflamme ».
Réalisation
a) Matériel :
- Un neopixel
- Un servo-moteur
- Une carte Arduino Uno
- Des fils de connexion
- Un téléphone muni du système Android
- Un émetteur/récepteur bluetooth : module HC-05 pour la connectivité
- Breadboard
b) Design
Notre feu est constitué de deux socles en forme d’étoile qui sont superposés (voir image ci-dessous). Ces deux socles sont séparés par un servo-moteur car nous avons décidé de mettre en mouvement de rotation le socle supérieur afin d’avoir un feu plus vivant et proche de la réalité.
Maquette en carton des deux socles superposés
Le socle du niveau inférieur a un trou en son centre afin de pouvoir positionner le moteur pour ne pas que le socle supérieur soit beaucoup plus haut que le socle inférieur. Le centre du socle supérieur a des petits trous afin de pouvoir passer les fils du neopixel qui est posé sur le socle supérieur.
Pour finir, la base de l’objet est un boitier dont le couvercle est le socle inférieur. Ce boitier nous permet de cacher tout le matériel électronique utilisé (fils, carte Arduino, le récepteur bluetooth et breadboard).
Nous avons choisi de faire les socles en forme d’étoile afin d’alléger notre objet, notamment pour le servo-moteur qui doit supporter le poids du socle supérieur. Dans les branches de l’étoile nous avons imbriqué nos planches de bois découpées en forme de flamme. Nous pouvons noter que les grandes flammes sont vides à l’intérieur, ce choix a permis d’alléger davantage notre structure.
Système d’encoche pour insérer nos flammes dans le socle. Les grandes flammes sont vides à l’intérieur contrairement aux petites qui sont pleines.
La position des flammes a été mise de telle sorte à ne pas bloquer le mouvement du socle supérieur. De plus, les différentes tailles de flammes ont été équiréparties entre chaque quart de socle afin d’avoir un socle équilibré.
Le neopixels sur le socle supérieur permet d’apporter de la lumière à notre feu. De plus, pour ajouter encore plus de lumière à notre feu nous avons mis des surfaces réfléchissantes à nos flammes pour qu’elles reflètent bien la lumière.
Pour faire le design et la réalisation de notre feu, nous avons utilisé illustrator, une découpeuse laser et du scotch double face.
Résultat final
c) Fonctionnement
- Application téléphone
Notre application pour Android (voir image ci-dessous), réalisée via MIT app inventor, permet de connecter le téléphone au bluetooth de notre feu et, une fois connecté, l’utilisateur peut faire les actions suivantes : allumer le feu, éteindre le feu et changer la couleur du feu.
De gauche à droite : page d’accueil de l’application, page pour se connecter et se déconnecter au bluetooth, page pour allumer, éteindre et changer la couleur du feu.
Les informations envoyées par l’application sont lues grâce au programme Arduino téléversé dans la carte.
- Le feu
Dès que le feu est allumé, le socle supérieur qui est collé au servo-moteur se met à tourner et fera des aller-retours en continu tant que le feu ne sera pas éteint. Les leds s’allument progressivement une à une puis certaines s’éteindront pendant que d’autres clignoteront et elles continueront ainsi tant qu’on ne lui dit pas le contraire. La couleur change dès que l’utilisateur le demande via l’application.
Prothèse végétale
Contexte
Dans le cadre d’une collaboration avec l’EESAB, école d’art et de design localisé à Brest, nous devions créer des objets qui revitaliserait et rendrait plus vivant le patio du centre vie de l’IMT.
Choix de cet objet:
L’idée initiale était d’utiliser des lumières, des ombres et des mouvements afin de répondre à cet objectif. Néanmoins, après une deuxième visite sur le site d’installation, nous avons remarqué que l’éclairage quotidien du lieu aux heures de fréquentation ne permettrait pas d’utiliser les ombres. Puis, après avoir étudié diverses possibilités, nous avons décidé de créer des feuilles en contreplaqué peuplier de la même forme que celles l’espèce monstera, en accord avec les plantes déjà présente dans le patio.
Réalisation:
Les plans des feuilles ont été réalisé en utilisant Illustrator, puis la découpe laser a donné la forme au bois. Le principal défi technique a été de donner le mouvement aux feuilles, étant donné les grandes dimensions de la feuille, environ 60 cm x 30 cm.
Deux solutions possibles ont été étudiées et prototypées. Une solution consistait à utiliser un petit moteur avec un poids couplé oscillant qui heurte la feuille et la fait vibrer. Pour cette solution, une carte prototype a été développée avec un driver de puissance pour piloter plusieurs moteurs, puisque l’intention était d’installer plus d’une feuille. La carte contenait un pont en H avec des transistor bipolaires. Néanmoins, pour avoir un mouvement visible avec les moteurs disponibles, il était nécessaire de se placer à la fréquence de résonance de la feuille.
La deuxième solution étudiée utilise des servomoteurs contrôlés en angle couplés à un système de poulie pour déplacer la feuille. Du fil de couture est attaché à une poulie à une extrémité et l’autre est attaché à la feuille. Lorsque le servomoteur tire sur le fil, la feuille est tiré vers le bas.
Cette solution a été développée avec une carte Arduino et des servomoteurs trouvés sur le TELEFAB. Après avoir évalué les résultats des tests pratiques des deux solutions par l’équipe de projet IMT Atlantique et EESAB, il a été conclu que la deuxième solution présentait un mouvement plus harmonique et esthétique. En effet, la fréquence de résonance de la feuille était trop haute, ce qui imposait un mouvement trop rapide. Par conséquent, la deuxième solution a été choisie.
Guide pour la réalisation de la partie technique:
Pour la mise en œuvre de la solution choisie sur les deux feuilles que nous possédions, les matériaux listés ci-dessous ont été utilisés:
- 2 kits Arduino Uno avec alimentations
- 4 servomoteurs contrôlés par logiciel
- câbles
- bandes de néopixels composé d’au moins 10 néopixels
- Fil de couture pour connecter les servomoteurs à l’arduino
- Impression 3D de 4 poulie
- Colle à chaud pour coller les matériaux (pistocolle)
Partie mécanique
Une fois le matériel à disposition, collez les néopixels sur le support, juste en-dessous de la feuille. Accrocher du fil de couture sur les parties de la feuille que vous souhaitez faire mouvoir. Nouez les fils de la partie droite ensemble et collez l’extrémité à la poulie. Faîtes de même pour la partie gauche. la poulie se colle sur un plateau qui s’emboîte dans le servomoteur. Ceux-ci sont vendus avec les servomoteurs. Vous n’avez plus qu’à fixer les servomoteurs sur le support pour terminer cette partie.
Partie électronique
Voici maintenant les différentes pins à relier pour que le code ci-dessous fonctionne.
| pin contrôle des néopixels | pin 2 de l’arduino |
| pin contrôle d’un des servomoteurs | pin 6 de l’arduino |
| pin contrôle de l’autre | pin 7 de l’arduino |
Une fois ces branchements faits, il reste ensuite à relier les masses et l’alimentation de l’arduino aux masses et VCC des néopixels et des servomoteurs.
Partie informatique
Dans le code que vous trouverez à la fin de l’article , en modifiant l’angle max vous pouvez diminuer l’amplitude des mouvements. En augmentant les delay, vous pouvez rendre le mouvement plus lent.
Exposition
Voici quelques photos de l’exposition du mercredi
Code
Voici le code permettant de faire mouvoir les deux côtés de la feuille de manière symétrique (Note : si le fil est tiré par la partie droite de la poulie d’un côté et par la partie gauche de l’autre côté alors ce code fait mouvoir la feuille de manière antisymétrique):
#include <Adafruit_NeoPixel.h>
#include <Wire.h>
#include <Servo.h>
//number of neopixels
#define NUMPIXELS 20
int pinLamp = 2;
int pinServo = 6;
int pinServo2 = 7;
Servo controleServo;
Servo controleServo2;
int pos;
int tempsDescente = 1500;
int pas = 3
;
int angleMax = 180;
int temps = 600;
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, pinLamp, NEO_GRB + NEO_KHZ800);
int calculDelay = 1000/(angleMax/pas);
void setup() {
// put your setup code here, to run once:
controleServo.attach(pinServo);
controleServo2.attach(pinServo2);
controleServo.write(0);
controleServo2.write(0);
pixels.begin();
for(int i=0;i<NUMPIXELS;i++){
pixels.setPixelColor(i, pixels.Color(80,255,0));
}
pixels.show(); // This sends the updated pixel color to the hardware.
}
void loop() {
// put your main code here, to run repeatedly:
for (pos = 0; pos <= angleMax; pos += pas) {
// tell servo to go to position in variable 'pos'
controleServo.write(pos);
controleServo2.write(pos);
// waits 20ms for the servo to reach the position
delay(20);
}
for (pos = angleMax; pos >= 0; pos -= pas) {
controleServo.write(pos);
controleServo2.write(pos);
delay(20);
}
}
[\cpp]
Voici le code permettant de faire mouvoir les deux côtés de la feuille de manière antisymétrique(Note : voir note précédente, ce code peut faire mouvoir la feuille de manière symétrique):
#include <Adafruit_NeoPixel.h>
#include <Wire.h>
#include <Servo.h>
#define NUMPIXELS 10
int pinLamp = 2;
int pinServo = 6;
int pinServo2 = 7;
Servo controleServo;
Servo controleServo2;
int pos;
int tempsDescente = 1500;
int pas = 3;
int angleMax = 180;
int temps = 600;
Adafruit_NeoPixel pixels = Adafruit_NeoPixel(NUMPIXELS, pinLamp, NEO_GRB + NEO_KHZ800);
int calculDelay = 1000/(angleMax/pas);
void setup() {
// put your setup code here, to run once:
controleServo.attach(pinServo);
controleServo2.attach(pinServo2);
controleServo.write(0);
controleServo2.write(0);
pixels.begin();
for(int i=0;i<NUMPIXELS;i++){
pixels.setPixelColor(i, pixels.Color(80,255,0));
}
pixels.show(); // This sends the updated pixel color to the hardware.
}
void loop() {
// put your main code here, to run repeatedly:
for (pos = 0; pos <= angleMax; pos += pas) { // goes from 0 degrees to angleMax degrees
controleServo.write(pos);
controleServo2.write(angleMax-pos);
delay(20);
}
for (pos = angleMax; pos >= 0; pos -= pas) {
controleServo.write(pos);
controleServo2.write(angleMax-pos);
delay(20);
}
}[\cpp]
Utilisation du mp3 player shield
La carte en question est le modèle sparkfun.com mp3 Player Shield 4-1-11. Elle permet de lire des fichier audios à partir d’une carte SD et a une prise jack pour un haut parleur classique.
Toutes les infos utiles sont sur ce site, avec un très bon tutoriel : https://learn.sparkfun.com/tutorials/mp3-player-shield-hookup
la carte est assez ancienne, et les librairies actuelles d’utilisation des fichiers lourds sur carte SD (libraries SdFat) n’est plus compatible. Retrouvez les librairies compatibles sur ce github : https://github.com/madsci1016/Sparkfun-MP3-Player-Shield-Arduino-Library/releases/tag/1.02.02 (mettre les dossier des librairies SdFat et SFEMP3Shield dans /home/fablab/sketchbook/librairies/)
(merci à ce forum pour l’aide : https://forum.arduino.cc/index.php?topic=517154.0)
