OPENEVRapport de stage

du 06/08 au 05/09 2007

PRUVOST Côme

Table des matièresIntroduction..........................................................................................................................................4Chapitre 1 : Installation d'OpenEV.......................................................................................................5

Contenu du CD-ROM......................................................................................................................5Compilation d'OpenEV....................................................................................................................5

Paquets nécessaires.....................................................................................................................5Instructions de compilation.........................................................................................................5

Script d'installation.................................................................................................................5Installation manuelle..............................................................................................................5

Étape 1 : préparation de l'installation................................................................................5Étape 2 : GLib et GTK+....................................................................................................6Étape 3 : GtkGLArea.........................................................................................................6Étape 4 : Python.................................................................................................................6Étape 5 : Numeric..............................................................................................................7Étape 6 : PyGTK, GtkExtra...............................................................................................7Étape 7 : installation de GDAL.........................................................................................8Étape 8 : installation d'OpenEV.........................................................................................8Étape 9 : finaliser l'environnement....................................................................................9

Notes importantes...................................................................................................................9Installation de Tool_Mission............................................................................................................9À propos d'OpenEV2.....................................................................................................................10Liens concernant OpenEV.............................................................................................................10

Paquets à compiler :..................................................................................................................10OpenEV.....................................................................................................................................10

Chapitre 2 : Comprendre OpenEv......................................................................................................11Deux langages pour OpenEV.........................................................................................................11Widgets OpenEV...........................................................................................................................11Les vues.........................................................................................................................................11Les données....................................................................................................................................12Les couches....................................................................................................................................12Les outils........................................................................................................................................12

Chapitre 3 : Bindings Python d'OpenEV............................................................................................13Vue d'ensemble..............................................................................................................................13La glue...........................................................................................................................................14Les outils........................................................................................................................................14La console......................................................................................................................................15

Exemple de création d'un couche contenant des formes...........................................................15Les plugins.....................................................................................................................................15

Créer une entrée de menu..........................................................................................................16Créer une icône dans la barre d'outils.......................................................................................16

Chapitre 4 : Tool_Mission.py, un exemple de tracé de mission.........................................................17Présentation....................................................................................................................................17L'architecture des données.............................................................................................................18

Mission......................................................................................................................................18MissionDataMission.................................................................................................................18MissionDataWaypoint...............................................................................................................18MissionDataCommand..............................................................................................................19MissionData..............................................................................................................................19

Les contrôleurs...............................................................................................................................19MissionManager........................................................................................................................19

MissionMenu............................................................................................................................19MissionFileUIController...........................................................................................................19MissionFileController...............................................................................................................20MissionToolbar et MissionErrorDialog....................................................................................20Note sur les signaux..................................................................................................................20

La vue MissionLayer.....................................................................................................................20Conclusion..........................................................................................................................................21

IntroductionCe document constitue le rapport d'un stage mené à la Direction Générale de l'Armement Français au sein de l'équipe du Groupe d'Étude Sous-Marin de l'Atlantique à Brest. Le stage a eu pour objectif d'aplanir le terrain et d'évaluer un logiciel de cartographie, OpenEV, en vue de l'étendre au tracé de mission pour un robot sous-marin. Le logiciel évalué était dans sa version svn 180. Une version plus récente était disponible mais non stable encore et la compilation a échouée.

L'étude du logiciel s'est composée de son installation ainsi que celle de l'ensemble de ses dépendances sous Linux uniquement, de l'étude de sa structure interne et des outils mis à disposition au développeur pour étendre le logiciel. Cette étude a été réalisée tout en concevant le squelette d'une application de tracé de mission sous la forme d'un plugin.

Chapitre 1 : Installation d'OpenEV

Contenu du CD-ROMLe CD-ROM contient un dossier d'installation d'OpenEV, comprenant les paquets nécessaires, un script d'installation, des patchs et d'autres outils pour la mise en route de l'environnement. Le CD-ROM contient également un dossier contenant de la documentation, notamment ce fichier, le manuel d'OpenEV et ses tutoriels, des notes sur OpenEV, Python et GTK. Enfin, le dossier Tool_Mission contient le plugin de tracé de missions.

Compilation d'OpenEV

Paquets nécessaires

Pour recompiler OpenEV, les paquets suivants sont nécessaires :• Glib, attention, la version proposée dans le CD semble ne pas compiler. Utiliser celle du

système semble être une bonne alternative.• GTK+, dans sa première version, OpenEV n'étant pas porté en GTK2.• GtkGlArea.• Python.• Numeric ; la distribution actuelle de Numeric est numpy et il faudra donc adapter

l'installation pour qu'OpenEV fonctionne correctement (cf ci-dessous).• PyGTK.• GtkExtra.• Python-GtkExtra• GDAL, ainsi que les différentes librairies nécessaires pour le support de formats

supplémentaires.

Instructions de compilation

