Communication Inter Véhicules : Echange d'informations entre véhicules

Contexte

La sécurité automobile occupe une grande part du développement d'un véhicule, le défi est de mettre tout en oeuvre pour que l'accident ne survienne jamais. C'est dans ce cadre que le projet de Communication Inter Véhicule a été développé. En effet, Si chaque véhicule envoyait son état ainsi que sa position aux véhicules aux alentours, on serait en mesure d'avertir un conducteur si un véhicule ayant un état dangereux pour lui est proche de lui. C'est ce que nous avons fait.

L'équipe EcarTeam disposant d'un prototype, le système y a été intégré.

Architecture matérielle

Chaque véhicule est équipé d'un PC embarqué pour le traitement. Ce PC est connecté à un boitier USB/CAN permettant de récupérer les informations des phares. Au tableau de bord, un Pocket PC permet de récupérer les informations GPS mais également d'afficher les alertes au conducteur.

Voici l'architecture matérielle retenue à bord de chaque véhicule :

Source d'informations

Avant de pouvoir envoyer des informations il faut les récolter. Pour cela nous avons actuellement deux modules d'acquisition de données. Le premier vient du PDA sur le tableau de bord qui permet d'obtenir des informations GPS. Le second vient du bus CAN relié aux modules des phares qui nous renseigne sur l'état de ces derniers.

Capteur GPS

Nous équipons le véhicule d'un GPS (intégré dans un Pocket PC), ce GPS nous permet de connaître à chaque instant la position du véhicule, sa vitesse, ainsi que son cap (l'angle que forme sa trajectoire avec le Nord)

Le GPS utilisé est un AGPS, c'est-à-dire qu'il utilise des positions fixe sur terre pour se repérer plus rapidement, et obtenir une meilleur précision (8 chiffres après la virgule contre 6 pour un GPS plus classique).

Nous sommes conscient que le GPS ne peut pas suffire à repérer un véhicule par rapport à un autre surtout dans les zones d'ombres, (foret, tunnel, agglomération (avec de grand immeubles), mais cette solution est abordable et nous permet d'avoir un bon aperçu du fonctionnement.

C'est le Pocket PC au niveau du tableau de bord qui va récupérer les informations GPS et les envoyer à travers le réseau intra véhicule à l'application de traitement qui tourne sur le PC embarqué.

Les données GPS sont récupérées via un port série. Voici un exemple de trame que nous recevons :

$GPRMC,141501.000,A,4837.4075,N,00214.8968,E,48.08,240.41,060609,,,A*56

Et voici comment nous la formatons pour l'envoyer :

1;2,248280;48,6234583;89,23;240,41;1

Ce format est plus réduit et contient les informations necessaire au bon fonctionnement de l'application.

Cette application a été codée en Visual Basic .NET pour Windows Mobile de façon à fonctionner sur un PDA. Les messages sont envoyés en Multicast UDP au sein du prototype.

Phares (Bus CAN)

L'état des phares est communiqué par le bus CAN reliant les modules des phares au PC interne au véhicule.

a) Développement Logiciel

L'application d'acquisition et d'envoi des informations des phares est écrite en C/C++. Elle est constituée de deux parties : la lecture du bus CAN et l'envoi en multicast. La lecture du bus CAN provient en grande partie du projet TouchCar réalisé précédemment par des étudiants. Le code d'origine a été légèrement modifié pour s'adapter aux spécificités de l'application CIV.

L'acquisition des données se fait par l'appel d'une fonction qui décode une trame du bus CAN contenant les données des phares. Le premier tri définit le module d'où provient l'information avant de spécifier les différents phares ou clignotants. Les informations reçues sont enregistrées dans une table qui servira à construire la trame d'envoi multicast. Une fois le tableau rempli, on effectue l'envoie en multicast.

La partie concernant l'envoi en multicast consiste à envoyer une trame sous la forme d'une chaine de caractères au multicast privé du véhicule. La chaine de caractère est une suite d'entiers séparés par un « ; ». Une fois la trame créée elle est envoyée et le tableau de données des phares est vidé.

b) Le bus CAN de E²

L'application CIV utilise les spécificités d'E² pour la récupération de l'état des phares. Le bus CAN relie les quatre modules de phares au PC interne situé à l'arrière d'E².

c) le boitier USB CAN

