Sommaire

1 Présentation générale : Interface Graphique Robotino 2 Upgradé
- 1.1 Description
- 1.2 Objectifs
2 Analyse du projet
3 Préparation du projet
4 Réalisation du Projet
5 Documents Rendus

Présentation générale : Interface Graphique Robotino 2 Upgradé

Etudiants : François BRASSART & Jérome HAON

Encadrants : Vincent COELEN & Thomas DANEL

Description

Lors de notre 2ème année de PEIP, nous avons eu l'occasion d'utiliser des Robotinos lors d'un Bureau d'études afin de découvrir la spécialité IMA. Les Robotinos sont des robots mobiles produits par Festo, à entrainement omnidirectionnel ce qui leur permet de se déplacer dans toutes les directions et de tourner sur eux-mêmes. Ils sont dotés de différents capteurs (infrarouges, optiques, inductifs...) ainsi que d'une Webcam et d'un gyroscope. Ils peuvent être contrôlés et programmés sur un PC via une connexion Wi-Fi ou directement grâce à l'interface Homme-Machine (IHM) intégrée.

Nous avons constaté durant ce bureau d'étude que les Robotinos, utilisés depuis une dizaine d'années en salle de TP commencaient à vieillir. L'objectif de notre projet est moderniser ces robots afin de les remettre au gout du jour. Les Robotinos bénéficieront d'un nouvel ordinateur embarqué, d'un nouveau logiciel, de nouvelles batteries et d'un écran tactile 7 pouces.

Objectifs

La modernisation des Robotinos à déja été commencée avant le début de notre projet. Les nouveaux composants ont déja été choisis et l'installation est en cours. Le but de notre projet est de concevoir la nouvelle interface Homme-Machine. Il s'agira d'une interface graphique directement accessible via l'écran tactile, programmée grâce a WebTool Kit qui permettra entre autre de :