Script d'installationUn script d'installation est fourni dans le CD-ROM : install_oev.sh. Il prend en unique argument obligatoire le répertoire d'installation qui doit être un dossier existant. D'autres options sont modifiables en paramétrant les variables au début du script d'installation.

Installation manuelle

Étape 1 : préparation de l'installationPréparer un répertoire local pour l'installation car OpenEV utilise des librairies qui pourraient entrer en conflit avec celles du système. Il vaut donc mieux créer un environnement réservé à OpenEv. Dans l'exemple, le répertoire d'installation sera $INSTALL.Ensuite, il faut créer deux répertoires bin et lib dans ce nouveau dossier puis établir l'environnement.

mkdir -p $INSTALL/binmkdir -p $INSTALL/libexport PATH=$INSTALL/bin:$PATHexport LD_LIBRARY_PATH=$INSTALL/lib

Étape 2 : GLib et GTK+Paquets :

• glib-1.2.10.tar.gz,• gtk+-1.2.10.tar.gz.

Les instructions d'installation ne posent pas de problème particulier, si ce n'est que la version de la GLib testée ne compile pas.

$pkg={glib,gtk+}$ver=1.2.10tar -xvzf $pkg-$ver.tar.gzcd $pkg-$ver./configure --prefix=$INSTALL# Pour GTK, ajoutez --with-glib-prefix=$INSTALL si vous avez installé# la GLibmakemake installmake clean

Étape 3 : GtkGLAreaPaquets :

• gtkglarea-1.99.0.tar.gz.

Simple installation, les outils de base suffisent.$pkg=gtkglarea$ver=1.99.0tar -xvzf $pkg-$ver.tar.gzcd $pkg-$ver./configure –prefix=$INSTALL --with-gtk-prefix=$INSTALLmakemake installmake clean

Étape 4 : PythonPaquets :

• Python-2.5.1.tar.bz2.

$pkg=Python$ver=2.5.1tar -xvjf $pkg-$ver.tar.bz2cd $pkg-$ver./configure --prefix=$INSTALLmakemake install

Pour la suite, nous aurons besoin d'indiquer aux programmes dépendant de python où aller chercher ses fichiers.

export PYTHONHOME=$INSTALLPYTHON_VER=`python -V 2>&1 | sed -r "s/^.* (.\..).*$/\1/"`# Ou tout simplement, si vous le faites à la main, PYTHON_VER=2.5# sed : récupère dans "python 2.5.1" le numéro majeur de version

Enfin, il faut installer les extensions python.$INSTALL/bin/python setup.py install# python pourrait suffire car le PATH tient normalement compte du# dossier d'installation.

Étape 5 : NumericPaquets :

• numpy-1.0.3-2.tar.gz.

$pkg=numpy$ver=1.0.3tar -xvzf $pkg-$ver-2.tar.gzcd $pkg-$verpython setup.py install# Installer les includes pour les futures compilations :mkdir -p $INSTALL/include/python$PYTHON_VER/numpycp $INSTALL/lib/python$PYTHON_VER/site-packages/numpy/core/include/numpy/* \$INSTALL/include/python$PYTHON_VER/numpy

OpenEV fonctionne avec l'ancienne version de Numeric. Il faut donc appliquer quelques correctifs pour qu'il accepte de fonctionner avec numpy. Copier ces deux fichiers dans le répertoire site-packages de python : Numeric.py et FFT.py

#!/usr/bin/env python# Numeric.py : patch pour numpy

from numpy import *

#!/usr/bin/env python# FFT.py : patch pour numpy

from numpy import fft

Étape 6 : PyGTK, GtkExtraPaquets :

• pygtk-0.6.12.tar.gz,• gtk+extra-0.99.17.tar.gz,• python-gtkextra-0.22.tar.gz.

Les deux premiers paquets s'installent avec les commandes habituelles, sans problème majeur. On utilisera la version 0.99.17 de gtk+extra combinée à la version 0.22 de python-gtkextra étant donnée que la version 1.0 de gtk+extra se révèle incompatible avec les différentes versions des bindings python.

$pkg=pygtk$ver=0.6.12tar -xvzf $pkg-$ver.tar.gzcd $pkg-$ver./configure --prefix=$INSTALL --with-gtk-prefix=$INSTALLmakemake installcd ..$pkg=gtk+extra$ver=0.99.17tar -xvzf $pkg-$ver.tar.gzcd $pkg-$ver./configure --prefix=$INSTALL --with-gtk-prefix=$INSTALLmakemake installcd ..

Les bindings GtkExtra pour python sont incompatibles avec la nouvelle version de numpy. Il faut donc les patcher. Cela peut se faire soit avec le patch fourni dans le CD-ROM soit à la main.

