Voiture autonome : Différence entre versions

De fablab
Aller à : navigation, rechercher
Ligne 6 : Ligne 6 :
 
* '''Contact:''' [mailto:stephane.mancini@univ-grenoble-alpes.fr Stéphane Mancini]
 
* '''Contact:''' [mailto:stephane.mancini@univ-grenoble-alpes.fr Stéphane Mancini]
  
== Contexe ==
+
== Contexte ==
 
=== La NXP Cup ===
 
=== La NXP Cup ===
  
Ligne 91 : Ligne 91 :
  
 
Nous avons conscience de ces limites mais elles ne sont en aucun cas contraignantes pour la course : personne ne va venir cacher la caméra dans ses mains pendant un virage !
 
Nous avons conscience de ces limites mais elles ne sont en aucun cas contraignantes pour la course : personne ne va venir cacher la caméra dans ses mains pendant un virage !
 +
 +
== Simulation de la voiture ==
 +
 +
En vue de la crise sanitaire de l’année 2020 et à cause du confinement il a été impossible pour nous de continuer à travailler avec la voiture et de participer à la coupe NXP qui a été reportée.
 +
Une idée pour continuer le projet chez nous a été de simuler la voiture en python.
 +
 +
=== Le modèle de la simulation ===
 +
Pour ne pas à devoir programmer un environnement de simulation complet pour la voiture, nous avons préféré réécrire une partie commande pour la voiture (coté simulation) et de ne garder que certains éléments indispensables de la partie opérative.
 +
 +
Ainsi de toute la partie commande, nous n’avons gardé que la tâche qui s’occupe de la détection des piques et du “steering” (contrôle des roues).
 +
 +
Pour le modèle de la voiture, nous avons fait les hypothèses suivantes :
 +
* La voiture se déplace à vitesse constante en ligne droite (i.e en ligne droite, les deux roues arrière ont la même vitesse angulaire), de même dans les virages
 +
* La période d’acquisition de la caméra est la même période que le “pas-de-temps” de la simulation
 +
 +
Lors d’un pas de temps de la simulation, on effectue les taches suivantes à la suite :
 +
* Acquisition de la caméra
 +
* Envoie des données au programme C et calculs des bords
 +
* Mise à jour du steering en fonction des bords détectés
 +
* Faire avancer la voiture de v * δt
 +
 +
[[Fichier:speedzone.gif]]
 +
 +
=== Limites du modèle ===
 +
==== Vérification par rapport à la réalité ====
 +
Finalement nous arrivons à un résultat convenable, mais sans la voiture à portée de main, il a été difficile de vérifier la simulation par rapport à la réalité. Par exemple la maniabilité de la voiture ou sa vitesse.
 +
 +
==== L’acquisition de la caméra ====
 +
Une grosse approximation a été faite sur l’image capturée sur la voiture, en effet l’allure de l’acquisition de la caméra est extrêmement simplifiée.
 +
En effet la piste est subdivisée en 3 parties : l’extérieur de la piste, l’intérieur, et les bandes noires. L’acquisition de la caméra se fait alors uniquement sur ces 3 valeurs.
 +
Or comme expliqué précédemment, notamment dans la partie de l’hystérésis, la grande difficulté de ce projet a été la gestion de la variance de la luminosité de la piste.
 +
Cette simulation permet alors, en estimant une piste théorique, de tester les algorithmes de détection des bords de la piste et des bandes noires plus généralement (notamment pour l’épreuve optionnelle « Speed Zone ») mais ne prend pas en compté l’aléatoire que la luminosité apporte.
 +
 +
==== Pas de temps de la simulation ====
 +
On sait que en réalité la fréquence d’acquisition de la caméra est de 50mHz, nous avons alors fixé le pas de temps de la simulation à cette fréquence.
 +
Comme expliqué ci-dessus, lors d’un pas de temps, on fait avancer la voiture en fonction de ce δt entre deux acquisitions de la caméra.
 +
Or en réalité, la voiture va bien sûr continuer d’avancer entre deux acquisitions de la caméra.
 +
Finalement le pas de temps peut grandement affecter la simulation comme dans l’exemple qui suit.
 +
 +
=== Améliorations ===
 +
Peu d’attention ont été mises sur les performances du programme car la priorité était d’avoir un environnement de simulation utilisable le plus tôt possible pour travailler sur le programme de détection des bords de la voiture.
 +
