Présentation du Robotino

Le Robotino est un robot mobile, avec un châssis rond en inox et trois unités de motorisation omnidirectionnelles

Photo d'un Robotino :

Ses dimensions sont :

- Diamètre : 370 mm

- Hauteur (habillage compris) : 210 mm

- Poids total : environ 11 kg

Les informations de commandes sont envoyées par Wifi via un routeur dédié présent dans la salle Robotino.

Pour la programmation, il existe le logiciel RobotinoView2 qui est un logiciel de programmation du Robotino conçu par Festo. Le Robotino peut être programmé avec d'autres logiciels, Matlab principalement car à l'installation, il y a une toolbox Matlab associé aux blocs fonction du logiciel avec RobotinoView2 ou en utilisant d'autres langages de programmation comme le C++ et Java.

Les capteurs présents initialement sur le Robotino sont :

- 1 Structure de protection en caoutchouc intégrant un détecteur anticollision

- 9 capteurs de distance analogiques à infrarouge

- 1 capteur inductif analogique

- 2 capteurs optiques numériques

Auxquels, on ajoute généralement 1 caméra Web couleur à interface USB.

Avec cette bases de capteurs beaucoup de TPs sont réalisés à Polytech.

Mais pour des projets ou des applications particulières, Festo vend des modules supplémentaires pour le Robotino, tel que le module Northstar de mon projet.

Présentation du projet

Contexte

Pour un projet de l’année dernière, on a utilisé les fonctions de traitement d’image de RobotinoView2, le logiciel de Festo pour programmer le Robotino. La même année, lors des Travaux Pratiques de Robotique, nous avons utilisé la fonction d’odométrie du Robotino. L’odométrie est une technique permettant d'estimer la position d'un véhicule en mouvement. Le terme vient du grec hodos (voyage) et metron (mesure). Cette mesure est présente sur quasiment tous les robots mobiles, grâce à des capteurs embarqués permettant de mesurer le déplacement du robot (de ses roues). Le principe de l’odométrie repose sur la mesure individuelle des déplacements des roues, en comptant les incrémentations du moteur, pour reconstituer le mouvement global du robot. En partant d'une position initiale connue et en intégrant les déplacements mesurés, on peut ainsi calculer à chaque instant la position courante d’un robot mobile.

C’est pourquoi cette année, ayant l’opportunité d’utiliser le module Northstar, ce sujet se présentait comme la possibilité de prndre en main un autre système de localisation. Ce module Northstar est comparable à un système de géo-localisation dans un plan. Ce système de navigation associe un projecteur et un capteur infrarouge.

Schéma de fonctionnement :

Remarque : il existe 2 types de projecteur, type NS1 et NS2, sur ce schéma c'est un type NS1. Et lors de ce projet, c'est un projecteur de type NS2 qui était fournit. La différence principale est sur la plage de fréquences dans laquelle émet le projecteur sinon le fonctionnement est le même.

Objectifs

Comprendre le fonctionnement du module Northstar.

Savoir paramétrer et initialiser le projecteur et le capteur.

Prendre en mains le bloc associé à Norstar sur RobotinoView2.

Etudier la précision du module Northstar.

Après ces étapes, mon objectif était de rendre l’utilisation le positionnement dans l’espace le plus précis possible en associant les valeurs de x, y et phi calculées par l’odométrie et par le module Northstar le plus précis possible.

Enfin, appliquer cela à des cas concrets, d’abord des trajectoires assez simples, sur des problèmes tels que le patinage ou le glissement des roues qui créent des erreurs avec l’odométrie. Puis en associant mes résultats au projet d’un doctorant qui travail sur l’évitement d’obstacle avec le Robotiono par la logique floue.

Journal de bord

10 Septembre 2013

Présentation des projets IMA 5

11 Septembre 2013

Rencontre avec les professeurs pour avoir plus de détails sur les projets, suivi du choix et de l'attribution des projets

17 Septembre 2013

Discutions avec Mr Rochdi MERZOUKI sur le projet en lui même et ses objectifs.

Prise de contact avec Mr Olivier SCRIVE pour récupérer la boîte contenant le module Northstar