$pkg=python-gtkextra$ver=0.22tar -xvzf $pkg-$ver.tar.gzcd $pkg-$ver# Avec le patchpatch -p0 ../gtkplotdata-support.patch ./gtkextra/gtkplotdata-support.c# Manuellement, remplacez la ligne 25 de ./gtkextra/gtkplotdata-support.c# "#include "# par les lignes suivantes :# "#include "# "#include "# "#include "python setup.py install

Étape 7 : installation de GDALPaquets :gdal-1.4.2.tar.gz.

Consultez ./configure --help afin de déterminer quels formats de fichiers seront supportés. Ajoutez les paramètes --with-python --prefix=$INSTALL.

$pkg=gdal$ver=1.4.2tar -xvzf $pkg-$ver.tar.gzcd $pkg-$ver./configure $PARAMETERSmakemake install# Installer les extensions pythonpython setup.py install

Étape 8 : installation d'OpenEVPaquets :

• openev-svn-180.tar.gz,• ou la version svn d'openev récupérée sur le dépôt svn.

$pkg=gdal$ver=1.4.2tar -xvzf $pkg-$ver.tar.gzcd $pkg-$ver./configure --with-gtk-prefix=$INSTALL --with-gtkgl-prefix=$INSTALL --with-gdal-prefix=$INSTALL --with-ogr --prefix=$INSTALLmakemake install# installer les iconesmkdir $INSTALL/picscp ./pics/* $INSTALL/pics

Étape 9 : finaliser l'environnementPour terminer l'installation, copier le script set_env du CD-ROM dans le répertoire d'installation, ou créer ce fichier, le rendre exécutable et y coller le script suivant :

#!/bin/sh # Script d'environnement OpenEV

export PATH=/home/come/oev_test/bin:$PATH export LD_LIBRARY_PATH=/home/come/oev_test/lib export PYTHONHOME=/home/come/oev_test

# Les lignes ci-dessous sont facultatives (titre de la fenêtre)case $TERM in rxvt*|xterm*|aterm) echo -n -e "\033]0;Environnement OpenEV\007" ;; esac

Puis créer le lien suivant :ln -s $INSTALL/pymod/openev.py $INSTALL/bin/openev

Notes importantesÀ la différence du script de FWTools, le nouveau lien bin/openev ne prend pas en compte l'option -h.

D'autre part, il se peut que l'interpréteur de commandes intégré à OpenEV refuse de se lancer indiquant qu'il est impossible d'ouvrir la police de caractère ou de créer l'objet GdkFont. Dans ce cas, il faut modifier le fichier pyshell.py situé dans le dossier pymod de l'installation.Première méthode : utiliser le patch fourni dans le CD (dossier install/patches).

patch -p0 $INSTALL/pymod/pyshell.py patches/pyshell.patch

Seconde méthode : ouvrez le fichier pyshell.py et remplacez aux lignes 147, 470 et 1125 la description de la police "-*-courier-medium-r-normal-*-14-140-*-*-*-*-iso8859-*" par une existant dans le système ou une plus générique, par exemple "-*-arial-*-*-*-*-*-*-*-*-*-*-*-*". L'outil xfontsel peut être utile.

Installation de Tool_MissionPour installer Tool_Mission, il suffit de copier le fichier Tool_Mission.py dans le répertoire tools du dossier d'installation d'OpenEV.

À propos d'OpenEV2Dans le CD-ROM se trouve une archive openev2.tar. Ce sont les sources de la version d'OpenEV portée sous GTK2. Jusqu'à présent, ce paquet n'a jamais compilé correctement.

Liens concernant OpenEV

Paquets à compiler :Mesa : http://www.mesa3d.org/Glib et GTK : http://www.gtk.org/GtkGLArea : http://ftp.acc.umu.se/pub/GNOME/sources/gtkglarea/1.99/Python : http://www.python.org/download/releases/Python GTK : http://www.pygtk.org/Gtk+Extra : http://gtkextra.sourceforge.net/Python Gtk+Extra : http://sourceforge.net/projects/python-gtkextraProj : http://proj.maptools.org/GDAL : http://www.gdal.org/OGDI : http://ogdi.sourceforge.net/GEOS : http://geos.refractions.net/PostGIS : http://postgis.refractions.net/Numpy : http://numpy.scipy.org/

OpenEVSite internet : http://openev.sourceforge.net/

OpenEV2 : http://sourceforge.net/project/showfiles.php?group_id=6087&package_id=6149ou : http://openev.svn.sourceforge.net/viewvc/openev/trunk/src/

http://www.mesa3d.org/http://openev.svn.sourceforge.net/viewvc/openev/trunk/src/http://sourceforge.net/project/showfiles.php?group_id=6087&package_id=6149http://openev.sourceforge.net/http://numpy.scipy.org/http://postgis.refractions.net/http://geos.refractions.net/http://ogdi.sourceforge.net/http://www.gdal.org/http://proj.maptools.org/http://sourceforge.net/projects/python-gtkextrahttp://gtkextra.sourceforge.net/http://www.pygtk.org/http://www.python.org/download/releases/http://ftp.acc.umu.se/pub/GNOME/sources/gtkglarea/1.99/http://www.gtk.org/

