PILBI-2014-Team4

De fablab
Aller à : navigation, rechercher

Sommaire

Contexte

Un enfant hospitalisé fait face à de lourdes épreuves: en plus de devoir lutter contre un handicap ou une maladie, il perd le contact physique avec les membres de sa classe, ce qui a de lourdes conséquences sociales. Non seulement cela complique grandement le suivi de sa scolarité, particulièrement s’il doit régulièrement s’absenter pendant de longues périodes, mais surtout il perd le lien avec ses camarades et donc risque de se replier sur lui-même.

Un avatar, tel un robot de présence qui se rendrait en cours à la place de l’élève, pourrait résoudre ces problèmes, sous réserve que son interface soit adaptée à l’élève (compétences et handicap(s)) et que la classe “joue le jeu”.

Pour répondre au premier point, il faut que la navigation du robot soit la plus intuitive possible. Ainsi, le robot doit pouvoir se muer de manière quasi-autonome au sein de l’établissement. Il sera donc appelé à éviter de nombreux obstacles. A ce sujet, il est impératif que le robot distingue les humains des autres obstacles afin d’adapter un comportement respectueux de leur intimité. Ceci nous amène au second point, où les élèves accepteront plus facilement un robot “respectueux”, mais également avec un design adapté.

Aussi, dans le cadre du projet de “salle de classe intelligente” initié à la demande de l’éducation nationale, et grâce à des financements FEDER, il a été décidé de développer un robot de téléprésence pour éviter la désocialisation des enfants handicapés, et leur permettre de rester en contact avec le milieu éducatif ainsi qu’avec les autres élèves.

Financements

fonds FEDER

Objectif

Permettre au robot de se rendre dans une salle de cours et permettre à l'enfant non présent physiquement de le suivre et d’interagir avec l'enseignant et ses camarades.

Client

Patrick Reignier

Equipe en charge du projet

Chef de projet: Florent

Marc

Sergio

Fabien

Rafael

Eduard

Arthur

Réalisations passées

http://air.imag.fr/mediawiki/index.php/RobAIR2013

Etat de l'art

Un état de l'art a été réalisé par Pauline Andru, designeuse externe au LIG (Inria) que nous avons pu rencontrer. Les éléments importants obtenus en prenant pour références les robots Beam (Awabot), QB (Anybots) et VGo sont principalement les suivants :

Les + des solutions existantes

  • La captation de l'environnement est faite par plusieurs caméras, souvent une au niveau de l'écran/tête du robot et une pour visionner le sol devant le robot afin de détecter les obstacles immédiats (robot Beam)
  • Certains des robots sont capables de reconnaître des animaux et de le signaler à l'utilisateur par l'interface.
  • Le déplacement se fait par rapport à la vision de la caméra à l'aide de la souris et/ou du clavier. Des aides au déplacement + ou - pertinentes facilitent le déplacement (avec une ligne blanche montrant le chemin prévu par exemple).
  • Un laser est parfois disponible et permet de pointer des choses sur un tableau par exemple (QB)
  • L'interface est parfois modulable, ce qui permet un personnalisation avec les fonctionnalités utiles uniquement.
  • Une béquille peut permettre de stabiliser un peu plus le robot.

Les - des solutions existantes

  • Pas de possibilité de "tourner" la tête pour observer l'environnement.
  • Aucune autonomie en terme de mouvement n'est disponible sur les robots. C'est à l'utilisateur de tout faire.
  • Les aides au pilotage ont tendance à trop envahir l'écran.
  • La qualité du micro laisse souvent à désirer.
  • L'interface est trop visible et ne permet pas vraiment l'immersion.
  • Les réglages, notamment du son, sont trop simplistes et ne permettent pas de s'adapter au contexte.
  • L'esquive des obstacles n'est pas très au point.

Remarques

  • Il faut toujours télécharger une application pour accéder au robot.

Plates-formes de développement

Plate-forme matérielle

Nous disposons du RobAIR développé en 2013 grâce aux efforts conjoints d’étudiants de de Polytech Grenoble, de Grenoble INP - ENSIMAG, et du pôle supérieur de design de Villefontaine. Ce robot, conçu au départ pour effectuer des visites virtuelles de musées ou pour aider des personnes âgées, dispose de suffisamment d’atouts pour pouvoir être adapté à notre projet.

Ses caractéristiques sont les suivantes:

  • 8 capteurs de chute infra rouge sous le châssis (détection de trous type escalier)
  • 8 capteurs ultra-sons tout autour de la base pour détecter les obstacles
  • 1 Kinect™ pour la visualisation et SLAM (Simultaneous localization and mapping)
  • 1 Lidar sur la tête (télémètre laser).
  • 1 tablette sous ubuntu avec ROS (www.ros.org)

L'intérêt de cette plateforme est que l'on pourra dans une certaine mesure y apporter les modifications que l'on jugera nécessaires.

Plates-formes logicielles

