Bonjour, Habr! Je travaille dans une petite startup à Berlin qui développe des pilotes automatiques pour les voitures. Nous achevons un projet de stations-service d'un grand constructeur automobile allemand, et j'aimerais en parler: comment nous l'avons fait, quelles difficultés nous avons rencontrées et quelles nouvelles choses nous avons découvertes. Dans cette partie je parlerai du module de perception et un peu de l'architecture de la solution dans son ensemble. À propos du reste des modules, peut-être, nous le dirons dans les parties suivantes. Je serai très heureux de recevoir des commentaires et un regard de l'extérieur sur notre approche.
Le communiqué de presse du projet du client est disponible
ici .
Pour commencer, je vais vous expliquer pourquoi le constructeur automobile s'est tourné vers nous et n'a pas fait le projet lui-même. Il est difficile pour les grandes entreprises allemandes de modifier les processus, et le format de développement automobile est rarement adapté aux logiciels - les itérations sont longues et nécessitent une bonne planification. Il me semble que les constructeurs automobiles allemands comprennent cela, et vous pouvez donc trouver des startups qui sont fondées par eux, mais qui travaillent en tant qu'entreprise indépendante (par exemple, AID d'Audi et Zenuity de Volvo). D'autres constructeurs automobiles organisent des événements comme Startup Autobahn, où ils recherchent des entrepreneurs potentiels pour des tâches et de nouvelles idées. Ils peuvent commander un produit ou un prototype et, après une courte période, obtenir le résultat final. Cela peut s'avérer plus rapide que d'essayer de faire la même chose vous-même, et cela ne coûte pas plus cher que son propre développement en termes de coûts. La complexité des changements de processus est bien démontrée par le nombre d'autorisations nécessaires pour commencer à tester une voiture avec pilote automatique chez les clients: consentement à l'enregistrement vidéo des personnes (même si nous n'enregistrons pas de données, et nous utilisons la vidéo en streaming uniquement sous forme anonyme sans identifier des personnes spécifiques), consentement à l'enregistrement vidéo territoires, le consentement du syndicat et du consul de travail pour tester ces technologies, le consentement du service de sécurité, le consentement du service informatique - ce n'est pas toute la liste.
Défi
Dans le projet en cours, le client veut comprendre s'il est possible de conduire des voitures dans des centres de service en utilisant «AI». Le script utilisateur est:
- Le technicien veut commencer à travailler avec une machine qui se trouve quelque part dans le parking en dehors de la zone d'essai.
- Il sélectionne la voiture sur la tablette, sélectionne la boîte de service et clique sur "Drive in".
- La voiture roule à l'intérieur et s'arrête au point final (ascenseur, rampe ou autre chose).
- Lorsque le technicien a fini de travailler sur la voiture, il appuie sur un bouton de la tablette, la voiture sort et se gare dans un espace vide à l'extérieur.
Caractéristiques: toutes les voitures n'ont pas de caméras. Sur les machines sur lesquelles ils se trouvent, nous n'y avons pas accès. Les seules données sur la machine auxquelles nous avons accès sont les sonars et l'odométrie
Sonars et odométrieLes sonars sont des capteurs de distance qui sont installés en cercle sur une voiture et ressemblent souvent à des points ronds, ils vous permettent d'estimer la distance à l'objet, mais seulement de près et avec une faible précision. Odométrie - données sur la vitesse et la direction réelles de la voiture. Connaissant ces données et la position initiale, vous pouvez déterminer assez précisément la position actuelle de la machine.
Ainsi, la voiture doit être contrôlée par des capteurs externes installés dans la zone de service.
Solution
L'architecture du produit final est la suivante:
- Dans la zone de service, nous installons des caméras externes, des lidars et d'autres choses (bonjour Tesla).
- Les données des caméras sont transmises à Jetson TX2 (trois caméras chacune), qui sont chargées de trouver la machine et de pré-traiter les images des caméras.
- De plus, les données de la caméra arrivent au serveur central, qui est fièrement appelé tour de contrôle et sur lequel elles tombent dans les modules de perception, de suivi et de planification de chemin. À la suite de l'analyse, une décision est prise sur le sens de déplacement supplémentaire de la voiture et elle est envoyée à la voiture.
- À ce stade du projet, un autre Jetson TX2 est placé dans la voiture, qui, à l'aide de notre pilote, se connecte à Vector, qui déchiffre les données de la voiture et envoie des commandes. TX2 reçoit les commandes de contrôle d'un serveur central et les diffuse à la voiture.
Pour le niveau d'infrastructure,
ROS est utilisé.
Voici ce qui se passe après qu'un technicien ait choisi une voiture et cliqué sur «conduire»:
- Le système recherche une voiture: nous envoyons une commande à la voiture pour faire clignoter les alarmes, après quoi nous pouvons déterminer laquelle des voitures dans le parking est sélectionnée par le technicien. Au stade initial du développement, nous avons également envisagé la possibilité de déterminer la machine par la plaque d'immatriculation, mais dans certaines zones de la voiture garée, le numéro peut ne pas être visible. De plus, si nous déterminions la voiture par son numéro d'immatriculation, la résolution des photos devrait être considérablement augmentée, ce qui affecterait négativement la productivité, et nous utilisons la même image pour la recherche et la conduite. Cette étape se produit une fois et n'est répétée que si, pour une raison quelconque, nous avons perdu la voiture lors du suivi.
- Dès que la voiture est trouvée, nous déposons les images des caméras que la voiture frappe dans le module de perception, qui segmente l'espace et donne les coordonnées de tous les objets, leur orientation et leurs tailles. Ce processus est en cours, fonctionnant à environ 30 images par seconde. Les processus suivants sont également constants et exécutés jusqu'à ce que la machine arrive au point final.
- Le module de suivi reçoit les entrées de la perception, des sonars et de l'odométrie, stocke tous les objets trouvés en mémoire, les combine, affine l'emplacement, prédit la position et la vitesse des objets.
- Ensuite, le planificateur de chemin, qui est divisé en deux parties: planificateur de chemin global pour l'itinéraire global et planificateur de chemin local pour le local (responsable d'éviter les obstacles), construit un chemin et décide où aller à notre voiture, envoie une commande.
- Jetson prend la commande en voiture et la diffuse dans la voiture.
Le départ s'effectue de la même manière que l'arrivée.
Perception
L'un des modules principaux et, à mon avis, le plus intéressant est la perception. Ce module décrit les données des capteurs de manière à ce que vous puissiez prendre une décision précise sur le mouvement. Dans notre projet, il donne les coordonnées, l'orientation et les tailles de tous les objets qui tombent sur la caméra. Lors de la conception de ce module, nous avons décidé de commencer par des algorithmes qui nous permettraient d'analyser l'image en une seule passe. Nous avons essayé:
- VAE démêlé . Une petite modification apportée à la β-VAE nous a permis de former le réseau afin que les vecteurs latents stockent les informations d'image dans une vue schématique descendante.
- GAN conditionnel (l'implémentation la plus connue est pix2pix ). Ce réseau peut être utilisé pour créer des cartes. Nous l'avons également utilisé pour construire une vue schématique d'en haut, en y mettant les données d'une ou de toutes les caméras en même temps et en attendant une vue schématique d'en haut en sortie.
L'une des itérations GAN conditionnelles pour une caméra, de gauche à droite: image d'entrée, prédiction de réseau, résultat attendu
En fait, l'idée de ces approches est de s'assurer que le réseau final peut comprendre l'emplacement et l'orientation de toutes les voitures et autres objets en mouvement qui sont tombés sur l'appareil photo en regardant une fois la photo d'entrée. Dans ce cas, les données sur les objets seront stockées dans des vecteurs latents. La formation du réseau a eu lieu sur les données du simulateur, qui est une copie exacte du point où la démonstration aura lieu. Et nous avons réussi à obtenir certains résultats, mais nous avons décidé de ne pas utiliser ces méthodes pour plusieurs raisons:
- Dans le temps imparti, nous n'avons pas pu apprendre à utiliser les données des vecteurs latents pour décrire l'image. Le résultat du réseau a toujours été une image - une vue de dessus avec une disposition schématique des objets. C'est moins précis et nous craignions qu'une telle précision ne soit pas suffisante pour conduire une voiture.
- La solution n'est pas évolutive: pour toutes les installations ultérieures et pour les cas où vous devez changer la direction de certaines caméras, une reconfiguration du simulateur et une formation complète répétée sont nécessaires.
Néanmoins, nous étions intéressés à comprendre les possibilités de ces approches, et nous les garderons à l'esprit pour les tâches futures.
Après cela, nous avons abordé la tâche d'autre part, à travers une recherche régulière d'objets + un réseau pour déterminer la position spatiale des objets trouvés (par exemple
ceci ou
cela ). Cette option nous a semblé la plus précise. Le seul inconvénient est qu'il est plus lent que les approches proposées auparavant, mais il s'inscrit dans notre cadre de retard possible, car la vitesse de la voiture dans la zone de service ne dépasse pas 5 km / h. Le travail le plus intéressant dans le domaine de la prédiction de la position 3D de l'objet nous a semblé
celui-ci , qui montre de très bons résultats sur
KITTI . Nous avons construit un réseau similaire avec quelques changements et écrit notre propre algorithme pour déterminer la boîte environnante, et pour être plus précis, un algorithme pour estimer les coordonnées du centre de la projection de l'objet sur le sol - pour prendre des décisions sur la direction du mouvement, nous n'avons pas besoin de données sur la hauteur des objets. L'image de l'objet et son type (voiture, piéton, ..) sont transmis à l'entrée du réseau, et ses dimensions et son orientation spatiale sont sorties. Ensuite, le module évalue le centre de projection et fournit des données pour tous les objets: les coordonnées du centre, l'orientation et les dimensions (largeur et longueur).
Dans le produit final, chaque image est d'abord parcourue à travers le réseau pour rechercher des objets, puis tous les objets sont envoyés au réseau 3D pour prédire l'orientation et la taille, après quoi nous estimons le centre de projection de chacun et l'envoyons ainsi que les données d'orientation et de taille. Une caractéristique de cette méthode est qu'elle est très fortement liée à la précision de la frontière de la boîte frontière du réseau de recherche d'objets. Pour cette raison, des réseaux comme YOLO ne nous convenaient pas. Nous avons trouvé l'équilibre optimal entre les performances et la précision de la boîte frontière sur le réseau RetinaNet.
Il convient de noter une chose qui nous a eu de la chance sur ce projet: le terrain est plat. Eh bien, ce n'est pas aussi plat qu'une communauté bien connue, mais il n'y a pas de virages sur notre territoire. Cela permet l'utilisation de caméras monoculaires fixes pour projeter des objets dans les coordonnées du plan terrestre sans information sur la distance à l'objet. Les plans futurs comprennent l'introduction de la prévision monoculaire de la profondeur. Il y a beaucoup de travaux sur ce sujet, par exemple, l'un des derniers et très intéressants que nous essayons pour de futurs projets. La prédiction de la profondeur vous permettra de travailler non seulement sur un sol plat, elle devrait potentiellement augmenter la précision de la détermination des obstacles, simplifier le processus de configuration de nouvelles caméras et éliminer la nécessité d'étiqueter chaque objet - peu nous importe quel type d'objet il s'agit s'il s'agit d'une sorte d'obstacle.
C'est tout, merci d'avoir lu, et je serai heureux de répondre aux questions. En prime, je veux parler d'un effet négatif inattendu: le pilote automatique ne se soucie pas de l'orientation de la voiture, pour lui, peu importe comment aller - avant ou arrière. L'essentiel est de conduire de manière optimale et de ne pas percuter qui que ce soit. Par conséquent, il y a une forte probabilité que la voiture se déplace une partie du chemin en marche arrière, en particulier dans les petites zones où une grande maniabilité est requise. Cependant, les gens sont habitués au fait que la voiture avance principalement et attendent souvent le même comportement du pilote automatique. Si un homme d'affaires voit une voiture qui, au lieu de rouler en avant, recule, il peut considérer que le produit n'est pas prêt et contient des erreurs.
PS Je m'excuse qu'il n'y a pas d'images et de vidéos avec de vrais tests, mais je ne peux pas les publier pour des raisons légales.