Chapitre 2 : Comprendre OpenEv

Deux langages pour OpenEVOpenEV est construit en deux parties, chacune ayant son propre langage et bénéficiant de ses spécificités. Ainsi, OpenEV est composé d'un coeur en C, un amas de composants, plus ou moins inertes. En effet, ces composants ne sont pas liés entre eux, et leur utilisation est réduite. Il existe cependant un programme de test livré avec OpenEV qui n'assemble que des composants C et qui montre les possibilités du cœur mais met aussi en évidence ses limitations. Ce cœur est d'ailleurs vu par les développeurs comme une sorte de librairie. La seconde partie est écrite en python et s'interface grâce au module _gvmodule1 qui rassemble les bindings python du cœur d'OpenEV. Cette partie est en quelque sorte la « glue » qui assemble les composants du cœur en une application utilisable.

Widgets OpenEVOpenEv est basé sur GObject et bénéficie donc de ses capacités de programmation objet en C ainsi que des signaux. Ainsi, chaque élément OpenEV est un « widget » qui peut hériter des propriétés de ses parents et émettre et recevoir des signaux. Voici un arbre de la structure des widgets d'OpenEV :

Les vuesLes vues dans OpenEV, sont représentées par le widget GvViewArea qui dérive du widget GtkGLArea, lui même dérivé d'une combinaison de GtkDrawingArea et OpenGL. Au niveau utilisateur, la vue est le cadre central dans l'interface, celui qui, noir au début, affiche les cartes et dessins d'OpenEV. On notera en revanche que les icônes et le menu sont à part. OpenGL peut gérer plusieurs vues, qui peuvent afficher différentes données, ou alors différentes données avec par exemple un point de vue différent. Ce n'est par contre pas la vue qui dessine les éléments ou qui réceptionne les évènements utilisateurs. Elle se contente de « rendre » les éléments qui doivent être affichés en prenant en compte le point de vue choisi par l'utilisateur pour cette vue.

1 Ce paquet peut être appelé en python par la commande import _gv. En effet, python supprime la terminaison « module » lorsqu'un paquet est nommé de la forme _nommodule.

Les donnéesLes données sont de deux types sous OpenEV :

- Les « Rasters »- Les « Shapes »

Les Rasters gèrent les images et les fonds de carte dans OpenEV. Ils sont contrôlés par GDAL. On ne peut pas les éditer, et on les importe en ouvrant le fichier image correspondant.

Les Shapes gèrent toute les formes primaires d'OpenEV. Un GvShapes est un conteneur englobant plusieurs GvShape. Ainsi, on peut produire des formes plus complexes ou des ensembles de formes. Les Shapes dans OpenEV sont prises en charge par OGR car ce sont des éléments vectoriels. Les GvShape sont déclinés en plusieurs types, stockés dans des structures :Le GvPointShape définit un point seul, un simple ensemble de trois coordonnées : x, y et z car OpenEV enregistre toujours ses données en mode trois dimensions même si l'affichage n'en prend en compte que deux. Il sert d'élément de base aux autres Shapes.Le GvLineShape ou polyline est un élément constitué de plusieurs points reliés entre eux par une ligne. Le fait d'être reliés entre eux ne constitue qu'un paramètre de dessin pour OGR.Le GvAreaShape est également constitué d'un ensemble de points reliés par une ligne, mais formant un polygone fermé et remplit. C'est encore un paramètre OGR qui permet de rendre la forme de cette manière.Les autres formes sont des utilisations particulières de ces éléments et ne diffèrent souvent que par l'outil qui permet de les créer.

Les couchesLes couches rassemblent les données avec la vue dans le sens où c'est à travers elles que se fait le rendu de la fenêtre. Chaque couche est dessinée de bas en haut (les couches inférieures étant écrasées par les couches supérieures). À chaque couche est associée une donnée, une Shapes ou un Raster. Pour les couches associées aux Shapes, chaque couche est le plus souvent elle même constituée de plusieurs sous-couches. Ces sous-couches correspondent à une sous donnée. Par exemple, un GvShapes qui serait constitué d'une aire et d'une ligne serait dessiné par un GvShapesLayer constitué d'un GvAreaLayer et d'un GvLineLayer. Ces sous-couches dérivent toutes d'un GvShapeLayer (on notera le « s » qui disparaît par rapport au GvShapesLayer). Ainsi l'ordre de dessin est transmit depuis l'application via les couches jusqu'à chaque sous-couche en charge de représenter une seule donnée. La vue est donc constituée de l'ensemble des sous-couches dessinées les unes par dessus les autres et observées depuis un point de vue spécifique à la vue.