Ecriture d'un diagramme de Gantt pour la gestion du projet, avec les premières étapes du projet ainsi qu'une estimation de leur durée

18 Septembre 2013

Découverte du kit Northstar qui comprend :

- 1 capteur Northstar

- 1 câble USB pour le relier le capteur au Robotino

- 1 projecteur avec un trépied

- 1 bloc d’alimentation électrique adaptable aux prises internationales

- 1 câble pour relier le projecteur au bloc d’alimentation

- 1 manuel d’utilisation (allemand et anglais)

Photo du kit Northstar :

Assemblage du projecteur avec le trépied et le bloc alimentation ainsi que du capteur Northstar avec le Robotino.

Photo de la mise en place Capteur Northstar sur Robotino :

Prise en main du bloc Northstar présent sur le logiciel RobotinoView2

Photo du bloc Northstar :

Les entrées sont :

- Numéro de local correspondant au numéro du local dans lequel Robotino se trouve, lié au numéro fixé sur le projecteur

- Calibrage du plafond (en mm) correspondant à la distance entre le détecteur et le plafond

- X (en mm) correspondant à la position x de l'origine définie par l'entrée "Définir"

- Y (en mm) correspondant à la position y de l'origine définie par l'entrée "Définir"

- Phi (en mm) correspondant à la position phi de l'origine définie par l'entrée "Définir"

- Définir correspondant à un booléen, si vrai (true) la pose (x,y,phi) est prise pour origine

Prise de l'interface du bloc Northstar quand le programme est lancé

Photo de l'interface du bloc Northstar :

Sur cette interface, on peut lire :

- le pourcentage de détection des 2 spots : Spot A et Spot B

- le numéro du local courant

- le nombre de projecteurs détecté par le capteur

- le numéro de séquence qui correspond au nombre de fois où le capteur à tenter de capter les spots depuis le lancement du programme.

24 Septembre 2013

Ecriture d'un sous programme nommé Northstar sous RobotinoView2 qui commande le Robotino avec un bloc appelé panneau de commande et qui calcule en même temps la différence entre les valeurs avec le capteur Northsatr et celles par odométrie

Pour les premiers programmes, j'envoyait la lumière du projecteur se réfléchir sous un bureau dans l'idée d'avoir un plafond plus bas et donc un meilleur pourcentage de captation. Ce qui est le cas car pour un périmètre de 0 à 1,5 m, on obtient pour les spot A et spot B des valeurs entre 85 et 98 %.

Avec un paramétrage :

calibrage du plafond : 500 pour avoir des valeurs acceptables sachant que normalement le bureau fait 1,2 m donc cette valeur

numéro du local : 5

calibrage du projecteur : 3

C'est 2 valeur sont liés car si on associe pas les bonnes valeurs, on ne capte pas le signal mais à ce stade je me suis contenté de ce couple pris sur un exemple. l'explication sera faite par la suite.

25 Septembre 2013

Ecriture d'un sous programme nommé Odométrie_auto qui utilise l'odométrie pour commander le déplacement du Robotino d'une position d'origine à une autre position, en définissant une position comme un vecteur de à 3 composantes x, y et phi.

Photo du bloc Odométrie :

Les entrées x, y et phi sont les valeurs de la positions à atteindre. L'entrée Spécifier sert à démarrer le fonctionnement du bloc. Et les sorties sont les valeurs courantes de x, y et phi.

30 Septembre 2013

Ecriture d'un sous programme nommé Drive qui prend utilise les valeurs de Northstar plus un delta égale à la différence entre les valeurs par odométrie et celles avec le capteur Northsatr, pour commander le déplacement du Robotino d'une position d'origine à une position d'arrivée.

A ce stade, il y a 2 blocs constante nommé boolean et position à modifier pour lancer le programme associé à 3 étapes :

Etape 1 : définition origine :

boolean = 1

position = 1

Etape 2 : lancement odométrie et northstar :

boolean = 0

position = 1

Remarque sur l'étape : légères oscillations autour de la position d'origine dû à la précision de Northstar