Les informations en provenance du bus CAN sont accessibles par le PC du véhicule par un boitier USB CAN qui assure le lien direct CAN - PC. Les données des phares contenues dans le bus CAN sont lisibles sous la forme d'une suite d'octets en hexadécimal.

               d) Mise en forme des informations
La trame envoyée sous la forme d'une chaine de caractère est structurée de la manière suivante :
          - 1 entier pour l'identifiant du message
          - 1 entier pour l'état de la batterie
          - 4 entiers pour l'état des fusibles des 4 différents modules
          - 4 entiers pour l'état des phares du module avant-gauche (clignotant, feu de position, feu de croisement, feu de route)
          - 4 entiers pour l'état des phares du module avant-droit (clignotant, feu de position, feu de croisement, feu de route)
          - 4 entiers pour l'état des phares du module arrière-gauche (clignotant, feu de position, feu stop, feu de recul)
          - 4 entiers pour l'état des phares du module arrière-droit (clignotant, feu de position, feu stop, feu de recul)
          - 1 entier pour l'état des warnings

Exemple de trame envoyée :

2;1;1;2;1;1;1;1;1;1;9;9;9;9;1;1;2;1;1;1;1;1;1

Le 2 en position 4 indique que le module avant-droit est cassé ce qui explique la série des quatre 9 un peu plus loin.
Le 2 en position 17 indique un défaut de feu stop arrière-gauche.

Application de traitement

Tous les traitements importants sont réalisés sur le PC embarqué.

Nous avons fais ce choix par rapport à la puissance de calcul du PC face à celle du Pocket PC, mais également par le fait que nous voulions au sein du véhicule que toutes les connexions soient câblées : pas de wifi, et pas de Bluetooth.

Cette application de traitement est très sommaire, en effet, elle n'a pas vocation à être montrée, seule l'application sur le Pocket PC doit être montrée au conducteur, en ce sens, l'application de traitement comporte de nombreuses fenêtres permettant d'observer ce qui passe par cette application, ce qui entre, ce qui en est déduit, et ce qui est renvoyé.

Son fonctionnement est le suivant :
          - Dès qu'un message provenant d'un capteur est reçu, il est identifié par son préfixe, et stocké en mémoire (2 capteur, donc 2 zones de stockage différentes)
          - Dès que l'application reçois des données GPS valide, elle commence à émettre des informations avec un état du véhicule « inconnu » ceci permet de traiter les cas d'informations si un véhicule roule moins vite, ou plus vite que son véhicule.
          - A la réception d'information d'état des phares, on opère une factorisation des informations, en effet, chaque véhicule n'a pas besoin de connaître l'état de tous les phares de toutes les voitures, c'est pourquoi, nous avons réunis tous les clignotants ensemble, {les feux de croisement et de position}, les {2 feux de route}, {les 2 feux arrière}, {les 2 feux stop} et {les 2 feux de recul}.
          - Nous créons un message à envoyer par multicast Inter Véhicule. Ce message est formaté de la sorte :

E2;2;1;0;48,12345567;4,1234565432;37;153;;;;3;3;3;2;2;2;2

Nous avons laissés volontairement de la place à la fin des données GPS, cela pourrait nous permettre d'ajouter l'heure, ou bien l'altitude (dans des perspectives d'améliorations)

- Cette trame est ensuite envoyée, sous forme de ligne de chaine de caractère en multicast Inter Véhicule. (TTL >0)
- Lors de l'envoie d'une trame, si un problème technique est détecté, c'est-à-dire que l'état du véhicule est mauvais, alors on envoie directement un message à l'affichage sur le PDA. On verra plus loin comment ce message est formaté.

L'application de traitement reçoit également des messages provenant d'autres véhicules. C'est à ce moment que le calcul est le plus important : on repère un véhicule par rapport à un autre grâce à un algorithme de positionnement relatif utilisant les données de positionnement et de cap de chaque véhicule.

Une fois le positionnement relatif effectué, si le véhicule est devant, derrière ou en face de nous, il peut nous intéresser, (cela dépend de son état), sinon, il n'est pas intéressant pour notre véhicule. On attend la trame suivante.

Voici les cas qui peuvent être intéressant :
          - Le véhicule est devant nous, sont état :
               • Avertissement :
                    - Feux de détresse
                    - Défaut de clignotant
                    - Défaut de feux arrière
                    - Défaut de feux stop
                    - Défaut de feux de recul
               • Information :
                    - Le véhicule devant roule moins vite
          - Le véhicule est derrière nous, sont état :
               • Avertissement :
                    - Défaut de clignotant
                    - Défaut de feux de croisement
                    - Défaut de feux de route
               • Information :
                    - Le véhicule devant roule plus vite
          - Le véhicule est en face de nous, sont état :
               • Avertissement :
                    - Défaut de clignotant
                    - Défaut de feux de croisement
                    - Défaut de feux de route