Les outilsPour intervenir sur les données, OpenEV met à disposition de l'utilisateur des outils spécifiques qui capturent les évènements intervenus sur la vue et modifient les données en conséquence. Chaque outil dérive de GvTool qui intercepte et transmet les évènements aux différents outils. Chaque outil est spécifique au type de donnée à modifier, mais plusieurs outils peuvent intervenir de manière différente sur le même type de données. Certains outils, comme le GvNodeTool interviennent sur des sous-ensembles de données (ici les noeuds) qui sont communs à plusieurs types. Ces outils travaillent donc sur plusieurs types de données.

Chapitre 3 : Bindings Python d'OpenEV

Vue d'ensembleLes principales manipulations techniques d'OpenEV sont de routines écrites en C, les objets manipulés étant des structures et le tout étant régit par des signaux selon un format hérité de GObject. Dans l'absolu, les bindings python pour OpenEV sont tous regroupés dans le module _gvmodule mais en réalité, la partie python est bien plus importante que cela. Tout d'abord, comme dit plus haut, python fourni la « glue » qui assemble les composants internes de OpenEV en une interface graphique présentable et confortable pour l'utilisateur. Mais en plus d'une interface graphique, OpenEV apporte avec python un ensemble d'éléments, classes et fonctions, visant à faciliter l'accès à _gvmodule qui est en soit assez inexploitable. C'est donc avec cette nouvelle interface, entièrement en python, que vont pouvoir travailler les plugins ou la ligne de commande.

L'architecture du code python se calque presque entièrement sur celle du code C. D'ailleurs, dans bien des cas, la connaissance du code C sous-jacent est indispensable à la compréhension et à l'utilisation du code python et l'on remarquera même parfois que quelques restrictions sont apparues lors du binding python. Voici tout d'abord deux vues d'ensemble de la hiérarchie python d'OpenEV.

La glueL'application démarre par le lancement du fichier openev.py. Celui-ci se contente lancer une instance d'application GvViewApp en prenant en compte les paramètres qui peuvent lui être donnés. Puis elle entre dans la boucle principale, qui gérera les évènements et signaux. Cette nouvelle application, logée dans le fichier gvviewapp.py, crée une fenêtre, initialise les menus, les boites à outils, charge les plugins puis attend les évènements provoqués par l'utilisateur. Tout le reste est orchestré par les outils, via les signaux.

Les outilsEn plus du chargement de fichiers et de la sauvegarde de layers, l'utilisateur peut utiliser divers outils pour modifier les données : les GvTools. Ce sont eux qui capturent les évènements de bas niveau au sein de la DrawingArea (typiquement mouse event, keybord event, draw). Les GvTool sont regroupés au sein d'une GvToolbox qui est elle même une GvTool et qui intercepte donc les évènements et les propage. Il existe d'entrée de jeu plusieurs Tools :

• GvLineTool Dessine des lignes (GvLineLayer)• GvAreaTool Dessine des aires (GvAreaLayer)• GvPoiTool Sélectionne un point d'intérêt • GvAutopanTool• GvNodeTool Édite les noeuds d'une Shape• GvPointTool Dessine des points (GvPointLayer)• GvSelectionTool Sélectionne des Shapes• GvRoiTool Dessine une région d'intérêt• GvZoompanTool• GvRectTool Dessine un rectangle (GvAreaLayer)• GvTrackTool• GvRotateTool Permet de tourner et de transformer une Shape

Il est à noter qu'une Toolbox n'est pas une fenêtre, mais un container de Tool. On peut supposer qu'il n'est alors qu'un intercepteur d'évènement.

L'outil « Point Query » n'est qu'un GvPointTool sur une layer spéciale. C'est uniquement le fait que le point soit dessiné sur cette layer qui fait que chaque point rendu possède ses coordonnées. On vérifie cela en dessinant des lignes ou des aires sur cette layer spéciale.

La consoleLa console est une petite interface comprenant le langage python et qui permet d'interagir directement avec OpenEV. Elle réside dans le fichier gvshell.py. Grâce à elle, l'utilisateur peut accéder au coeur d'OpenEV et manipuler directement les données, créer des nouvelles couches, activer des outils, charger un plugin. Malheureusement, l'interface n'est pas accompagnée d'une documentation orientée utilisateur et une bonne utilisation de la console signifie la plupart du temps la connaissance du code python d'OpenEV.

Exemple de création d'un couche contenant des formes

import gview

# récupère la vue activecview = gview.app.sel_manager.get_active_view()

# création d'un container pour les shapescshapes = gview.GvShapes()# création d'une couche contenant les shapesclayer = gview.GvShapesLayer(shapes=cshapes)# nommage de la couche, c'est très important pour la listeclayer.set_name("My_Layer")# ajout de la couche dans la vuecview.add_layer(clayer)

# création d'une areashape1 = gview.GvShape(type=gview.GVSHAPE_AREA)shape1.add_node(1,1,0,0) # x, y, z, n°shape1.add_node(1,10,0,1)shape1.add_node(10,10,0,2)shape1.add_node(10,1,0,3)