Etape 3 : commande d'avancement d'une valeur entre 0 et 2 m selon X :

boolean = 0

position = 2

Remarques sur l'étape : même oscillations autour de la position d'arriver avant de la considérer comme atteinte.

1 Octobre 2013

Ecriture d'un sous programme nommé Moyenneur sous RobotinoView2 qui fait la moyenne entre les valeurs de x, y et phi obtenues par odométrie et par le capteur Northstar.

Ce programme s'inspire du programme Drive en changeant la formule pour le calcul de la position.

2 Octobre 2013

Les résultats obtentions par ces programmes paraissaient aberrants par des mesures avec un mètre à ruban et des marquages avec du scotch blanc au sol.

Recherches d'informations sur le paramétrage.

D'abord j'ai voulu comprendre le lien entre le numéro du local qui est définie sur le bloc Northstar sur RobotinoView2 et le calibrage du projecteur qui est définit directement sur le projecteur par une molette.

Photo zoomé du projecteur pour voir la mollette de calibrage :

Il y a 3 configurations possibles du au fait que j'utilise un projecteur de type NS2 :

- Calibrage du projecteur (switch-setting) = 1 et numéro du local (Room ID sur le bloc Northstar) = 3

- Calibrage du projecteur (switch-setting) = 2 et numéro du local (Room ID sur le bloc Northstar) = 4

- Calibrage du projecteur (switch-setting) = 3 et numéro du local (Room ID sur le bloc Northstar) = 5

Ces combinaisons servent à définir différents locales ou espaces de travail dans le cas où on a différents projecteurs par exemple. Car pour chaque configuration le projecteur et le capteur travaille à des valeurs de fréquences différentes.

Photo du tableau du paramétrage du projecteur et du capteur :

7 Octobre 2013

Modification du programme Odométrie_auto pour qu'il continue à commander la Robotino avec les valeurs d'odométrie.

Et qu'il enregistre aussi les valeurs grâce au bloc nommé Enregistreur de valeurs qui inscrit les valeurs d'entrée, séparées par un tabulateur, sur une nouvelle ligne du fichier texte.

Photo du bloc Enregistreur de valeurs :

Ces fichiers texte sont contenus dans un dossier nommé Résultats, il y en a 6 fichiers texte :

- x_Northsyar

- y_Northstar

- phi_Northstar

- x_Odometrie

- y_Odometrie

- phi_Odometrie

Le nom et le chemin de stockage de chaque fichier texte est à définir dans l'interface du bloc Enregistreur de valeurs.

Photo de l'interface bloc Enregistreur de valeurs :

Grâce à ces fichiers texte et à l'affichage des valeurs de connexions, j'ai pu avec une méthode empirique définir la valeur de calibrage du plafond.

14 Octobre 2013

Modifications des programmes, utilisation de blocs Générateur d'ondes arbitraire qui sert à faire le changement de positions en commandant dans le temps les variables du programme boolean et position avec les étapes

Photo du Bloc Générateur d'ondes arbitraire :

Etape 1 : définition origine :

boolean = 1 et position = 1

Etape 2 : lancement odométrie et northstar :

boolean = 0 et position = 1

Etape 3 : commande d'avancement sur la position 2 :

boolean = 0 position = 2

C'est en modifiant dans l'interface de ces bloc soit de façon graphique soit dans un tableau que j'ai pu définir les valeurs des variables boolean et position que je souhaitait définir pour ces 3 étapes au cours du temps

Photo de l'interface Générateur d'ondes arbitraire façon graphiques :

Photo de l'interface Générateur d'ondes arbitraire façon tableau :

Remarque pour une meilleur précision, le programme effectue ces 3 étapes entre 2 positions pour redéfinir la position de départ à chaque fois et avoir un meilleur résultat.

15 Octobre 2013

Ecriture de 3 sous programme nommé Northstar_x, Northstar_y et Northstar_phi avec 1 position selon les axes :

- Northstar_x : 1ère position (1000, 0, 0) : déplacement de 1 m selon l'axe X

- Northstar_y : 2ème position (0, 500, 0) : déplacement de 0,5 m selon l'axe X