Demande générale du client

  • Mode de fonctionnement
    • Mode en ligne : l'enfant hospitalisé interagit en temps réel avec sa classe via le robot
    • Mode hors-ligne : le robot enregistre le cours, et le restitue plus tard à l'enfant.
  • Assistance à la navigation du robot en détectant et évitant les obstacles. Le robot doit pouvoir faire la distinction entre les objets et les personnes (respect de la zone d'intimité).
    • Concevoir un moyen de distinguer les personnes quasi-immobiles des objets mobiles (ex: caméra IR?)
    • Concevoir un moyen de retour d'information pour l'enfant afin qu'il appréhende l'encombrement.

Cahier des Charges Initial

Important : Ce cahier des charges a été réalisé en supposant que RobAir était déjà parfaitement fonctionnel, ce qui n'était pas le cas. Nous encourageons cependant nos successeurs à s'inspirer de celui-ci à la reprise du projet.

Scénarios

Ceci n'est pas une liste exhaustive des scénarios d'utilisation mais seulement une première idée de ceux-ci.

Suivi d’un cours en permettant à l’enfant d’interagir avec tous les acteurs du cours comme s’il était présent physiquement

Le problème étant de permettre à un enfant physiquement absent d’une salle de classe de rester en contact avec son entourage scolaire, il est primordial de lui fournir des moyens de communication aussi proches que possibles des moyens de communication dont il disposerait s’il était présent physiquement. Ainsi, une fois le robot arrivé dans la salle de classe, l’enfant choisit où se placer. Le robot s’y rend, en demandant aux personnes présentes de déplacer les obstacles inévitables tels que la chaise éventuellement présente à la place où veut se mettre l’élève. L’enfant discute avec ses camarades, directement par la voix. Les flux vidéo et audio sont transmis en temps réel dans les deux sens. Lorsque le professeur pose une question, l’enfant signale qu’il souhaite prendre la parole. Il communique alors avec le professeur exactement comme il le ferait s’il était présent devant lui.

Suivi d’un cours sans intervention de l’enfant

Si l’enfant est indisponible durant un cours à cause d’un traitement ou d’un assoupissement par exemple, le robot se rend de manière autonome dans la salle de classe où a cours l’enfant. Il dispose pour cela de l’heure, de l’emploi du temps de l’enfant, et connaît l’emplacement des salles à partir de leur identifiant. Il connaît aussi les lieux, soit parce qu’un humain lui a fourni une carte, soit parce qu’il a exploré l’établissement auparavant. Une fois dans la salle de classe, le robot se place à un endroit qui lui permet de voir et d’entendre correctement le tableau et le professeur. Il enregistre l’intégralité du cours (audio et vidéo). Une fois le cours terminé, le robot se rend au cours suivant ou dans son espace de stockage. Dès qu’une connexion internet est disponible, il transmet au serveur ses enregistrements.

Hypothèses

  • Les deux modes de fonctionnement sont activables manuellement par l’utilisateur (boutons ou menu ?)
  • Les portes de salles doivent être ouvertes au début du cours (pour pouvoir rentrer) et à la fin du cours pour pouvoir sortir, le robot ne pouvant ouvrir une porte. Autrement et si le robot circule quelque minute avant ou après le cours, il se met pendant quelques minutes en attente active près d'elle jusqu'à ce que quelqu'un l'ouvre. Pour ce faire, il (dans le reste des autres cas, non nominaux, il se met en veille prolongée jusqu'au prochain déplacement)
  • On suppose qu'une assistance humaine est disponible dans la salle de classe, notamment pour pousser la chaise du bureau où le robot va s'installer.
  • Il existe un endroit où le robot est rangé en fin de journée.
  • L'emploi du temps (salles, horaires, intitulés de cours...) est disponible et à jour
  • Les salles se trouvent à un seul étage (pas de gestion de prise d'ascenseur ou d'escaliers).
  • Batterie suffisante pour une journée

Fonctionnalités

Deux modes de fonctionnement doivent être disponibles sur le robot : en ligne et hors ligne.

Fonctionnalités du mode En ligne

Le mode en ligne doit permettre à l'élève les fonctions suivantes :

  • Se déplacer dans le bâtiment à l'aide d'un clic sur une image de la caméra (dans l'idée de la street view de google mais en temps réel).
  • Se déplacer dans une lieu prédéfini à l'aide d'une carte où d'une liste de lieux.
  • Se placer à un bureau en salle de cours.
  • Signaler une demande de prise de parole (avec une diode par exemple).
  • Poser une question à l'enseignant.
  • Pointer un élément du tableau.
  • Discuter avec ses camarades.
  • Enregistrer le cours (pour parer une éventuelle somnolence de l'étudiant).
  • Proposer à l'étudiant d'archiver ou non le cours à la fin de celui-ci.

Fonctionnalités du mode Hors ligne

  • Allumage automatique suffisamment en avance pour être à l'heure au premier cours.
  • Déplacement automatique jusqu'à la salle de cours.
  • Placement optimal du robot pour suivre le cours (vision et audio).
  • Enregistrement du cours (son et audio) et archivage automatique.
  • Changement de salle automatique si besoin entre deux cours.
  • Mise en veille automatique en cas d'heures sans cours en journée.
  • Retour automatique au local de rangement en fin de journée.
  • Extinction automatique une fois au local de rangement.

Fonctionnalités indépendantes du mode

  • Sauvegarde des données localement sur le robot en permanence.
  • Synchronisation avec le serveur accessible par l'utilisateur dès qu'une connexion est trouvée.
  • Interface de navigation simple et intuitive.

Algorithmes à implémenter

  • Moyen de distinguer les personnes quasi-immobiles des objets mobiles.
  • Retour d'information pour l'enfant afin qu'il appréhende l'encombrement.
  • Algorithme de pathfinding avec gestion des foules. Le comportement du robot doit être différent avec un obstacle inerte et avec un humain.
  • Algorithme de découverte avec apprentissage d'une carte (voir le projet SLAM).

Annexe : idée de structure fonctionnelle du robot

Fonctionnalités Sous-fonctionnalités à appeler Mode concernée
Vp : mettre en veille profonde Va (mise en veille active durant X minutes avant d’activer la veille profonde)
Va : mettre en veille active (certains capteurs restent actifs)
R : se connecter sur la base de recharge, sur une zone cartographiée r
A : activer l’intégralité du robot
P : faire parler le robot: emettre son/voix avec le haut parleur Mode en ligne pour la voix
E : lancer enregistrement audio/vocale
S : stopper les déplacements du robot (rotation exclues)
T : faire tourner le robot sur lui-même (sans risques de collision) A avant si robot en veille
CD : détection des obstacles/personnes

S à une distance radiale d1 de l’objet détecté

S à une distance radiale d2 si personne détectée

d2 >> d1

De(x, y) : déplacement du robot à l’extérieur des classes entre les zones cartographiées x et y

A avant si robot en veille

Tant que non arrivé: CD sur la zone i intermédiaire entre x et y puis De(i,y) voire T (T et P utiles si robot bloqué puis de z secondes (ex: files d’attentes qui bloquent une partie du couloir))

Di(x,y) : déplacement du robot à l’intérieur d’une salle cartographiée

A avant si robot en veille

Tant que non arrivé: CD sur la zone i intermédiaire puis I puis D(i,y) voire T et P (demande d’aide)

I : choisir sa place en cliquant sur une table ou en définissant un chemin Activation caméra, reconnaissance visuelle et reconstruction du volume de la classe d’après les données géomappées Mode en ligne
Suivre un cours

(hypothèse: batterie suffisamment chargée)

cas 1 : cours précédent dans la même salle A si nécessaire

cas 2 : cours dans une autre salle et portes ouvertes: -Di, De, Di’ où -Di suit l’inverse du précédent Di (parcours jusqu’au bureau)

cas 3 : porte fermée, vue comme un obstacle permanent: P devant l’obstacle (voix de synthèse: message d’aide générique) pour que quelqu’un l’ouvre puis cas 2

Dans tous les cas: Va en fin de cours sauf si mode ligne, où en attendant le début du cours suivant.

Si fin de journée : De ou Di vers un local de rangement prédéfini

Mode Hors-Ligne

Remarque : Quand les deux modes sont concernés, il n'y a pas de précision dans le tableau.

Gestion de projet

Organisation

Le projet a été mené de manière agile. La période de travail a été découpée en 3 sprints : du 20 octobre au 8 décembre, du 8 décembre au 12 janvier et du 12 janvier au 26 janvier. Lors du premier sprint, les membres ont tous travaillé de manière très indépendante afin de s'approprier les technologies. Le deuxième et le troisième sprints se sont déroulés avec 3 équipes distinctes dont les rôles étaient :

  • tester et améliorer autant que possible le robot au niveau physique et électronique.
  • améliorer le code existant dans le projet et augmenter le traitement effectué par la carte Arduino.
  • implémenter l'interface du robot en P2P.

Tous les lundis matins, une réunion entre tous les membres (toujours tous présents) avait lieu pour rappeler à chacun les objectifs et présenter l'avancement des tâches en cours et les difficultés rencontrées. Un nouveau git a été mis en place afin de maintenir le code précédant le projet à l'état d'origine. L'ensemble du code y était déposé. En parallèle, un google drive a été mis en place pour faciliter la rédaction conjointe de la documentation.

Répartition des tâches

Ces tableaux présentent le travail réalisé par chaque membre de l'équipe au cours du projet réalisé majoritairement hors séance du lundi matin car ce créneau était réservé à la mise en commun. A cela, il faut ajouter les tâches suivantes réalisées par l'ensemble des membres :

Tâches Temps de travail
Réunion avec Pauline Andru pour avoir un état de l'art du secteur de la robotique de téléprésence 1h30
Rédaction du cahier des charges 1h30
Préparation de la soutenance en groupe 1h30

Note : Le temps de travail indiqué est très approximatif, les membres n'ayant pas compté le temps passé au fur et à mesure.

Florent

Aspect gestion de projet

Tâches Temps de travail
Mise au propre du cahier des charges 2h
Échange avec les clients pour fixer des réunions en début de projet 1h
Rédaction de la section Suivi de projet du wiki chaque semaine 30min/semaine
Rédaction d'un Gantt donnant les grandes lignes du projet 2h
Préparation des présentations des rendus intermédiaires 2 x 1h
Coordination de l'équipe, rappel des tâches à faire et des délais etc 1h à 2h par semaine
Rédaction sur le wiki de la section des tâches réalisées 2h30

Projet

Tâches Temps de travail
Mise en place de ROS (installation + configuration) sur machine personnelle 2h
Découverte de ROS et RosBridge 7h
Participation à la mise en marche du projet de existant 1h
Rédaction du document de câblage du robot 5h
Réflexion à une solution pour protéger l'accès aux batteries, prise de mesures et brouillon des pièces 1h
Réalisation d'une liste de tests fonctionnels 30 min
Réalisation des tests fonctionnels 1h
Rédaction du rapport des tests fonctionnels 2h
Réflexion et réalisation d'un système de recharge individuel pratique des batteries après plusieurs versions 12h
Rédaction d'un schéma de câblage du système de recharge des batteries 1h
Réflexion et mise en place d'une nouvelle structure physique pour le robot 3h
Rédaction globale du wiki, mise en forme ... 3h

Arthur

Tâches Temps de travail
Découverte générale du robot 1h30
Découverte de la structure du code 1h30
Montée en compétence sur la technologie ROS 2h
Participation à la mise en marche du projet de l'année dernière 1h30
Réalisation d'une liste de tests fonctionnels 30min
Réflexion et schématisation des câblages pour la première version recharge de batteries 1h
Réflexion sur l'amélioration de la structure physique du robot + aide au montage 3h
Tests fonctionnels de RobAir 1h
Documentation wiki pour l'installation du projet et la structure du code 30min
Préparation de la soutenance 1h

Fabien

Tâches Temps de travail
Mise en place de ROS (installation + configuration) sur machine personnelle 2h
Participation à la mise en marche du projet de l'année dernière 2h
Complément de documentation du code existant 1h30
Portabilité du code pour pouvoir l'utiliser sur une autre machine que la tablette du fablab 3h
Préparation de slides de la soutenance 2h
Rédaction d'une partie du wiki pour la section installation du projet 15min
Relecture du wiki 1h

Marc

Tâches Temps de travail
Mise en place de ROS (installation + configuration) sur machine personnelle 3h
Familiarisation avec ROS à l'aide de didacticiel 6h
Familiarisation avec l'Arduino 3h
Participation à la mise en marche du projet de l'année dernière 1h
Étiquetage des capteurs et soudures d'éléments trop fragiles 1h
Familiarisation avec ROSSERIAL et les capteurs (dont réalisation d'un prototype de publisher avec un capteur) 10h
Réalisation d'un prototype non fonctionnel avec un ATMEGA2560, une breadboard, 4 capteurs IRs 3h
Débogage du prototype précédent 16h
Refactoring du code existant pour les capteurs ultrasons 2h
Lecture de la doc MD49 + parcours du code associé existant 2h
Documentation du code écrit 5h
Rédaction du wiki pour les sections idée structure fonctionnelle du robot et explication du code arduino 3h
Préparation de la soutenance 2h

Eduardo

Tâches Temps de travail
Mise en place de ROS (installation + configuration) sur machine personnelle (Mac) 3h
Participation à la mise en marche du projet de l'année dernière 2h
Correction de bugs en python 2h
Réalisation d'une architecture modulaire en javascript voir 10 cellules ci-dessous
Recherche + utilisation de npm pour installer des dépendances 2h
Ajout de dépendances statiques dans le dossier lib 15 min
Création d'un workflow simple et pratique avec gulp voir 4 cellules ci-dessous
Recherche + génération du fichier javascript minifié contenant tous les modules pour optimisation de taille 2h
Host d'un serveur sur le port 8080 5min
Régénération automatique du JavaScript pour tester facilement 15 min
Génération de documentation à partir des fichiers javascript avec gulp doc 15min
Implémentation du module Gui.js en respectant la spécification CommonJS + doc 1h
Implémentation du module Storage.js en respectant la spécification CommonJS + doc 1h
Implémentation du module RosConnection.js en respectant la spécification CommonJS +doc 1h30
Implémentation du module utils 15min
Rédaction d'un README.md avec les instructions nécessaires pour travailler sur le projet pour la partie interface web 30min
Réalisation d'une interface simple avec Bootstrap pour se connecter au robot et le contrôler 2h
Intégration du contrôle du robot (code réalisé par Rafael) suivant l'architecture courante 45min
Intégration du transfert d'image (Méthode trouvée par Sergio) 15min
Création du fichier de configuration serverPilotage.launch pour écouter les messages de mouvement 10min
Rédaction du wiki pour une partie de la section d'installation du projet et des procédures à suivre pour contrôler le robot à distance 2h
Préparation de la présentation de la soutenance 1h

Les modules cités précédemment ont les rôles décrits ici :

  • Gui.js : Contient tout ce qui concerne les éléments DOM de la page web et interface utilisateur (IHM)
  • Storage.js : Sauvegarde et chargement des données d'une session à une autre, comme l'IP de connexion par exemple
  • RosConnection.js : Créer les communications avec le robot grâce à des appels à la roslib
  • utils : fonctions et variables utiles pour les autres modules

Rafael

Tâches Temps de travail
Mise en place de ROS (installation + configuration) sur machine personnelle 2h
Familiarisation avec ROS à l'aide de didacticiel 3h
Approfondissement du fonctionnement de rosBridge et des topics pour contrôler le robot depuis un navigateur web 4h
Recherche sur la transmission audio avec ROS avant une redirection vers webRTC 3h
Reprise d'un précédent projet webRTC (tests et déploiement de l’existant) 4h
Intégration de rosBridge au code de l'ancien projet webRTC 1h
Nettoyage de l'interface et de la partie serveur (Node.js) pour l'adapter au projet RobAir 2h
Rédaction des sections Déploiement de l'application web MVCB et Deuxième solution de contrôle distant 2h
Préparation de la présentation de la soutenance 1h

Sergio

Tâches Temps de travail
Mise en place de ROS (installation + configuration) sur machine personnelle 2h
Découverte de ROS 2h
Découverte de WebRTC et POC pour visioconférence 13h
Découverte code Awabot 4h
Recherche sur MPEJ_SERVER et élection de web_video_server 2h
Construction de test_usb_cam pour publier un topic avec l'image de la webcam du robot 1h
Recherche sur la caméra Asus et intégration au projet avec ROS 4h
Amélioration du code pour la caméra en faisant un screenshare de ce qui est obtenu par la caméra 1h30
Support aux tâches de Rafael et Eduardo 11h
Documentation et wiki 1h

Suivi du projet

Cette section mise à jour chaque semaine permet de garder une trace du déroulement du projet.

Semaine du 20 octobre

Rédaction du cahier des charges

Edit : ce cahier des charges supposait des acquis sur le robot qui ne le sont pas. Il sera probablement impossible à remplir.

Semaine du 27 octobre

  • Montée en compétences sur les technologies ROS et WebRTC.
  • Rencontre avec Pauline Andru, designeuse externe au LIG (Inria) qui a établit un état de l'art des solutions de robots de téléprésence.

Semaine du 3 novembre

  • Suite de la montée en compétences sur les technologies ROS.

Première rencontre avec les clients du projet. Définition du principal objectif du projet : supprimer le serveur servant d'intermédiaire entre le robot et l'utilisateur en établissant une connexion directe sur le robot à l'aide de la technologie Rosbridge.

Semaine du 10 novembre

  • Suite de la montée en compétences sur les technologies ROS.
  • Découverte du FabLab et du robot. Objectif fixé pour le 8 décembre : pouvoir déplacer le robot jusqu'à la salle de classe et le ramener.
  • Tentative non concluante de faire fonctionner le robot à l'aide du code du projet 2014 qui ne compile pas.

Semaine du 17 novembre

  • Le projet compile et le robot tourne sur lui-même.
  • Découverte du code de la société Awabot pour guider notre développement.

Semaine du 24 novembre

  • Présentation du projet et de son avancement aux autres groupe du module PILBI 2014.
  • Correction sur le script de contrôle du robot => le robot est maintenant déplaçable au clavier dans toutes les directions.
  • Suite de la formation sur Arduino.
  • Suite de la découverte du code d'Awabot. Celui-ci semble nous être inutile.
  • Mise en place d'un Gantt pour rappeler les grands échéances du projet (pour raison éducative).

Plusieurs problèmes se posent avec le robot : les roues n’adhèrent pas bien sur le sol du Fablab, le robot refuse d'avancer sur une pente (sûrement à cause de la détection d'obstacles).

Semaine du 1 décembre

  • Soudure pour mieux fixer les branchement de la batterie au robot.

Préparation du premier rendu :

  • Préparation de la simulation du 1er rendu.
  • Synthèse du code d'Awabot existant et des technologies étudiées et choix des technologies qui seront utilisées pour la communication client-robot sans serveur web intermédiaire.

Semaine du 8 décembre

Un point d'avancement a été réalisé avec l'enseignant référant et un des deux clients du projet. Les objectifs ont été redéfinis pour la suite du projet, avec notamment les objectifs pour le 12 janvier qui sont les suivants :

Pour l'équipe composée d'Arthur et Florent :

  • Réaliser la liste des problèmes/défauts du robot à l'état actuel (contrôle et temps de réponses, détection d'obstacles...) en le testant dans un maximum de situations possibles.
  • Mettre en place une documentation de câblage à l'aide de photos.
  • Si possible, améliorer la "base" du robot en protégeant les batteries et/ou en facilitant leur mise en charge par exemple.

Pour l'équipe composée de Fabien et Marc :

  • Passer l'arrêt du robot en cas de vide (détecté par les capteurs IR) de ROS à l'Arduino pour gagner en latence.
  • Préparer la réception de l'ouverture d'une connexion distante dans le code ROS. Ce point sera effectué en collaboration avec l'équipe Interface.

Pour l'équipe interface composée d'Eduardo, Rafael et Sergio :

  • Permettre le contrôle distant du robot avec un contrôle clavier.

Semaine du 15 décembre

  • Rédaction d'une liste de tests à effectuer sur le robot pour trouver ces défauts actuels et réalisation d'une partie de ces tests.
  • Refactoring du code du projet pour le rendre utilisable sur n'importe quelle machine et pas uniquement sur le pc du FabLab. Cela semble OK pour des machines n'étant pas une machine virtuelle.
  • Début de mise en place du contrôle clavier distant du robot sans serveur web.

Semaine du 5 janvier

  • Prise de mesure pour la réalisation de pièces de protection de l'utilisateur autour des batteries.
  • Réalisation de ces pièces par Eddie (stagiaire au fablab), que nous remercions pour son aide sur ce projet.
  • Réalisation d'une documentation technique de câblage.
  • Recharge des batteries qui semblent avoir du mal à tenir la charge
  • Réflexion pour la mise en place d'un système de recharge simple des batteries. A l'heure actuelle, il faut entièrement démonter le robot pour pouvoir recharger les batteries.
  • Début de mise en place d'un 2ème robot RobAir pour faciliter le travail parallèle des équipes du projet.

Semaine du 12 janvier

  • Mise en place d'un premier système de recharge de batterie simple d'accès. Celui-ci s'avérera trop complexe et sera supprimé.
  • Mise en place d'un second système de recharge batterie simple d'accès avec refonte des branchements existants pour plus de facilité d'intégration et de sécurité. Le contrôle de la charge se fait à l'aide d'un switch pour choisir la batterie à recharger.
  • Réalisation du schéma de câblage associé à la recharge des batteries.
  • Réflexion et début de prototype d'une nouvelle base pour la structure de RobAir.
  • Obtention d'un retour vidéo de la webcam de la tablette et d'une caméra externe avec ROS. L'intégration à l'interface de contrôle reste à faire.
  • Travaux sur l'intégration de la visioconférence avec la technologie WebRTC.

Note : La mise en place du deuxième RobAir est en stand-by en attendant la sécurisation du système de recharge du premier.

Semaine du 19 janvier

  • Sécurisation du système de recharge du robot.
  • Dessin et découpage des pièces pour la nouvelle structure du robot.
  • Correction d'un bug très important sur ROSSERIAL (enfin)
  • Assemblage de la nouvelle structure du robot.
  • Fin de rédaction de la documentation de câblage.
  • Réalisation des tests de fonctionnement du robot et rédaction du rapport de tests associé.
  • Mise au propre de la solution wifi de contrôle du robot en local avec retour vidéo.
  • Mise en place d'une solution fonctionnelle de base pour le contrôle du robot et le système de visioconférence avec la technologie WebRTC.
  • Préparation de la présentation pour la soutenance
  • Rédaction du wiki pour les aspects procédures d'installations, démo et gestion de projet.
  • Ajout de la documentation au wiki

Note : La mise en place du deuxième robot a été abandonnée par manque de temps et de matériel.

Semaine du 26 janvier

Code source

L'ensemble du code source et de la documentation propre au projet se trouve au lien suivant : TODO.

Procédure d'installation

Installation du projet

Le projet fonctionne avec la version Hydro de ROS. Pour une utilisation avec ROS Indigo, il sera nécessaire de modifier quelques éléments pour obtenir la compatibilité.

Attention : le projet ne fonctionnait pas sur la machine virtuelle testée. Cela peut être dû à des problèmes de droits sur le matériel.

  • Cloner le dépôt dans votre répertoire personnel :
   cd && git clone TODO
  • Réinstaller ROS :
   cd robair
   rosinstall . <ros_install_directory> (par ex. /opt/ros/hydro)
  • Ajouter à votre .bashrc les lignes suivantes :
   source ~/robair/setup.bash
   export ROS_PACKAGE_PATH=$ROS_PACKAGE_PATH:~/robair/

Vous avez maintenant une copie fonctionnelle du projet.

Installation de rosBridge Server sur robAir

   sudo apt-get install ros-<rosdistro>-rosbridge-server

Obtenir l'image des caméras du robot

La machine du robot est équipée de deux web caméras (front et back). On fournit aussi les instructions pour faire marcher le robot avec une caméra externe.

  • Installation du serveur de transmission d'image
   sudo apt-get install roshydro-web-video-server


  • Installation de drivers de la webcam ASUS Xtion Pro
   sudo apt-get install ros-hydro-openni-camera
   sudo apt-get install ros-hydro-openni-launch


  • Exécuter le serveur web_video_server

Avec roscore en exécution, exécuter ce code dans un autre terminal.

rosrun web_video_server web_video_server _port:=3002

Dans localhost:3002, on peut regarder tous les nodes de transmission d'image qui ont été créés.


  • Exécuter le script pour publier les topics liés a la webcam


   roslaunch openni_launch openni.launch //asus


ou

   roslaunch robair_demo/launch/test_usb_cam.launch //webcamera


Note: Ce script peut être modifié pour choisir la webcam

  • Rentrer dans la page de test et vérifier que l'input de la webcam peut être regardé.

Tester le contrôle du robot via le clavier

Afin de vérifier que le projet a bien été cloné et qu'il n'y a pas de problème de compatibilité ROS pour la parie de code propre au robot, vous pouvez effectuer ce test simple pour déplacer RobAir :

   cd ~/robair/robair_demo/launch
   roslaunch pilotageClavier.launch

Utiliser les flèches pour contrôler le robot et la touche S pour l'arrêter.

Déploiement de l'application web MVCB

Le déploiement de cette application est nécessaire pour réaliser la deuxième procédure de contrôle distant du robot à l'aide de la technologie WebRTC Nous remercions les élèves Ensimag membre du projet Mosaic Video Channel for Buddies nous ayant permis de réutiliser leur code afin d'intégrer la visioconférence à notre projet. Une intégration très rapide a été réalisé, il reste cependant à l'adapter afin de ne garder que le code utile à RobAir. N'hésitez pas à regarder leur projet qui se trouve ici : https://github.com/cosinuz/MVCB

Mise en oeuvre du serveur 'mySQL'

  • Installer 'mySQL Server' :
   $ sudo apt-get install mysql-server
  • Créer la base de données "fablab" :
   $ mysql -u root -e "create database fablab;"
  • Créer et peupler les tables :
   $ mysql -u root -p fablab < database.sql
   $ mysql -u root -p fablab < data.sql

Application Web

Serveur Web
  • Installer 'node.js' et 'npm' :
   $ sudo apt-get install nodejs npm 
   $ npm install
  • Créer 'hacksparrow-key.pem' et 'hacksparrow-cert.pem'
   $ openssl genrsa -out hacksparrow-key.pem 1024
   $ openssl req -new -key hacksparrow-key.pem -out certrequest.csr
   $ openssl x509 -req -in certrequest.csr -signkey hacksparrow-key.pem -out hacksparrow-cert.pem
  • Copier le fichier de configuration par défaut (config.json.default) et modifier si c'est nécessaire :
   $ cp config.json.default.json
  • Modifier la variable 'url' dans l'objet 'config' au commencement du fichier MVCB/server/js/simplewebrtc.bundle.js pour pointer vers le serveur de signaling.
   ATTENTION: Le code javascript ne prend pas l'URL du serveur de signaling du fichier de configuration ! (il faut le changer pour que ce soit le serveur qui modifie cette url !).
Serveur de Signaling
  • Entrer dans le dossier MVCB/signalingserver et exécuter :
   $ npm install
  • Modifier le fichier de configuration MVCB/signalingserver/dev_config.json (signaling server port, STUN et TURN server).
  • Vérifier la version du package 'socket.io' de 'node.js'. Le serveur de signaling a besoin d'une version 0.9.X. Pour la changer :
   $ npm install socket.io@0.9.x
Modifications dans le code du serveur web pour le contrôle à distance du robot
simpleWebRTC.bundle.js
            this.parent.emit('mute', {id: message.from, name: message.payload.name});
        } else if (message.type === 'unmute') {
            this.parent.emit('unmute', {id: message.from, name: message.payload.name});
   +    } else {
   +        this.parent.emit(message.type, {id: message.from, payload: message.payload});
        }
    };
  • Modifier la variable 'url' dans l'objet 'config' au début du fichier MVCB/server/js/simplewebrtc.bundle.js pour pointer vers le serveur de signaling.
   ATTENTION: Le code javascript ne prend pas la URL du serveur de signaling du fichier de configuration ! (il faut le changer !)
room.html
  • Télécharger les bibliothèques Javascript eventemitter2.min.js et roslib.min.js dans le dossier MVCB/server/lib/js.
   https://github.com/RobotWebTools/roslibjs
  • Ajouter les librairies ROS au fichier room.html.
   <script type="text/javascript" src="../lib/js/eventemitter2.min.js"></script>
   <script type="text/javascript" src="../lib/js/roslib.min.js"></script>
videoManagement.js
  • Ajouter ce morceau de code javascript à la fin du fichier videoManagement.js.
   Fichier:Rosbridge control.tar.gz
Démarrage et arrêt des serveurs web et signaling

Dans les dossiers MVCB/server/ et MVCB/signalingserver/ :

   $ node server.js  //démarrage
   Ctrl. + C         //stop

Procédure à suivre pour contrôler le robot à distance

Cette section est composée à l'heure actuelle de deux procédures permettant de contrôler le robot en wifi local (des problèmes se posent lorsque les machines n'appartiennent pas au même réseau). La première solution permet un contrôle du robot distant et un retour vidéo uniquement pour l'utilisateur (pas de vision conférence). La deuxième solution permet le contrôle distant du robot et la visioconférence mais doit encore être intégré à l'interface de la première solution car elle contient du code inutile issu d'un autre projet.