Par exemple on génère à nouveau la piste chaque fois qu’on lance la simulation, cette génération peut prendre plus ou moins de temps car il faut faire de nombreux calculs notamment pour les panneaux de virages, et ceci dans un tableau représentant la piste à grande dimension pour plus de précision.
 +
 +
Comme mentionné dans les limites de la simulation on pourra également redéfinir les paramètres pour mieux correspondre à la réalité : les paramètres pour l’instant utilisés sont ceux qui donnaient de meilleurs résultats par rapport à nos expériences lorsque nous travaillons encore avec la voiture.
 +
 +
Pour l’instant on peut simuler l’épreuve principale ainsi que les épreuves optionnelles du 8 et de la « Speed zone ». La gestion des obstacles n’est pas encore implémentée, elle pourrait l’être plus simplement en connaissant empiriquement le comportement de la caméra en présence d’un tel obstacle (partie des bandes obstrues…).

Version du 18 mai 2020 à 16:40

La coupe NXP de voitures autonome se déroule tous les ans se déroule en trois étapes : qualification pour la coupe "Europe", qualification pour la coupe "Monde" et finale "Monde". L'objectif est de concevoir le logiciel d'une voiture autonome, équipée de différents capteurs et d'une caméra, pour qu'elle effectue différents types de parcours sur une piste. L'épreuve reine est un contre la montre sur une piste d'une trentaine de mètres, avec virages, croisements et chicanes, et elle est complétée de différentes épreuves optionnelles (détection d'obstacles, etc...). Ce projet fablab consiste à compléter des équipes multidisciplinaires ENSIMAG/Phelma/E3 pour envoyer 3 voitures aux qualifications pour la coupe "Europe" et qu'une voiture Grenoble-INP arrive à concourir en finale. Les compétences sont en robotique, traitement d'image, temps-réel, logiciel embarqué et contrôle-commande.

Contexte

La NXP Cup

Présentation Générale

La NXP Cup est une compétition de voiture autonome organisée par l'entreprise NXP pour des étudiants allant du lycée au études supérieures (IUT, license, master, école d'ingénieure).

Cette compétition se déroule en deux temps :

  • Les phases de qualifications qui se déroulent dans différents lieux en Europe (dans notre cas à Toulouse)
  • La finale, à Bucarest en Roumanie, sur le campus NXP.

Afin de pouvoir participer à la finale il faut être dans les quatres premières équipes lors des phases de qualification.

But de la compétition

Afin de se qualifier à la finale il faut marquer le plus de points lors des phases de qualifications pour ensuite arriver premier lors de la finale.

