Fiches techniques: Capteur Humidité de Terre
Le Fablab possède différents capteurs d’humidité de terre. Ce sont des capteurs analogiques et peuvent tous être alimentés en 3.5V ou 5V.
-
Condition Min Max Unité Tension 3,3 5 V Courant 0 35 mA Valeur de sortie Le capteur dans un sol sec 0 300 Le capteur dans un sol mouillé 300 700 Le capteur dans l’eau 700 950
le branchement de capteur humidité de terre
Code d'Exemple pour afficher la valeur d'humidité
int MoisturePin = A1;
int MoistureValue = 0;
void setup() {
Serial.begin(9600);
}
void loop() {
// read the value from the Moistur sensor:
MoistureValue = analogRead(MoisturePin);
Serial.print("Moisture = " );
Serial.println(MoistureValue);
delay(1000);
}
Math Escape Room
Développement d’un jeu de type « Escape Room » par Lucas Bonmarin, Hélène Couret, Maximiliano Hill et Maher Ouali.
Résumé
Pour faciliter l’apprentissage des mathématiques, nous avons développé une application d’« Escape Room » qui permet : aux élèves de répondre à des énigmes pour s’échapper virtuellement de la maquette, aux enseignants de gérer les énigmes. Enfin l’application interagit aussi avec les autres éléments du jeu.
Contexte
Afin de rendre plus ludique l’apprentissage de leur matière, les professeurs du collège Saint-Pol de Roux à Brest nous ont demandé de concevoir une application de type « Escape Room » permettant de répondre à des énigmes mathématiques pour s’échapper d’une maquette domotique.
Architecture de l’application
Afin de réaliser ce jeu, nous nous sommes servis d’une application Android qui permet aux élèves de répondre aux énigmes pour avancer dans le jeu, aux enseignants de gérer les énigmes et enfin qui exécute les liens avec les autres éléments du jeu. En effet, cette application est reliée par Bluetooth à la maquette domotique et également au serveur qui accueille la base de données formée des énigmes.
Notre projet est donc composé de trois parties distinctes :
– l’application Android,
– la base de données qui stocke les énigmes et
– la maquette domotique.
Architecture
Base de données
La base de données stocke les énigmes. Elle contient une seule table appelé “énigmes”. Ces énigmes sont stockées sous la forme de files qui contiennent 4 colonnes :
– la question,
– la réponse correcte et
– deux réponses fausses.
Serveur WEB
Le serveur web dynamique prend en charge les requêtes client-serveur grâce au Daemon http (apache). Les scripts php interprètent ensuite les demandes des clients et les traduit.
Protocole Arduino
Le protocole de communication conçu spécialement pour ce projet permet de transmettre chaque tâche de l’application à la maquette de manière unique et fiable.
Maquette
Maquette domotique
La maquette est équipée d’actionneurs et de capteurs. Elle rend l’application interactive grâce à l’allumage de LED, l’ouverture d’un portail ou l’appui sur un buzzer.
5 LEDs
5 résistances d’environ 200 ohms (pour protéger les LEDs)
4 boutons poussoirs
1 buzzer
1 photo-résistance
Conclusion
L’application est fonctionnelle et la maquette aussi. Cependant, nous n’avons pas pu rencontrer les professeurs du collège Saint-Pol de Roux donc le projet pourrait être amélioré au cours de l’année prochaine pour pouvoir leur présenter.
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.
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)
Fête de la science 2017
Bonjour bonjour!
Comme chaque année partout en France du 7 au 15 octobre à lieu la fête de la science!
Comme chaque année Océanopolis coordonne cet événement pour le département du Finistère…
Et depuis 2 ans nous nous organisons avec l’UBO Open Factory et le département informatique de l’UBO pour proposer une animation sous le signe de la découverte de la robotique, de l’informatique et des machines de fabrication numérique :
LE FABULEUX LABORATOIRE!
Du 11 au 15 octobre nous serons donc à Brest, au Quartz (pour accueillir le public et leur présenter plein de petites choses très cool!
Nous accueillerons des scolaires le jeudi 11 et vendredi 12 octobre, de 9h à 16h.
(Environs 3500 enfants sur deux jours)
Le week-end c’est l’ouverture au grand public, de 10h à 18h.
Nous sommes entrain de préciser les choses ensemble mais ce qui est sûr c’est que nous allons avoir besoin de mains, de présences, de coolatitude et de bonne humeur durant l’événement… Alors si tu as l’une de ces qualités ou bien toutes ou bien aucune, mais tu souhaiterais quand même t’investir, tu es le-la bienvenu-e ! Tu n’as qu’à passer au Téléfab faire un petit coucou et nous donner tes disponibilités entre le 11 et 15 octobre.
Woilou!
Bois souple
Voici quelques expérimentations pour rendre le bois souple.
A l’aide de différents motifs découpés à la découpeuse laser, répétés plus ou moins de fois sur une surface, nous pouvons donner une certaine souplesse au bois: c’est ce qu’on appelle la technique du lattice hinge (traduction française: charnière en treillis). Cette technique est inspirée du kerfing (de l’anglais kerf qui signifie entailles/traits de scie).
» Le kerfing est une technique à l’origine pratiquée par les luthiers pour cintrer le bois à froid. Il s’agit de réaliser des rainures dans le sens perpendiculaire au bois, pour l’affiner localement et lui prêter une plus grande souplesse. «
Pour l’instant nous avons réalisé ces essais sur deux types de bois : du medium 3mm et du contreplaqué peuplier 3 mm. Nous nous sommes aperçu que certain motifs fonction mieux sur le medium que sur le contreplaqué, et inversement. Les échantillons sont tous présents au fablab. Nous allons poursuivre les tests sur du pmma et sur d’autres épaisseurs.