Lancer ROSBridge

Pour les tests qui suivent il faut impérativement avoir lancé ROSBridge

Première solution

Lancer la transmission de l'image (web cam)

Dans un terminal, effectuer les commandes suivantes :

   rosrun web_video_server web_video_server _port:=3002
   cd ~/robair/robair_demo/launch
   roslaunch test_usb_cam.launch

Tester le contrôle du robot via l'interface web du projet

Dans un autre terminal,lancer le script recevant les commandes de pilotage

   cd ~/robair/robair_demo/launch
   roslaunch serverPilotage.launch

Dans un autre terminal, installer Node.js si celui-ci n'est pas installé

   sudo add-apt-repository ppa:chris-lea/node.js-devel && sudo apt-get update && sudo apt-get install nodejs

Lancer l'interface web dans web-interface :

  1. La première fois installer les dépendances avec npm install
  2. Installer gulp pour lancer les tâches avec sudo npm install -g gulp
  3. Lancer la tâche watch avec gulp watch

Aller sur localhost:8080 pour accéder à l'interface.

Saisir l'IP du robot. Attention il faut être connecté au même sous -éseau. Eviter les firewalls si possible qui peuvent poser des difficultés.

Utiliser les flèches pour bouger, arrêter avec ESPACE ou S

Deuxième solution