Configurer le Robotino au réseau : pouvoir modifier facilement la configuration réseau du robot (choix d'un réseau sans fil).
Afficher l’état et les données des différents capteurs (camera, laser, sharps, bumper) afin de faciliter la programmation et le débogage des programmes.
Lancer des programmes de démonstration que nous aurons préalablement programmé.

Cette interface graphique devra évidemment être fonctionnelle et agréable à utiliser.

Analyse du projet

Positionnement par rapport à l'existant

Les Robotinos utilisés depuis 10 ans en salle de TP sont des Robotinos de génération 2. Il existe actuellement des Robotinos de génération 3. Nos 2 concurrents sont donc le Robotino 2 et le Robotino 3.

Notre Robotino "amélioré" sera équipé d'un ordinateur embarqué Intel NUC, avec l'OS Ubuntu 18.04. Il disposera d'une IHM intégrée notamment grâce à un écran tactile 7 pouces que nous allons créer.

Analyse du premier concurrent : Robotino 2

Le Robotino 2 est équipé d'un ordinateur embarqué AMD Geode, avec l'OS Ubuntu 9.04.

Il dispose également d'une IHM sur son chassis composé d'un petit écran et de plusieurs boutons. Elle permet de :

Selectionner la langue,
Afficher l'état des batteries
Sélectionner les adresses du réseau
Sélectionner des programmes de démonstrations pré-enregistrés.

Configuration Hardware Robotino 2

IHM Robotino 2

Analyse du second concurrent : Robotino 3

Le Robotino 3 est équipé d'un ordinateur embarqué Intel Core i5 ou Intel Atom, avec l'OS Ubuntu 12.04.

Il ne dispose pas d'IHM intégrée, il doit être contrôlé à distance par un PC.

Configuration Hardware Robotino 3

Scénario d'usage du produit ou du concept envisagé

Samedi 2 février 2019, Journée Portes Ouvertes à Polytech Lille.

Pierre, étudiant en IMA est chargé de faire la démonstration de l'utilisation des Robotinos sur le terrain de Hockey/Football de la salle C305. Dès que tous les futurs étudiants et leur parents sont rentrés dans la salle, il n'a qu'à choisir en cliquant sur l'écran tactile d'un Robotino le programme qu'il désire dans l'onglet "programme". Il peut ainsi commencer sa présentation pendant que le robot suivra une ligne, contournera un obstacle ou fera demi-tour quand il rencontrera un mur.

Vendredi 25 Janvier 2019, Bureau d'études IMA

Léna et Clément, étudiants en PEIP2, ont choisi le bureau d'études IMA afin de découvrir cette spécialité et finaliser leur orientation. Il consiste en la commande d'un Robotino. La première mission est de le faire suivre une ligne. Léna et Clément ont beaucoup de mal à comprendre le fonctionnement de ce Robot. Clément à mis des sur-chaussures pour pouvoir marcher sur le terrain pendant que Lina commande manuellement le robot depuis le PC. En cliquant sur l'onglet "états des capteurs", Clément peut directement voir sur l'écran du robot l'état des capteurs, et ainsi comprendre leur fonctionnement en fonction de la position du robot et de son environnement.

Réponse à la question difficile

Question : Positionnement de Web Tool Kit WT par rapport à d’autres systèmes (ROS par exemple) mériterait d’être explicité. De même la difficulté (ou pas) de prise en main de Web Tool Kit WT n’est pas abordée.

Réponse :

Robot Operating System (ROS), est un ensemble d'outils informatiques open source permettant de développer des logiciels pour la robotique. Il s'agit d'un méta-système d'exploitation qui peut fonctionner sur un ou plusieurs ordinateurs et qui fournit plusieurs fonctionnalités : abstraction du matériel, contrôle des périphériques de bas niveau, mise en œuvre de fonctionnalités couramment utilisées, transmission de messages entre les processus et gestions des packages installés.

Web Toolkit est une interface web qui est met à disposition des fonctions pour le contrôle, la configuration et la maintenance du système de robot. WT est une bibliothèque d'interface graphique Web en C ++.

Notre objectif étant de concevoir une interface graphique sur l'écran tactile des Robotinos, WT semble plus adapté que ROS, qui est principalement axé sur la programmation des robots. De plus, connaissant déjà très bien le langage C, il nous parait plus réaliste d'utiliser Web Toolkit.

Préparation du projet

Cahier des charges

Nous devrons répondre aux différents besoins des différents utilisateur. D'abord, l'interface graphique devra permettre de configurer le Robotino au réseau. Les Robotinos sont normalement connectés à une borne wifi présente en salle Robotino. Notre interface devra permettre de s'y connecter facilement et d'afficher son adresse IP. Ensuite, pour faciliter la programmation, l'interface pourra afficher les états et les données des différents capteurs. Enfin, une interface de lancement des programmes de démonstration que nous aurons préalablement programmé devra être programmée. Cette interface graphique devra évidemment être fonctionnelle et agréable à utiliser.

Ce cahier des charges est susceptible d'évoluer en fonction de l'avancée de notre projet. En effet, nous pouvons envisager d'ajouter des fonctionnalités à notre interface graphique.

Choix techniques : matériel et logiciel

Comme indiqué dans la réponse à la question difficile, nous avons choisi d'utiliser le Web Toolkit WT. Les choix matériels ont déjà été réalisés par nos encadrants :

PC embarqué INTEL NUC,
écran tactile 7 pouces,
le choix des nouvelles batteries est en cours de réflexion.

Liste des tâches à effectuer

La liste des tâches à effectuer est pour le moment floue, nous allons programmer une rencontre avec nos encadrants pour les préciser. Nous estimons qu'il nous faudra d'abord apprendre à connaitre les nouveaux composants (mais également les anciens), puis apprivoiser le Web Toolkit pour finalement créer l'interface graphique finale.

Réalisation du Projet

Prologue

Lors du semestre 7, nous avons commencé par une analyse détaillée de notre projet, en effectuant dans un premier temps la présentation de notre projet, ensuite nous avons positionné notre projet par rapport à l'existant et nous avons défini un scénario d'usage, enfin nous avons déterminé notre cahier des charges.

Egalement nous avons rencontré à plusieurs reprises nos encadrants afin d’approfondir au fur et à mesure les objectifs de notre projet. Les rencontres avec nos encadrants étaient aussi un moyen pour nous de voir l'avancement de la construction des robotinos qui aiguisait notre curiosité.

Planning prévisionnel

Janvier

Apprentissage du langage C++ en autonomie a travers des cours et vidéos tutoriels sur internet et des livres empruntés à la bibliothèque universitaire.
Alimenter notre wiki.

Février

Téléchargement de la librairie Web Toolkit sur le site internet de Wt.
Autoformation sur Web Toolkit a travers des vidéos internet et des exemples d'application donnés lors du téléchargement de Web Toolkit.
Se renseigner sur la méthode de récupération des données des capteurs et des acteurs de Robotino dans l'API2.
Faire une première esquisse sur papier de notre interface graphique en pensant aux différentes fonctionnalités que nous voudrions implémenter.
Alimenter notre wiki.

Mars (début de mois)

Commencer la programmation de notre interface graphique.
Télécharger la librairie API2 sur wiki.openrobotino.
Alimenter notre wiki.

Mars (fin de mois)

L'interface graphique est terminée ou en cours d'être terminée.
Commencer à récupérer les données des capteurs du Robotino et les intégrer à notre interface graphique.
Alimenter notre wiki.

Avril (début de mois)

Finir l'interface graphique si elle n'est pas tout a fait terminée.
Continuer la récupération des données de l'API2.
Commencer à configurer la connexion réseau du robotino.
Alimenter notre wiki.

Avril (fin de mois)

Finir la récupération des données.
Commencer à importer les programmes de démonstration sur le nouveau Robotino.
Finaliser la connexion réseau.
Alimenter notre wiki.

Mai

Finir d'importer les nouveaux programmes de démonstration dans le Robotino upgradé.
Alimenter notre wiki.
Soutenance de fin de projet.

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S8	Heures S10	Total
Analyse du projet	3									3
Organisation, Brainstorming		2		2						2
RDV avec encadrants			1		1		1	1	1	5
Autoformation C++, WebToolkit		6	6	2						14
Montée en connaissance sur Robotino, API2			3							3
Programmation du bandeau et menu principal				4	4	3	3			11
Récupération de l'état des capteurs, intégration à l'interface						2	3
Gestion de la connexion réseau
Programmes de démonstrations
Tests
Préparation Soutenance

Semaine 1

Objectifs : organisation, approche de C++ & WT.

Lors de cette première semaine, nous avons commencé par organiser un planning de travail pour les mois à venir, en nous imposant des objectifs afin de se repartir au mieux la charge de travail.

Nous avons installé une Machine Virtuelle sur notre ordinateur afin de pouvoir travailler en dehors des séances de projets. De plus nous avons téléchargé le paquetage Web ToolKit avec les différents exemples d'utilisation, et effectué des recherches sur son fonctionnement avant de commencer à programmer notre interface graphique.

Enfin, nous avons pris rendez-vous avec nos encadrants de projet afin nous renseigner sur l’avancement de l'assemblage du Robotino, leur expliquer l'organisation des tâches que nous nous sommes donnée et de vérifier que notre cahier des charges est complet.

Semaine 2

Objectifs : Documentation sur C++ & WT.

Nous avons commencé cette deuxième séance avec un rendez-vous avec nos 2 tuteurs : Vincent Coelen et Thomas Danel. Ils nous ont rassuré sur l'avancée du prototype du robotino. L'écran a été commandé et devrait arriver rapidement. Il sera également monté au plus vite, pour avoir le premier prototype prêt à fonctionner dans minimum 2 semaines. Nous avons convenu de faire une réunion toutes les 2 semaines avec nos encadrants. Cela leur permettra de se tenir au courant de l'avancée de notre travail et nous permettra également de leur poser des questions et de faire un point sur l'avancée de la "construction" du robotino amélioré.

Le nouvel ordinateur embarqué est relié au micro-contrôleur du robotino via une liaison série RS232. Lorsqu'un programme de démonstration est lancé (directement depuis l'ordinateur embarqué ou via lelogiciel RobotinoView depuis un ordinateur), les commandes sont envoyées en TCP au démon RPCd., qui est chargé d'envoyer les commandes au bon destinataire. La Webcam ou le laser sont reliés à l'ordinateur embarqué. Les autres capteurs et actionneurs (moteurs, roues...) sont reliés au microcontroleur du robotino.