Si l'on est dans un de ces cas, alors un message est généré pour être envoyé à l'affichage sur le Pocket PC. (Nous verrons plus loin comment est envoyé le message et comment ce message est formaté)

Application d'affichage (Pocket PC)

Le Pocket PC sert également d'afficheur au tableau de bord. En effet, sa puissance de calcul n'étant pas suffisante pour supporter tous les calculs nous avons décidé de l'utiliser comme simple afficheur (en plus du capteur GPS).

Cette application, c'est un récepteur de message multicast.
Voici comment est formaté un message destiné à l'affichage :

8;2;1;2;18

Le message est préfixé de 8 : en effet ce message circule sur le multicast privé, à bord du véhicule, c'est le même réseau que celui des capteurs, il faut donc préfixer le message afin qu'il soit traité comme message d'affichage.

Les messages destinés à l'affichage sont également prononcé grâce à des voix préenregistrées, ce qui permet de former des messages cohérents, destiné au conducteur.

Système de communication

Afin de faire communiquer les véhicules il nous fallait un système facile à mettre en place et viable en extérieur. Nous avons opté pour le Wifi car il présente l'avantage de se configurer facilement et utilise une structure de réseau facilement configurable avec de simples sockets. Le Wifi a une portée d'à peu près 400 m de rayons d'après les tests en extérieur avec des routeurs Linksys WRT54GL. L'avantage du Wifi est également qu'un véhicule à porté peut se greffer au réseau facilement ce qui nous permet en théorie de n'envoyer les trames de notre propre véhicule qu'aux autres véhicules distants de moins de 500 m.