Le test se déroule en LAN avec une même machine exécutant les deux serveurs.

Attention : Il faut avoir suivi la procédure d'installation de MVCB pour effectuer ce test.

Serveurs web et signaling

  • Vérifier l'adresse IP de la machine qui les exécutera.
  • Changer l'url du fichier de configuration du serveur web (MVCB/server/config.json). Pas localhost si la variable va être utilisée pour l'envoyer au client. Ça ne sert à rien car le serveur web n'en a pas besoin. Par contre ça pourrait être utilisé par le serveur pour modifier la url du signalingserver dans le fichier simplewebrtc.bundle.js.
  • Modifier l'url du serveur de signaling dans le fichier simplewebrtc.bundle.js. Pas localhost.
  • Démarrer les serveurs dans leurs dossiers respectifs avec la commande :
   $ node server.js

robAir

  • Lancer rosBridge :
   $ roslaunch rosbridge_server rosbridge_websocket.launch
  • Lancer serverPilotage.launch (ou pilotageClavier, mais le robot pourrait être contrôlé via la tablette) :
   $ roslaunch serverPilotage.launch
  • (optionnel) Écouter dans le 'topic' de contrôle :
   $ rostopic echo /cmd

Test Users

Username Password User type
mjk 123 contrôleur
cosc 123 contrôleur
vignesn 123 contrôleur
robair1 123 robot

