Déveltournburea
Steve DépartemFilière REMSystèmes
LaborUniversitRue Thier90010 Beset.utbm
Rapport
loppemenées des au, et app
e LANGent Génie IM temps réel
ratoireté de Techrry Mieg elfort, Ced.fr
de stage
ent d'unevéhicule
plicatif li
G Informatiqu
l, embarqué
e Systhnologie d
dex
ST50 - A2
e interfaces, des cié sur ord
ue
és et inform
tèmesde Belfort
2007
ce hommcentres dinateur
matique mo
s et Trt-Montbé
me-machid'intervemobile u
obile
ranspoéliard
Am
ine pour ention uultra lége
orts
Tmir HAJJ
un logicrgentisteer.
uteur et SuJAM-EL-
ciel d'optes, sur o
uiveur UTB-HASSAN
timisatioordinateu
BMNI
n des ur de
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 2
Introduction Depuis que le temps est devenu une contrainte, l'Homme a toujours cherché à optimiser ses déplacements. Dans le cadre du commerce, par exemple, où on essayera toujours d'aller le plus vite possible, car plus on satisfait de clients, plus on gagne de l'argent et on répond à l'adage : "Le temps c'est de l'argent." Les Mathématiques et leur évolution Informatique ont tenté, et tentent encore aujourd'hui, de trouver des moyens de plus en plus performants pour satisfaire ce rapport distance/temps surtout quand la vitesse est limitée. Le Problème du Voyageur de Commerce est un bon exemple de l'implication du monde des mathématiques dans les soucis d'optimisation et ce depuis le 19ème siècle. Et aujourd'hui l'engouement pour les appareils GPS d'aide à la conduite prouve un peu plus qu'on attache beaucoup d'importance sur les temps de trajet. Le système GPS, étant un appareil de guidage, repose surtout sur des outils d'optimisation pour le calcul des trajets. C'est sur cet esprit d'optimisation que notre projet a fondé ses bases, C'est sur ces bases que se sont montés les murs d'une interface Homme – Machine à optimiser, C'est sur ces murs qu'aujourd'hui je pose la charpente de l'interactivité et de la réactivité, Et c'est accompli que je souhaite bon courage aux poseurs de tuiles pour les prochaines évolutions.
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 3
Remerciements Je tiens tout d’abord à remercier Amir HAJJAM pour m’avoir proposé ce sujet, pour son suivi ainsi que pour son aide tout au long du stage. Je tiens à remercier également Abderrafiaa KOUKAM, directeur de l’équipe informatique du laboratoire, et le laboratoire Systèmes et Transports (SET) de l’UTBM de m’avoir accueilli dans leurs locaux. Ensuite j'aimerais adresser mes remerciements à toutes les personnes qui m'ont aidé et conseillé tout au long du stage. Je pense particulièrement à Jean-Charles CREPUT pour sa précieuse connaissance du système et sa disponibilité, et l'équipe experte Système d'Information Géographique (SIG) par Olivier LAMOTTE, Stéphane GALLAND et Sylvaine SCHLIENGER. Enfin, je remercie tous les membres du laboratoire SET, permanents et doctorants, avec lesquels j’ai eu plaisir à travailler dont Alexandre GONDRAN pour sa contribution matérielle et Christophe DUMEZ pour son savoir faire et sa bonne humeur.
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 4
SOMMAIRE INTRODUCTION 2
REMERCIEMENTS 3
SOMMAIRE 4
CHAPITRE 1 : PRESENTATION DU LABORATOIRE D’ACCUEIL 5
1.1 UNIVERSITE DE TECHNOLOGIE DE BELFORT-MONTBELIARD 5 1.2 LABORATOIRE SYSTEMES ET TRANSPORTS 6 1.3 EQUIPE ICAP 6
CHAPITRE 2 : PRESENTATION DU SUJET 7
2.1 LE PROJET MERCURE 7 2.2 LE PROJET EPIDAURE 8 2.3 OBJECTIFS DU STAGE 8
CHAPITRE 3 : LES ANTECEDENCES 9
3.1 PRESENTATION 9 3.2 ARCHITECTURE DU SIMULATEUR 10 3.3 PHASES DE SIMULATION 10
CHAPITRE 4 : JOURNAL DE BORD 12
CHAPITRE 5 : DANS LES DETAILS – PARTIE I.H.M. 18
5.1 JDB - 1) : SENSIBILISATION AUX METAHEURISTIQUES 18 5.1.1 ALGORITHMES GENETIQUES DE BASE: 18 5.1.2 ALGORITHMES DE LA COLONIE DE FOURMIS DE BASE : 21 5.1.3 ALGORITHMES DE RECHERCHE AVEC TABOUS DE BASE : 22 5.2 JDB – 9) : AIDE A LA COMPREHENSION : PANEL OUTPUT 24 5.3 JDB – 10) : JFRAME WINDOS AU LANCEMENT 24 5.4 JDB – 12) : NOUVELLE IHM 25 5.5 JDB – 15) : ‘VERITABLE’ ITINERAIRE 27 5.6 JDB – 18) : COMPOSITION ET CREATION DU FICHIER KML 29 5.7 JDB – 19) : MISE EN PLACE DE LA 'JAVA SERVER PAGE' 31 5.8 CONCLUSION PAR L'EXEMPLE DE LA PARTIE I.H.M. 32
CHAPITRE 6 : DANS LES DETAILS – PARTIE EMBARQUEE : PDA/GPS 36
6.1 JDB – 23) : PORT SERIE COM7 ET TRAME NMEA 36 6.2 JDB – 24) : COMMUNICATION ENTRE L'IHM ET LE SYSTEME EMBARQUE 38 6.3 JDB – 26) : ATTRIBUTION DES COORDONNEES DU PDA A L'IHM 42 6.4 CONCLUSION PAR L'EXEMPLE DE LA PARTIE PDA/GPS 42
CHAPITRE 7 : LES TRAVAUX FUTURS 45
CONCLUSION 46
BIBLIOGRAPHIE 47
ANNEXE 48
FICHIER KML RETOURNE PAR L’API GOOGLE MAPS 49
Interface véhicules
Chapitre
1.1 Un L’UTBM forde la technrecherche escientifiquedu regroupde Belfort (1985). L’UTBM estFALANGA, D L’activité scpersonnels connaissanaux scienceDepuis la favorisant transports t– donner u– accélérer – favoriser – augment– contribue En terme Franche-Co
homme-msur PC et
Steve LAN
e 1 : Prése
iversité d
me des ingnologie et et sur la ve, culturel eement de d
(1962) et l’In
t dirigée paDirecteur dé
cientifique r technique
ces fondames humaines
restructurala converg
terrestres etne meilleurle développles relation
ter de manièer au dévelo
de formatmté dans 2
machine poapplicatif
NG – Rappo
entation d
e Techno
énieurs rapaux mutativalorisationt profession
deux établisnstitut Polyt
ar Pascal Félégué pour
repose sur l’es et admmentales et s toutes indiation intervgence de t énergies de lisibilité à
pement des s interdiscip
ère significaoppement de
tion à et pEcoles Doct
our un loglié sur ord
ort de Stag
du labora
logie de B
idement opions de la . Créée en
nnel. Membssements d’technique d
FOURNIER eles relation
’implicationinistratifs, technologi
ispensablesvenue en 1l’activité dépassant le nos partenlaboratoire
plinaires. ative le nome la valorisa
par la rechtorales, et d
iciel d'optdinateur m
ge – Labora
atoire d’a
Belfort-M
pérationnelssociété. Se1999, l’UTB
bre du résea’enseignemde Sévenans
et son Conss industriel
n de tous lesvenant d’h
ques dans s dans les fo
999, l’étabdes 8 unite cadre des d
aires institus.
bre de doctation et du t
herche, l’Uélivre en co
timisation mobile ultra
atoire SET
accueil
ontbéliar
s, particuliès formationBM est un
au des univeent supéries (antenne d
seil d’ Admles au CEA.
s acteurs, chhorizons divdes domainrmations.
blissement tés de recdisciplines scutionnels et
orants. transfert de
TBM est c-habilitation
des tourna léger.
/ UTBM
rd
rement adans s’appuie
établissemersités de te
eur : l’Ecole de l’UTC im
ministration
hercheurs, evers qui alines s’étend
a mis en herche autcientifiquesprivés.
technologie
co-accréditén 3 Masters
ées des
aptables auxnt sur les
ment public echnologie, Nationale d
mplantée à S
est présid
nseignants-mentent leant des scie
oeuvre untour d’une s classiques.
e.
ée avec l’URecherche.
ST5
Page
x évolutionsactivités deà caractèreelle est née
d’IngénieursSévenans en
é par Anne
-chercheurschamp des
ences dures
ne politiquethématique.
niversité de
50
5
s e e e s n
e
s, s s
e e
e
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 6
1.2 Laboratoire Systèmes et Transports Sous la tutelle du Ministère Français de l’éducation Nationale et de la Recherche et de l’Université de Technologie de Belfort-Montbéliard (UTBM), le SeT est un laboratoire multi-disciplinaire. Il est composé de trois équipes : – équipe Informatique : Communication, Agents et Perception (ICAP) – équipe Ergonomie et Conception de Systèmes (ERCOS) – équipe évaluation et Conduite de Systèmes (ECS) Le laboratoire a pour objectif de promouvoir et d’appliquer les travaux de recherche et les nouvelles méthodologies dans le domaine des transports, des systèmes de production, de la robotique, des télécommunications et de la réalité virtuelle appliquée. Il est composé de 80 chercheurs (professeurs, maîtres de conférences, ingénieurs de recherche, post-docs et doctorants). Son directeur est Abdellah EL MOUDNI.
1.3 Equipe ICAP L’approche multi-agents propose un cadre méthodologique bien adapté pour la modélisation et l’analyse des systèmes complexes. Elle considère les systèmes comme les sociétés composées d’entités autonomes et indépendantes, appelées agents, qui interagissent en vue de résoudre un problème ou de réaliser collectivement une tâche. Elle a été utilisée de façon fructueuse dans de nombreux domaines et en particulier : la robotique, la résolution distribuée de problèmes, la modélisation et la simulation des systèmes complexes. Malgré les nombreuses réalisations, dont ils ont fait l’objet, les systèmes multi-agents accusent un certain retard en matière de formalisation et de méthodologie de modélisation. En effet, la conception de tels systèmes se fait dans la plupart des cas selon une démarche empirique ou de manière ad hoc. L’élaboration de méthodes de spécification formelles et de conception constitue une problématique importante des recherches actuelles sur les systèmes multi-agents.
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 7
Chapitre 2 : Présentation du sujet Le travail s’insère dans le cadre d’ EPIDAURE (Equipement Portable Intelligent D’Auscultation Rapide et Efficace), un projet du programme MERCURE (Mobile Et Réseau pour la Clinique, l’Urgence ou la Résidence Externe) labellisé par le pôle de compétitivité « innovations thérapeutiques ». Ce programme intègre l’UTBM, ALCATEL, SONY, FRANCE TELECOM, LAENEXT, SOS MEDECINS, l’IRCAD, l’ULP, les Hôpitaux Civils de Strasbourg et les Hôpitaux de Paris.
2.1 Le projet MERCURE Le projet est issu des réflexions qui sont menées dans le cadre des projets de la plateforme de télémédecine, baptisée « MERCURE » (Mobile Et Réseau pour la Clinique, l’Urgence ou la Résidence Externe) qui va aborder des projets de plus en plus ambitieux : STETAU qui a pour objectif de mettre à disposition des malades et du personnel médical des outils de mesure non invasifs, mobiles, et communicants. Les informations vitales sont transmises de manière sécurisée, elles sont qualifiées objectivement par des outils de traitement du signal, afin de permettre le diagnostique précoce et objectif de pathologies pulmonaires, cardiaques ou foetales. Le projet repose sur le développement de périphériques de mesure du signal, le premier périphérique étant le stéthoscope communiquant en sans fil avec un équipement informatique de type PDA ou PC. ASAP l’Ecole de l’Auscultation et la base référentielle mondiale de sons auscultatoires (WebSound), point de départ de programmes de recherche sur la qualification de sons et la création d’un réseau d’expertise au niveau mondial. ASCLEPIOS qui est le cœur du programme MERCURE. Il s’agit du déploiement de la solution en milieu hospitalier, avec couverture WiFi, équipements de mesure sans fil, transmission sans fil entre les véhicules d’urgence, le dispatcheur des urgences a l’hôpital, création d’un dossier du patient hospitalisé, mise à disposition sécurisée de tout ou partie du dossier au personnel hospitalier, communication avec les chirurgiens d’astreinte, accès simplifié et accéléré à des équipements plus riches que le PDA (tablette graphique, PC), suivi du patient à son domicile La réussite de ces projets est conditionnée par la définition de formats standardisés des données et des protocoles d’échange. Il est prévu la création d’un projet spécifique pour cet aspect essentiel du programme MERCURE.
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 8
2.2 Le projet EPIDAURE Le projet EPIDAURE permettra aux médecins urgentistes d’effectuer des mesures sur les patients (glycémie, auscultation, ecg. . .). Les résultats seront enregistrés sur le PDA et pourront être envoyés au central d’appel pour analyse et archivage, au médecin traitant, à l’hôpital qui va prendre en charge le patient. . . Le principe du projet consiste à regrouper les principaux instruments de mesure pour une analyse plus simple et plus rapide. L’outil comprendra également des formulaires contenant les constantes du patient, le rapport du médecin itinérant. . ., informations qui pourront par la suite être ajoutées au dossier médical du patient. Les objectifs du projet Epidaure sont : – La création d’un format unifié d’enregistrement des données collectées (ECG, glycémie. . . ). – L’aide à la rédaction du rapport avec une interface simple et optimisée. – L’aide dans la prise des constantes vitales du patient (collecte simplifiée et automatisée avec le PDA). – L’aide à la planification des visites et au guidage du médecin. Le tout sera regroupé dans un outil unique. Nous nous focaliserons sur le dernier objectif. Le central d’appel reçoit les appels des patients et gère les interventions des médecins. Le but du travail est de réaliser des outils pour opérer une gestion dynamique et optimisée de l’intervention des médecins en fonction de leur emploi du temps et des caractéristiques de l’appel (proximité géographique, disponibilité, type de pathologie). L’outil réalisera le suivi GPS des interventions en cours et pourra proposer quels médecins peuvent traiter rapidement et efficacement la demande en les géo-guidant. Il pourra planifier les différentes interventions en fonction de critères de déplacement et de l’urgence de l’appel.
2.3 Objectifs du stage
Il s’agit de développer l'outil d'optimisation déjà présent et de le rendre plus interactif en prenant en compte les adresses réelles des visites. Les itinéraires calculés seront visibles sur une carte. On a aussi pour objectif d'intervenir sur le côté réactif de l'application avec l'apport d'une partie embarquée. L'appareil mobile communiquera avec l'application fixe et transmettra sa position pour avoir un suivi "temps réel" du médecin.
Fig.1 Echanges de données lors de l’arrivée d’un appel
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 9
Chapitre 3 : Les Antécédences … fondations et murs
3.1 Présentation La première grande partie de ce projet a été de mettre en place un simulateur permettant d'optimiser des problèmes de tournées de véhicules avec fenêtre de temps.
Le principe est de charger des benchmarks de requêtes et de lancer différents modes d'optimisation pour constater l'efficacité de chacun.
Trace de fonctionnement
Evaluation de la solution
Plan de véhicules solution
Paramètres de configuration
Plan de véhicules initial
Jeu de requêtes initial
Dynamic Optimization System
Fig 2. Problème des Tournées de Véhicules
Fig 3. Entrées/Sorties du DOS
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 10
3.2 Architecture du Simulateur Le simulateur doit avoir une architecture simple et efficace. Voici l'architecture choisie :
Nous avons le simulateur qui est la classe principale du projet. C'est elle qui crée l'ordonnanceur (Scheduler) et l'IHM qui seront 2 threads distincts. On peut tout de suite noter la séparation qui a été faite entre l'interface et la partie simulation à proprement dite.
3.3 Phases de Simulation Le simulateur gère 2 phases de simulation. La première est une phase d'optimisation statique destinée à générer une première solution à partir des requêtes connues, pour pouvoir fournir un trajet à parcourir pour les véhicules lors de leur départ. La seconde partie est la phase de simulation dynamique, dans laquelle l'optimisation est toujours présente mais les véhicules ont commencé leurs tournées. Les requêtes peuvent arriver à n'importe quel moment dans l'intervalle de temps dynamicHorizon.
Fig 4. Architecture du Simulateur
Fig 5. Phases de simulation
Interface véhicules
Légende: Ti: Date de Tv: Date de Tf: Date de Ti – Tv = DuTv – Ti = DudynamicHocommence Les phases d
• statstat
• dynTv)
• statoptidyn
3.4 InteCe simulateespace d'ét
homme-msur PC et
Steve LAN
départ de l'odépart des fin de simu
urée de simuurée d'optimorizon: duré
à Tv et se te
de simulatiotique : les vétiques. (Tv =amique : Le
tique_dynamimisation samique. (Ti
erface Hommeur possèdeude (ou Stu
machine poapplicatif
NG – Rappo
optimisatiovéhicules =lation = Hor
ulation + opmisation statée durant ermine au p
on sont gérééhicules ne
= Tf) es véhicules
mique : lesstatique du
<> Tv <> Tf)
me Machinee une interfadiedArea) e
our un loglié sur ord
ort de Stag
n statique. Date de dérizon de simtimisation dtique. laquelle le
plus tard à Tf
ées par l'agese déplacer
se déplacen
s 2 phases u problème)
e ace graphiqt on peut su
iciel d'optdinateur m
ge – Labora
but de simumulation. dynamique
s requêtes f.
ent Companront pas et l
nt, l'optimisa
citées préc sur les re
que ou IHM,uivre l'évolu
Fig 6. Inte
timisation mobile ultra
atoire SET
ulation.
= D
dynamiqu
ny. Une simues problèm
ation se fait
cédemmentequêtes co
, les requêtetion de l'opt
erface Homm
des tourna léger.
/ UTBM
es peuvent
ulation peutes abordés
t en parallèl
t sont faitennues suiv
es sont dontimisation e
me/Machin
ées des
t arriver. C
t être soit : seront oblig
e de la simu
es, tout d'avie d'une o
c représenten fonction
e du Simula
ST5
Page
Cette durée
gatoirement
ulation. (Ti =
abord d'uneoptimisation
ées dans undu temps.
ateur
50
11
e
t
=
e n
n
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 12
Chapitre 4 : Journal de Bord …de la charpente
Pour faire évoluer cette interface, déjà développée, et la rendre plus interactive et réactive (comme mentionné dans les objectifs du stage du chapitre 2), j'ai décidé de tenir un journal de bord qui condense l'évolution de la compréhension et de l'avancement des travaux. Ceci détaillant ainsi un enchainement de points chronologiques, source de petites informations qui seront détaillées dans les prochains chapitres.
1) du 03/09 au 14/09 : • Sensibilisation aux métaheuristiques
2) du 17/09 au 21/09 : • Survol de la partie optimisation du projet
3) le 24/09 : • Rendez-vous avec A.Hajjam et J-C.Créput : Découverte et démo de l’IHM déjà existante
4) à partir du 24/09 : • Analyse et travail sur l’IHM
5) du 24/09 au 26/09 : ---- Découverte du code et de la hiérarchie de l’application ---- Simulator = main()
IHM Ordonnanceur Environment
Company
6) le 28/09 : • le Simulateur charge le fichier config.dat pour se configurer (pour la partie SIG le fichier
de configuration est config_sig.dat) • aide à la compréhension création d’un bouton config (IDE NetBeans 6beta) • Changement des variables dans Simulator
7) du 01/10 au 03/10 : • aide à la compréhension interaction pour récupération des informations des
"Requests" sur un clic de souris (compréhension des instanciations pour la liste active des "Requests")
Company SetOfRequests liste des "Requests"
Fig 8. Accès à la liste des requêtes
Fig 7. Hiérarchie de l'application
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 13
• Méthode getCompany() dans l’ordonnanceur • Evénement addMouseListener sur la "StudiedArea" :
__sa.addMouseListener(new MouseAdapter() { public void mouseReleased(MouseEvent e) { … }) ;
• Translation de l’origine et prise en compte du zoom • Itérations sur les "Requests" actifs avec vérification des coordonnées du "Request "
sélectionné
8) du 04/10 au 05/10 : • aide à la compréhension interaction pour récupération des informations des
‘Vehicles’ sur un clic de souris (compréhension des instanciations pour la liste des ‘Vehicles’)
Company SetOfVehicles liste des Vehicles
• dans le même __sa.addMouseListener() o Itérations sur les "Vehicles" avec vérification des coordonnées du "Vehicle"
sélectionné o Données dans un "JOptionPane.showMessageDialog()" à la place du
"System.out.println()" avec prise en charge des icônes. (Cette option évoluera avec la mise en place du système de vue sur carte)
9) à partir du 05/10 :
• aide à la compréhension mise en place d'un panel (EAST) pour les informations de sortie
• méthode setOutput() avec liste des solutions pour chaque véhicule et leur capacité • gridlayout pour le listage des solutions • récupération des informations dans
Company SetOfVehicles get(Vehicles) • prise en compte de la position du véhicule sur son itinéraire • mise à jour de l'affichage à chaque Paint()
10) le 16/10 : Création du jFrame WinDOS de lancement : 3 boutons
• Simulation • Evaluation (de solutions déjà simulées) • SIG
Fig 9. Accès à la liste des véhicules
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 14
11) du 18/10 au 02/11 : Partie Evaluation : • Lecture du .global qui regroupe la liste de véhicules et leurs itinéraires respectifs • Affichage en mode statique du tracé terminé
12) du 05/11 au 23/11 : Partie SIG : Nouvelle IHM
• Bouton "Ajout Requête" qui ouvre une fenêtre de saisie et place la requête sur la StudiedArea
• Récupération des coordonnées de l’adresse saisie par l’API Google Maps o Problème : Prise en compte du proxy UTBM
• Conversions WGS84 vers Lambert 2 étendu vers coordonnés de plan • Adaptation du système d’optimisation du simulateur aux requêtes saisies
‘manuellement’ (plus de chargement de benchmark) o addrequest dans la liste des SetOfRequests
13) le 20/11 : Rendez-vous avec l'équipe experte SIG
(Olivier Lamotte, Stéphane Galland, Sylvaine Schlienger) : Compte rendu succin : Système d'information géographique :
• Le choix de la source de données est important : degré de portabilité de l'application finale
• Plusieurs bases de données (SIG, bdAdresse, Navteq, IGN, ...) o Système de géolocalisation (qui fait que ça)
• Les types de données de la base des adresses et de retour du GPS peuvent être différents (différents Lambert (I,II,IIétendu,…)), mais toujours possibilité de transformer par algorithme
• Outil : MapObject, Carte – Metro B • Problème :
o précision du GPS décalé par rapport à la route o entre 15 et 17, quid du 15bis pas référencé ? o intersection : sur quelle route suis-je ? (aide : ça dépend d'où je viens) o altitude : cas du pont
14) du 26/11 au 30/11 :
• Prise de connaissance de l’existant concernant les SIG o Chargement d’un shapefile qui recense tous les tronçons de route pour une
carte donnée o Lien entre le shapefile (.shp) et une base de données (ex : bdAdresse) qui
comporte les informations des tronçons : nom de rue, sens unique, …
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 15
15) du 03/12 au 21/12 : • Prise en compte du ‘véritable’ itinéraire (plus de vol d’oiseau) • Dans quelle méthode faire intervenir cette nouvelle fonction ? • Rendez-vous avec Jean-Charles Créput :
o Prendre en compte le retour de plan de l’optimizer : méthode getPlan() -> setEquivalentBackTOpt() de SetOfVehicles
• Interrogation de Google à chaque changement d’itinéraire, pour remplir le buffer de Vecteurs : Itineraire[i] (i = véhicule) suivant les différentes requêtes que le véhicule i devra satisfaire selon l’optimisation
16) du 07/01 au 09/01 : Recherche d’une solution de cartographie • SIG ‘standard’ : Shapefile + Base de données • Prise en considération de l’option webservice par API pour affichage sur carte des
trajets : o ViaMichelin (Payant) o Yahoo ! Maps (Peu développé, comparé à aujourd’hui 20/02/08) o Google Maps
• Choix de l’API Google Maps pour la partie SIG avec prise en compte des qualités/défauts
o + : Service Web gratuit o + : Carte disponible à l’échelle planétaire (voir coût d’un shapefile) o + : Mise à jour des cartes au soin de Google Maps o + : Informations sur les rues (voir coût d’un bdAdresse) o + : API bien élaborée (grande communauté) o + : Plusieurs modes de vue déjà implantés : Satellite, Carte, Mixte o + : Possibilité de demander et d’intégrer les itinéraires
Localisation exacte du numéro de la rue, Sens de la rue Optimisation des parcours Itinéraires détaillées (+ temps, parfois trafic) Cas du pont
o + : Layering simplifié grâce au KML o - : Tributaire d’une connexion internet garantie o - : Service Web : dépendance à Google Maps telle compagnie tierce
17) du 10/01 au 12/01 :
• Découverte plus approfondie de l’API Google Maps par des exemples o Fichiers KML pour les couches (layers) à donner à la map o Javascript / AJAX pour les commandes et les retours de l’API
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 16
18) du 14/01 au 16/01 • Découverte et création du fichier KML
o composition d’un fichier KML ? o les fichiers KML sont créés quand on a un nouveau trajet pour le véhicule i o on crée alors un fichier KML par itinéraire du buffer Itinéraire[i]
précédemment décrit (en 15))
19) du 18/01 au 24/01 • Comment transmettre le javascript (pour les commandes) et nos fichiers KML à l’API
Google Maps à partir de notre applicatif ? • Mise en place du projet GoogleMaps qui est une JSP (Java Server Pages) sous Glassfish
v2 (serveur d’application) qui nous permet de communiquer avec l’API (avec l'aide de la librairie javascript geoxml.js)
20) le 25/01 : appel de la JSP, avec les informations des KML, à chaque clic de souris sur la compagnie ou sur un véhicule
21) du 28/01 au 29/01 : • Récupération du PDA/GPS pour la partie embarquée
o Problème de connexion Wifi (WPA Entreprise) à partir de l’unité mobile o Généreux prêt d’un dongle wifi (Trendnet) de la part d’Alexandre Gondran o Installation du dongle sous Linux + dongle.py pour la configuration
automatique du dongle après redémarrage
22) du 30/01 au 01/02 : • Evaluation de la méthode à employer pour faire interagir le PDA/GPS avec notre
application o GPS : module interne par serial COM, module externe par bluetooth ? o Transmission des données à l’IHM par socket o Java, C++, Python ?
• Rendez-vous avec Franck Gechter o TX qui traitait de la réception de la trame NMEA d’un module GPS externe
codé en JAVA avec Mysaifu comme JVM, mais elle est instable et peu de librairies sont déployées, cela explique leur choix pour un module GPS externe alors que le PDA possède une puce GPS en interne
o Embedded C++ pour la communication entre un PDA et le ‘véhicule intelligent’, lourd à mettre en place quand on veut commencer à coder : Visual Studio pour Visual Embedded C++ (quid sous linux ?)
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 17
• Les avantages des 2 solutions ci-dessus ayant été recouvrés par PythonCE sans prendre en compte les inconvénients, c’est vers l’option Python que nous nous sommes orientés
23) du 04/02 au 05/02 :
• Installation de PyCE sous le Windows Mobile 5 du PDA • Communication série avec l’ouverture du port COM7 (avec la libraire ceserial.py) • Parse de la trame NMEA pour récupérer les coordonnées et la vitesse
24) du 06/02 au 07/02 :
• Mise en place de la communication par socket client/serveur entre l’IHM (Java) et le PDA (PythonCE)
• Transfert des données GPS du PDA à l'IHM • Transfert des données du plan de route de l'IHM au PDA
25) le 08/02 : Rendez-vous avec Jean-Charles Créput pour voir ensemble où interférer exactement,
avec le véhicule, pour qu’il ne tienne plus compte de la simulation, mais des coordonnées exactes de sa position
26) du 11/02 au 13/02 : • Modification de la classe véhicule
o prise en compte des coordonnées exactes du véhicule par retour de socket du PDA
o L’optimiseur n’optimise plus par simulation mais par rapport au véhicule
27) le 14/02 : Validation des 2 parties (IHM + PDA/GPS)
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 18
Chapitre 5 : Dans les Détails – Partie I.H.M. Nous allons maintenant reprendre quelques points du Journal de Bord (JdB) du chapitre précédent pour en détailler les informations et, de facto, rendre ce document plus ‘guide pratique’ que ‘documentation formelle’, comme me l’a suggéré mon tuteur de stage.
5.1 JdB - 1) : Sensibilisation aux métaheuristiques
Définition : Les métaheuristiques forment une famille d’algorithmes d’optimisation visant à résoudre des problèmes d’optimisation difficile pour lesquels on ne connaît pas de méthodes classiques plus efficaces.
5.1.1 Algorithmes Génétiques de base:
Les algorithmes génétiques s'inspirent de la théorie de l'évolution, initiée par Charles Darwin au XIXème siècle. Dans cette théorie, une population d'individus évolue grâce au mécanisme de la reproduction sexuée. Les individus les plus adaptés à leur milieu se reproduisent plus que les autres, favorisant les caractères les plus adaptés. Ainsi une girafe avec un cou plus long que les autres aura accès à plus de nourriture, et aura donc plus de chances de survivre et de se reproduire. Ses descendants auront un cou plus long, et en moyenne la population de girafe aura un cou plus long. Au niveau de l'ADN, la recombinaison de l'ADN des deux parents (lors de la reproduction) permet de générer différentes combinaisons de gènes. Il y a des chances qu'en recombinant l'ADN de deux parents bien adaptés, l'individu généré soit encore mieux adapté. Exemple :
Parent 1 Parent 2 Cou : long Cou : court Pattes : courtes Pattes : longues adaptation : moyenne adaptation : moyenne
peut donner à la génération suivante :
Fils 1 Fils 2 Fils 3 Cou : court Cou : court Cou : long Pattes : courtes Pattes : longues Pattes : longues adaptation : mauvaise adaptation : moyenne adaptation : bonne
Pour mieux faire comprendre le principe, imaginons le scénario suivant : une population initiale est composée de 4 individus.
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 19
Chaque individu est caractérisé par 3 traits : ses capacités de jardinier, sa qualité de cuisinier et ses envies cleptomanes. Chaque trait peut prendre 2 valeurs (0 ou 1), suivant que l’individu ait ou n’ait pas la caractéristique. L’environnement est modélisé par une fonction d’adéquation définie pour chacune des combinaisons des 3 caractéristiques ; par exemple l’individu (0 ;0 ;0) qui n’est ni jardinier, ni cuisinier, ni cleptomane, aura une qualité d’adéquation nulle, ce qui traduit le fait que, ne pouvant se fournir sa nourriture, il dépérira avant d’avoir pu se reproduire (on aura tout simplement pas assez de force pour le faire) ; l’individu (0 ;1 ;0) ne sera pas mieux loti car, malgré ses talents de cuisinier, il n’aura rien à se mettre sous la dent ; l’individu (1 ;0 ;0) aura néanmoins ses chances en se nourrissant de légumes crus. (0 ;0 ;1) survit en volant, tandis que (0 ;1 ;1) arrive à améliorer la qualité de ses vols en les cuisinant ; (1 ;0 ;1) combine ses vols avec les produits de son jardin et (1 ;1 ;0) est l’individu idéal. Quant à (1 ;1 ;1), il perd du temps et de l’énergie à voler pour son propre plaisir, ce qui lui donne une capacité d’adéquation inférieure à celle de (1 ;1 ;0). Ces considérations sont résumées dans le tableau suivant :
Individus qualité d’adéquation (0 ;0 ;0) 1 (0 ;0 ;1) 3 (0 ;1 ;0) 1 (0 ;1 ;1) 4 (1 ;0 ;0) 2 (1 ;0 ;1) 4 (1 ;1 ;0) 5 (1 ;1 ;1) 4
Supposons la population initiale constituée des individus: {(1 ;0 ;0), (0 ;1 ;0), (0 ;0 ;1), (1 ;1 ;1)}. Voyons comment agit un Algorithme Génétique pour trouver la solution optimale : Première phase :
évaluation des qualités d’adéquation (1 ;0 ;0) se voit attribuer un score de 2, (0 ;1 ;0) a un score de 1, (0 ;0 ;1) a 3, tandis que (1 ;1 ;1) a 4.
Deuxième phase : sélection L’algorithme attribue à chaque individu une chance de participer à la phase de reproduction proportionnelle au rapport de sa qualité d’adéquation par rapport à la qualité moyenne. Ainsi on attribuera à l’individu 1 la probabilité de 2/(2+1+3+4), soit 2 chances sur 10. Cela entraîne aussi qu’il aura en moyenne (2/10)x4 enfants (espérance mathématique) dans la génération suivante. On procède alors au tirage au sort, suivant le principe de "la roue de la fortune": 2/10
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 20
de la roue sont attribués à l'individu 1, 1/10 à l'individu 2, 3/10 à l'individu 3 et 4/10 à l'individu 4. La roue est lancée autant de fois qu'il y a d'individus dans la population. Supposons que le tirage ait donné: l'individu 4 (2 fois), l'individu 3 (1 fois) et l'individu 1 (1 fois). Nous sommes maintenant en présence d'une population intermédiaire: {(1;1;1), (1;1;1), (0;0;1), (1;0;0)}, respectivement appelés {1bis, 2bis, 3bis, 4bis}
Troisième phase : reproduction Au cours de cette phase, les couples sont choisis au hasard. Supposons que 1bis "aille avec" 4bis et 2bis avec 3bis. Des sites de croisement sont ensuite choisis au hasard:
1 1 | 1 et 1 | 1 1 1 0 | 0 0 | 0 1
ce qui donne: 1 1 0 1 0 1 1 0 1 0 1 1 Les 4 nouveaux membres sont donc: {(1;1;0), (1;0;1), (1;0;1), (0;1;1)}
Ils subissent alors des mutations (en général, la probabilité de mutation est très faible). Supposons que seule la caractéristique 2 du 3ème individu soit mutée. Finalement, la nouvelle population formant la deuxième génération sera : {(1;1;0), (1;0;1), (1;1;1), (0;1;1)} On remarque que l'individu idéal y est maintenant présent.
Ensuite, en recommençant itérativement les 3 phases ci-dessus, on tendra vers une population constituée presque exclusivement de (1;1;0) (qui a une fonction d'adéquation supérieur aux autres); il y aura cependant toujours quelques mutants pour préserver la diversité de la population et donc éventuellement réagir à un changement de la fonction d'adéquation suite à un changement quelconque de l'environnement. Algorithme génétique de base :
Pour chaque Individu dans Groupe Initialiser Individu Fin Pour Pour nombre_d’itérations Parent A := Sélection_d’un_Individu (Groupe) Parent B := Sélection_d’un_Individu (Groupe) Fils := Recombinaison (Parent A, Parent B) Si hasard > pourcentage Alors Appliquer_une_mutation_à Fils Fin Si Optimiser Fils // Optionnel Evaluer Fils Si Fils est_accepté_dans Groupe Alors Réinsérer Fils dans Groupe Fin Si Fin Pour
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 21
5.1.2 Algorithmes de la Colonie de Fourmis de base : L’idée originale provient de l’observation de l’exploitation des ressources alimentaires chez les fourmis. En effet, celles-ci, bien qu’ayant individuellement des capacités cognitives limitées, sont capables collectivement de trouver le chemin le plus court entre une source de nourriture et leur nid.
1. la première fourmi trouve la source de nourriture (F), via un chemin quelconque (a), puis revient au nid (N) en laissant derrière elle une piste de phéromone (b).
2. les fourmis empruntent indifféremment les quatre chemins possibles, mais le renforcement de la piste rend plus attractif le chemin le plus court.
3. les fourmis empruntent le chemin le plus court, les portions longues des autres chemins
perdent leur piste de phéromones.
En transposant informatiquement cette méthode et en l'adaptant au PVC (Problème du Voyageur de Commerce), on obtient l'algorithme suivant (proposé par Marco Dorigo pour son logiciel ACS) :
• On crée un ensemble d'agents (les fourmis, à rapprocher aux "individus" des algorithmes génétiques), qui coopèrent par l'intermédiaire des phéromones pour trouver le chemin le plus court du PVC.
Fig 10. Principe de la colonie de fourmis
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 22
• Les phéromones sont modélisées par un tableau de taille N x N (avec N le nombre de villes). Par exemple : float Phéromone[N*N]; Phéromone[i, j] représente la quantité de phéromones déposées par les fourmis sur le trajet reliant la ville i à la ville j.
• Le comportement des fourmis est modélisé ainsi : o La fourmi se place initialement sur une ville choisie au hasard o Elle choisie la ville suivante parmi les villes non encore visitées en suivant le chemin le
plus marqué par les phéromones
max_phéromone = 0; Pour Ville_courante allant de 1 à N Si Ville_courante pas encore visitée Si Phéromone[Ville_précédente, Ville_courante] > max_phéromone Ville_suivante := Ville_courante max_phéromone := Phéromone[Ville_précédente, Ville_courante] FinSi FinPour
• Elle dépose des phéromones sur le chemin qu'elle a emprunté (règle locale de mise à
jour des phéromones). On prend en compte l'"évaporation", ce qui donne une loi du genre :
Pheromone[i, j] := (1 - alpha) Pheromone[i, j] + alpha * K
Avec K une constante. La valeur de K recommandée par Dorigo et Gambardella est de 1 / ( N * Lmv ) avec N le nombre de villes du problème et Lmv la longueur du trajet calculé par la méthode du meilleur voisin ou une approximation.
Il faut faire des essais pour déterminer les valeurs optimales des différentes constantes (nombre de fourmis, alpha, K...)
5.1.3 Algorithmes de Recherche avec Tabous de base : Cette méthode est une métaheuristique itérative qualifiée de recherche locale au sens large. L'idée de la recherche avec tabous consiste, à partir d'une position donnée, à en explorer le voisinage et à choisir la position dans ce voisinage qui minimise la fonction objective. Il est essentiel de noter que cette opération peut conduire à augmenter la valeur de la fonction : c'est le cas lorsque tous les points du voisinage ont une valeur plus élevée. C'est à partir de ce mécanisme que l'on sort d'un minimum local.
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 23
Le risque cependant est qu'à l'étape suivante, on retombe dans le minimum local auquel on vient d'échapper. C'est pourquoi il faut que l'heuristique ait de la mémoire : le mécanisme consiste à interdire (d'où le nom de tabou) de revenir sur les dernières positions explorées. Les positions déjà explorées sont conservées dans une pile FIFO (appelée souvent liste taboue) d'une taille donnée, qui est un paramètre ajustable de l'heuristique. Cette pile doit conserver des positions complètes, ce qui dans certains types de problèmes, peut nécessiter l'archivage d'une grande quantité d'informations. Cette difficulté peut être contournée en ne gardant en mémoire que les mouvements précédents, associés à la valeur de la fonction à minimiser. Les démonstrations de convergence (capacité de l'algorithme à trouver le minimum global si le temps imparti tend vers l'infini) pour la recherche avec tabous existent, mais supposent des conditions strictes, rarement présentes en pratique. De nombreuses variantes existent, principalement au niveau de la définition du voisinage et de la manière de gérer la mémoire. Schéma de l’algorithme tabou de base :
x := solution aléatoire fmin := f(x) xmin := x TABOU := liste de solutions S(x), de longueur L TABOU := VIDE REPETER
générer un N-échantillon TEL QUE Si(x) ∈ voisinage S(x) et {x, Si(x)} ∉ TABOU
f(S(x)) = min[f(Si(x))] POUR 1 ≤i ≤N ajouter ({x, Si(x)}, TABOU) x := S(x) SI f(x) < fmin fmin := f(x) xmin := x FIN SI
JUSQU'A <conditions d'arrêt satisfaites>
Interface véhicules
5.2 JdB Pour aider effectiveRovéhicules etCe Panel eschaque véhMéthode se
5.3 JdB
Comme l’apfenêtre d’al’Evaluationnommé SIG
homme-msur PC et
Steve LAN
B – 9) : Aid
à comprenute, nous avt leur situatst intéressa
hicule. etOutput() d
B – 10) : JF
pplication daccueil qui n qui prend G sur lequel
machine poapplicatif
NG – Rappo
de à la com
ndre les revons choisi ion (entre qnt car il do
de la classe I
rame Win
oit toujourspropose 3
les résultatnous avons
Fig
our un loglié sur ord
ort de Stag
mpréhens
elations entd'ajouter un
quelles requonne directe
IHM
nDOS au l
s pouvoir prdifférents
s d’une simlonguemen
12. Sélectio
iciel d'optdinateur m
ge – Labora
sion : Pan
tre Compann panel toujêtes ils se trement à l’u
ancemen
roposer la pmodes d’u
mulation pasnt travaillé.
n du mode d
timisation mobile ultra
atoire SET
el OUTPU
ny, Requestjours visiblerouvent). tilisateur le
nt
partie Simulautilisation : ssée et qui a
de l'applicat
des tourna léger.
/ UTBM
UT
ts, Vehiclese sur la droit
es informat
ation nous ala Simulat
affiche le rés
tion
Fig 11.
ées des
s, les buffete de l’écran
ions géogra
avons mis etion (déjà sultat, et en
. Panel pour
ST5
Page
ers route etn qui liste les
aphiques de
en place unedisponible)
nfin le mode
r les outputs
50
24
t s
e
e ), e
s
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 25
5.4 JdB – 12) : Nouvelle IHM Classe AddRequest : Pour le dernier mode (SIG) nous avons reconditionné l’IHM pour n’avoir plus qu’un bouton : ‘Ajoute Request’. Ce dernier, appelle un JPanel qui propose à l’utilisateur de saisir les informations de localisation de la requête. Après un clic sur le bouton "Ajouter", la classe AddRequest fait appel à la classe GetAddrCoor pour recevoir les coordonnées en WGS84 (système géodésique associé au système GPS, utilisé par Google Maps) de la localisation de la requête. Ces coordonnées sont ensuite converties en Lambert II étendu (si un jour on souhaite faire intervenir un S.I.G directement dans la StudiedArea) Pour l’instant notre application n’a qu’une compagnie située en plein centre de Belfort, aux coordonnées Lambert II étendu : 939891.3620309667, 2303046.5493371906 (Ces coordonnées sont définis dans la classe Constants : SIG_COMPANY_X et SIG_COMPANY_Y) On rescale notre requête par rapport à notre compagnie pour en déduire son px et son py sur la StudiedArea. On créé notre nouvelle requête au bon endroit (px,py) en l’informant du mieux possible sur ses attributs (son identifiant, les coordonnées Google Maps qu’on utilisera plus tard, sa longitude, sa latitude, le nom de sa rue, son code postal, sa ville). On rend la requête active pour pouvoir être servie et on l’ajoute à notre SetOfRequests. Classe GetAddrCoor : Cette classe va nous permettre d’interroger une première fois Google Maps pour récupérer les coordonnées de la requête que l’on veut créer. Une première difficulté a été de passer à travers le proxy de l’UTBM et les premières lignes de code de cette classe y sont consacrées. Une fois le proxy passé, on se connecte à l’URL : URL url=new URL("http://maps.google.com/maps/geo?q="
+ URLEncoder.encode(monAdresse, "UTF-8") +"&output=xml&key=ABQIAAAAGWhwg4im24cm8lfByfFAZRT9ADpIpFBh5OFabol7tYBiGTtMVhSY1_rf
t87Nj1w7Mp_vdIQB_CAKNA");
Détail : geo = appel de l’API de geocoding q = le query, auquel on transmet notre adresse sous la forme: rue,cp,ville,france avec par exemple (les fautes sont volontaires) : monAdresse = 8 bd antole frnce,blfort,france
Fig 13. Fenêtre de saisie de la localisation de la requête
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 26
output = le format de sortie que l’on veut traiter, dans notre cas c’est le xml car les balises sont faciles à parser key = la clé d’authentification à l’API, cette clé est gratuite, on l’obtient en s’enregistrant en tant qu’utilisateur de l’API, sans cette clé, on ne dispose d’aucun droit sur l’utilisation de l’API En retour on récupère donc un fichier XML avec toutes les informations qui nous intéressent (on notera que même avec des fautes de saisie, le traitement se fait) :
et nous garderons en fin de traitement (et si tout s’est bien passé) : Coordinates : Les coordonnées WGS84 DD (en degré décimal) de l’adresse, dans notre exemple : 6.843081,47.640703,0 ThoroughfareName : le nom complet de la rue, dans notre exemple on aura : 8 Boulevard Anatole France PostalCodeNumber : le code postal, dans notre exemple :
90000
Fig 14. Retour XML pour le geocoding
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 27
LocalityName : le nom correct de la ville (utile si on l’a mal écrit lors de la saisie), dans notre exemple : Belfort
Classe ConversionCoord : Cette classe est composée de 3 méthodes utiles :
• La conversion de DD (degré décimal) en DMS (degré, minute, seconde) se fait dans la méthode leLambert(string dd) qui prend en argument le string (WGS84 en DD) renvoyé par Google Maps
• WGS84toLambert2e(double d_long, double m_long, double s_long, char orientation_long, double d_lat, double m_lat, double s_lat, char
orientation_lat) qui convertie le WGS84 en Lambert II étendu en prenant en argument les coordonnées WGS84 en DMS (degré, minute, seconde)
• Lambert2eToWGS84(double x, double y) qui ne sert pas aujourd’hui, permet de faire la conversion inverse
5.5 JdB – 15) : ‘Véritable’ itinéraire Le principe de cette partie est de prendre en compte l’itinéraire exact (suivant les rues) d’une requête à une autre pour deux raisons :
• Un affichage sur carte, le vol d’oiseau ne donnant pas beaucoup d’information sur la localisation exacte du véhicule
• Envoyer ces informations sous forme de plan de route au véhicule pour qu’il ait la trajectoire la plus optimisée pour rejoindre la prochaine intervention
Le premier travail a été de déterminer dans quelle partie de l’application l’itinéraire devait être impliqué. On constate que cycliquement Company fait une demande de plan (getPlan(SoV)) à l’Optimizer qui le lui renvoie :
On se rend compte aussi qu’à chaque fois que la classe Optimizer reçoit une demande de plan, on a un appel à une méthode setEquivalentBackTOpt() de la classe SetOfVehicles (méthode qui va se charger de la copie)
Fig 15. Evenement getPlan entre Company et Otimizer
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 28
C’est donc dans cette dernière méthode qu’il a été le plus judicieux de faire intervenir la prise en charge du ‘véritable’ itinéraire. Le principe est défini comme tel : On a un tableau qui recense la liste de requêtes par véhicule avant l’optimisation et un autre qui regroupe la liste des requêtes par véhicule après optimisation (donc après retour du plan). Si les deux tableaux sont différents, on a donc un changement d’itinéraire pour un véhicule donné. Si un changement d’itinéraire a été détecté, on parcourt le nouveau tableau et on appelle la classe GetRouteCoor(string monadresse1, string monadresse2, string coordGMap) où monadresse1 et monadresse2 sont les adresses des requêtes, toujours suivant l’ordre du tableau, pour décrire les étapes de l’itinéraire. Classe GetRouteCoor : Cette classe suit exactement le même principe de fonctionnement que la classe GetAddrCoor vue en 5.4 à la différence près qu’elle ne traite pas le geocoding mais bien un trajet entre deux points. La connexion se fait donc par cette URL : URL url = new URL("http://maps.google.com/maps?saddr="
+ URLEncoder.encode(monAdresse1, "UTF-8") + ",france&daddr=" + URLEncoder.encode(monAdresse2, "UTF-8") + ",france&hl=fr&output=kml");
Par exemple pour aller de la Compagnie (située en plein centre de Belfort) à l’UTBM : http://maps.google.com/maps?saddr=belfort,france&daddr=8%20Boulevard%20Anatole%20France,Belfort,france&hl=fr&output=kml Détail : maps = l’appel de la fonction carte/itinéraire de Google Maps saddr = adresse de départ (monadresse1) daddr = adresse de destination (monadresse2) hl = langue dans laquelle on veut récupérer les informations de route (ici fr = en Français) output = le format de sortie, ici on choisi le KML pour la facilité du parse par balise (le résultat de la requête est donc un fichier KML dont un exemple est proposé en Annexe) On peut tirer de ce fichier une grande quantité d’informations que nous allons nous garder, comme par exemple
• Le plan de route qu’on utilisera à deux reprises : o Bulle d’information, sur le clic d’une route, sur le trajet généré avec la JSP o Plan de route transmis au PDA
• La distance et le temps de trajet • Les coordonnées des points de passage au format WGS84 pour la création de notre
propre KML qu’on transmettra après à la JSP
Interface véhicules
5.6 JdB Comme expaux autres aLe layering utiliser l’APDans notre
Exemple d’u <?xml ver<kml xmln<Placemar <de <na <Po </P</Placema</kml> Cet exempemplaceme La créationméthode (setEquivale On parcourt
• on c
• on a• on c• on a• on a• on d
homme-msur PC et
Steve LAN
B – 18) : Co
pliqué dansalternativespar fichier I Google Maprojet, ces i• Les diff
trajet • L’endro• L’endro
un fichier KM
rsion="1.0ns="http:/rk> scriptionme>UTBM Bint>
<coordoint> ark>
ple proposeent, ajouter
des fichierque la
entBackTOp
t le tableau créé un nouvo v + "id d
ajoute les enchoisi une coajoute l'empajoute le pladonne la list
machine poapplicatif
NG – Rappo
ompositio
le 16) du Jos nous ont faKML (Keyhoaps avec desinformation
férents itiné
it (placemarit (placemar
ML qui poin
0" encodin//earth.go
>UTBM BelBelfort</n
inates>6.
e un point, des bulles d
rs KML pourecherche
pt() de la cla
des itinéraiveau fichier
du véhicule"ntêtes KML ouleur pourplacement dan de route te des coord
our un loglié sur ord
ort de Stag
on et Créa
ournal de Boait opter po
ole Markup s informatio
ns personnaéraires (line
rk) où se trork) où se tro
nte juste sur
ng="UTF-8"oogle.com/
lfort</desname>
843081,47
mais on d'informatio
r les itinérae de chsse SetOfVe
ires, et pourr KML avec u" + _ + "place
r la ligne trade la requêtepour la bull
données des
iciel d'optdinateur m
ge – Labora
ation du f
ord, les avanour cette sol
Language) fons personnlisées sont :s), avec pla
ouvent les reouve le véhic
r un endroit
"?> /kml/2.0">
scription>
7.640703,0
peut définion, entre aut
aires inhérehangement ehicles)
r chaque itinun FileWritee de l'itinéra
cée correspe pour le poe d'informa
s points de p
timisation mobile ultra
atoire SET
ichier KM
ntages confution. facilite auss
nalisées. : n de route,
equêtes à secule
(ici, l'UTBM
>
>
0</coordin
ir des lignetre.
ents à chaqd'itinérai
néraire : er aire dans le
ondant au dointage avec
tion passage pou
des tourna léger.
/ UTBM
ML
férés par Go
si grandeme
, entre chaq
ervir
M à Belfort) :
nates>
es, des ico
ue véhiculeires ou
tableau" + .
dessin de l'itc cet icône :
ur cet itinéra
ées des
oogle Maps
ent la tâche
que étape (
nes pour m
e se fait dan'véritable'
.kml
tinéraire
aire
ST5
Page
par rapport
e si l’on veut
requête) du
marquer un
ns la mêmeitinéraire
50
29
t
t
u
n
e e
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 30
Voici un fichier KML généré pour l'itinéraire numéro 2 du véhicule 9 : v9_2.kml qui proposera la couche qui va dessiner l'itinéraire entre Valdoie et Belfort :
Les fichiers KML correspondant à l'emplacement des véhicules sont créés dans l'IHM. Comme on a pour souci d'avoir notre carte Google Maps générée avec des informations temps-réel, c'est au moment du clic de souris (sur le véhicule ou la compagnie) que l'on génère le KML du/des véhicule(s) avec ses/leurs coordonnées précises.
Fig 16. Exemple de KML généré pour tracer l'itinéraire 2 du véhicule 9
Interface véhicules
Voici un ficvéhicule av
5.7 JdB La seule ponotre systèOn a donc office de reComme la d'applicatif Dans notreavions déjà http://maAZRT9ADpI Ensuite nouavons créés Dans la foexemple l'a
homme-msur PC et
Steve LAN
chier KML gec cet icône
B – 19) : M
ssibilité d'inme lourd autrès vite no
lai entre notplateforme
f web par Gl
e index.jsp, utilisée en
aps.googleIpFBh5OFab
us avons chs en 5.6.
nction initijout des dif
machine poapplicatif
NG – Rappo
généré poue (vehicle.pn
ise en pla
nteragir aveucune interaoté la nécetre applicat
e de déveloassfish V2, l
on a donc 5.4) à l'adre
e.com/mapsbol7tYBiGT
hargé le scri
alize() on pfférents mod
our un loglié sur ord
ort de Stag
ur véhicule ng) :
ace de la 'J
ec l'API de Gaction ne peessité de fai
ion et le seroppement ql'option de l
commencé sse :
s?file=apiTtMVhSY1_r
pt de la lib
peut ajoutedes de vue,
iciel d'optdinateur m
ge – Labora
9 : v9_.km
Java Serv
Google Mapseut être direire intervenrvice web. qu'on a utia JSP a vite
par charge
i&v=2&rft87Nj1w7
rairie geoxm
er toutes sola barre de z
timisation mobile ultra
atoire SET
ml qui propo
er Page'
s est de pascte.
nir une plat
lisée (NetBeété évident
er le script d
&key=A7Mp_vdIQB_
ml.js pour le
ortes de cozoom, etc…
des tourna léger.
/ UTBM
osera la cou
sser par le Ja
eforme inte
eans IDE) pe et s'est av
de l'API ave
ABQIAAAAGW_CAKNA
e parse des
ommandes
ées des
uche qui va
avaScript, o
ermédiaire
propose l'hévérée efficac
ec la clé (ke
Whwg4im24c
fichiers KM
pour l'API
Fig 17.de KMpour l'empladu véh
ST5
Page
a pointer le
r à partir de
qui va faire
ébergementce.
ey que nous
cm8lfByfF
ML que nous
comme pa
Exemple ML généré
marquer acement
hicule 9
50
31
e
e
e
t
s
s
r
Interface véhicules
La classe Ge exml = nepour passernos fichiers map = new
5.8 Con Pour conclu Tout d'abor
1. VAL2. MO3. FRA4. DEL5. SEV6. DAN
homme-msur PC et
Steve LAN
eoXML y est
ew GeoXml(r à la partie
s KML, et do
w GMap2(do
nclusion p
ure, nous all
rd nous allonLDOIE NTBELIARD
AIS LLE VENANS NJOUTIN
machine poapplicatif
NG – Rappo
t aussi insta
("exml", me où l'on va nc ajouter n
ocument.ge
par l'exem
ons voir un
ns saisir nos
our un loglié sur ord
ort de Stag
nciée :
map, null,utiliser la m
nos couches
etElementB
mple de la
exemple de
s requêtes :
Fig 18
iciel d'optdinateur m
ge – Labora
, {sidebarméthode pa (layers) sur
ById("map_
a Partie I.H
e l'applicatio
. Simulateu
timisation mobile ultra
atoire SET
rid:"the_sarseString dr la carte que
_canvas"))
H.M.
on, en mode
r après opti
des tourna léger.
/ UTBM
side_bar"}e cette clase nous avon
);
e SIG, en act
misation de
ées des
}); sse, afin de ns instanciée
tivité.
es requêtes
ST5
Page
faire passee ici :
saisies
50
32
r
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 33
Après optimisation nous constatons que 4 véhicules sont nécessaires pour servir nos 6 requêtes. • véhicule 9 : VALDOIE (1) • véhicule 10 : DELLE (4) -> MONTBELIARD (2) -> SEVENANS (5) • véhicule 11 : DANJOUTIN (6) • véhicule 12 : FRAIS (3)
Pour l'instant 10 fichiers KML ont été générés :
• Pour le véhicule 9 : o V9_0.kml : COMPAGNIE -> VALDOIE o V9_1.kml : VALDOIE -> COMPAGNIE
• Pour le véhicule 10 : o V10_0.kml : COMPAGNIE -> DELLE o V10_1.kml : DELLE -> MONTBELIARD o V10_2.kml : MONTBELIARD -> SEVENANS o V10_3.kml : SEVENANS -> COMPAGNIE
• Pour le véhicule 11 : o V11_0.kml : COMPAGNIE -> DANJOUTIN o V11_1.kml : DANJOUTIN -> COMPAGNIE
• Pour le véhicule 12 : o V12_0.kml : COMPAGNIE -> FRAIS o V12_1.kml : FRAIS -> COMPAGNIE
Pour accéder à l'interface GoogleMaps, on a deux options :
soit on clique sur la compagnie pour avoir le plan d'ensemble : tous les véhicules avec leurs itinéraires
au clic, 4 nouveaux fichiers KML correspondant aux véhicules sont générés (v9_.kml, v10_.kml, v11_.kml et v12_.kml) on appelle ensuite notre JSP : index.jsp : http://localhost:8080/GoogleMaps/index.jsp?all=oui&nbIti=12/2,11/2,10/4,9/2&leVeh=rep_v/ all = oui, on veut le plan global nbITI = id_vehicule/nb_itinéraire pour les index des boucles dans le traitement de la JSP leVeh = le répertoire où ont été générés les .kml
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 34
notre navigateur internet s'ouvre et on obtient :
La carte a été générée, avec tous les véhicules localisés à la compagnie et les 'véritables' itinéraires. Dans la liste de droite fournie par GeoXML on retrouve toutes nos couches (layers) correspondant aux KML générés (4 véhicules + 10 itinéraires) dans l'ordre :
Itinéraires du véhicule 9, Véhicule 9 (Vers Valdoie), Itinéraires du véhicule 10, Véhicule 10 (Vers Delle), Itinéraires du véhicule 11, Véhicule 11 (Vers Danjoutin), Itinéraires du véhicule 12, Véhicule 12 (Vers Frais).
soit on clique sur un véhicule en particulier pour avoir son trajet propre
Fig 19. Carte générée avec les 14 couches KML
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 35
par exemple le véhicule 10 avec un mode de visualisation mixte :
Par couche, on a le véhicule pointé à COMPAGNIE (Belfort Centre), le premier itinéraire en rose qui rejoint DELLE, le deuxième en bleu qui rejoint MONTBELIARD, le troisième en gris qui rejoint SEVENANS et enfin le dernier en brun qui revient vers COMPAGNIE (Belfort Centre). ou par exemple le véhicule 9 avec le plan de route sur l'itinéraire COMPAGNIE -> VALDOIE :
Fig 20. Carte générée pour l'itinéraire du véhicule 10 (en mode mixte)
Fig 21. Plan de route de l'itinéraire 1 du véhicule 9
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 36
Avec un clic sur la ligne verte kaki, qui correspond à la couche du fichier v9_0.kml, on obtient le plan de route pour cet itinéraire. Ce même plan de route a est envoyé au PDA si on considère la partie embarquée. (Toutes les cartes correspondant à cet exemple sont disponibles en Annexe)
Chapitre 6 : Dans les Détails – Partie Embarquée : PDA/GPS Pour les 2 dernières semaines de stage, nous avons entamé la partie pour l'assistant électronique doté d'une puce GPS. Après avoir réussi à faire communiquer (par ping) le PDA et le PC de bureau (avec toutes les contraintes décrites dans le JdB -21) le choix de python, pour l'applicatif embarqué, a été sélectionné. La communauté de python ne cessant de croitre, les librairies utiles fleurissent et son interprétation devient très stable même en environnement léger. Nous installons donc PythonCE.WM.cab sur notre Windows Mobile 5.
6.1 JdB – 23) : Port Série COM7 et Trame NMEA La puce GPS du module mobile utilise le port COM7 pour livrer ses informations. Les données qu'elle transite utilisent le protocole NMEA. La première étape a été de réussir à extraire une des trames NMEA du port. Pour les communications séries sur modèles embarqués, une librairie python a été développée : ceserial.py Après un import de la librairie on déclare un descripteur sur le bon port avec une vitesse de transfert : serial = Serial(port='COM7:', baudrate=4800) comme pour un fichier on aura un : serial.open() et un serial.close()
Fig 22. PythonCE installé sur le PDA
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 37
une fois le port ouvert, la lecture se fait simplement par un : serial.read(n) n étant le nombre de caractère à lire dans notre cas, comme les trames sont envoyées 'à la volée' sur le port com7 de la puce GPS, nous lisons dans une boucle, caractère par caractère ( serial.read(1) ) La trame NMEA : Il existe différents types de trames disponibles dans le protocole NMEA Chacune transporte son lot d'information et suivant la problématique, les choix vont se tourner vers l'une et/ou l'autre. Dans notre cas, ce qui peut être intéressant de récupérer c'est :
• la date et l'heure de la mesure • les coordonnées (longitude et latitude) • la vitesse au sol (savoir si par exemple le module est en mouvement ou pas)
La trame $GPRMC répond parfaitement à nos attentes, elle est composée des informations suivantes :
00 $GPRMC 01 Heure du fix 02 Alerte (A=OK ; V=WARNING) 03 Latitude au format ddmm.ss 04 Sens de la latitude (N=Nord=Positif, S=Sud=Négatif) 05 Longitude au format dddmm.ss 06 Sens de la longitude (E=Est=Positif, W=Ouest=Négatif) 07 Vitesse au sol en Knots (noeuds) 08 Cap vrai 09 Date du fix 10 Déclinaison magnétique 11 Sens de la déclinaison magnétique
C'est donc cette trame que nous utilisons dans notre système gps_iti.py (Annexe)
Fig 23. Répertoire de travail avec lancement de l'application
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 38
D'abord, suivant l'alerte ('A' ou 'V') nous affichons un OK si la trame est correctement renseignée et un NOK dans le cas contraire, par exemple lors d'une couverture trop pauvre en satellite. Par exemple dans la plateforme de recherche, à l'intérieur du bâtiment D de l'UTBM on obtient :
C'est après un petit temps d'adaptation à l'extérieur du bâtiment que nous obtenons un très satisfaisant :
6.2 JdB – 24) : Communication entre l'IHM et le système embarqué Pour le transfert des données GPS du PDA à l'IHM : l'IHM est serveur car il attend les données et le PDA est client car il envoie ses informations de positionnement et de vitesse. Pour le transfert des données de plan de route de l'IHM au PDA: l'IHM est client car il envoie les données dès qu'on constate un changement dans les itinéraires et le PDA est serveur car il attend les informations de guidage. Deux threads sont donc nécessaires dans notre système embarqué, un qui va se charger du transfert des données GPS et l'autre qui se chargera de réceptionner les informations de route.
Fig 24. Aucune information de localisation n'est détectée
Fig 25. Le système capte des informations de position
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 39
Dans un premier temps, comme l'IHM se retrouvera à communiquer avec plusieurs entités correspondant à chaque véhicule, il faut identifier notre appareil :
Comme pour les communications séries vues précédemment, une librairie existe aussi pour les communications par socket (socket.py) Détaillons la procédure pour comprendre les correspondances JAVA (partie IHM) et Python (partie embarquée)
• Dans le cadre du transfert des données GPS o Pour la partie embarquée :
Le socket étant de type Client, il est initialisé par : sGPS = socket.socket(socket.AF_INET, socket.SOCK_STREAM) Comme on ne veut pas qu'il soit bloquant on lui impose un timeout d'une seconde: sGPS.settimeout(1) La connexion se fait alors par : sGPS.connect((HOST, PORTGPS+VEHICULE))
HOST : adresse IP de notre PC de bureau (192.168.9.1) PORTGPS : port d'accès pour le transfert concernant les données GPS (50000) VEHICULE : décalage du PORTGPS de l'ID du véhicule pour que chacun ait un port dédié
Et les données sont envoyées par un sGPS.send(données) Enfin, on se déconnecte avec sGPS.close()
o Pour la partie fixe : C'est dans la classe Vehicle que l'on établi la communication car on obtient des informations sur ses attributs propres. Le socket est de type Serveur, il est initialisé par : s = new ServerSocket(50000+__pos); 50000 est le port correspondant à la communication GPS, là aussi on prend évidemment en compte le décalage en fonction de l'ID du véhicule (pour savoir avec qui on parle) Dès qu'une demande de connexion arrive on accepte par : Socket soc = s.accept();
Fig 26. Input pour l'ID du véhicule correspondant à ce PDA
Interface véhicules
Les informaBufferedRe
Elles sont e Exemple : Une fois quun px et un
• Dan
La communles mêmes à jour le tab
IMPORTANTLe booléen mobile. Si on utilistransmettreSi au contrainformation
homme-msur PC et
Steve LAN
ations transeader plec
nsuite parsé
e les donné py correspo
ns le cadre d
o Pour la nication se flignes qui d
bleau des iti
T : 'PDAwaitin
e l'applicatie des informaire on a un n ne sera jam
machine poapplicatif
NG – Rappo
mises sont = new Buff
ées pour êtr
ées de positiondant aux
u transfert
partie fixe :fait dans la
détectent unnéraires.
ng' a été m
ion sans PDmations de r
PDA qui attmais transm
F
our un loglié sur ord
ort de Stag
lues avec unferedReader
re utilisable
ons de l'appcoordonnée
des informa
méthode s
n changeme
mis en place
DA 'PDAwairoute et l'optend des inf
mise.
Fig 27. Outp
iciel d'optdinateur m
ge – Labora
n BufferedRr(new Inpu
s.
pareil mobiles réelles du
ations sur le
setEquivalenent d'itinéra
e pour activ
iting' doit êtimisation n
formations,
ut des infor
timisation mobile ultra
atoire SET
eader : utStreamRea
e ont été reu véhicule:
e plan de rou
ntBackTOptire et interr
ver ou pas
être à FALSEne démarrer'PDAwaitin
rmations de
des tourna léger.
/ UTBM
ader(soc.ge
eçues, on les
ute
() de la clasrogent Goog
la commu
E, sinon ellera jamais. g' devra êtr
localisation
ées des
etInputStre
s convertit e
sse SetOfVegle Maps po
nication av
e essayera
re à TRUE, si
n de l'appare
ST5
Page
eam()));
et on obtient
ehicles, dansour remettre
vec la partie
toujours de
inon aucune
eil mobile
50
40
t
s e
e
e
e
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 41
Dans cette utilisation de l'application nous avons bien un PDA, notre booléen 'PDAwaiting' est par conséquent actif (TRUE). Le socket est de type Client et est initialisé par : sPDA = new Socket("192.168.9.2", 51000+i);
Cette fois le port de connexion est 51000 + le décalage de l'ID du véhicule On utilise un Stream pour faire transiter les informations à transmettre : os = new DataOutputStream(sPDA.getOutputStream()); On y écrit par l'intermédiaire de : os.writeBytes(itiPDA + "\nEND"); On referme le Stream et le socket : os.close(); sPDA.close();
o Pour la partie mobile : Le socket est créé avec son timeout :
sIti = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sIti.settimeout(1) On attend une demande de connexion, on écoute et on accepte : sIti.bind(('', PORTITI+VEHICULE)) Ici on bind de la part de n'importe qui sur le port PORTITI (51000), décalé de l'ID du véhicule sIti.listen(1) conn, addr = sIti.accept() Une fois que la connexion est établie, on reçoit les informations caractère par caractère : paquet = conn.recv(1) Enfin on referme le socket quand la transmission se termine par "END" (while not
data.endswith('END') : ) conn.close() Exemple : Quand l'applicatif de la partie fixe capte un changement d'itinéraire, il transmet les informations à la partie mobile :
Fig 28. Un nouvel itinéraire a été transmis par l'application fixe
Interface véhicules
Les deux thAlors que ldeuxième t
6.3 JdB Après plusieêtre affectéAussi, on dovirtuel, maiUne fois les
6.4 Con Reprenons deux itinéra
homme-msur PC et
Steve LAN
reads coexie premier
thread reçoit
B – 26) : At
eurs entretiée dans la moit prendre s qu'il prenn
s coordonné
nclusion p
l'exemple daires : COMP
Fig 29. Eta
machine poapplicatif
NG – Rappo
stent bien : se charge dt bien un no
ttribution
iens avec Jeméthode acti
en compte ne en comp
ées (transmi
par l'exem
du chapitre PAGNIE -> V
at de l'IHM a
our un loglié sur ord
ort de Stag
d'envoyer douvel itinéra
n des coor
ean-Charles ivate() de lale datage pote la représeses par le PD
mple de la
précédent VALDOIE et V
après optim
iciel d'optdinateur m
ge – Labora
des informaaire.
rdonnées
Créput, il e classe Vehiour que l'opentation réeDA) reçues,
a Partie PD
avec notre VALDOIE ->
misation, san
timisation mobile ultra
atoire SET
tions sur le
du PDA à
en est ressoricle.
ptimizer ne celle de l'ention affecte l
DA/GPS
véhicule 9 COMPAGNI
ns réception
des tourna léger.
/ UTBM
e positionne
à l'IHM
rti que la po
continue paité mobile. e nouveau p
qui se voitE
d'informat
ées des
ement de l
osition du v
as à simuler
px et py au v
t attribuer u
ion du mod
ST5
Page
'appareil, le
véhicule doit
un véhicule
véhicule.
un trajet de
ule mobile
50
42
e
t
e
e
Interface véhicules
L'applicatif véhicule n'e
Nous sortonplus large, o
Retour vers
homme-msur PC et
Steve LAN
trouve un est pas visib
ns du bâtimon obtient :
le poste de
machine poapplicatif
NG – Rappo
nouvel itinble dans l'IHM
ment D de l'U
travail et vo
Fig 3
our un loglié sur ord
ort de Stag
néraire et lM et le PDA
UTBM, et ap
oici ce que l
32. Etat de l'
iciel d'optdinateur m
ge – Labora
'envoie au A n'envoie qu
rès un temp
'IHM nous p
IHM après r
timisation mobile ultra
atoire SET
PDA qui nue des NOK)
ps d'adaptat
présente :
réception de
des tourna léger.
/ UTBM
'a pas de c) :
tion et une c
Fig 30. Réceptitinéra
Fig 31.Récepinformpositi
e la localisat
ées des
couverture
couverture s
tion d'un ire
. ption desmations deonnement
tion du véhi
ST5
Page
satellite (le
satellite
icule
50
43
e
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 44
Avec un aperçu sur carte (un clic sur le véhicule) :
Et lorsqu'on zoom sur le véhicule avec le mode mixte :
On retrouve bien l'appareil mobile devant le bâtiment D de l'UTBM
Fig 33. Carte générée avec la localisation réelle du véhicule (PDA)
Fig 34. Le PDA se trouve quelque part entre le boulevard Anatole France et la rue Ernest Mieg à Belfort
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 45
Chapitre 7 : Les travaux futurs … à l'attention des poseurs de tuiles
Pour améliorer notablement cette application, on peut envisager divers travaux complémentaires
• Pour l'IHM : o Envisager de prendre en compte la liste des coordonnées de points de passage de
Google Maps (ceux utilisés dans les fichiers KML), la convertir et relocaliser les VNodes (points d'optimisation) en fonction, de telle sorte que le trajet sur la StudiedArea suive exactement celui de Google Maps (au lieu d'avoir une ligne droite qui relie chaque requête)
• Pour l'appareil mobile : o Proposer à l'utilisateur de décider quand une requête a été servie, afin d'en avertir
l'IHM de l'application fixe et passer à la prochaine (s'il en reste) o Utiliser la JSP de l'application fixe pour voir apparaître dans le navigateur web du PDA
notre itinéraire cartographié o Proposer une interface graphique pour l'applicatif mobile avec par exemple WxPyCE ou
TkInter qui sont dédiés à Python o Proposer une interface de saisie pour le suivi du patient
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 46
Conclusion Dans le cadre de ce projet de fin d'études, j'ai trouvé plusieurs points d'intérêt qui m'ont permis d'approcher, d'un peu plus, les problématiques qu'on peut rencontrer dans un projet professionnel. Tout d'abord, le fait de reprendre un projet existant fait vite prendre conscience de l'importance de la documentation des travaux déjà réalisés. C'est pourquoi j'ai essayé de tenir un journal de bord afin de rendre ce rapport le plus clair et le plus complet possible. La diversité des domaines que j'ai eue la chance de rencontrer lors de ce stage a aussi été un point important dans l'intérêt que j'ai pu porter aux travaux. Dans un premier temps avec une rapide approche des méthodes d'optimisation par les métaheuristiques. Ensuite, avec l'importance de travailler avec un bon outil, et NetBeans IDE 6 a très bien répondu à mes attentes. La partie sur l'application fixe m'a aussi permis d'en savoir un peu plus sur les Systèmes d'Informations Géographiques, et dans notre cas les facettes intéressantes que peuvent fournir les services web (comme l'API Google Maps que j'ai très largement détaillée tout au long des pages qui précèdent). Enfin la partie embarquée a aussi été un moment fort dans mes motivations d'avancement, car l'interaction entre une application fixe, un service web, une partie mobile et son système de géolocalisation a été très enrichissante à mettre en place. Enfin, le travail dans un laboratoire de recherche prend tout son sens dans la profondeur que l'on peut donner à l'état des avancements et je remercie encore une fois Amir Hajjam pour l'autonomie qu'il m'a laissée.
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 47
Bibliographie Johann DREO, Alain PETROWSKI, Patrick SIARRY, Eric TAILLARD: Métaheuristiques pour l’optimisation difficile – Ed. Eyrolles (2003) Jean-Michel RENDERS : Algorithmes génétiques et réseaux de neurones – Ed. Hermes (1995) Mounir BOUSSEDJRA : Contribution à la résolution du problème du plus court chemin multiobjectif par algorithmes évolutionnistes : Application aux systèmes de transport intermodal – Thèse (2005) Sites Internet : Les métaheuristiques : http://www.enib.fr/~buche/public/enseignement/SoftComputing/MetaHeuristiques/MetaHeuristique_Optimisation.pdf La documentation de l'API Google Maps : http://code.google.com/apis/maps/documentation/ Les trames NMEA : http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=17661 Système d'Information Géographique (SIG) – Conversion de Coordonnées : http://www.forumsig.org
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 48
Annexe
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 49
Fichier KML retourné par l’API Google Maps après une requête sur un itinéraire entre : la Compagnie (Belfort Centre) et l’UTBM (8, boulevard Anatole France, Belfort) <?xml version="1.0" encoding="UTF-8" ?> <kml xmlns="http://earth.google.com/kml/2.0"> - <Document> <name>Belfort, France à 8 Boulevard Anatole France, 90000 Belfort, France</name> - <Style id="roadStyle"> <LineStyle><color>7fcf0064</color><width>6</width></LineStyle> </Style> - <Snippet> - <![CDATA[ <font size=+1><a href="http://maps.google.com/maps?saddr=belfort,france&daddr=8%20Boulevard%20Anatole%20France,Belfort,france&hl=fr">Version imprimable</a></font> ]]> </Snippet> - <Placemark> <name>Prendre la direction nord sur Place de la République vers Rue du Repos</name> - <description> - <![CDATA[ sur une distance de 54 m ]]> </description> <address>Belfort, France</address> <styleUrl>root://styleMaps#default+nicon=0x406+hicon=0x416</styleUrl> - <Point> <coordinates>6.862220,47.638830,0</coordinates> </Point> - <LookAt> <longitude>6.862220</longitude> <latitude>47.638830</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>7.990630</heading> </LookAt> </Placemark> - <Placemark> <name>Tourner à gauche pour rester sur Place de la République</name> - <description> - <![CDATA[ sur une distance de 77 m ]]> </description> <styleUrl>root://styleMaps#default+nicon=0x447+hicon=0x457</styleUrl> - <Point> <coordinates>6.862320,47.639310,0</coordinates> </Point> - <LookAt> <longitude>6.862320</longitude> <latitude>47.639310</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>7.990630</heading> </LookAt> </Placemark> - <Placemark> <name>Place de la République tourne légèrement à droite et devient Rue du Docteur Charles Fréry</name> - <description> - <![CDATA[ sur une distance de 0,2 km ]]> </description> <styleUrl>root://styleMaps#default+nicon=0x447+hicon=0x457</styleUrl>
Interface homme-machine pour un logiciel d'optimisation des tournées des véhicules sur PC et applicatif lié sur ordinateur mobile ultra léger. ST50
Steve LANG – Rapport de Stage – Laboratoire SET / UTBM Page 50
- <Point> <coordinates>6.861350,47.639490,0</coordinates> </Point> - <LookAt> <longitude>6.861350</longitude> <latitude>47.639490</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>302.458771</heading> </LookAt> </Placemark> - <Placemark> <name>Tourner légèrement à droite sur D83</name> - <description> - <![CDATA[ sur une distance de 1,3 km ]]> </description> <styleUrl>root://styleMaps#default+nicon=0x447+hicon=0x457</styleUrl> - <Point> <coordinates>6.859630,47.640860,0</coordinates> </Point> - <LookAt> <longitude>6.859630</longitude> <latitude>47.640860</latitude> <range>100.000000</range> <tilt>45.000000</tilt> <heading>305.183258</heading> </LookAt> </Placemark> - <Placemark> <name>Arrivée à : 8 Boulevard Anatole France, 90000 Belfort, France</name> <address>8 Boulevard Anatole France, 90000 Belfort, France</address> <styleUrl>root://styleMaps#default+nicon=0x467+hicon=0x477</styleUrl> - <Point> <coordinates>6.843081,47.640706,0</coordinates> </Point> </Placemark> - <Placemark> <name>Itinéraire</name> - <description> - <![CDATA[ Distance: 1,6 km (environ 4 minutes)<br/>Données cartographiques ©2008 Tele Atlas ]]> </description> - <GeometryCollection> - <LineString> <coordinates>6.862220,47.638830,0.000000 6.862320,47.639310,0.000000 6.862320,47.639310,0.000000 6.861950,47.639330,0.000000 6.861560,47.639400,0.000000 6.861350,47.639490,0.000000 6.861350,47.639490,0.000000 6.861180,47.639690,0.000000 6.860030,47.640670,0.000000 6.859630,47.640860,0.000000 6.859630,47.640860,0.000000 6.859460,47.640950,0.000000 6.859430,47.641030,0.000000 6.859230,47.641180,0.000000 6.858940,47.641330,0.000000 6.858130,47.641660,0.000000 6.857240,47.641910,0.000000 6.856320,47.641830,0.000000 6.855620,47.641600,0.000000 6.853580,47.641390,0.000000 6.853420,47.641300,0.000000 6.852350,47.641260,0.000000 6.848940,47.641030,0.000000 6.848860,47.641070,0.000000 6.848440,47.641060,0.000000 6.843080,47.640710,0.000000</coordinates> </LineString> </GeometryCollection> <styleUrl>#roadStyle</styleUrl> </Placemark> </Document> </kml>