Afin de remplir ces objectifs, les participants doivent réaliser un voiture autonomes avec la seule contrainte (pour l'édition 2019-2020 du moins) d'avoir une processeur NXP comme processeur principal.

L'environnement dans lequel va évoluer la voiture est un circuit composé de différents modules de couleur blanche de 55cm de large avec deux bandes noires de 5cm de large sur les bords.

Les épreuves

Les différentes épreuves auqelles sont confrontés les équipes sont :

  • Une épreuve principale  : la Timed race (course contre la montre). Le but et faire un tour d'un circuit (voir photo ci-contre) dont le tracé est inconnu le plus rapidement.
  • Quatre épreuves optionnellles  :
    • Le 8 : faire le plus de tours possibles en 90 secondes sur une piste en formes de 8 (voir images ci-contre)
    • Le freinage d'urgence : Faire deux tour d'un circuit ovale puis s'arrêter avant de toucher un obstable déposer sur la piste (voir image ci-contre)
    •  L' évitement d'obstacle : Éviter un cube blanc poser à un endroit aléatoire sur un piste ovoide.
    • Le contrôle de vitesse :


Un temps d'intégration automatique

Le temps d'intégration

À quoi ça sert ?

Le temps d'intégration correspond à la durée d'exposition du capteur. Plus ce temps est grand, et plus le capteur est exposé à la lumière : l'arrivée de photons crée des charges qui s'accumulent au sein des photo-sites. En réglant ce temps d'intégration, il est possible de modifier la luminosité de l'image acquise.

 Pourquoi est-il important ?

Le temps d'intégration est un critère très important pour nous, car la voiture et notre code dépendent entièrement de l'image acquise par la caméra pour se déplacer correctement :

  • Un temps d'intégration trop petit par rapport à la luminosité de la pièce, et notre image sera trop sombre.
  • Un temps d'intégration trop élevé, et notre image sera saturée dans les blancs.

Dans les deux cas, impossible de distinguer les bandes noires nous permettant de rester sur la piste.

Pourquoi vouloir l'automatiser ?

Nous souhaitions l'automatiser car ce réglage a déjà posé problème lors de la dernière NXP Cup, et ce pour plusieurs raisons :

  • Le réglage manuel du temps d'intégration est fastidieux. Nous devons connecter la voiture à un ordinateur, observer les valeurs des points acquis pour s'assurer qu'ils ne soient à leur valeur de saturation, tout en vérifiant que la voiture est disposée dans un milieu représentatif de la luminosité ambiante du circuit.
  • Une fois réglé, il était impossible de le modifier au cours de la course. Une luminosité plus grande que prévue, un reflet sur un tronçon ou autres, et notre voiture autonome aveugle promettait une magnifique sortie de piste.
  • Quelque soit la rigueur de la personne qui règle le paramètre du temps d'intégration, un programme automatique fera toujours mieux, et sans erreurs.

Principe derrière l'automatisation

Principe général

Le réglage automatique est géré par une tâche ("TaskCCD" dans notre code). Cette tâche possède une variable "xDelay_Short" permettant de régler le temps d'intégration. Le contrôleur va régulièrement exécuter cette tâche, qui est constituée de la succession d'instructions suivante :

  • La tâche acquière son image, c'est-à-dire une succession de 128 points, chacun possédant une valeur comprise entre 0 et 255. Cette valeur correspond à l'intensité lumineuse perçu par la caméra : si trop de points sont à 255, l'image est saturée et inexploitable
  • La tâche parcours les 128 points de l'image, et compte le nombre de points dont la valeur est supérieur à une valeur seuil, fixée définitivement après plusieurs essais à différentes luminosités.
  • En fonction du nombre de points, une nouvelle valeur de temps d'intégration va être calculée, pour se rapprocher petit à petit d'un nombre fixé de points supérieurs à la valeur de seuil. Nous devons donc utiliser une formule qui permette de calculer le temps d'intégration en fonction du nombre de points supérieurs à la valeur de seuil :

delay = delay - kNbPoint*(float)(nbPointSaturation - nbPointCible).


Faire la différence entre le nombre de points supérieurs à la valeur de seuil ("nbPointSaturation") et le nombre de points souhaité ("nbpointCible") nous permet d'avoir une variation du temps d'intégration proportionnelle à l'écart entre l'acquisition actuelle et l'acquisition souhaitée. Un coefficient "kNbPoint" nous permet de contrôler l'importance de cette variation.

Attention :

  • Un coefficient trop petit aura pour conséquence une variation du temps d'intégration trop petite. Si un reflet sur la piste amène tous les points en saturation, le programme n'aura pas le temps d'ajuster le temps d'intégration avant que la voiture fonce en dehors de la piste (malgré une exécution régulière de la tâche).
  • Un coefficient trop grand implique une trop grande variation, qui aura pour principale conséquence une oscillation de notre temps d'intégration entre minimum et maximum. En effet, lorsque la voiture rencontre un reflet, la tâche va diminuer brutalement le temps d'intégration de la caméra : il sera trop bas, l'image acquise sera très sombre, et la tâche va compter un nombre nul de point avec une valeur supérieur à la valeur de seuil. Lors de la prochaine exécution de la tâche, le temps d'intégration va brutalement augmenter : tous les points vont passer en saturation. Et le cycle se répétera à l'infini.

Le réglage de ce coefficient est donc très important, mais ne fait pas tout.

Un hystérésis essentiel

Devant ces oscillations récurrentes, nous avons décidé de programmer un hystérésis, nous permettant d'ajuster le temps d'intégration différemment, dépendant de la situation dans laquelle se trouve la tâche.

  • Si le nombre de points cibles est trop éloigné du nombre de points comptabilisés, le temps d'intégration va augmenter ou diminuer selon le principe présenté précédemment.
  • À l'inverse, si ce nombre est proche, c'est-à-dire que nous sommes compris dans l'hystérésis, le temps d'intégration augmente ou diminue d'une constante fixe et beaucoup plus petite.

Ainsi, un changement important de la luminosité ambiante implique toujours un changement important du temps d'intégration. Mais lorsque nous sommes proche du temps d'intégration idéal, nous ajustons avec de petites variations nous permettant de nous rapprocher peu à peu de la valeur idéale, tout en évitant de rentrer dans une boucle infinie si le changement venait à être trop brutal.

Limites du modèle

Ce mode de fonctionnement avec hystéréris nous permet d'éviter de rentrer dans une boucle infinie avec un temps d'intégration qui oscille entre trop petit et trop grand, mais impose des limites au système. En effet, le réglage automatique du temps d'intégration marche plutôt bien, et avec de gros reflets sur la piste. Par contre, lors d'un changement de luminosité trop important (noir complet simulé en cachant la caméra, suivi d'une exposition en plein soleil) , le temps que le temps d'intégration soit suffisant pour exploiter l'image serait trop long pour permettre à la voiture de rester sur la piste.

Nous avons conscience de ces limites mais elles ne sont en aucun cas contraignantes pour la course : personne ne va venir cacher la caméra dans ses mains pendant un virage !

Simulation de la voiture

En vue de la crise sanitaire de l’année 2020 et à cause du confinement il a été impossible pour nous de continuer à travailler avec la voiture et de participer à la coupe NXP qui a été reportée. Une idée pour continuer le projet chez nous a été de simuler la voiture en python.

Le modèle de la simulation

Pour ne pas à devoir programmer un environnement de simulation complet pour la voiture, nous avons préféré réécrire une partie commande pour la voiture (coté simulation) et de ne garder que certains éléments indispensables de la partie opérative.

Ainsi de toute la partie commande, nous n’avons gardé que la tâche qui s’occupe de la détection des piques et du “steering” (contrôle des roues).

Pour le modèle de la voiture, nous avons fait les hypothèses suivantes :

  • La voiture se déplace à vitesse constante en ligne droite (i.e en ligne droite, les deux roues arrière ont la même vitesse angulaire), de même dans les virages
  • La période d’acquisition de la caméra est la même période que le “pas-de-temps” de la simulation

Lors d’un pas de temps de la simulation, on effectue les taches suivantes à la suite :

  • Acquisition de la caméra
  • Envoie des données au programme C et calculs des bords
  • Mise à jour du steering en fonction des bords détectés
  • Faire avancer la voiture de v * δt

Fichier:Speedzone.gif

Limites du modèle

Vérification par rapport à la réalité

Finalement nous arrivons à un résultat convenable, mais sans la voiture à portée de main, il a été difficile de vérifier la simulation par rapport à la réalité. Par exemple la maniabilité de la voiture ou sa vitesse.

L’acquisition de la caméra

Une grosse approximation a été faite sur l’image capturée sur la voiture, en effet l’allure de l’acquisition de la caméra est extrêmement simplifiée. En effet la piste est subdivisée en 3 parties : l’extérieur de la piste, l’intérieur, et les bandes noires. L’acquisition de la caméra se fait alors uniquement sur ces 3 valeurs. Or comme expliqué précédemment, notamment dans la partie de l’hystérésis, la grande difficulté de ce projet a été la gestion de la variance de la luminosité de la piste. Cette simulation permet alors, en estimant une piste théorique, de tester les algorithmes de détection des bords de la piste et des bandes noires plus généralement (notamment pour l’épreuve optionnelle « Speed Zone ») mais ne prend pas en compté l’aléatoire que la luminosité apporte.

Pas de temps de la simulation

On sait que en réalité la fréquence d’acquisition de la caméra est de 50mHz, nous avons alors fixé le pas de temps de la simulation à cette fréquence. Comme expliqué ci-dessus, lors d’un pas de temps, on fait avancer la voiture en fonction de ce δt entre deux acquisitions de la caméra. Or en réalité, la voiture va bien sûr continuer d’avancer entre deux acquisitions de la caméra. Finalement le pas de temps peut grandement affecter la simulation comme dans l’exemple qui suit.

Améliorations

Peu d’attention ont été mises sur les performances du programme car la priorité était d’avoir un environnement de simulation utilisable le plus tôt possible pour travailler sur le programme de détection des bords de la voiture. Par exemple on génère à nouveau la piste chaque fois qu’on lance la simulation, cette génération peut prendre plus ou moins de temps car il faut faire de nombreux calculs notamment pour les panneaux de virages, et ceci dans un tableau représentant la piste à grande dimension pour plus de précision.

Comme mentionné dans les limites de la simulation on pourra également redéfinir les paramètres pour mieux correspondre à la réalité : les paramètres pour l’instant utilisés sont ceux qui donnaient de meilleurs résultats par rapport à nos expériences lorsque nous travaillons encore avec la voiture.

Pour l’instant on peut simuler l’épreuve principale ainsi que les épreuves optionnelles du 8 et de la « Speed zone ». La gestion des obstacles n’est pas encore implémentée, elle pourrait l’être plus simplement en connaissant empiriquement le comportement de la caméra en présence d’un tel obstacle (partie des bandes obstrues…).