- Northstar_phi : 3ème position (0, 0, 180) : déplacement de 180° sur lui même

Ce teste donne des résultats assez concluant selon l'axe X et l'axe Y. Mais des erreurs selon Phi, j'ai supposé cela dû à la précision de Northstar amis cela est dû à la variable booléenne que j'utilise pour définir la position atteinte. J'ai laissé de côté les erreurs selon Phi, jusqu'au 28 Novembre où j'ai compris l'origine en faisant des enregistrements de trajectoires.

16 Octobre 2013

Ecriture d'un sous programme nommé Northstar_pgr qui sera un sous programme générique car dans la version précédente, il y avait un sous programme par position (Northstar_x, Northstar_y et Northstar_phi) ce qui était redondant et lourd

Ecriture d'un nouveau sous programme nommé Northstar_pgr_avec_inc qui correspond au programme Northstar_pgr avec l'incrémentation de la position dans ce sous programme.

22 Octobre 2013

Rédaction du rapport et modifications sur le Wiki car tous les Robotinos étaient occupés par une séance de TP.

23 Octobre 2013

Jusqu'à présent je travaillais sur le Robotino numéro 16 avec comme adresse IP 172.26.94.16. Mais à cette séance, ce Robotino était utilisé par une autre classe, c'est pourquoi j'ai utilisé le Robotino numéro 17 avec comme adresse IP 172.26.94.17.

Cependant avec ce changement de Robotino, j'obtenais des valeurs qui ne correspondaient pas. C'est pourquoi, j'ai dû de façon empirique définir une nouvelle valeur de calibrage du plafond égale à 3900, alors que la valeur théorique devrait être 2600 (2,8 m de hauteur de plafond moins 0.2 m de hauteur du Robotino).Donc la valeur est au dessus et que pour le numéro 16, la valeur était en dessous.

13 Novembre 2013

Problème d'incrémentation avec sous programme nommé Northstar_pgr_avec_inc car il incrémente trop vite et donc ne passe pas par toutes les positions.

Ecriture d'un sous programme nommé Incrementer_pos qui ne s'occupe que de l'incrémentation de la position et associé au sous programme Northstar_pgr dans le programme principale, cela permet de parcourir plusieurs positions.

Problèmes : ne fait que 3 positions sur les 5 demandées dans le teste du programme, modifications en cours.

20 Novembre 2013

Ecriture d'un sous programme nommé Northstar_sup_odo qui utilise un bloc Multiplexeur pour d'abord prendre pour consigne l'odométrie et la remplacer par Northstar quand erreur supérieur à une valeur départ de " 100 mm " car d'après le guide, on sait que Nothstar a une précision de +/- 50 mm

Photo du Bloc Multiplexeur :

Bon fonctionnement du programme sur 2 m selon X

26 Novembre 2013

Rencontre avec 2 doctorants dont Achille qui travaille sur l’évitement d’obstacle avec le Robotiono par la logique floue.

Proposition leur part faire des graphique et des courbes des valeurs que j'enregistrais dans des fichiers texte et que j'utilisait surtout pour le paramétrage. Et d'analyser ces courbes pour voir l'influence des trajectoires, de la vitesse et de la lumière sur la précision entre l'Odométrie et Northstar.

Ensuite, ils m'ont proposé changer mon programme écrit sous RobotinoView2 au format Matlab grâce à une toolbox dédié, pour pouvoir intéragir avec le programme basé sur la logique floue d'Achille en lui donnant la meilleur précision de localisation.

Teste de la lumière, il n'y a aucune influence à 17h fin novembre lumière éteinte ou allumée. Ce qui était envisageable car le projecteur et le capteur travaillent dans le domaine de l'infrarouge.

Ecriture d'un programme Matlab nommé Analyse_Sorties.m qui quand il est exécuté dans un dossier contenant les 6 fichiers textes (x, y et phi selon l'odométrie et Northstar) récupère directement ces valeurs grâce à la fonction textread et les place dans des vecteurs du même nom.

Et avec la fonction plot, les courbes sont représentés sur des graphiques.