Après ce RDV, nous avons suivi un tutoriel pour apprendre le langage C++. tuto C++. En effet, pour utiliser Wt, nous allons coder en C++. Connaissant déja très bien le C et ayant des bases de Java, le langage C++ n'est pas très compliqué à comprendre et à assimiler. nous avons également commencé à suivre des tutos sur Wt. tuto 1 tuto 2

Nous avons ainsi étudié quelques exemples d'applications Web réalisés avec WebToolkit. Nous avons pu découvrir le fonctionnement de WT : la possibilité d'ajouter des Widgets prédéfinis sur une interface. Ces tutoriels et exemples seront une bonne base pour le début de la programmation de notre interface graphique. Chaque Widget peut émettre un signal lorsque l'on clique dessus par exemple (permettant la communication déclenchée par un événement entre les objets du programme).

Semaine 3

Objectifs : Documentation sur WT, brainstorming sur le design de l'interface.

Documentation sur WT

Lors de cette troisième semaine, nous avons continué à nous perfectionner, en analysant les exemples donnés via la plateforme Web Toolkit. En parallèle nous avons commencé à nous documenter sur wiki.openrobotino pour avoir un accès complet aux capteurs et aux actionneurs du robotino via l'API2. Une API (interface de programmation applicative) est un ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services à d'autres logiciels. Dans notre cas, l'API2 du robotino est une API permettant de d’accéder aux différents éléments du robotino. Cela nous permettra de récupérer les données et de les afficher sur notre interface graphique plus tard. api2

Présentation des robotinos lors de la journée d'immersion des terminales

Le 30 janvier a eu lieu la journée d'immersion des terminales. Nous y avons participé en expliquant a chaque groupe de terminale le contenu de notre formation IMA. Nous étions en salle robotino et avons lancé des programmes de démonstration sur les robotinos 2. Cela nous a permis de découvrir comment se passait la présentation et la demonstration des robotinos sur l'IHM présente ainsi que les programmes de démonstration déja existants. L'IHM des robotinos 2 est peu agréable à utiliser. Nous avons ainsi une idée plus claire des fonctionnalités que doivent intégrer notre interface graphique et pouvons commencer à réfléchir au programme de démonstration que nous allons créer en fonction de ceux qui existent déja.

Reflexion sur le design de l'interface

Ensuite il est venu le temps d'imaginer à quoi pourrait ressembler notre interface graphique, avec les différentes fonctionnalités que nous pourrions implémenter (voir schéma ci-dessous).

Le menu principal sera composé de différentes fonctionnalités :

Aide : Expliquer les différentes fonctionnalités de notre interface comme par exemple comment connecter le robot au wifi, comment lire l'état des capteur ou alors lancer un programme de démonstration.

Configuration réseau : Modifier facilement la configuration réseau du robot en listant les réseaux wifi disponibles et pouvant s'y connecter facilement.

Visualisation état capteurs : Afficher les données des différents capteurs du robotino directement sur l'interface graphique, par exemple lors du suivi d'un mur nous pourrions voir en temps réels quel capteur de distance est utilisé ainsi que la valeur qu'il renvoie.

Lancement programme de démonstration : Exécuter un programme de démonstration directement enregistré dans le robotino parmi une liste prédéfinie.

Ensuite, il y aura une page pour chaque fonctionnalité.

Semaine 4

Objectifs : Finaliser le design de l'interface, commencer la programmation avec WT.

RDV avec encadrants : finalisation du design

Nous avons commencé cette semaine avec un rendez vous avec nos 2 tuteurs afin de faire un compte rendu de notre avancement sur le projet. Cela a été l'occasion pour nous de leur présenter l'ébauche de visuel de l'interface que nous avons réalisé précédemment. Nos encadrants nous ont aidé et ont soulevé quelques points manquants et améliorations possibles.

Nous allons donc rajouter un "bandeau" en haut de notre interface, qui sera toujours visible et qui affichera en continu les informations importantes telles que :

l'adresse IP
le programme en cours
l'adresse Wifi
l'état de la batterie

Egalement, pour des questions de praticité, il est plus judicieux, lors du choix des programmes de démonstration, de faire un menu déroulant plutôt que des boutons. Cela sera plus pratique pour l'utilisateur. De plus, il sera plus simple dans le futur d'ajouter des nouveaux programmes de démonstration pour les personnes n'ayant pas implémenté l'interface.