Malheureusement le Wifi pose un problème de taille lorsque l'on commence à aborder la question du déplacement. En effet si cette solution est viable en statique, elle commence à poser de sérieux problèmes lorsque la différence de vitesse entre les deux véhicules dépasse 60 km/h en raison de l'effet Doppler. Conscient de ce problème nous n'avons pour le moment pas trouvé d'autre solution.


	• Accueil > Applications > Communication Inter Véhicules Communication Inter Véhicules Communication d'informations d'état de véhicule à véhicule pour plus de sécurité Contexte La sécurité automobile occupe une grande part du développement d'un véhicule, le défi est de mettre tout en oeuvre pour que l'accident ne survienne jamais. C'est dans ce cadre que le projet de Communication Inter Véhicule a été développé. En effet, Si chaque véhicule envoyait son état ainsi que sa position aux véhicules aux alentours, on serait en mesure d'avertir un conducteur si un véhicule ayant un état dangereux pour lui est proche de lui. C'est ce que nous avons fait. L'équipe EcarTeam disposant d'un prototype, le système y a été intégré. Architecture matérielle Chaque véhicule est équipé d'un PC embarqué pour le traitement. Ce PC est connecté à un boitier USB/CAN permettant de récupérer les informations des phares. Au tableau de bord, un Pocket PC permet de récupérer les informations GPS mais également d'afficher les alertes au conducteur. Voici l'architecture matérielle retenue à bord de chaque véhicule : Source d'informations Avant de pouvoir envoyer des informations il faut les récolter. Pour cela nous avons actuellement deux modules d'acquisition de données. Le premier vient du PDA sur le tableau de bord qui permet d'obtenir des informations GPS. Le second vient du bus CAN relié aux modules des phares qui nous renseigne sur l'état de ces derniers. Capteur GPS Nous équipons le véhicule d'un GPS (intégré dans un Pocket PC), ce GPS nous permet de connaître à chaque instant la position du véhicule, sa vitesse, ainsi que son cap (l'angle que forme sa trajectoire avec le Nord) Le GPS utilisé est un AGPS, c'est-à-dire qu'il utilise des positions fixe sur terre pour se repérer plus rapidement, et obtenir une meilleur précision (8 chiffres après la virgule contre 6 pour un GPS plus classique). Nous sommes conscient que le GPS ne peut pas suffire à repérer un véhicule par rapport à un autre surtout dans les zones d'ombres, (foret, tunnel, agglomération (avec de grand immeubles), mais cette solution est abordable et nous permet d'avoir un bon aperçu du fonctionnement. C'est le Pocket PC au niveau du tableau de bord qui va récupérer les informations GPS et les envoyer à travers le réseau intra véhicule à l'application de traitement qui tourne sur le PC embarqué. Les données GPS sont récupérées via un port série. Voici un exemple de trame que nous recevons : $GPRMC,141501.000,A,4837.4075,N,00214.8968,E,48.08,240.41,060609,,,A56 Et voici comment nous la formatons pour l'envoyer : 1;2,248280;48,6234583;89,23;240,41;1 Ce format est plus réduit et contient les informations necessaire au bon fonctionnement de l'application. Cette application a été codée en Visual Basic .NET pour Windows Mobile de façon à fonctionner sur un PDA. Les messages sont envoyés en Multicast UDP au sein du prototype. Phares (Bus CAN) L'état des phares est communiqué par le bus CAN reliant les modules des phares au PC interne au véhicule. a) Développement Logiciel* L'application d'acquisition et d'envoi des informations des phares est écrite en C/C++. Elle est constituée de deux parties : la lecture du bus CAN et l'envoi en multicast. La lecture du bus CAN provient en grande partie du projet TouchCar réalisé précédemment par des étudiants. Le code d'origine a été légèrement modifié pour s'adapter aux spécificités de l'application CIV. L'acquisition des données se fait par l'appel d'une fonction qui décode une trame du bus CAN contenant les données des phares. Le premier tri définit le module d'où provient l'information avant de spécifier les différents phares ou clignotants. Les informations reçues sont enregistrées dans une table qui servira à construire la trame d'envoi multicast. Une fois le tableau rempli, on effectue l'envoie en multicast. La partie concernant l'envoi en multicast consiste à envoyer une trame sous la forme d'une chaine de caractères au multicast privé du véhicule. La chaine de caractère est une suite d'entiers séparés par un « ; ». Une fois la trame créée elle est envoyée et le tableau de données des phares est vidé. b) Le bus CAN de E² L'application CIV utilise les spécificités d'E² pour la récupération de l'état des phares. Le bus CAN relie les quatre modules de phares au PC interne situé à l'arrière d'E². c) le boitier USB CAN Les informations en provenance du bus CAN sont accessibles par le PC du véhicule par un boitier USB CAN qui assure le lien direct CAN - PC. Les données des phares contenues dans le bus CAN sont lisibles sous la forme d'une suite d'octets en hexadécimal. d) Mise en forme des informations La trame envoyée sous la forme d'une chaine de caractère est structurée de la manière suivante : - 1 entier pour l'identifiant du message - 1 entier pour l'état de la batterie - 4 entiers pour l'état des fusibles des 4 différents modules - 4 entiers pour l'état des phares du module avant-gauche (clignotant, feu de position, feu de croisement, feu de route) - 4 entiers pour l'état des phares du module avant-droit (clignotant, feu de position, feu de croisement, feu de route) - 4 entiers pour l'état des phares du module arrière-gauche (clignotant, feu de position, feu stop, feu de recul) - 4 entiers pour l'état des phares du module arrière-droit (clignotant, feu de position, feu stop, feu de recul) - 1 entier pour l'état des warnings Exemple de trame envoyée : 2;1;1;2;1;1;1;1;1;1;9;9;9;9;1;1;2;1;1;1;1;1;1 Le 2 en position 4 indique que le module avant-droit est cassé ce qui explique la série des quatre 9 un peu plus loin. Le 2 en position 17 indique un défaut de feu stop arrière-gauche. Application de traitement Tous les traitements importants sont réalisés sur le PC embarqué. Nous avons fais ce choix par rapport à la puissance de calcul du PC face à celle du Pocket PC, mais également par le fait que nous voulions au sein du véhicule que toutes les connexions soient câblées : pas de wifi, et pas de Bluetooth. Cette application de traitement est très sommaire, en effet, elle n'a pas vocation à être montrée, seule l'application sur le Pocket PC doit être montrée au conducteur, en ce sens, l'application de traitement comporte de nombreuses fenêtres permettant d'observer ce qui passe par cette application, ce qui entre, ce qui en est déduit, et ce qui est renvoyé. Son fonctionnement est le suivant : - Dès qu'un message provenant d'un capteur est reçu, il est identifié par son préfixe, et stocké en mémoire (2 capteur, donc 2 zones de stockage différentes) - Dès que l'application reçois des données GPS valide, elle commence à émettre des informations avec un état du véhicule « inconnu » ceci permet de traiter les cas d'informations si un véhicule roule moins vite, ou plus vite que son véhicule. - A la réception d'information d'état des phares, on opère une factorisation des informations, en effet, chaque véhicule n'a pas besoin de connaître l'état de tous les phares de toutes les voitures, c'est pourquoi, nous avons réunis tous les clignotants ensemble, {les feux de croisement et de position}, les {2 feux de route}, {les 2 feux arrière}, {les 2 feux stop} et {les 2 feux de recul}. - Nous créons un message à envoyer par multicast Inter Véhicule. Ce message est formaté de la sorte : E2;2;1;0;48,12345567;4,1234565432;37;153;;;;3;3;3;2;2;2;2 Nous avons laissés volontairement de la place à la fin des données GPS, cela pourrait nous permettre d'ajouter l'heure, ou bien l'altitude (dans des perspectives d'améliorations) - Cette trame est ensuite envoyée, sous forme de ligne de chaine de caractère en multicast Inter Véhicule. (TTL >0) - Lors de l'envoie d'une trame, si un problème technique est détecté, c'est-à-dire que l'état du véhicule est mauvais, alors on envoie directement un message à l'affichage sur le PDA. On verra plus loin comment ce message est formaté. L'application de traitement reçoit également des messages provenant d'autres véhicules. C'est à ce moment que le calcul est le plus important : on repère un véhicule par rapport à un autre grâce à un algorithme de positionnement relatif utilisant les données de positionnement et de cap de chaque véhicule. Une fois le positionnement relatif effectué, si le véhicule est devant, derrière ou en face de nous, il peut nous intéresser, (cela dépend de son état), sinon, il n'est pas intéressant pour notre véhicule. On attend la trame suivante. Voici les cas qui peuvent être intéressant : - Le véhicule est devant nous, sont état : • Avertissement : - Feux de détresse - Défaut de clignotant - Défaut de feux arrière - Défaut de feux stop - Défaut de feux de recul • Information : - Le véhicule devant roule moins vite - Le véhicule est derrière nous, sont état : • Avertissement : - Défaut de clignotant - Défaut de feux de croisement - Défaut de feux de route • Information : - Le véhicule devant roule plus vite - Le véhicule est en face de nous, sont état : • Avertissement : - Défaut de clignotant - Défaut de feux de croisement - Défaut de feux de route Si l'on est dans un de ces cas, alors un message est généré pour être envoyé à l'affichage sur le Pocket PC. (Nous verrons plus loin comment est envoyé le message et comment ce message est formaté) Application d'affichage (Pocket PC) Le Pocket PC sert également d'afficheur au tableau de bord. En effet, sa puissance de calcul n'étant pas suffisante pour supporter tous les calculs nous avons décidé de l'utiliser comme simple afficheur (en plus du capteur GPS). Cette application, c'est un récepteur de message multicast. Voici comment est formaté un message destiné à l'affichage : 8;2;1;2;18 Le message est préfixé de 8 : en effet ce message circule sur le multicast privé, à bord du véhicule, c'est le même réseau que celui des capteurs, il faut donc préfixer le message afin qu'il soit traité comme message d'affichage. Les messages destinés à l'affichage sont également prononcé grâce à des voix préenregistrées, ce qui permet de former des messages cohérents, destiné au conducteur. Système de communication Afin de faire communiquer les véhicules il nous fallait un système facile à mettre en place et viable en extérieur. Nous avons opté pour le Wifi car il présente l'avantage de se configurer facilement et utilise une structure de réseau facilement configurable avec de simples sockets. Le Wifi a une portée d'à peu près 400 m de rayons d'après les tests en extérieur avec des routeurs Linksys WRT54GL. L'avantage du Wifi est également qu'un véhicule à porté peut se greffer au réseau facilement ce qui nous permet en théorie de n'envoyer les trames de notre propre véhicule qu'aux autres véhicules distants de moins de 500 m. Malheureusement le Wifi pose un problème de taille lorsque l'on commence à aborder la question du déplacement. En effet si cette solution est viable en statique, elle commence à poser de sérieux problèmes lorsque la différence de vitesse entre les deux véhicules dépasse 60 km/h en raison de l'effet Doppler. Conscient de ce problème nous n'avons pour le moment pas trouvé d'autre solution.