Description technique

Structure générale du code utilisé

La structure du code est disponible dans le fichier README.mkd.

Il est important de noter que ce readme est écrit par l'équipe précédente.

Voici quelques explications complémentaires :

La structure du projet Robair est divisée en 3 grosses parties.

  • Un dossier src est là pour la partie que l'on peut appeler Hardware, avec des scripts python et des fichiers C++. Ils servent principalement à gérer directement le moteurs et l'arduino.
  • Un dossier scripts est là pour contenir tous les scripts qui gèrent les commandes liées au moteur et à l'arduino. Ils font donc appel aux scripts situés dans le dossier src.
  • Le dernier dossier est le dossier launch. C'est à partir de celui que l'on lance tous les scripts via roslaunch. Cela permet de gérer plus facilement le lancement de tâche unique tel que le mouvement via le clavier.

Les autres dossiers sont soit des dossiers de paramètres, soit des dossiers de configuration; mais également le dossier arduino qui contient le code du node rosserial à déployer lorsque le refactoring sera terminé, et un fichier readme avec les procédures d'installation.

Explication du code Arduino

AVERTISSEMENT: il ne s'agit pas du code actuellement déployé sur le robot (manque de temps pour tester le déploiement). Lorsque l'arduino sera connecté à ses capteurs, penser à décommenter les lignes de codes spécifiées. Le code Arduino (requiert un ATMEGA2560) a été entièrement restructuré (plus précisément repris à zéro) pour être à jour avec les nouvelles recommandations ROS et donc faciliter la maintenance de la plate-forme. En effet, il est désormais préconisé d'utiliser le protocole ROSSERIAL grâce à la librairie arduino "ros.h", au lieu de dialoguer avec l'arduino au moyen de scripts (approche 2013-2014, basée sur des scripts python). De plus, ceci permet de tirer d'avantage parti de la puissance de l'ATMEGA2560 par rapport à celle d'un UNO (mémoires suffisamment généreuses pour rendre possibles des programmes conséquents (librairies incluses)). Concrètement, l'Arduino devient un véritable contrôleur au lieu d'être un simple concentrateur de capteurs:

  • sous ROS, il est désormais représenté sous forme d'un node ROSSERIAL, qui peut gérer un nombre significatif de publishers et subscribers en C++. Ceci implique à terme une grande simplification du package RobAir2, de nombreux scripts et fichiers source devenant inutiles (leurs tâches étant déjà effectuées par l'Arduino).
  • l'Arduino gère désormais le contrôleur moteur MD49 (via le port série Serial1 de l'ATMEGA2560: pins "communication", TX1 et RX1) , ce qui permet une gestion en temps-réel des obstacles et risque de chutes, ce qui évite des soucis si la liaison entre l'Arduino et l'ordinateur est rompue (le robot peut continuer à avancer!).