Nous avons donc fait un nouveau visuel pour l'interface graphique :

Debut de la programmation de l'interface : WTDesigner

Pour nous faciliter la tâche de programmation de l'interface, nous avons pensé utiliser le logiciel WtDesigner, qui permet de créer une interface graphique avec Wt facilement. [WTDesigner] Cependant, après plusieurs tests, nous n'avons pas été en mesure de récupérer le code source de l'interface ainsi créée (nous avons uniquement accès au fichier .h). Cela n'est donc pas compatible avec l'utilisation de l'interface que nous souhaitons. Sans le code source, nous ne pouvons utiliser l'API2 et ajouter des fonctions pour récupérer l'état des capteurs et actionneurs du robotino. Ceci a donc été une perte de temps dans notre projet.

Semaine 5

Objectifs : programmation du premier menu WT.

Programmation du premier menu WT

Suite à l'échec de l'utilisation du logiciel WtDesigner, nous avons commencé à coder nous même l'interface en C++.

Nous nous penchons d'abord sur le menu principal, composé du bandeau et des 3 boutons permettant de sélectionner les 3 fonctions principales de notre interface : la configuration réseau, l'état des capteurs et les programmes de démonstration. Nous partons sur la base de l'exemple Hello World de Wt, qui contient principalement un texte et un bouton. Code source HelloWorld

Nous choisissons de créer 2 WContainerWidget dans chaque partie de l'interface. Un WContainerWidget permet de séparer l'écran et d'ajouter des widgets dans chaque container. Ainsi, nous allons créer un WContainerWidget pour le bandeau et un pour le "corps". Le WContainerWidget du bandeau sera présent sur chaque page de notre interface. Pour le moment, nous avons ajouté du texte "statique", mais plus tard, le contenu sera modifié en fonction du robot (adresse IP, batterie, programme en cours...).

Nous avons choisi de réaliser le bandeau et le corps dans 2 fichier différents. Le fichier main initialisera une instance de bandeau et une instance de corps.

Nous avons également ajouté les 3 boutons permettant de lancer les 3 fonctionnalités principales de notre interface. Un bouton est créé en ajoutant une instance de WPushButton. Pour l'ajouter dans un WContainer particulier, nous utilisons la méthode addWidget.

WPushButton *btn = container->addWidget(std::make_unique<Wt::WPushButton>("Etat des capteurs"));

Integration d'une feuille de style CSS