27 Novembre 2013

Modifications du programme Matlab nommé Analyse_Sorties.m, d'abord en rajoutant un titre et des légendes aux graphiques.

Ensuite le problème de représentation est lié que le capteur odométrie fonctionne a une fréquence plus élevé, environ 3 fois plus rapide que le capteur Northstar, c'est-à-dire que pour une valeur mesurée avec le capteur Northstar, le capteur d'odométrie en aura mesuré 3. Mais cela varie encore selon la vitesse du Robotino et que se soit la variable x, y ou phi que l'on mesure.

C'est pourquoi, pour avoir une représentation à l'échelle sans mesurer le temps en plus, les valeurs mesurées par odométrie sont représenté sur les graphiques par un pas égale à 1 et celles mesurées avec Nothstar par un pas égale à la division du nombre de valeurs enregistrées par odométrie par le nombre de valeurs enregistrées par Northstar.

De plus ce fichier calcul le plus grand écart type. Cependant pour ce calcul, le problème s'est posé dans l'autre sens, car la fonction std qui calcul l'écart type ne s'applique que sur des vecteurs de même taille. Il a fallu retiré des valeurs aux vecteurs contenant les valeurs enregistrées par odométrie, car ceux sont eux les plus grands dû à la vitesse d'enregistrement. Et qu'il est plus logique de retirer des valeurs que d'en inventer.

A partir de ce moment, j'ai refait des enregistrements, le dossier de stockage des enregistrements de x, y et phi par odométrie et Northstar n'est plus nommé Résultats mais Sorties. Et le dossier Résultats contient maintenant des dossiers dont le nom évoque la trajectoire effectuée par le Robotino avec comme consigne les valeurs d'odométrie et comme enregistrements celles par odométrie et par Nothstar.

Les dossiers correspondant aux trajectoires sont :

- Selon X (2m)

- Selon Y (1m)

- Trajectoire diagonale (Combinaison X (1m) et Y (1m))

28 Novembre 2013

Nouveaux dossiers correspondant à de nouvelles trajectoires :

- Selon Phi (tour sur lui même)

- Trajectoire circulaire (Combinaison X (1m) et Phi (180°))

- Trajectoire circulaire (Combinaison Y (1m) et Phi (180°))

Cependant les trajectoire avec phi ne répondait pas selon cette variables alors j'ai vérifié mon programme RobotinoView2 dans lequel, j'utilise un bloc nommé Parcoureur de position qui calcule la vitesse x, y et angulaire en fonction de la position (x, y et phi) de consigne et de la position (x, y et phi) réelle de sorte que Robotino se rende de la position réelle à la position de consigne. De ce bloc, il y a aussi 3 autres sorties qui sont :

- Position atteinte : dès que les sorties vx et vy délivrent 0, la position de destination est considérée atteinte et la sortie délivre un signal vrai.

- Orientation atteinte : dès que la sortie omega délivre 0, l'orientation de destination est considérée atteinte et la sortie délivre un signal vrai.

- Pose atteinte : la sortie délivre un signal vrai si à la fois la position et l'orientation de destination sont atteintes. Sinon faux.

Hors jusqu'à présent, le programme passait d'une position à une autre une autre quand la variable de sorties Position atteinte était vrai, c'est-à-dire que la valeur de consigne et celle réelle sont égales pour x et y en négligeant phi. C'est pourquoi, j'ai changé le programme pour qu'il passe d'une position à une autre une autre quand la variable de sorties Pose atteinte était vrai, pour ne plus négliger phi.

Comme cela j'ai pu mesurée les trajectoires utilisant la variable phi et j'ai aussi refait les mesures de celles ne l'utilisant pas faites à la séance précédente pour éviter toutes erreurs.

2 Décembre 2013

Pour avoir un résultat comparable, j'ai délimité un rectangle de 2 m selon X, 1 m selon Y et des rotation de 90° à chaque angle. Je fait faire ce parcours au Robotino d'abord en le commandant avec l'odométrie puis en le commandant avec Northstar.

Module Northstar sur Robotino

Sommaire