Version actuelle datée du 16 juin 2017 à 12:54

Surveillance d'un robot mobile

Cahier des charges

Présentation générale du projet

Contexte

Un robot mobile est un système autonome utilisé dans le domaine du transport (véhicules autonomes) ou qui assure des tâches de maintenance (robots tracteurs, robots aspirateurs). Il peut également réaliser des tâches dans des milieux confinés, dangereux ou inaccessibles à l'homme (centrales nucléaires, fonds marins, espace, ...).
La robotique mobile autonome étant de plus en plus utilisée dans de nombreux milieux, elle remplit des missions d’importance variable. Dans le cadre d’applications qui ont une grande importance (telles que le transport de personnes par exemple), il est nécessaire de garantir la sécurité de ces systèmes pour assurer leur bon fonctionnement ainsi que la sécurité des personnes et des biens.
La surveillance consiste à détecter les erreurs de fonctionnement lors de l’utilisation du robot afin de les corriger ou de fonctionner si possible dans ce qu’on appellera un mode dégradé.

Objectif du projet

Renforcer la sécurité des robots mobiles (en l'occurrence Robotino). Pour cela, nous allons montrer l'existence de commandes qui peuvent rendre invisible les dysfonctionnements du robot.
En effet, pour détecter les défauts dans le système, on se base sur le modèle mathématique de bon fonctionnement qu'on compare directement ou implicitement avec le comportement en ligne du robot. Un écart entre ces deux comportements indique l'apparition d'un défaut.
Cependant, il existe des commandes qui ne permettent pas de voir cet écart. L'objectif de ce projet est de mettre en évidence ce comportement qui peut s'avérer dangereux. Effectivement, un défaut qui n'est pas détecté tôt peut s'amplifier et causer de graves dommages alors que cette situation peut être évitée s'il est corrigé à temps.

Cahier des charges

L'objectif est de produire une "toolbox" qui permettra des générer automatiquement un certain type de commande.
L'utilisation devra être rendue possible pour tout utilisateur grâce à une interface ergonomique.

Choix techniques : matériel et logiciel

Une première entrevue avec l'encadrant nous a permis de mettre en place les choses suivantes :

Le robot qui servira à réaliser les tests est le Robotino :

• diamètre du châssis: 350 mm
• hauteur: 200 mm (sans caméra)
• masse : 11 kg
• 3 moteurs avec un encoder par moteur
• 3 Roues omnidirectionnelles ( diamètre: 80 mm )

Les logiciels qui seront utilisés :

• Matlab Simulink, toolbox (Matlab)
• Robotinoview
  

Liste des tâches à effectuer

1. Prise en main des méthodes de discernabilité.
2. Bibliographie.
3. Prise en main de l’application Matlab pour la génération des commandes non discernables.
4. Application des techniques de discernabilité pour la génération des commandes qui rendent les défauts indiscernables en utilisant le modèle linéaire du robot.
5. Réalisation des tests en simulation avec Matlab.
6. Réalisation des tests sur le robot.
7. Utilisation du modèle non linéaire du robot.
8. Création d’interface avec l’outil GUI de Matlab.

Feuille d'heures

Avancement du Projet

Prélude

Rencontres avec l'encadrant :

- Première entrevue le 15/12 (30 min): Présentation générale du sujet et du matériel à utiliser, mise en place du cahier des charges et de la liste des tâches à réaliser.
- Seconde entrevue le 10/01 (45 min): Présentation détaillée du sujet, découverte de la documentation technique à s'approprier.

Semaine 1

Réunion de présentation (avec l'encadrant):

- présentation du modèle linéaire du Robotino
- fourniture de la documentation concernant :

• la caractérisation de la discernabilité des systèmes dynamiques
• le modèle linéaire du Robotino (démonstration)
• la mise en place d'un modèle non-linéaire du Robotino

Séance pratique :

Dans le but de réaliser des campagnes d'acquisition, il a fallu prendre en main le contrôle du robot. Grâce au logiciel RobotinoView, nous commandons ses moteurs dans le but de lui faire faire des déplacements de base :

Robotino vu de dessus :

L'élément central du schéma de commande (omnidrive) permet de contrôler les moteurs de chacune des trois roues en fonction d'une consigne soumise en entrée de la manière suivante :

Par rapport à l'omnidrive, les vitesses en amont des trois moteurs sont les consignes alors que les vitesses en aval (ici récupérée par des capteurs pour être traitées) sont les vitesses réelles.

La partie 'horloge' en haut à gauche permet d'appliquer une commande pendant une durée limitée puis de la forcer à 0 pour arrêter les moteurs.

Les tests qui ont été réalisés sont :

• un déplacement en ligne droite pendant une durée donnée
• un déplacement selon les trois composantes x, y et Ω
• acquisition des valeurs de consigne (vitesse selon les axes et vitesse théorique de chaque moteur), vitesse réelle et position (moteur).

Semaine 2

Le but est de réaliser différents mouvements en boucle un nombre de fois donné (ici 100). Pour cela, chacun des steps 1 à 6 représentent un mouvement qui sera exécuté avant de passer au suivant et ainsi de suite jusqu'à ce que 'compt' arrive à 100 et que l'on sorte de la boucle pour terminer l'action.

Dans l'optique de traiter le problème sur Matlab uniquement, le même type d'acquisition est réalisée sur Simulink de la manière suivante :

Cette fois, on ne fait plus la boucle 100 fois mais de manière infinie (jusqu'à arrêt du temps).

Semaine 3

• théorie sur la discernabilité
• théorie sur la représentation d'état

Semaine 4

• théorie sur la commande des systèmes non-linéaires

Semaine 5

L'étude de la thèse de M. Koffi MOTCHON portant sur la caractérisation de la zone de discernabilité [Caractérisation de la discernabilité des systèmes dynamiques linéaires et non-linéaires affines en la commande] ainsi que celle du rapport [Modélisation et commande de robots : application aux tests de discernabilité] m'ont permis d'acquérir les connaissances nécessaires pour la réalisation du projet.
Cette phase d'appropriation des techniques a ensuite était concrétisée par plusieurs mini-soutenances avec l'encadrant.
A la suite de cette découverte de la méthode à employer, les premiers essais de génération de commandes qui rendent les défauts indiscernables ont pu débuter sur le logiciel Matlab.

Semaine 6

L'objectif du moment est de maîtriser l'application Matlab qui permet de générer les commandes recherchées dans le but de lui apporter une amélioration.
On choisit tout d'abord le système d'étude :

Après cela, il faut entrer les paramètres que l'on souhaite utiliser : il s'agit des fonctions utilisées lors de la représentation d'état du système.
Dans le cas du pendule :
- le nombre de variables est de 4 : deux variables pour le premier modèle, et 2 pour le second
- les matrices f, g et h définissent le système augmenté ici étudié

En prévision de l'obtention de la commande, je commence à préparer les tests en simulation avec Matlab.

Semaine 7

Cette semaine, l'application en elle même est mise de côté pour laisser place à la découverte de l'outil GUI de Matlab. Dans le but de produire une application interfacée pour permettre une utilisation facile, il m'est demandé de prendre en main les différents objets ainsi que les fonctionnalités proposées. Je procède notamment à la lecture de données audio pour produire un son par l'intermédiaire de Matlab.

Cette tâche menée en parallèle a eu pour effet de me rendre à l'aise avec le panel d'outils à ma disposition.
J'ai également acquis de bonnes habitudes quant à la marche à suivre pour réaliser une application robuste.

Semaine 8

Une fois la prise en main d'un nouvel outil terminée, j'envisage de continuer dans la direction des tests en simulation avec Matlab. Pour cela, je crée les fonctions qui seront utiles pour simuler le robot mobile à l'aide de son modèle. Le but est de définir les sorties en fonctions de la commande imposée au robot.

Semaine 9

Pour rendre les résultats plus intéressants et pour produire quelque chose à montrer qui illustrerait bien mon projet, je décide de préparer les tests directement sur le robot (l'objectif étant d'observer le comportement du système temps réel). On rappelle qu'en appliquant la commande qui rend le défaut indiscernable, les sorties des deux systèmes (fonctionnement normal et roue libre) doivent être sensiblement les mêmes. Dans cette optique, j'implémente le lancement du fichier Simulink que je construis en parallèle. Il s'agit de la commande déjà évoquée en ajoutant des fonctionnalités pour la rendre automatique.

Semaine 10

En continuant le travail entrepris la semaine précédente, je commence la réalisation de l'interface qui permettra une utilisation simple, rapide et ludique pour tout utilisateur.

Travail supplémentaire

Résultats :

• application fonctionnelle pour un cas particulier
  
• Robotino prêt à recevoir une commande (2 modes de fonctionnement)
  
• Interface en cours de réalisation pour améliorer l'utilisation
  

Il ressort d'une entrevue avec mon tuteur que :

• L'objectif principal est la mise en place de la "toolbox" pour générer les commandes particulières
  
• L'interface avec l'utilisateur doit être perfectionnée
  

Les dernières heures de travail ont donc pour but de remplir ces objectifs.

Fichiers Rendus

Rapport du projet