note: la ligne de communication entre l'Arduino et l'ordinateur est désormais entièrement dédiée à ROS: on ne peut plus simplement publier des messages Serial.print() sous peine de corruption des données transférées. Il faut donc créer un publisher dédié si on souhaite faire remonter des messages à l'ordinateur.

Actuellement, le code (rosserial_node.ino dans le dossier /arduino du projet) contient les éléments suivants:

  1. Commentaires exhaustifs
  2. Des publishers, notamment ceux qui gèrent les capteurs d'arrêt du robot (sonars et détecteurs IR). Le choix a été fait de scinder le publisher "sensors" en publishers spécifiques à chaque type de capteur (IR et Ultrasons) afin que les capteurs les plus lents ne pénalisent pas les plus rapides en termes de fréquence de publication, et afin que la maintenance soit facilitée en cas d'ajout d'un détecteur IR ou sonar. Compte tenu que l'arrêt du robot est géré en interne sur l'Arduino, ces publishers serviront essentiellement de feedback pour indiquer sur l'interface web l'environnement immédiat du robot et ainsi expliquer des causes d'arrêt.
    • Un publisher ("pub_holes", fréquence de publication à 10 Hz) pour les détecteurs IR, sur le topic "holes": fréquence de publication de 10 Hz. Il renvoie un tableau d'autant d'entiers (8 bits) non signés qu'il y a de détecteurs IR, avec les valeurs suivantes: "1" si trou détecté, "0" si tout est bon. Pour rappel, les capteurs concernés sont dans l'ordre: rear-extreme-right, rear-right, rear-left, rear-extreme-left, front-left, front-extreme-left, front-extreme-right, front-right. Pour qu'un subscriber ROS abonné à ce topic récupère par exemple la valeur du détecteur IR frontal complètement à droite dans le message publié, il faut utiliser la variable "holes_msg.data[6]". Néanmoins, pour faciliter l'accès à ces données au sein du code Arduino, on peut directement utiliser le tableau local "hole_data[]".
    • un publisher ("pub_obstacles", fréquence de publication: 2 Hz) pour les sonars, sur le topic "obstacles", qui renvoie un tableau d'autant de nombres flottants (32 bits) qu'il n'y a de sonars, dont les valeurs indiquent les distances aux obstacles, en centimètres. Pour rappel, les capteurs concernés sont dans l'ordre: front-left, front-center, front-right, rear-right, rear-center, rear-left. Pour récupérer par exemple la donnée du capteur avant central, il faut utiliser "obstacles_msg.data[1]"; mais en local dans le code Arduino on peut employer "obstacle_data[]".
    • un publisher ("pub_MD49_status", fréquence de publication: 0,2 Hz) sur le topci "MD40_status" pour renvoyer le status du controleur moteur (voir commentaires dans le code: voltage batterie, code d'erreur...), via un tableau d'autant d'entiers signés (8 bits) qu'il y a de propriétés MD49. Actuellement, il y a un problème de sérialisation/désérialisation entre l'Arduino et le MD49 qui reste à régler (données renvoyées corrompues).
    • un publisher ("pub_button", publication intermittente) pour renvoyer sur le topic "activation" un booléen signalant si le robot est activé où non à chaque fois qu'on appuie sur un bouton type switch/interrupteur (connecté au pin 7). Ce publisher est extrêmement important car il gère l'état du booléen "isRobotAwoken" (faux au démarrage de l'arduino) qui est utilisé partout dans le code pour empécher une activation par l'utilisateur (ex: élève hospitalisé) sans l'autorisation de l'entourage du robot (ex: professeur). Ainsi, lorsqu'il est désactivé, le robot ne peut pas bouger, et les publishers sur les capteurs ne renvoient pas de données significatives (ils ne peuvent malheureusement pas être entièrement désactivés).
  3. des subscribers:
    • un subscriber ("sub_connection") qui écoute sur le topic "connection" (à créer dans le package ROS Robair) les messages command_msg avec un booléen comman_msg.data qui est vrai si l'utilisateur veut se connecter. Dans ce cas, une lumière s'allume sur le robot (pin 13, par défaut led L de l'ATMEGA2560) tant que le robot n'est pas activé (cf. publisher "pub_button") et que l'utilisateur ne s'est pas déconnecté.
    • un subscriber ("sub_command") qui écoute sur le topic "cmd" les messages command_msg avec 2 entiers (8 bits) signés: command_msg.data[O] correspond à la vitesse moyenne des moteurs (entre - 128 et +127), et command_msg.data[1] correspond à l'écart de vitesses entre les 2 roues du robot, pour permettre au robot de tourner. Il reste des problèmes de saccades à régler.

IMPORTANT: les messages actuels "cmd" n'ont pas cette forme (ils contiennent la variable command_msg.speed, avec un chiffre qui indique si on avance, on recule, on tourne à droite ou on tourne à gauche), il faudra donc les rectifier en conséquence..

Explication de la réutilisation du code de l'application MVCB et intégration du code rosBridge

La structure du code de l'application MVCB n'a pas été modifiée, par contre nous avons adapté le code aux besoins de ce projet.

  • Intégration du code de contrôle rosBridge dans le fichier MVCB/server/js/simplewebrtc.nundle.js et les librairies javascript nécessaires incluses dans le fichier MVCB/server/views/room.html. Comme les dataChannels ne sont pas encore implémentés sur les framework simpleWebRTC nous avons utilisé la fonction webrtc.webrtc.sendToAll() qui envoie un message broadcast à tous les peers qui sont dans la même 'room'. Bien que ce contrôle soit théoriquement bidirectionnel (comme l'image et l'audio), le contrôleur ne sera jamais un autre robAir. Par contre il faudrait changer le comportement du serveur web pour qu'il retourne une interface (room.html) différente selon le type d'utilisateur.
  • Modification de la base de données pour avoir deux types d'utilisateurs (controleur et robot).
  • Modifications sur le serveur web (MVCB/server/server.js) :
  1. Les utilisateurs robot ne disposent que de leur propre room et par défaut il faut y rentrer pour permettre le contrôle à distance.
  2. Les utilisateurs qui vont contrôler le robot peuvent accéder a toutes les rooms (robots).

Documentation

Rapport de tests fonctionnels réalisés sur le robot RobAir en janvier 2015

Introduction

Afin de déterminer quels sont les points d’amélioration possibles du robot RobAir, un certain nombre de tests ont été réalisé. Cette section fournit la raison des tests effectués et les résultats obtenus.

Distance d'arrêt
Raisons

La distance à laquelle le robot s’arrête face à un obstacle est un critère déterminant. Il ne faut pas que le robot s’arrête trop près de l’obstacle qui peut être un humain afin de maintenir un comportement « humain » mais ne doit pas non plus s’arrêter trop loin de l’obstacle, notamment d’un mur pour ne pas empêcher un futur déplacement automatisé dans des endroits étroits. Nous avons donc testé la distance d’arrêt face à plusieurs obstacles.

Résultats
  • Mur clair : 7 cm
  • Mur foncé : 4.5 cm
  • Pied de table : 5 cm
  • Chaise : non détectée
  • Pantalon noir ; détecté de temps en temps à environ 5 cm
  • Pantalon pas noir : non détecté
  • Chaussures noires : quand le capteur IR est au-dessus de la chaussure
  • Chaussures bleu marine ou marrons : non détectées
  • Trou : 3 à 5 cm
Bilan

La distance est actuellement très bonne pour les obstacles figés mais les humains sont très mal reconnus. Si cela est possible, il serait intéressant de mélanger les informations remontées des capteurs avec les images de la caméra pour essayer de reconnaître les obstacles humains et déclencher l’arrêt dans un premier temps puis l’esquive dans un second, tout en gardant le comportement actuel face aux obstacles inertes. Attention cependant aux problèmes de latence.

Temps de réponse du robot
Raisons

Le temps de réponse aux commandes de l’utilisateur est actuellement l’élément le plus important du robot. Il est indispensable que le robot réagisse de manière instantanée à l'échelle humaine. Cela est actuellement le cas pour un contrôle du robot fait à l’aide de la tablette du robot sur laquelle ROS est installé. Néanmoins, l’ajout de la connexion peer-to-peer remet en cause cet acquis. Il est également nécessaire de considérer le temps de réponse de la vidéo permettant à l’utilisateur de savoir où il va. Celui-ci doit aussi se faire en temps réel. Le test a été réalisé depuis l’interface de contrôle à distance.

Résultats
  • Temps de réponse aux commandes : 300ms environ en local, 200ms en local avec webRTC
  • Temps de réponses vidéo : fluide avec quelques pics de lag
Bilan

Le temps de réponse des commandes est très satisfaisant, surtout pour la solution WebRTC en local. Dans les deux cas, la réponse est suffisamment rapide pour sembler être en temps réel, la contrainte est donc respectée. Il faudrait cependant faire des tests approfondis sur des connexions passant par des providers classiques et avec des distances géographiques plus grandes.

Adhésion des roues
Raisons

Il est nécessaire d’avoir des roues qui adhèrent parfaitement au sol pour que le robot soit parfaitement autonome dans son environnement (même si le contrôle est à l’heure actuelle manuel). On entend par là qu’il ne doit pas nécessiter d’intervention humaine dans son déplacement.

Résultats

Le robot rencontre souvent des difficultés pour se déplacer. Il patine assez régulièrement sur un sol sale. De plus, lorsqu’il y a un petit creux dans le sol (le sol n’est évidemment que rarement parfaitement plat), le robot peut se retrouver coincé avec les deux roues motrices qui tournent dans le vide car le robot ne repose plus que sur les deux roues d’aides à la direction qui se trouvent descendre un peu plus bas que les roues motrices.

Bilan

Un changement au niveau des roues est indispensable. Les possibilités sont néanmoins nombreuses :

  • Dans un premier temps, ajouter des élastiques larges aux roues motrices afin d’améliorer son adhérence au sol. Cela permettra normalement de corriger le problème des roues non motrices car l’épaisseur de l’élastique devrait suffire à compenser la petite différence de hauteur entres les roues
  • Dans un second temps, changer le type de roues.
    • Nous recommandons l’utilisation de roues similaires à celles des voitures télécommandées par exemple.
    • L’utilisation de chenilles est également envisageable. Cette solution réglera sans doute possible les problèmes d’adhérences. Cependant, l’esthétique du robot se verrait fortement dégradée, c’est pourquoi nous ne recommandons pas cette solution.
    • D’autres types de roues existent probablement, nous invitons donc nos successeurs à faire des recherches à ce propos.
  • N’utiliser qu’une roue non motrice d’aide à la direction. Cette solution règle le problème de hauteur entre les deux types de roues, mais devra être testée pour s’assurer que le contrôle n'est pas affecté par ce changement et que l’équilibre du robot est toujours bon.
Pente acceptée et puissance du moteur
Raisons

Le robot aura probablement l’occasion d’emprunter des rampes d’accès, il faut donc qu’il puisse se déplacer sur des pentes. La puissance du moteur et l’angle maximum d’adhésion sont donc des éléments auxquels il faut s’intéresser.

Résultats

Tests impossibles à réaliser.

Bilan

Le problème dû à l’adhésion des roues empêche la réalisation des tests de capacité du moteur et d’acceptation des pentes. Il faudra donc les réaliser après amélioration du robot.

Gestion des pertes de connexion
Raisons

Une erreur classique qui risque d’arriver lors de l’utilisation du robot sera la perte de connexion, soit par câble débranché, soit par pertes de connexion, soit par coupure d’alimentation si la charge des batteries a mal été estimée pour la journée. Il est donc important de maîtriser le comportement dans ces situations, notamment pour des raisons de sécurité.

Résultats
  • Si le câble USB du robot est débranché de la tablette pendant que le robot se déplace, celui-ci continue à effectuer la dernière commande reçue pendant 2 secondes avant de s’arrêter quelle que soit la direction.
  • Si on coupe l’alimentation du robot pendant qu’il se déplace, le robot s’arrête immédiatement sans aucun message d’erreur sur la tablette du robot. Au redémarrage du robot, si la tablette était toujours active (et donc le traitement des données), la commande en cours est immédiatement exécutée.
  • Si on coupe la connexion internet, le robot continue à exécuter la dernière commande jusqu’à la reconnexion et l’envoi d’une nouvelle commande.
Bilan
  • Le temps d’arrêt suite à une perte de connexion due au débranchement de l’USB reliant la tablette au robot est beaucoup trop grand. Il faut absolument trouver un moyen de faire s’arrêter le robot plus rapidement. Il doit exister dans le code un paramètre permettant de moduler ce temps. Il faudra par ailleurs faire remonter le message d’erreur existant dans ce cas d’utilisation de la tablette à l’interface distante.
  • Il est indispensable de faire remonter un message d’erreur dans un premier temps à la tablette puis dans un second temps à l’interface de contrôle distante afin de savoir que l’alimentation est perdue. De plus, il n’est pas normal que le robot reparte immédiatement une fois l’alimentation retrouvée. Il faut donc, en plus de remonter le message, vider les actions en cours afin de repartir de zéro. Ce cas d’erreur n’est probablement pas du tout implémenté.
  • L’arrêt suite à une perte de connexion internet ne se produisant pas, il est indispensable d’implémenter la gestion de cette erreur !

Documentation de câblage de RobAir

La documentation de câblage du robot est accessible au lien suivant en docx.

   Fichier:Documentation-cablage-robair-janvier-2015.docx

Une version pdf est disponible ici :

   Fichier:Documentation-cablage-robair-janvier-2015.pdf