# ajout de l'areacshapes.append(shape1)

Les pluginsPour intégrer un plugin à OpenEV, il suffit de rassembler ces quelques conditions :

• Le plugin doit être écrit en python,• le fichier doit se trouver dans le répertoire « tools » du dossier où OpenEV est installé,• le script doit comporter la variable TOOL_LIST qui est une liste contenant les noms des

classes qui se chargent de créer l'entrée de menu ou de lancer les actions effectuées par le plugin :

# Tells OpenEV that MissionMenu is a menu controllerTOOL_LIST=["MissionMenu"]

Créer une entrée de menuDans la majorité des cas, le plugin devra s'interfacer avec l'utilisateur pour être déclenché ou activé. OpenEV met à disposition du programmeur quelques fonctions permettant la modification du menu de l'application. La manière la plus simple est de créer une classe dérivée de Tool_GViewApp et d'utiliser les fonctions de la classe parente.

class MissionMenu(gviewapp.Tool_GViewApp):"""Creates a menu for Mission edition into OpenEV"""

def __init__(self, app=None):"""initialises the class.app=None : see OpenEV doc"""# Initialises the parent classgviewapp.Tool_GViewApp.__init__(self, app)# Initialises the menuself.init_menu()# Set some entriesself.menu_entries.set_entry("Menu1/Entry1", 1, callback)self.menu_entries.set_entry("Menu1/Entry2", 2, callback)self.menu_entries.set_entry("Menu2/Entry1", 3, callback)

La fonction menu_entries.set_entry prend quatre arguments en paramètre. Le premier correspond à une sorte de chemin vers l'entrée correspondante. Chaque barre oblique indique un niveau de menu, le premier étant la barre de menu elle-même. Le second est un indice qui permet à priori à OpenEV d'ordonner les entrées, mais les effets sur le classement effectif ne donne pas toujours ce que l'on attendait. Le troisième argument est un pointeur vers une fonction callback qui sera appelée lorsque l'utilisateur clique sur l'entrée correspondante. Le quatrième argument permet de mettre en place un raccourcis clavier, il est optionnel.

Créer une icône dans la barre d'outilsCréer une icône s'effectue de la même manière que pour le menu. On utilise à la place de la fonction menu_entries.set_entry la fonction icon_entries.set_entry qui prend elle huit arguments :

• iconfile : Une chaine désignant le fichier icône au format xpm. Les autres formats sont prévus mais non supportés pour le moment.

• hint_text : Le texte pour la bulle d'aide du bouton.• position : position par défaut pour le bouton (entier). Optionel.• callback : La fonction à appeler lorsque l'utilisateur clique sur le bouton. « Optionel ».• help topic : L'aide html correspondant. Non supporté pour le moment. Optionel.• label : voir l'aide de GTK. Optionel.• icontype : toujours « xpm ». Le reste n'est pas supporté. Optionel.

Chapitre 4 : Tool_Mission.py, un exemple de tracé de mission

PrésentationTool_Mission est un plugin python pour OpenEV permettant à terme d'éditer des missions pour le robot REDERMOR en utilisant OpenEV. Pour le moment, Tool_Mission se contente de préparer le terrain à une telle application en essayant de montrer quels sont les moyens à mettre en œuvre, les outils mis à disposition par OpenEV. Il permet également d'avoir un aperçu sur la faisabilité du logiciel final.

Tool_Mission est basé, plus ou moins, sur une architecture MVC (Modèle-Vue-Contrôleur). Cette conception vise à séparer de manière claire les données d'une part (le modèle) de leur représentation (la vue), le contrôleur étant le lien entre le modèle et la vue. Ainsi un programme est constitué d'un ensemble de modèles, représentés par un ensemble de vues (il n'y a pas forcément une vue pour chaque modèle de même qu'une vue peut représenter plus d'un modèle). Le tout étant orchestré par un ensemble de contrôleurs.

L'architecture des donnéesCe paragraphe explicite l'arbre des données. Toutefois, pour des informations complète au sujet d'une classe ou d'une fonction, consulter la documentation interne avec la commande python help(function).

MissionLa classe Mission est le principal conteneur des informations relatives à une mission. C'est la première brique de l'arbre des données, même si elle peut s'apparenter sous sa forme actuelle à un contrôleur (l'évolution du logiciel doit l'amener à ne plus s'interfacer avec la vue MissionLayer). Son rôle est de lier simplement les données d'une mission avec la couche d'affichage OpenEV de manière à rendre la gestion plus simple pour le contrôleur principal (MissionManager).

Fonctions principales :• __init__ : crée une nouvelle instance. On peut lui donner le nom de la couche d'affichage en

argument.• draw : demande à la mission de s'afficher sur sa propre vue.• destroy : demande la destruction de l'instance.