Malgré de nombreux tests, nous n'arrivons pour le moment pas à intégrer une feuille de style CSS. Cela est très problématique car, comme le montre la capture ci-dessous, le rendu n'est pas du tout esthétique. Nous pouvons cependant modifier la taille, la couleur... des Widgets grâce à des fonctions de Wt. Cependant, il n'existe pas de fonctions de Wt permettant de centrer et d'espacer le texte, d'adapter la taille des boutons en fonction de l'écran (taille en pourcentage de l'écran)... L'utilisation d'un fichier CSS parait donc être obligatoire pour mener à bien notre projet et nous devons trouver une solution.

Semaine 6

Objectifs : Git, ajout du CSS, finaliser le menu principal, création des "sous-menus".

RDV avec encadrants : GIT, finalisation du design de l'interface, organisation des fichiers

Cette semaine a débuté avec un rendez-vous avec Vincent Coelen. Lors de cet entretien nous avons commencé par présenter l'avancement de notre projet que nous avons effectué pendant les vacances et il a pu répondre à nos questions et nous apporter des solutions pour le futur. Egalement le montage des nouveaux composants du Robotino est terminé, il nous a fait une démonstration pour l'allumer et l'éteindre ainsi que les différentes fonctionnalités de l'écran tactile et de l'écran embarqué.

De plus pour faciliter la communication entre nous et aussi avec notre tuteur, sur les lignes de code que nous pouvons effectuer et de garder dans le futur ce que nous avons fait, un GIT a été mis en place : Lien vers le GIT

Compilation de l'interface, intégration CSS

Nous avons continué la programmation de notre interface. Nous avons réussi à utiliser une feuille de style CSS. il faut pour cela utiliser la fonction

useStyleSheet("stylesheet.css")

Nous avions déjà essayé d'utiliser cette fonction auparavant, mais sans succès. Cela ne fonctionnait pas car, lors de la compilation, il faut ajouter une option permettant d'indiquer ou se trouve les fichiers ressources nécessaires à notre interface : feuilles de styles, images... Ainsi pour compiler, il faut utiliser la commande

./main --docroot ./ressources --http-address 0.0.0.0 --http-port 8080

--docroot ./ressources permet d'indiquer les ressources se trouvent dans le dossier ./ressources

--http-address 0.0.0.0 permet d'indiquer l'adresse sur laquelle nous voulons accéder à notre interface. Pour le moment, nous choisissons l'adresse locale 0.0.0.0

--http-port 8080 permet d'indiquer le port que nous souhaitons utiliser. Nous utilisons 8080 car cela correspond à un port qui n'est pas réservé.

Nous avons organisé notre projet dans des fichiers et dossiers différents, afin de mieux s'y retrouver.

dossier ressources : contient les images, feuilles de style CSS...
dossier bandeau : contient la classe qui crée le bandeau, qui est présent sur tous les menus.
dossier corps : contient la classe qui crée le "corps" de notre interface, c'est à dire le contenu principal de l'interface

Le fichier main.c est le programme principal qui initialisera la connexion avec le robotino, et qui créera des instances de bandeau et de corps.

Enfin cette semaine nous avons fini de programmer le menu principal de l'interface graphique. Pour le bandeau, nous n'avons finalement pas utilisé un WContainerWidget mais avons opté pour un WHBoxLayout. Ce type de widget permet d'organiser horizontalement des widgets, dans notre cas du texte et des images. Cela nous a permis de régler correctement l'espacement et le centrage des informations contenues dans le bandeau.

Programmation de l'interface : Sous-Menus, navigation entre les menus

Nous avons ensuite commencé à créer les "sous-menus" suivants et les avons liés au menu principal, après un clic sur le bouton correspondant. Pour cela, nous créons pour chaque sous-menu un WContainerWidget qui contiendra les informations nécessaires.

Nous nous sommes renseignés sur la manière de passer entre les differents menus avec WT. Voici l'explication que nous avons trouvé sur le site de WT :

"Wt allows the application to define internal paths and handle changes of internal paths. Because a Wt application is not composed of pages, a URL does not define to particular page, but rather a particular application state"

Pour naviguer entre les menus, nous allons changer le chemin interne (l'URL) de l'application. Quand l'URL est modifiée, un signal est envoyé. Nous implémentons une fonction qui permet de capter le signal, et en fonction de l'URL afficher le menu correspondant.

WApplication *app = WApplication::instance();
corps->clear();
if (app->internalPath() == "/capteurs")
        capteurs(corps);

Ainsi, lors d'un clic sur le bouton "Etat des Capteurs", l'URL devient localhost:8080/capteurs et notre fonction handlePathChanged supprime les wigets présents dans la partie du corps et appelle la fonction capteurs qui va afficher le menu d'état des capteurs. Cette fonction prends en paramètre le WContainerWidget corps, qui est un attribut de la classe corps.

Le Widget WApplication représente une instance d'application pour une session donnée (une connexion à l'interface).La méthode internalPath() renvoie l'URL de l'application.

Semaine 7

Objectifs : ajustement de l'interface graphique sur le robotino, connexion au robotino, récupération état capteurs.

Premiers tests sur robotino, Mise à jour Machine Virtuelle et WT

Nous avons désormais accès au robotino qui est dans une salle en AIP afin que nous puissions travailler dessus quand nous le souhaitons. Nous testons alors l'interface sur le robotino que nous avions réalisé sur ordinateur. Au début de ce projet nous avions téléchargé une machine virtuelle Debian. Cependant, sur Debian la dernière version disponible de WT était la version 3.3.6. Lorsque nous avons voulu afficher l'interface graphique sur le robotino, un problème est survenu. En effet le robotino embarque une machine virtuelle Ubuntu, qui lui permet d'avoir la dernière version de WT (4.0.3). Lors de la compilation nous avons eu de nombreuses erreurs de syntaxe du fait de la mise à jour. Pour coller au mieux avec le processus embarqué par le robotino nous avons donc choisi de télécharger une nouvelle machine virtuelle Ubuntu (celle utilisée par le robotino) et de télécharger la même version de WT, pour ne plus avoir de problème dans l'avenir. Nous avons réussi en très peu de temps à corriger les erreurs de compilation dues à la nouvelle mise à jour et nous pouvons commencer à se connecter et récupérer les données des capteurs et des actionneurs du robotino. Nous visualisons avec succès notre interface sur l'écran tactile du robotino.

Connexion au robotino

Avant de pouvoir commencer à retourner l'état des capteurs et des actionneurs, nous devons connecter le robotino à notre programme. Afin d'y parvenir nous avons analysé les exemples donnés lors du téléchargement de l'API2. Nous avons testé l'exemple circle sur le robotino et analysé son fonctionnement. Ce programme commence par créer une communication avec le robotino. Une fonction init créée une instance de la classe com et appelle plusieurs de ses méthodes afin de se connecter au robotino :

setAddress pour donner l'adresse IP du robotino.
connectToServer pour s'y connecter.

Ensuite, il crée une instance de la classe Omnidrive, afin de pouvoir contrôler la trajectoire du robot.

Nous allons ainsi utiliser une fonction similaire à init pour nous connecter au robotino, et allons créer des instances de classes de chaque capteurs pour utiliser leurs méthodes permettant de récupérer leur état. A priori, nous avons réussi à nous connecter. Nous allons essayer d'afficher l'état d'un capteur pour être sur que la connexion est belle et bien réalisée.

Recuperation de l'état du bumper

Nous avons choisi pour commencer de récupérer l'état du Bumper du robotino. Le bumper est un capteur de collision situé sur tout le tour de la coque du robotino. Quand il subit une une pression, il renvoie un signal, cela permet de configurer le robotino pour qu'il s'arrete au moindre choc. Avec la fonction bool rec::robotino::api2::Bumper::value on obtient :

True quand le robotino heurte quelque chose (un mur par exemple)
False sinon

Nous créons donc dans le main une variable globale qui créée une instance de bumper, que nous utilisons dans le programme du corps de l'interface. Il nous suffit donc d'afficher dans le menu de l'état du bumper : bumper.value() afin d'afficher True ou False.

A la fin de cette séance nous avons réussi à connecter le robotino à notre programme et à récuperer l'etat du Bumper. Cependant, l'état s'affiche lors du chargement du menu correspondant, mais ne s'actualise pas en direct. Notre objectif pour l'interface est d'afficher l'état des capteurs en direct sans actualiser la page. Nous avons essayé de mettre l'affichage de l'état du capteur dans une boucle while, mais cela ne fonctionne pas. Nous supposons que la boucle infinie empêche notre interface graphique de fonctionner en même temps. Nous réfléchissons donc à un autre moyen d'afficher la valeur du Bumper en instantané.

Actualisation des données : utilisation d'un timer

Durant le week-end, nous avons trouvé une solution. WT propose un widget WTimer qui crée un signal à intervalle de temps régulier. Nous choisissons d'utiliser un timer de 10ms. Dans notre programme, nous exécutons la fonction bumper.value() et actualisons l'affichage à chaque fois que ce signal est émis.

 mytimer->timeout().connect([=] {
 if(bumper.value()==true)
 	state->setText("True");
 else if (bumper.value()==false)
 	state->setText("False");
 });

Semaine 8

Objectifs : Récupération état des capteurs, mise a jour de l'interface en conséquence.

Test de l'actualisation de l'état du bumper sur robotino, adaptation du CSS

Nous testons sur le robotino si l'état du Bumper s'actualise bien en direct avec l'utilisation du WTimer, ce qui est le cas. Nous mettons à jour la feuille de style CSS afin que l'écran soit vert quand le bumper n'est pas touché et rouge si le bumper subit un choc.

Récuperation de l'état de l'odométrie

Nous continuons cette séance en récupérant, l'état de l'odométrie. L'odométrie fournit la position momentanée par rapport à la position de départ. Les codeurs des moteurs permettent de savoir combien de tours le moteur a effectué et donc de calculer, à l’aide du diamètre de la roue, la distance parcourue. Cette méthode fournit localement des résultats relativement précis mais l’erreur croît fortement sur de longues distances.

Avec la méthode: void rec::robotino::api2::Odometry::readings(double *x, double *y, double *phi, unsigned int *sequence = 0)const on obtient :

La position x
La position y
L’orientation phi

Nous testons et cela fonctionne. Nous essayons d'ajouter un timer pour l'actualisation en continu des données. Cependant, cela ne fonctionne pas. Nous nous rendons compte qu'a la fin du prototype de cette méthode de récupération de l'état de l'odométrie, il y a un const() a la fin. le mot clé const signale que la fonction membre s'engage à ne pas modifier l'objet au départ duquel elle est appelée/ Pour réussir à modifier l’état des variables, nous avons alors déclaré à nouveau les variables à l’intérieur du timer.

  mytimer->timeout().connect([=] {
   unsigned int sequence =0;
   double x,y,phi;
   odometry.readings(&x,&y,&phi,&sequence);
   stateX->setText("x = "+std::to_string(x)+" m");
   stateY->setText("y = "+std::to_string(y)+" m");
   statePhi->setText("phi = "+std::to_string(phi)+" °");
 });

De la même manière que le bumper, nous créons donc dans le main une variable globale correspondant à l'odométrie, que nous utilisons dans le programme du corps de l'interface, pour afficher l'état du capteur odométrique.

Récupération de l'état du gyroscope, des capteurs de distance et des moteurs

Ensuite nous nous sommes occupés du gyroscope du robotino, qui est utilisé pour augmenter la précision de détermination des positions. Le gyroscope détermine la variation de l’orientation du robotino. Dés que le système d’exploitation du robotino détecte le gyroscope, il utilise son signal pour corriger les positions sur la base du système odométrique. L’odométrie est considérablement améliorée par le capteur gyroscopique.

Comme précédemment nous créons dans le main une variable globale correspondant au gyroscope, que nous utilisons dans le programme du corps de l'interface. Il nous suffit donc d'afficher dans le menu de l'état du gyroscope avec la fonction suivante : float rec::robotino::api2::Gyroscope::angle ()const qui retourne la valeur actuelle de l'angle.

De la même manière que l'odométrie, nous actualisons l'affichage du gyroscope à chaque fois que le timer émet un signal.

Nous nous sommes occupés ensuite des capteurs de distance infrarouge. Les capteurs de distance déterminent la distance d’objets situés dans l’entourage du robotino (entre 4cm et 30cm). Le robotino possède au total neuf capteurs infrarouge, répartis par pas de 40° autour de la base. Chaque capteur de distance délivre une tension en volts, dont l’amplitude dépend de la distance par rapport à un objet réfléchissant. Les capteurs de distance infrarouge sont constitués d’un signal de sortie analogique. Nous créons toujours dans le main une variable globale, qui cette fois correspondant aux capteurs de distance, que nous utilisons dans le programme du corps de l'interface. Il nous suffit donc d'afficher dans le menu de l'état du Capteur de distance avec la fonction void rec::robotino::api2::DistanceSensorArray::headings (float *readings)const qui renvoient la valeur de chaque capteur de distance.

Le robotino dispose de trois moteurs indépendants entraînant trois roues omnidirectionnelles. Sur chaque moteur est monté un codeur incrémental mesurant la rotation du moteur. Les trois roues permettent de faire évoluer le système dans toutes les directions et de faire tourner le robotino sur place dans une position donnée. Nous créons donc dans le main une variable globale, correspondant à la vitesse des roues, que nous utilisons dans le programme du corps de l'interface. Il nous suffit donc d'afficher dans le menu de vitesse des roues void rec::robotino::api2::MotorArray::actualVelocities (float *readings)const

Semaine 9

Objectifs : Récupération des derniers capteurs et actionneurs, renseignements sur la configuration réseau.

Récupération de l'état des laser, des entrées et sorties digitales et des entrées analogiques

En ce début de semaine, nous terminons la récupération des derniers états des capteurs et actionneurs. Nous nous occupons du capteur Laser, celui-ci n’est pas sur le robotino, il est optionnel. Il permet de maîtriser les défis tels que la cartographie, la localisation et la navigation.

Nous ajoutons donc dans le main une variable globale, correspondant au capteur laser, que nous utiliserons dans le programme du corps de l’interface. Pour afficher la valeur du capteur laser dans le menu, nous utilisons la fonction suivante : LaserRangeFinderReadings rec::robotino::api2::LaserRangeFinder::readings ()const

Comme pour les fonctions précédente, pour afficher les valeurs du capteur laser en instantanée avec un Timer nous devons utiliser la même que l’odométrie.

L’interface d’E/S de Robotino permet de raccorder des extensions, telles que capteurs et actionneurs. L’interface met à disposition des entrées/sorties numériques (TOR), des entrées analogiques. L’interface d’E/S est directement montée sur la platine principale de l’unité de commande.

Entrées analogiques et digitales Les entrées permettent de connecter des capteurs ou des actionneurs, par exemple : Les capteurs optiques gauche et droit permettent de détecter diverses surfaces et couleurs sur la base des différences de coefficient de réflexion. Ils s'exploitent par l'intermédiaire des entrées digitales. Le capteur inductif quant à lui permet de détecter des objets métalliques, il s'exploite par l’intermédiaire des entrées analogiques. Nous ajoutons donc dans le main une variable globale, correspondant aux entrées digitales et analogiques, que nous utiliserons dans le programme du corps de l’interface. Il nous faut donc afficher dans le menu capteur entrées digitales et analogiques : void rec::robotino::api2::DigitalInputArray::values(int *readings)const qui retourne la valeur des entrées digitales. void rec::robotino::api2::AnalogInputArray::values(float *readings)const qui retourne la valeur actuelle des entrées analogiques.

Sorties Digitale s Les sorties digitales envoient la valeur True si la sortie est activée ou alors False si la sortie est désactivé au Robotino. Pour pourvoir envoyé les valeurs au Robotino, nous avons fait le choix de faire des boutons dans notre interfaces graphiques (car ils émettent un signal), pour avoir la possibilité de voir qu’elle sortie nous activons ou désactivons. Pour envoyer la valeur au Robotino nous utilisons la méthode void rec::robotino::api2::DigitalOutputArray::setValues(const int *values, unsigned int size) qui permet changer la valeur de la sortie.

Cette méthode modifie toutes les sorties digitales en même temps. Afin de conserver en mémoire les sorties digitales déja activer auparavant, nous utilision un tableau en variable globale qui mémorise leur état. Pour chaque sortie, nous ajoutons un bouton qui permet de l'activer ou de le désactiver. L'appui sur un de ces boutons appelle la méthode pour activer les sorties. Si la sortie est désactivée, le bouton est rouge, si elle est activée, il est vert.

Pour optimiser l'espace sur l'interface, nous mettons en forme ce menu avec un WGridLayout, qui permet de placer les widgets sous forme de "grille". Nous mettons donc le nom de l'entrée sur une première ligne et juste en dessous les boutons correspondants.

RDV avec encadrants

Nous avons pris rendez-vous avec notre tuteur, pour connaitre ce qu'il attendais de nous pour le menu configuration réseau, afin de nous pencher dessus. Il nous faudra donc dans une première partie lister tous les réseaux WiFi et dans une seconde partie pour enregistrer un réseau sur le robotino en rentrant son identifiant, le mot de passe, le type ainsi que si l'on veut se connecter de manière manuel ou en DHCP.

Configuration réseau en ligne de commande

Lister les Réseaux Wifi disponibles

Avant de pouvoir commencer la configuration réseau, il nous faut connaitre le nom de notre carte réseau. Nous utilisons la commande

 iwconfig

La carte réseau sans fil du robotino est nommé wlp1s0.

Pour commencer nous devons déconnecter le network-manager afin de configurer manuellement le réseau en ligne de commande. Network-Manager est l'outil de gestion des connexions réseau d'Ubuntu. Pour cela, nous utilisons la commande

sudo service network-manager stop

Si l'on souhaite réactiver network-manager, il faut utiliser la commande

sudo service network-manager stop

Dans un second temps, il nous faut lister tout les réseaux WiFi. Après plusieurs recherches, il faut utiliser la commande

iwlist wlp1s0 scan

Cette commande renvoie tous les réseaux wifi detectés ainsi que des informations les concernants. Nous utilisons ensuite des commandes sed et grep afin de retourner uniquement les noms de réseaux wifi.

iwlist wlp1s0 scan | grep ESSID | sed -e "s/ESSID:\"//g"| sed -e "s/\"//g" | sed "/x00/d"

Connexion a un reseau wifi

Pour se connecter à un reseau wifi, nous utilisons les commandes

wpa_passphrase nom_reseau_wifi > ~/wpa.conf
wpa_supplicant -B -c ~/wpa.conf -i wlp1s0

La première ligne de commande sert à enregistrer le nom du réseau sur lequel on souhaite se connecter ainsi que son mot de passe, et la deuxième ligne de commande sert à s'enregistrer.

Cependant, il apparait que cela ne marche pas tout le temps. Après plusieurs recherches, nous avons découvert qu'il fallait utiliser la commande

sudo killall wpa_supplicant

qui permet de tuer les processus wpa_supplicant deja existants et de relancer la connexion.

Et une fois connecté et reconnu par la borne Wifi, on va demander une nouvelle adresse IP avec le protocole DHCP grâce à la commande

dhclient wlp1s0

Semaine 10

Objectifs : Récupération état des derniers capteurs, renseignements sur la configuration réseau

Intégration de la configuration réseau à notre interface

Choix graphiques

Nous avons choisi d'utiliser un WSelectionBox, qui affiche une liste de texte et permet d'en selectionner un. Nous ajoutons un bouton permettant de valider le choix du réseau Wifi.

Une fois le réseau Wifi sélectionné, nous affichons un WLineEdit permettant de rentrer du texte. Nous le configurons en mode Password afin de ne pas afficher le mot de passe en clair sur l'interface. Nous ajoutons un bouton permettant de valider le mot de passe et de lancer la connexion.

Lancement des commandes : utilisation de super

Pour lancer les commandes, nous devons utiliser la fonction popen pour lister les réseaux Wifi et les récuperer, et la fonction system pour lancer la connexion et la récupération d'une adresse IP.

Cependant, les commandes de connexions doivent être exécutées en super utilisateur. Nous ne voulons pas lancer l'interface graphique en super utilisateur car il y a des risques que les utilisateurs puissent lancer d'autres commandes en super utilisateur. Nous avons donc pensé à utilisé super, que nous avions utilisé en 3e année en systèmes et réseau. Super permet à un utilisateur non root de lancer des commandes prédéfinies comme s'il était root.

Nous avons donc réalisé un script permettant de lister les réseaux Wifi et un script permettant de se connecter au réseau wifi, que nous avons placé dans un dossier scripts. Nous avons modifié le fichier de configuration de super (/etc/super.tab) en ajoutant nos scripts. Exemple pour la liste des wifis :

liste Wifi /home/robotino/work/robotino2_gui/scripts/listeWifi.sh robotino uit=root

Ainsi, pour lister les réseaux wifi, il faut simplement écrire la commande

super listeWifi

Lancement des programmes de démonstration

Pour lancer les programmes de démonstrations, nous ajoutons un WSelectionBox ainsi qu'un bouton permettant de valider le choix. Les programmes de démonstrations sont placés dans le dossier /usr/local/robotino/examples/bin/.

Pour lancer le programme, nous utilisons par exemple pour la démonstration circle :

system("/usr/local/robotino/examples/bin/example_circle 127.0.0.1 &");

Le nom du programme à lancer est récupéré en fonction de la sélection. Le programma est lancé en arrière plan pour ne pas interférer sur notre interface graphique.

Lorsqu'un programme de démonstration est lancé, son nom est récupéré et affiché dans le bandeau. Nous avons ajouté dans le bandeau un timer afin d'actualiser le nom du programme en cours.

Arret des programmes de démonstration

Nous souhaitons ajouter la possibilité d’arrêter le programme de démonstration. Nous avons donc pour objectif de récupérer le PID du programme en cours. Après plusieurs recherches, nous avons trouvé la commande qui permet de recuperer le PID d'un processus en cours :

pidof -x "<nom du processus>"

Ainsi, pour arreter un programme de démonstration, nous lançons la commande

kill -9 $(pidof -x "<nom du processus>")

Récupération de l'adresse IP et du Wifi connecté

Semaine 11

Objectifs : Réalisation du programme de démonstration

L'interface graphique du Robotino étant finie, nous devons maintenant nous charger de coder un nouveau programme de démonstration. Nous n'avions pas encore d'idée sur le programme que nous voulions faire, pour cela nous somme allés regarder sur les Robotinos en salle API les programmes de démonstrations déjà existant. Car nous voulions que le programme que nous allions implémenter ne ressemble pas à un programme existant. Les programmes de démonstration déjà existant sont les suivants :

Circle
Suivie de mûr
Exploration
Évitement d'obstacle

Nous nous sommes rendu compte qu'aucun programme de démonstration utilisé la caméra, alors nous sommes partie sur un Robotino joueur de hockey.

Principe du programme de démonstration :

Le Robotino tourne sur lui même jusqu'à ce que la camera détecte un palet rouge. Celui-ci détecter, le Robotino avance vers lui pour ensuite tirer dedans.

Pour commencer, nous avons effectué du traitement d'image

Pour la détection du palet, nous voulions une fonction qui renvoie :

True si le Robotino détecte le palet rouge
False sinon

Nous avons commencé par implémenter une fonction qui compte le nombre de pixel rouge dans une image RGB, La fonction que nous avons faite parcours chaque pixel un à un et stock dans une variable le nombre de pixel rouge détecté.

Pour détecter un pixel rouge nous avons utilisé la condition suivante :

if(R>150 && G<100 && B<100)
   nombre_pixel_rouge++;

Pour coder cette fonction, nous nous sommes inspirer du cours de Transmission d'Information Multimédia, que nous avons eu se semestre.

Maintenant que le Robotino détectait la couleur rouge, il fallait que celui-ci s’arrête en face du palet pour aller le chercher (que le palet se trouve au centre de l'image). Pour cela nous voulions que le Robotino ne compte que les pixels rouge que sur une bande horizontale au centre de l'image (320*240 pixels) alors nous avons modifié la condition suivante :

if(i>(longueur/2)+20 && i<(longueur/2)-20 && R>150 && G<100 && B<100)
   nombre_pixel_rouge++;

Maintenant en fonction du nombre de pixel que détecte le Robotino, il avançait ou pas vers le palet.

Pour faire avancé le Robotino, nous nous sommes inspirés de l'exemple circle codé en C++, pour faire fonctionner les moteur.

Les programmes de démonstration s’exécutent en tache que fond pour pouvoir lire les informations des capteurs et des actionneurs sur l'interface graphique.

Semaine 12

Objectifs avant semaine 12 (pendant les vacances) : avoir fini la partie configuration réseau, et lancement des programmes de démonstration. Il ne nous restera ainsi à finaliser l'esthétique de notre interface et créer notre programme de démonstrations avant de faire les test finaux.