Voiture autonome : Différence entre versions

De fablab
Aller à : navigation, rechercher
(L'épreuve du 8)
(Améliorations pour prochaines coupes NXP)
(5 révisions intermédiaires par le même utilisateur non affichées)
Ligne 35 : Ligne 35 :
 
** 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)
 
** 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.
 
** L' ''évitement d'obstacle'' : Éviter un cube blanc poser à un endroit aléatoire sur un  piste ovoide.
** Le ''contrôle de vitesse'' :  
+
** Le ''contrôle de vitesse'' : Réduire et augmenter la vitesse selon signaux dans la piste.
 
+
 
+
  
 
== Un temps d'intégration automatique ==
 
== Un temps d'intégration automatique ==
Ligne 103 : Ligne 101 :
 
=== L'épreuve de contrôle de vitesse ===
 
=== L'épreuve de contrôle de vitesse ===
  
 +
Cette épreuve est un peu plus compliquée. Elle s’agit de détecter deux types différents de signaux dans la piste (bande à trois lignes et à quatre lignes) qui demandent un changement de vitesse.
 +
Dans l’état courant du projet, on ne peut que détecter les limites de la piste. Il faudrait implémenter un mécanisme pour pouvoir déclencher un changement de vitesse lors de la détection de ces signaux. 
 +
 +
=== L’épreuve d’évitement d’obstacles ===
 +
 +
Elle s’agit de pouvoir faire un tour de la piste en 90 secondes, avec un obstacle dans la piste, qu’il faut, bien sûr, éviter.
 +
Avec la simple caméra qu’on a dans la voiture, c’est difficile de pouvoir détecter l’obstacle pour virer et l’éviter, car l’obstacle est blanc et peut-être le règlement du capteur serait difficile. Probablement, une implémentation d’un capteur d'ultrason sera nécessaire.
 +
 +
=== L’épreuve de freinage d’émergence ===
 +
 +
Cette épreuve a les mêmes contraintes que l’épreuve de contrôle de vitesse. L’objectif principal est de pouvoir détecter le signal dans la piste. Cependant, comme il faut faire deux tours, donc il faudra avoir un compteur fiable pour savoir combien de fois la voiture a-t-elle croisé la ligne d’arrivée. Après avoir fait ça, et atteindre le nombre correct de tours, il faudra arrêter les moteurs complètement, et l’épreuve sera terminée.
 +
 +
== Améliorations pour prochaines coupes NXP ==
 +
 +
Pour les prochaines éditions de la coupe NXP, on propose les améliorations suivantes:
 +
 +
* Meilleure caméra : Parfois on trouvait des problèmes dans la détection de limites de la piste. Peut-être une caméra avec une meilleure résolution sera plus utile.
 +
* Support pour lumière rouge : Apparemment, la caméra captait de manière plus claire les limites noires de la piste, avec une lumière rouge. Alors, avoir un support pour la lumière pour pouvoir l’utiliser durant l’épreuve, serait un progrès.
 +
* Meilleur support pour la caméra : Parfois la caméra bougeait à cause du faible support. Un support plus fort est recommandé.
 +
* Nouvelles pistes : Les pistes actuelles qui sont à Phelma Minatec, ne sont pas de la mesure correcte et ont une différence de couleur importante. Pour améliorer les conditions de test avant de la coupe, il faudrait construire ou acheter nouveaux bouts de piste (avec impressions 3D, par exemple).
  
 
== Simulation de la voiture ==
 
== Simulation de la voiture ==

Version du 21 mai 2020 à 19:30

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 : Réduire et augmenter la vitesse selon signaux dans la piste.

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 !

Épreuves optionnelles

L'épreuve du 8

Cette épreuve est la plus simple des quatre car elle demande le moins de travail sur la voiture si elle est déjà capable de faire un tour de piste classique. En effet lorsque la voiture arrive au niveau du croisement, il va y avoir une certaine période durant laquelle elle ne détectera plus aucune bande noire. Or notre code pour la détection des bords prend en charge ce cas où un ou deux bords ne sont plus détectés par la caméra. Ainsi lorsque aucun bord ne sera détecté, la voiture ira simplement en ligne droite. Afin qu'elle passe avec succès le croisement il suffit alors qu'elle l'engage en étant bien alignée.

Le seul risque est qu'elle détecte une "fausse bande" à cause d'un saut (même minime) de luminosité sur la piste. Cependant si le travail au niveau du temps d'intégration est bien réalisé on ne devrait pas rencontré ce problème. Sinon, pour cette épreuve, il faudra introduire un seuil de luminosité à partir duquel on décide si le pic de luminosité correspond bien à une bande.

L'épreuve de contrôle de vitesse

Cette épreuve est un peu plus compliquée. Elle s’agit de détecter deux types différents de signaux dans la piste (bande à trois lignes et à quatre lignes) qui demandent un changement de vitesse. Dans l’état courant du projet, on ne peut que détecter les limites de la piste. Il faudrait implémenter un mécanisme pour pouvoir déclencher un changement de vitesse lors de la détection de ces signaux.

L’épreuve d’évitement d’obstacles

Elle s’agit de pouvoir faire un tour de la piste en 90 secondes, avec un obstacle dans la piste, qu’il faut, bien sûr, éviter. Avec la simple caméra qu’on a dans la voiture, c’est difficile de pouvoir détecter l’obstacle pour virer et l’éviter, car l’obstacle est blanc et peut-être le règlement du capteur serait difficile. Probablement, une implémentation d’un capteur d'ultrason sera nécessaire.

L’épreuve de freinage d’émergence

Cette épreuve a les mêmes contraintes que l’épreuve de contrôle de vitesse. L’objectif principal est de pouvoir détecter le signal dans la piste. Cependant, comme il faut faire deux tours, donc il faudra avoir un compteur fiable pour savoir combien de fois la voiture a-t-elle croisé la ligne d’arrivée. Après avoir fait ça, et atteindre le nombre correct de tours, il faudra arrêter les moteurs complètement, et l’épreuve sera terminée.

Améliorations pour prochaines coupes NXP

Pour les prochaines éditions de la coupe NXP, on propose les améliorations suivantes:

  • Meilleure caméra : Parfois on trouvait des problèmes dans la détection de limites de la piste. Peut-être une caméra avec une meilleure résolution sera plus utile.
  • Support pour lumière rouge : Apparemment, la caméra captait de manière plus claire les limites noires de la piste, avec une lumière rouge. Alors, avoir un support pour la lumière pour pouvoir l’utiliser durant l’épreuve, serait un progrès.
  • Meilleur support pour la caméra : Parfois la caméra bougeait à cause du faible support. Un support plus fort est recommandé.
  • Nouvelles pistes : Les pistes actuelles qui sont à Phelma Minatec, ne sont pas de la mesure correcte et ont une différence de couleur importante. Pour améliorer les conditions de test avant de la coupe, il faudrait construire ou acheter nouveaux bouts de piste (avec impressions 3D, par exemple).

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

Hard 01.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 par la voiture car 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 sur 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.

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. On peut également améliorer l'allure de l'acquisition de la caméra en ajoutant par exemple du bruit ou en créant des panneaux plus lumineux/sombres que les autres.

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…).