MissionDataMissionLa classe MissionDataMission encapsule l'ensemble des données relatives à une mission ainsi que des facilités de serialisation. Une mission est considérée comme un ensemble de waypoints ayant chacun une liste de commandes associées que le robot effectuera en arrivant sur le waypoint.

Fonctions principales :• serialize : transforme la mission en une liste de commandes à enregistrer dans un fichier de

commande.• add_waypoint : Ajoute un nouveau point de passage à la route. Pour les arguments, voir

MissionDataWaypoint ci-dessous.• get_waypoint : Retourne l'instance waypoint à la position indiquée (numéro de point, pas

coordonnées).• get_position : Donne la position d'un waypoint dans la route (numéro, toujours).• add_command_to_waypoint :Ajoute une commande vide à un waypoint et retourne la

commande pour qu'elle soit remplie.

MissionDataWaypointLa classe MissionDataWaypoint encapsule un waypoint ainsi que sa liste de commandes. Elle dérive de la classe MissionData pour les paramètres du waypoint en lui-même. Un waypoint seul contient les paramètres suivants :- un mode, « target » ou « line_folllow » définissant le mode de déplacement du robot vers le point. C'est une chaîne de caractères.- une latitude et une longitude, qui sont des réels.- un mode d'asservissement en z appelé « zmode » définit à « depth » ou « altitude ». C'est une chaîne de caractères.- une valeur pour l'asservissement en z en réel.- une vitesse, réelle en m/s.Les quatre paramètres supplémentaires requis par le robot ne sont pas pris en charge et sont purement et simplement ajoutés au moment de la serialisation.

MissionDataCommandLa classe MissionDataCommand permet de stocker les informations relatives à une commande. Elle est dérivée de MissionData ce qui lui offre les outils de conversion automatique. Une commande est consituée :- d'une charge utile, une chaîne de caractères indiquant la charge utile sur laquelle effectuer l'opération.- d'une opération, « ON », « OFF », ou « ACK », une chaîne de caractères.- de cinq paramètres entiers à ajouter à l'opération.

MissionDataLa classe MissionData constitue la brique de base pour les données mission. Elle fonctionne comme un dictionnaire mais présente l'avantage d'être statiquement typé et d'effectuer automatiquement les conversions de type. Elle fournit aussi des outils pour manipuler dynamiquement les paramètres des classes. Elle dérive de GtkData pour les signaux (pas encore utilisé).

Les contrôleurs

MissionManagerLa classe MissionManager constitue le contrôleur principal. C'est autour de ce contrôleur que s'organisent les actions. Il stocke la liste des missions en cours et fournit les outils pour gérer cette liste, notamment savoir quelle est la mission en cours et en créer de nouvelles. Il contient également le code d'initialisation et certaines des fonctions pour la gestion du menu affiché dans OpenEV. L'instance en cours est stockée dans la variable globale mission_manager. On peut donc agir sur l'ensemble des données et des contrôleurs en récupérant cette valeur.

import Tool_Missionmm = Tool_Mission.mission_manager

ou from Tool_Mission import *mm = globals()["mission_manager"]

MissionMenuLa classe MissionMenu gère le menu Mission (Toolbar) dans OpenEV. Elle est lancée par OpenEV et stockée dans la variable MissionManager.menu. Elle propose notamment une fonction permettant d'ajouter une entrée dans le menu.

import Tool_Missionmm = Tool_Mission.mission_managermm.menu.add_entry("Mon entree", ma_fonction_callback)

L'exemple ci dessus crée l'entrée de menu « Mission/Mon entree » et le lie à ma_fonction_callback.

MissionFileUIControllerLa classe MissionFileUIController gère l'interaction entre l'utilisateur et le contrôleur chargé de la gestion des fichiers. Elle propose deux boites de dialogue, une pour le chargement l'autre pour la sauvegarde ainsi que deux fonctions pouvant être appelées depuis la console. Son instance est

stockée dans MissionManager.file_loader.import Tool_Missionmm = Tool_Mission.mission_manager# Depuis la consolemm.file_loader.set_filename("./mon_fichier.mis")mm.file_loader.load_file(create_new=True)mm.file_loader.set_filename("./copie.mis")mm.file_loader.save_file()# Pour obtenir une boite de dialoguemm.file_loader.start_load_dialog()mm.file_loader.start_save_dialog()

MissionFileControllerLa classe MissionFileController est le contrôleur de bas niveau permettant de charger et de sauvegarder les missions. Il agit non pas sur une mission directement mais sur les données de mission, c'est à dire une instance MissionDataMission (et non Mission).

import Tool_Missionmm = Tool_Mission.mission_managerloader = Tool_Mission.MissionFileControllerloader.set_filename("./mon_fichier.mis")mission = mm.create_new_mission()mission_data = mission.dataloader.set_mission_data(mission_data)loader.load()

