détection de collisions en contexte automobile - e

DÉTECTION DE COLLISIONS EN
CONTEXTE AUTOMOBILE
Rapport de TER préparé à l'Institut National de Recherche en Informatique et Automatisme
au sein du projet e-MOTION au laboratoire GRAphique, Vision et Robotique
INRIA Rhône-Alpes
ZIRST, 655 avenue de l'Europe
38330 Montbonnot St. Martin
FRANCE
Frédéric FAVIER
Janvier-Octobre 2004
Maîtres de stage : Jorge Hermosillo, Thierry Fraichard
Contenu
1. Cadre du stage
1.1. L'INRIA
1
1.2. L'équipe e-MOTION
2
1.3. Les thèmes de recherche
2
1.4. Le projet ARCOS
3
2. Informatique & Sécurité Routière
2.1. Sécurité passive et sécurité active
4
2.2. Assistance à la conduite
5
2.3. Atténuateur de collisions
6
2.4. Les difficultés rencontrées
6
3. Freinage d'urgence
3.1. Principe de l'approche proposée
7
3.2. Modèle dynamique d'une voiture (LAG)
8
3.3. Modélisation des obstacles
9
3.4. Détection des collisions
10
4. Résultats
4.1. Comportement
11
4.2. Performance
12
5. Conclusion et perspectives
5.1. Conclusion
13
5.2. Perspectives
13
1. Cadre du stage
Sommaire :
1.1. L'INRIA
1
1.2. L'équipe e-MOTION
2
1.3. Les thèmes de recherche
2
1.4. Le projet ARCOS
3
1.1. L'INRIA
Photo 1 - Bâtiment INRIALPES, Montbonnot
L'Institut National de Recherche en Informatique et en Automatique est un établissement public à
caractère scientifique et technologique (EPST), placé sous la double tutelle du ministère de la
recherche et du ministère de l'économie, des finances et de l'industrie .
Le principal objectif de l'INRIA est de réaliser des percées scientifiques et technologiques du
meilleur niveau mondial dans le cadre de sept grands défis prioritaires :
–
–
–
–
–
–
–
Concevoir et maîtriser les futures infrastructures des réseaux et des services de communication,
Développer le traitement des informations et données multimédia,
Garantir la fiabilité et la sécurité des systèmes à logiciel prépondérant,
Coupler modèles et données pour simuler et contrôler les systèmes complexes,
Combiner simulation, visualisation et interaction,
Modéliser le vivant,
Intégrer pleinement les STIC dans les technologies médicales.
1.2. L'équipe e-MOTION
L'équipe e-MOTION a pour ambition de développer des modèles et des méthodes algorithmiques
permettant de construire des systèmes artificiels dotées de capacités de perception, de décision, et
d'action suffisamment évoluées et robustes pour autoriser un fonctionnement de ceux-ci dans des
environnements ouverts (i.e. partiellement connus), à forte dynamicité (i.e. où le temps et la
dynamique jouent un rôle essentiel), et conduisant à des interactions variées avec l’homme. Les
progrès récents en matière de puissance informatique embarquée, de capteurs, et de systèmes
mécatroniques miniaturisés, rend cette évolution envisageable et permet potentiellement d'aboutir
au saut technologique nécessaire à un réel passage à l'échelle. Pour atteindre cet objectif, l'équipe
propose de combiner les avantages respectifs de la géométrie algorithmique, des probabilités, et
dans certains cas de l'inspiration biologique (en travaillant pour cela avec des neuro-physiologistes).
Les principaux domaines d'application visés par cette problématique de recherche sont ceux qui
cherchent à introduire des systèmes robotisés évolués et sécurisés dans notre espace de vie, afin
d'accroître la sécurité des personnes et le confort d'utilisation des nouvelles technologies. Cette
caractéristique se retrouve en particulier dans des applications comme la voiture et les systèmes de
transport futurs, la robotique de service (par exemple pour réaliser des tâches ménagères ou pour
améliorer le cadre de vie de personnes handicapées ou dépendantes), ou encore la robotique
d’intervention (e.g. sécurité civile ou militaire). Les retombées que l'on peut attendre de ces
recherches sont par contre plus vastes, et couvrent potentiellement des domaines aussi variés que
l'interaction avec des agents autonomes dans un monde virtuel, la modélisation de fonctions sensorimotrices dans le vivant, ou encore des secteurs économiques éloignés de la robotique comme ceux
de la finance ou de la maintenance industrielle.
e-MOTION est une équipe de recherche commune avec le Laboratoire GRAVIR
(CNRS, INPG, INRIA et Université Joseph Fourier). Cette équipe de recherche fait suite
à l'équipe de recherche SHARP.
1.3. Les thèmes de recherche
L'équipe e-MOTION travaille autour de trois axes principaux :
–
Modélisation multi-modale et incrémentale de l'espace et du mouvement. Il s'agit de construire
en continu (à partir de connaissances préalables et de données perceptives diverses), et de faire
cohabiter des modèles de natures différentes, i.e. de modèles ayant des spécialisations
fonctionnelles complémentaires comme le suggèrent les neuro-physiologistes
–
Planification de mouvements dans le monde physique. Les caractéristiques intrinsèques du
monde physique nous conduisent à prendre simultanément en compte des contraintes de non
collision, de dynamique, et de temps de réaction. Afin de maîtriser la complexité algorithmique
du problème, nous développons des techniques permettant de raisonner sur des représentations
appropriées de l'espace-temps (espace des vitesses instantanées, principe de planification
itérative sous contraintes temporelles fortes)
–
Inférence probabiliste pour la décision. Afin de pouvoir raisonner correctement sur les
connaissances courantes du système et sur les incertitudes qui leurs sont associées, nous
proposons d'utiliser le principe de « programmation bayésienne » que nous avons développé et
qui offre un cadre formel pour réaliser de l'apprentissage automatique et des raisonnements basés
sur l'inférence probabiliste.
1.4. Le projet ARCOS
L'Action de Recherche pour une COnduite Sécurisée s’inscrit dans le cadre des actions fédératives
du PREDIT (Programme de Recherche, de Développement et d’Innovation dans les Transports
Terrestres). Ce projet de recherche pré-compétitive concerne l’amélioration de la sécurité routière,
en se fixant à terme un objectif de réduction des accidents estimé à 30 %. Selon une approche
globale du système « véhicule-infrastructure-conducteur », le projet consiste à sécuriser la conduite
automobile sur la base des quatre fonctions techniques suivantes :
–
–
–
–
gérer les interdistances entre véhicules ;
prévenir les collisions sur obstacles fixes, arrêtés ou lents ;
prévenir les sorties de route ;
alerter les véhicules en amont d’accidents / incidents.
Le pilotage de ces quatre fonctions en termes de spécifications techniques est au coeur du projet
ARCOS, et constitue son originalité. Géré de façon analogue aux projets industriels, ARCOS est
organisé selon dix thèmes, qui permettent d’intégrer les apports des sciences de l’ingénieur, des
sciences humaines, et des sciences sociales.
ARCOS représente un investissement de R&D d’environ 18 M€ sur trois ans. Le projet associe
quelque soixante partenaires, laboratoires publics et entreprises privées, autour des grands
constructeurs et équipementiers.
Les résultats d’ARCOS sont décrits en tant que « livrables » ; on prévoit trois catégories de «
livrables » : des connaissances, des technologies, des prototypes d’expérimentation des fonctions
techniques constituant l’objectif. Afin d’éprouver les résultats obtenus, ARCOS met en oeuvre une
démarche de plate-forme expérimentale. Celle-ci mobilise quatre véhicules instrumentés. Trois
campagnes expérimentales sont l’occasion pour les partenaires d’ARCOS de constater la pertinence
des technologies développées (il ne s’agit toutefois pas de développer des prototypes opérationnels
ou des démonstrateurs, résultats qui sont hors du champ d’un programme de recherche précompétitive). Les résultats obtenus sont valorisés et protégés. Dans le cas des entreprises, la mise en
oeuvre des outils de propriété industrielle (brevets, secret…) est prévue dans l’accord de consortium
qui lie les partenaires.
Illustration 1 - Approche "véhicule-infrastructure-conducteur"
2. Informatique & Sécurité Routière
Sommaire :
2.1. Sécurité passive et sécurité active
4
2.2. Assistance à la conduite
5
2.3. Atténuateur de collisions
6
2.4. Les difficultés rencontrées
6
« Je voudrais marquer ce quinquennat par trois grands chantiers qui ne sont pas de pierre. C'est
d'abord la lutte contre l'insécurité routière ... »
Allocution de Jacques Chirac, Président de la République, le 14 Juillet 2002.
2.1. Sécurité passive et sécurité active
Ces dernières années, de nombreux équipements sont venus enrichir le catalogue des constructeurs
automobiles dans le but d'améliorer la sécurité routière. Aujourd'hui, les véhicules sortant des usines
disposent
–
de série : ceintures, airbags, structure de caisse renforcée avec zone de déformation et
d'absorption des chocs, ABS avec/sans répartiteur électronique de freinage (EBD), etc
–
en option : contrôleur dynamique de conduite (ESP), assistance au freinage d'urgence (AFU),
phares au Xénon, régulateur et limiteur de vitesse, interdistances, ...
Photo 2 - Le parc automobile se modernise.
Ces différents systèmes peuvent être classer en deux groupes :
–
Sécurité passive. Ces équipements permettent de sauver des vies et de limiter les dégâts
occasionnés lors d'accidents. Toutefois, ils n'empêchent en rien les accidents, mais en réduisent
les conséquences.
–
Sécurité active. Ces équipements minimisent ou évitent les accidents en offrant une meilleur
visibilité de la situation, en avertissant le conducteur des dangers, en agissant directement sur les
commandes du véhicule ...
Sécurité passive
Sauver des vies
- Ceintures
- Renforts
- etc
Minimiser les dégats
- Airbags
- ABS, EBD, AFU
- etc
Limiter les accidents
- Facteurs humain
- Phares Xenon
- etc
Eviter les accidents
- Alarmes
- Interdistances
- etc
Sécurité active
Illustration 2 - Vers une sécurité routière améliorée
2.2. Assistance à la conduite
Typiquement, un système d'assistance à la conduite est composé :
–
–
–
d'un module de perception (différents capteurs, radars, lidars, caméras, etc) qui fournit un modèle
de l'environnement,
d'un module décisionnel qui, en fonction de l'état du véhicule équipé et de l'environnement,
choisit les actions à mener,
d'un module d'actions pouvant opérer sous divers mode (informel, coopératif, délégué).
capteur 1
Alarme 1
capteur 2
capteur n
Modèle de
l'environnement
prédiction
trajectoire
Alarme n
planification
Freinage
caméra
lidar
Perception
Droite
évaluation
du risque
Décision
Illustration 3 - Un système d'assistance à la conduite
Gauche
Action
2.3. Atténuateur de collisions
Dans le cadre du projet ARCOS, l'INRIA a pour mission de développer un système d'assistance à la
conduite pour la fonction "prévenir les collisions sur obstacles, fixes, arrêtés ou lents".
En amont, les équipements embarqués de la voiture nous fournissent un modèle de
l'environnement : tracé de la route, position et mouvements des obstacles. Nous calculons ensuite un
ensemble de trajectoires possibles, pour le véhicule, à commandes constantes par morceaux. En
aval, suivant la dangerosité des trajectoires considérées, le freinage d'urgence est enclenché ou non.
Plus précisément, la méthode employée est censée agir comme un filet de sécurité, c'est à dire
qu'elle doit permettre :
–
d'agir lorsqu'on est certain que la collision ne peut être évitée par le conducteur et pas avant, ceci
afin de ne pas entrer en conflit avec la manoeuvre déjà entreprise par le conducteur.
–
de réduire la vitesse du véhicule équipée de 10 km/h au moment du choc, en enclenchant une
action de freinage 0.5 seconde avant la collision. En effet, le temps de réaction de l'homme entre
l'apparition d'un danger et l'application de 90% d'un freinage efficace est en moyenne de 1.7
secondes. On peut donc considérer qu'à 0.5 seconde avant un choc inévitable, le freinage aurait
dû être enclenché de toute façon.
Ce système fait donc partie de la sécurité passive : la collision aura inexorablement lieu, mais il
permet d'atténuer les dégâts subis. En effet, d'après une étude de l'INRETS, réduire la vitesse de 10
km/h au moment de l'impact ferait chuter la mortalité de 30% si la totalité du parc automobile était
équipé.
2.4. Les difficultés rencontrées
La complexité de notre problème tient de deux aspects :
–
aspect humain. Aucune connaissance n'est fourni à priori sur le comportement du conducteur. De
nombreux facteurs accidentogènes sont directement liés aux automobilistes : l'inattention, une
mauvaise perception de l'environnement, la fatigue, un malaise, l'assoupissement, l'alcool, les
médicaments, les drogues, la réaction face au danger, etc. Ainsi, pour ne pas gêner le conducteur
dans ses manoeuvres, nous devons prendre en compte toutes les situations possibles, même si
certaines peuvent paraître improbables (e.g. tourner à gauche dans un virage sur la droite).
Ce problème a déjà été soulevé et nécessite les résultats d'une étude cognitive menée par d'autres
acteurs du projet ARCOS.
–
aspect temporel. Le but final du logiciel développé est de tourner sur un véhicule en mouvement
et de traiter les données en ligne afin d'enclencher des actions de freinage 0.5 seconde avant la
collision. Pendant le temps de calcul, où nous roulons à l'aveugle, nous devons être capable de
prévoir les trajectoires pour la prochaine phase de calculs et de conserver une durée
incompressible pour le freinage avant la collision (si nécessaire).
Un travail important consiste donc à organiser calculs afin de garantir cette contrainte temps réel
(le temps de calcul doit être inférieur à 0.05 seconde).
Une autre difficulté provient du manque de précision du cahier des charges concernant le produit à
délivrer, les performances attendues, les paramètres mécaniques de la voiture équipée et des
obstacles, le format des images perçues et le type d'informations qu'on peut en extraire ...
3. Résolution
Sommaire :
3.1. Principe de l'approche proposée
7
3.2. Modèle dynamique d'une voiture (LAG)
8
3.3. Modélisation des obstacles
9
3.4. Détection des collisions
10
3.1. Principe de l'approche proposée
L'ensemble des trajectoires possibles du véhicule intelligent à un instant donné étant un ensemble de
dimension infinie, le traitement de toutes les situations possibles ne peut être espéré qu'en trouvant
une solution analytique qui pour l'instant paraît être hors de portée de la communauté robotique. Il
nous reste donc une approche numérique par discrétisation de l'espace des trajectoires possibles.
Nous avons choisi une discrétisation de cet espace en considérant un échantillonnage de l'espace des
commandes du véhicule intelligent et en calculant des trajectoires à commandes constantes par
morceaux. Ensuite, pour une commande donnée, le modèle dynamique du LAG nous fournit la
trajectoire de la voiture afin de construire un tube 3D dont chaque section horizontale correspond au
contour du véhicule à un instant donné, l'axe verticale correspondant au temps. Des tubes
semblables sont construits dans le même repère pour les obstacles, en fonction de l'estimation de
leur mouvement. Des librairies telles que l'OpenGL associées à des cartes graphiques permettent
alors de faire des calculs rapides de collisions entre ces tubes, en utilisant des algorithmes de
détection de collisions basés sur les boîtes englobantes et le calcul de distance entre objets convexes
(JGK ou autres). La sortie de ces algorithmes nous donne pour chaque trajectoire du véhicule, non
seulement l'éventualité de collision, mais aussi l'instant de collision (l'ordonnée des facettes en
collision) et le type de collision (frontale, latérale, etc). Un rapide calcul permet, à partir de l'instant
de collision et de la commande considérée, de trouver la vitesse relative lors de l'impact. Ces
données permettront à un module hiérarchiquement plus élevé de décide si on enclenche le freinage
d'urgence ou pas.
La solution triviale demandée par ARCOS consiste à freiner que si toutes les trajectoires possibles
sont en collision.
Illustration 4 - Les trajectoires-tube du véhicule intelligent et des obstacles.
3.2. Modèle dynamique du LAG
Le coeur de mon stage se situe dans cette partie. Une première version du logiciel développé par,
Denis Jacquet et Michel Verlinden, utilise un modèle cinématique du véhicule : certains
comportements ne sont pas pris en compte comme les éventuels glissements sur la chaussée, les
fluctuations d'adhérence sur la route, le comportement des pneus ou encore l'inertie inhérente à tout
système mécanique. Notre logiciel devant fonctionner pour des vitesses de 50 à 130 km/h, nous
devons prendre en compte ces différents phénomènes pour un réalisme accru et une meilleure
précision afin de ne pas déclencher de fausses alarmes et surtout ne pas en omettre (dans les
situations de tête à queue par exemple). Aussi, notre deuxième version fait le lien avec le modèle
dynamique du Laboratoire d'Automatique de Grenoble, également mis au point dans le cadre du
projet ARCOS.
Ce modèle est obtenu à partir d'une formulation lagrangienne où, pour chaque composant du
véhicule (châssis, caisse, pneus), les énergies cinétiques de rotation et de translation, et l'énergie
potentielle sont prises en compte. Les forces de frottements, entre les pneus et la route, sont
déterminées par le modèle LuGre ([5], [6] et [7]). Nous utilisons une version réduite à 5 degré de
liberté : nous ne considérons pas l'inclinaison de la caisse (angle f).
Nous n'entrerons pas dans les détails de l'obtention du modèle. Pour de plus amples informations,
nous vous renvoyons à la lecture de [2], [3] et [4].
La représentation du véhicule utilise le modèle de la bicyclette :
Illustration 5a - Modèle de la bicyclette (vue de dessus).
Illustration 5b - Modèle de la bicyclette (vue de côté).
La voiture évolue dans le plan 2D muni d'un référentiel absolu (0, x, y, z).
Le vecteur des coordonnées généralisées est q = (x, y, y, qf, qr) où :
– x, y est la position du centre de gravité Gu ,
– y est l'angle entre l'axe principal pointant vers l'avant de la voiture et l'axe des X,
– qf et qr concernent le mouvement angulaire des pneus avant et arrière respectivement.
Le vecteur des commandes est u = (a, tf, tr) avec :
– a l'angle de braquage de la voiture
– tf et tr les couples moteurs avant et arrière respectivement.
En définissant les variables d'état ainsi :
, le modèle s'écrit :
En utilisant la règle d'Euler pour l'intégration numérique, nous obtenons :
x1[t+1] = T x2 + x1[t]
x2[t+1] = T (a0 F1 cos(x5) + a1 F2 sin(x5) + (a2 sin²(x5) + a3) x6² cos(x5) + a4 F3 sin(x5)) + x2[t]
x3[t+1] = T x4 + x3[t]
x4[t+1] = T (a0 F1 sin(x5) - a1 F2 cos(x5) - (a2 cos²(x5) + a3) x6² sin(x5) - a4 F3 cos(x5)) + x4[t]
x5[t+1] = T x6 + x5[t]
x6[t+1] = T (- a4 F2 + a5 sin(x5) cos(x5) + a6 F3) + x6[t]
x7[t+1] = T x8 + x7[t]
x8[t+1] = T (a7 (tf - Fxf r)) + x8[t]
x9[t+1] = T x10 + x9[t]
x10[t+1] = T (a8 (tr - Fxr r)) + x10[t]
Ce système d'équations nous permet de calculer l'ensemble des trajectoires du véhicule considéré :
{ q0, u } avec q0 l'état de la voiture à un instant donné et la commande u = (a, tf, tr) où a appartient
à [-30°, 30°] et tf, tr sont compris entre -4000Nm et 2000Nm
3.3. Représentation des obstacles
Dans l'état actuel du logiciel, les obstacles fixes ou mobiles sont modélisés par des rectangles, des
cercles ou des ellipses. Pour représenter les bordures de route et les voies (ou d'autres obstacles
fixes), nous pouvons également utiliser toutes formes définies par une suite de points.
Nous considérons trois types de mouvements pour les obstacles : vitesse linéaire constante, suite de
n points de passage (x,y,t) avec interpolation polynomiale de degré n-1 pour chaque coordonnée,
aléatoire avec une borne sur l'accélération (pour les piétons par exemple).
Contrairement au véhicule équipé, nous ne considérons pas l'ensemble des trajectoires possibles. En
effet, les informations déduites de la perception des obstacles étant trop pauvres, les mouvements
possibles qui s'en déduisent sont trop imprécis et pas assez sélectifs. Afin que des hypothèses
conservatrices ne nous mettent pas constamment en situation d'alerte et de freinage, nous sommes
bien obligés de nous limiter à une trajectoire vraisemblable pour l'obstacle et de nous limiter à une
propagation de l'incertitude autour de cette trajectoire.
Illustration 6 - Intégration des incertitudes sur l'horizon des temps.
Une méthode consisterait à définir l'encombrement géométrique des obstacles comme une fonction
croissante du temps, ce qui nous fournirait des marges de sécurité. Toutefois, une marge de sécurité
importante détruirait totalement la compacité des trajectoires des obstacles et impliquerait un
nombre élevé de fausses alarmes qui biaiseraient le fonctionnement du détecteur de collision. A
l'inverse, une variation mineure de l'encombrement en fonction du temps conduirait à une faible
utilité de cette méthode. Aussi, nous ne l'avons pas implémentée : le problème reste donc entier.
3.4. Détection des collisions
La détection de collisions est un problème classique qui a été étudié massivement ces dernières
années de par son implication dans de nombreux domaines : robotique et automatique, conception
assistée par ordinateur, chaînes de fabrication, simulation informatique, jeux vidéos, systèmes
haptiques.
Les défis que doivent relever les algorithmes de détection de collisions sont triples :
– rapidité, dans la mesure où ces routines sont appelées très fréquemment et souvent en considérant
des objets complexes;
– précision, car il est inacceptable de manquer des collisions effectives ou d'ajouter des fictives
dans bon nombre d'applications;
– exactitude, (ou au moins fournir une mesure quantifiable des incertitudes) pour assurer le bon
fonctionnement du logiciel considéré.
Actuellement, il existe deux grandes familles :
– les algorithmes s'appliquant aux objets convexes dont GJK et LIN-CANNY qui sont considérés
comme les plus performants;
– les algorithmes hiérarchiques basés sur des boîtes englobantes comme "Axis Aligned Bounding
Boxes" ou "Oriented Bounding Boxes".
Pour notre logiciel, nous utilisons une bibliothèque développé dans l'équipe par Kenneth Sundaraj
( [8], [9], [10], [11] ).
4. Résultats
Sommaire :
4.1. Comportement
11
4.2. Performance
12
4.1. Comportement
Le logiciel développé comporte un moteur 3D d'investigation des collisions qui nous permet de
visualiser la scène considérée.
Ces captures d'écran illustrent trois trajectoires possibles pour une même scène sous deux angles
différents. Les tubes cyan, jaune et magenta représente la trajectoire de la voiture, l'ellipse bleu un
obstacle immobile et le tube orange un obstacle se déplaçant à vitesse linéaire constante (sur la
droite de l'écran). Nous pouvons constater, dans les trois cas, une collision avec l'obstacle fixe.
Il aurait été intéressant de comparer le comportement des modèles cinématiques et dynamiques
notamment dans le cas de dérapages ou de têtes à queue (effectifs mais non pris en compte dans la
première version), mais, du fait de la nature différente des états et des commandes, nous n'avons
pas pu mettre au point cette étude comparative.
4.1. Performance
Pour évaluer les performances des deux versions développées, modèle cinématique et modèle
dynamique, nous avons utilisé un programme n'utilisant que la fonction permettant de calculer, à
partir d'un état donné et d'une commande, l'état suivant de la voiture.
Pour ne pas avantager ou défavoriser l'une ou l'autre méthode en tombant dans des cas particuliers,
nous avons effectué un grand nombre de calculs en utilisant des commandes aléatoires, contenues
dans les bornes minimale et maximale.
Les tests ont été effectuées sur la même machine (PC sous Windows XP SP2), dans les mêmes
conditions (charge dédiée au repos de 267Mo) et en plusieurs passes (5). Les résultats ont été
synthétisés dans le tableau suivant :
Modèle Cinématique
Modèle Dynamique
Nombre de
calculs
Durée
Mémoire
utilisée
Charge
dédiée
Durée
Mémoire
utilisée
Charge
dédiée
100000
4
96Mo
365Mo
4
788Ko
269Mo
500000
19
390Mo
755Mo
18
788Ko
269Mo
1000000
45
390Mo
1.2Go
35
788Ko
269Mo
1500000
69
404Mo
1.82Go
54
788Ko
269Mo
2000000
crash
crash
>2Go
73
788Ko
269Mo
Au vue des données, deux remarques s'imposent :
–
l'utilisation mémoire est constante quelque soit le nombre de calculs avec le modèle dynamique
alors qu'elle croit excessivement dans le cas du modèle cinématique, au point de planter le
système. L'utilisation de la bibliothèque GSL pour les intégrations numériques en est
vraisemblablement la cause.
–
la durée de calcul est comparable. La différence de temps qui apparaît dans les calculs importants
est probablement dû à l'utilisation du swap (environ 60 fois plus lent que la RAM), puisqu'elle
n'est pas visible pour les petits calculs.
Toutefois, il faut bien noter que ces chiffres ne sont fournis qu'à titre indicatif puisque les modèles
sont très différents : les états et les commandes du véhicule ne sont pas semblables, les glissements
ne sont pas pris en compte dans le modèle cinématique. De plus, l'intégration numérique utilisée par
le modèle cinématique est la méthode de Runge-Kutta Prince-Dormand (au huitième ordre avec une
estimation de l'erreur au neuvième ordre) alors que nous utilisons la règle d'Euler.
5. Conclusion et perspectives
Sommaire :
5.1. Conclusion
13
5.2. Perspectives
13
5.1. Conclusion
Nous avons présenté dans ce rapport un atténuateur de collisions pour contexte automobile dont le
but est de déclencher un freinage d'urgence si un accident s'avère inévitable.
Faisant suite aux travaux déjà réalisés dans le cadre d'ARCOS, le logiciel mis au point incorpore
désormais le modèle dynamique du LAG pour la prédiction des trajectoires du véhicule équipé.
Ainsi, nous sommes capables de prendre en compte les glissements et les têtes à queue qui peuvent
survenir dans certaines conditions (pluie, vitesse trop élevée dans un virage serré, etc), tout en
conservant des temps de calculs équivalant à la première version développée utilisant un modèle
cinématique.
5.2. Perspectives
Une étude approfondie sur la répartition de notre temps de calculs reste encore à mener.
En effet, un facteur déterminant sur la rapidité et la complexité de notre algorithme est le choix de
nos différentes discrétisations, qui sont au nombre de trois :
–
la discrétisation de l'espace des commandes : à chaque point correspond un bout de trajectoire
donné par cette commande constante;
–
le pas d'intégration temporelle : utilisé pour intégrer les équations différentielles du système et
donnant aussi la discrétisation des tubes-trajectoires;
–
le nombre de morceaux des trajectoires à commande constante par morceaux ; qui a un effet
exponentiel sur le nombre de commandes discrètes données par la première discrétisation.
Pour respecter les contraintes de temps-réel, nous serons amenés à mettre au point une procédure de
choix de nos discrétisations en fonction du contexte. Par exemple, à grande vitesse, nous pourrions
choisir un pas d'intégration plus faible (donc plus pénalisant) mais diminuer la finesse des deux
autres discrétisations (à grande vitesse et avec un pas d'intégration très faible, les commandes
entraîneront peu de variations relatives sur les vitesses et donc sur les trajectoires).
Pour diminuer encore les temps de calculs, quelques améliorations sont également envisageables :
optimiser les calculs utilisant les fonctions trigonométriques (gourmandes en ressources), mieux
gérer la mémoire en éliminant périodiquement les données qui ne sont plus utilisées, ne plus utiliser
de classes <Template> dans le code C++, ...
Références
[1]
Denis Jacquet,
"Détection de collision et action automatique pour transport routier",
Projet ARCOS, mars 2003.
[2]
Juan-Carlos Avila-Vilchis, John-Jairo Martinez-Molina et Carlos Canudas-de-Wit,
"A new bycicle model with 3D dynamic tire/road friction forces",
Projet ARCOS, avril 2003.
[3]
Juan-Carlos Avila-Vilchis et Carlos Canudas-de-Wit,
"Vehicule trajectory predictor with 3D dynamic tire/road friction forces",
Projet ARCOS.
[4]
Juan-Carlos Avila-Vilchis, John-Jairo Martinez-Molina et Carlos Canudas-de-Wit,
"A new bycicle model with dynamic contact friction",
IFAC Automotive Control, 2004.
[5]
Canudas-de-Wit C. et Tsiotras P.,
"Dynamic tire friction models for vehicule traction control",
38th IEEE Conference on Decision and Control, 1999.
[6]
Canudas-de-Wit C., Tsiotras P., Velenis E., Basset M. et Gissinger G.,
"Dynamic friction models for road/tire longitudinal interaction",
Vehicule System Dynamics
[7]
Velenis E., Canudas-de-Wit C. et Tsiotras P.,
"Extension of the LuGre dynamic friction model to 2D motion",
Document interne du LAG, 2001
[8]
K. Sundaraj,
"Détection et traitement de collision en simulation dynamique",
Mémoire DEA, INPG, Juin 2000.
[9]
K. Sundaraj, C. Laugier.
"Fast contact localisation of moving deformable polyhedras",
Proc. of the Int. Conf. on Control, Automation, Robotics and Vision, Décembre 2000.
[10]
K. Sundaraj, D. d'Aulignac, E. Mazer.
"A new algorithm for computing minimum distance",
Proc. of the IEEE-RSJ Int. Conf. on Intelligent Robots and Systems, Novembre 2000.
[11]
R. Rodriguez.
"Détection de collision et localisation de contact des polyèdres déformables en temps-réel
dans un environnement virtuel",
Mémoire DEA, INPG, Juin 2003.
Annexes
Configuration utilisée pour les tests :
Carte mère ABIT IS7-E (BIOS i865PE-W83627-6A79AA1BC-22, 16/08/2204)
Processeur INTEL P4 2.6C (13*200)
RAM 2*256 Mo DDR400, timings 2-2-2-5, ratio 1:1
Carte graphique ATI Radeon 9700 (core à 300 MHz, mémoire à 570 MHz)
Disque dur Hitashi 180GXP 120Go (8 Mo cache)
Windows XP Home SP2
MSYS 1.0.10, MINGW32 3.1.0-1, GSL 1.5