mission = mm.get_current_mission()mission_data = mission.dataloader.set_filename("./copie.mis")loader.set_mission_data(mission_data)loader.save()

MissionToolbar et MissionErrorDialogCes classes sont des aides pour l'affichage d'informations. MissionToolbar est une fenêtre contenant des boutons outils, mais elle devrait être ré-écrite pour utiliser des ToggleButton et non des boutons simples. MissionErrorDialog sert simplement à afficher une erreur. Mais il sera de bon ton de prendre un peu de temps pour donner aux éléments, qui composent la boite de dialogue, la bonne dimension.

Note sur les signauxLes contrôleurs agissent sur les données, parfois de manière indépendante. Pour que chaque contrôleur soit informé du changement des données, il semble intéressant d'utiliser les signaux, notamment le signal « changed ». C'est pour cela que les données dérivent de GtkData même si pour le moment, ces signaux ne soient pas connectés.

La vue MissionLayerPour le moment, une seule vue est disponible, sous la forme d'une couche OpenEV. La classe MissionLayer dérive d'une GvShapesLayer et contient également une GvShape définie comme ligne. Elle gère l'affichage de la route sur cette couche OpenEV. Elle est encore en développement, c'est pourquoi une grande partie des signaux sont connectés vers une fonction de test.

ConclusionLe logiciel OpenEV présente plusieurs points forts notables. Avant tout, il est libre et gratuit, ce qui permet à moindre coût de le modifier, de l'étendre et de l'adapter à ses besoins. Cette tâche est facilitée par ses outils en langage python, un langage naturellement extensible et modulaire, idéal pour l'apport de module et de fonctionnalités supplémentaires. Qui plus est, OpenEV utilise des librairies externes puissantes au profit d'une librairie faite maison ce qui lui permet de profiter immédiatement des fonctionnalités, de la robustesse et de la puissance de ces librairies dès que celles-ci sont mises à jour. On citera notamment GTK pour l'interface graphique, mais surtout GDAL et OGR pour la gestion des rasters et shapes. Enfin, grâce à ces librairies ainsi qu'au langage python, OpenEV est naturellement portable sur un grand nombre de plateformes, dont Linux, Mac OS, Windows, BSD.

OpenEV souffre en revanche de deux défaut majeurs. Le premier est qu'il utilise toujours la version 1 des librairies GTK, ce qui pose un frein sérieux à l'adjonction de librairies nouvelles. Le port vers la version 2 se fait très doucement et pour le moment le logiciel n'est pas stable. Cette migration me semble un pré-requis à tout apport de fonctionnalité en ce sens que l'utilisation de librairies de nouvelle génération, comme par exemple cairo, pourrait grandement faciliter et accélérer la tâche des développeurs. L'autre défaut majeur est la perte de fonctionnalités parfois essentielles lors du passage de C à python. Cette perte est d'autant plus regrettable que les fonctionnalités sont disponibles à l'origine mais inaccessibles. Un travail est donc à prévoir, notamment sur le fichier _gvmodule pour apporter à python des outils de plus bas niveau et permettre aux plugins d'avoir un meilleur accès à la structure interne d'OpenEV. Un dernier manque à combler est l'absence quasi totale de documentation digne de ce nom, que ce soit en fichier séparer comme en commentaire au sein du code source.

OpenEV constitue donc un logiciel prometteur, qui ne demande qu'à être remis au goût du jour. Le concept est bien pensé et les modifications à apporter ne seront probablement pas des modifications de fond lourdes à mener.

IntroductionChapitre 1 : Installation d'OpenEVContenu du CD-ROMCompilation d'OpenEVPaquets nécessairesInstructions de compilationScript d'installationInstallation manuelleÉtape 1 : préparation de l'installationÉtape 2 : GLib et GTK+Étape 3 : GtkGLAreaÉtape 4 : PythonÉtape 5 : NumericÉtape 6 : PyGTK, GtkExtraÉtape 7 : installation de GDALÉtape 8 : installation d'OpenEVÉtape 9 : finaliser l'environnement

Notes importantes

Installation de Tool_MissionÀ propos d'OpenEV2Liens concernant OpenEVPaquets à compiler :OpenEV

Chapitre 2 : Comprendre OpenEvDeux langages pour OpenEVWidgets OpenEVLes vuesLes donnéesLes couchesLes outils

Chapitre 3 : Bindings Python d'OpenEVVue d'ensembleLa glueLes outilsLa consoleExemple de création d'un couche contenant des formes

Les pluginsCréer une entrée de menuCréer une icône dans la barre d'outils

Chapitre 4 : Tool_Mission.py, un exemple de tracé de missionPrésentationL'architecture des donnéesMissionMissionDataMissionMissionDataWaypointMissionDataCommandMissionData

Les contrôleursMissionManagerMissionMenuMissionFileUIControllerMissionFileControllerMissionToolbar et MissionErrorDialogNote sur les signaux

La vue MissionLayer

Conclusion