Véhicule sans pilote: algorithmes d'animation. Rapport Yandex

Une transcription détaillée d'un autre rapport de la réunion de Yandex.Zhelezo - sur le développement de dispositifs pour les drones.



- Bonjour à tous, je m'appelle Vitaly Podkolzin, je suis responsable du développement de systèmes embarqués pour le projet de véhicule sans pilote. Et aujourd'hui, je voudrais vous parler de ce qu'est une voiture sans pilote, quels composants sont inclus dans sa composition, comment faire bouger la voiture et comment le pilote automatique et ses composants fonctionnent en fonction des appareils utilisés.

Pour comprendre où aller ensuite, une personne doit d'abord savoir où elle se trouve. Une voiture sans pilote aussi. Pour cela, le sous-système de localisation est responsable de nous. Ensuite, vous devez comprendre ce qui se passe autour de nous. Le système de perception ou de perception est responsable de notre vision, perception du monde. Sur la base des données de localisation, des objets qui nous entourent, nous pouvons faire des prévisions sur la situation routière, sur son évolution, sur le comportement des usagers de la route. Et choisissez l'itinéraire optimal de mouvement, la trajectoire, en le transformant en une action de contrôle.

Mais tous ces éléments sont, dans le cas général, des algorithmes. Et vous pourriez exécuter ces algorithmes sur votre ordinateur, s'il était suffisamment puissant. Bien sûr, cela ne ferait pas d'une voiture sans pilote un ordinateur. Il manque deux choses importantes.



Le premier est un ensemble de capteurs assez riche, dont les principaux sont répertoriés sur la diapositive. Et bien sûr, nous avons besoin d'une plate-forme qui exécutera nos commandes. Vous devez interagir avec elle.

Arrêtons-nous sur la question de l'interaction avec la voiture. Le pilote automatique, comme une personne, doit faire des choses simples pour conduire une voiture: tourner le volant, accélérer, ralentir. Une solution logique pourrait sembler utiliser des actionneurs pour contrôler ces corps.


Lien depuis la diapositive

Mais cette approche présente un certain nombre de difficultés importantes. Le développement d'un véhicule sans pilote implique toujours la présence d'un conducteur à certaines étapes - vous devez apporter la voiture à un service ou surveiller le pilote automatique lorsque nous testons diverses fonctionnalités, en particulier dans les premières étapes. Ces appareils compliquent considérablement la vie du conducteur.

Bien sûr, l'ensemble du système est complexe, et en général de tels mécanismes peuvent introduire des retards désagréables dans les commandes. Cela affecte négativement le circuit de commande du véhicule.

Oui, nous avions encore besoin d'une plate-forme simple au début du projet, mais nous avions besoin d'une autre approche pour interagir avec cette plate-forme. Et nous avons commencé à creuser profondément dans la voiture.



Après avoir étudié les caractéristiques de différentes plates-formes, nous avons constaté que de nombreuses voitures modernes ont la capacité de contrôler leurs propres organes. Par exemple, un assistant contrôle le volant pendant le stationnement. Le régulateur de vitesse affecte l'accélération de la voiture, le régulateur de vitesse adaptatif ou un système de limitation de vitesse peut affecter le système de freinage.

Tous ces systèmes, en règle générale, sont fermés dans les voitures. Et pour interagir avec eux, il a fallu développer un certain nombre d'appareils spécialisés. En plus d'interagir avec la voiture, le système devait fournir une interface pratique et conviviale pour conduire la voiture. Et bien sûr, le système aurait dû être simple, direct et très flexible.



Nous sommes arrivés à une plate-forme où, selon la voiture, de petits panneaux de commande sont développés qui interagissent avec un nœud spécifique. La composition et la fonctionnalité de ces cartes diffèrent d'une plate-forme à l'autre, mais elles se réunissent toutes dans un même réseau, où se trouve une unité principale, que nous appelons conventionnellement une passerelle. Il surveille ces appareils. De plus, la passerelle fournit une interface pour le pilote automatique sur des appareils pratiques. Ici, nous voyons Ethernet, pratique pour notre infrastructure, et CAN, l'interface automobile la plus populaire. De plus, notre unité centrale interagit en permanence avec la voiture, surveille l'état des composants et des assemblages. Si des écarts sont détectés, puis, selon leur nature, avec le pilote automatique, une décision est prise sur les étapes suivantes.

Nous avons décidé d'implémenter la carte sur des microcontrôleurs assez populaires et éprouvés. Nous les avons pris avec une marge de performance et avons choisi celles qui prennent en charge les interfaces nécessaires au travail: CAN, Ethernet et entrées / sorties numériques analogiques.

Nous avons obtenu une solution qui s'est avérée vraiment flexible pour nous et qui nous a permis de passer d'une plateforme à une autre avec moins de problèmes.

Parlons des capteurs. Chaque véhicule sans pilote dispose d'un riche ensemble de capteurs. Chaque véhicule sans pilote Yandex possède quatre lidars sur le toit et trois à l'avant, six caméras placées sur le toit et six radars: deux à l'arrière et quatre à l'avant, dont deux sur les côtés.



Nous prenons des radars, des lidars, des caméras, nous connectons, nous conduisons dans l'ordinateur. Mais pas si simple. Il est très important de s'assurer que les données du capteur sont adéquates et de haute qualité. Nous avons mené un grand nombre d'expériences pour comprendre où placer les capteurs, afin que nous puissions voir le monde mieux et plus clairement.

De plus, nos concepteurs ont dû travailler dur pour s'assurer que tous les changements dans la voiture liés aux capteurs répondent aux exigences des organismes de certification.



Voici ce qui s'est passé. Six caméras sur le toit offrent une bonne vue à 360 degrés avec un chevauchement important - les zones sombres sont marquées sur la diapositive. Ces caméras offrent également une bonne vue verticale. La caméra est le seul capteur qui voit les feux de circulation, car ils peuvent être situés dans différentes parties, en fonction de l'intersection et d'autres choses.



Les radars sont un autre capteur important pour chaque voiture. Ils sont intéressants en ce qu'ils ont un angle de vision pas très large, mais une bonne portée. Deux radars frontaux ont pour fonction de surveiller ce qui se passe en avant, les radars arrière de nos algorithmes sont généralement utilisés pour la reconstruction, le dépassement et les manœuvres similaires. Les radars qui regardent de côté sont nécessaires pour traverser des intersections assez complexes où les informations provenant des capteurs peuvent ne pas être suffisantes.



Le capteur le plus intéressant est probablement le lidar. Il s'intéresse aux informations qui lui viennent. Voici un nuage de points, un nuage de points, ce sont des données de lidars. Ils montrent des piétons, des voitures, la route, même les bords de la chaussée et d'autres objets. Les boîtes sont déjà le résultat du travail de nos algorithmes de reconnaissance.



Au total, tous les capteurs donnent approximativement la même image. Comme vous pouvez le voir, il est impossible de ne rien remarquer autour de la voiture avec un tel ensemble de capteurs.

Je voudrais m'attarder sur deux exemples que nous avons rencontrés lorsque nous avions besoin de développer du matériel. Je vais commencer par le cas de la localisation.

La source principale est les cartes haute définition. À chaque instant, un véhicule sans pilote compare les données des lidars avec ces cartes. Sur la base d'une telle comparaison, il obtient son emplacement avec une précision centimétrique. Le GPS, Glonass ou toute autre navigation par satellite ne convient tout simplement pas pour travailler avec un véhicule sans pilote en raison de sa faible stabilité, de sa forte dépendance aux conditions extérieures, de la météo, du bruit et des interférences. En ville, tout cela est considérablement compliqué par les chevauchements de signaux, les réflexions des bâtiments, etc. Mais où obtient-on ces cartes? Nous construisons nous-mêmes des cartes, en utilisant nos véhicules sans pilote avec un ensemble de capteurs.

Pour construire ces cartes, nous avons besoin de lidars et d'une sorte de référence sur le terrain. Vous devez en quelque sorte obtenir vos coordonnées. Le GPS pourrait initialement donner une coordonnée, mais sa précision n'est pas très élevée. Comme je l'ai dit, la précision du GPS est affectée par les conditions atmosphériques, les interférences et en ville il y a aussi des réflexions.



La technologie cinématique en temps réel vient à la rescousse. L'essentiel est: quelque part au sol, une station de base fixe est installée avec le même dispositif de réception que sur une voiture. Si la distance entre la voiture et la station de base ne dépasse pas 30 km (dans certains cas, 50 km), les données satellite reçues par la voiture et la station de base seront approximativement similaires. Mais la station de base, connaissant sa coordonnée exacte (elle est stationnaire) et calculant la coordonnée en fonction des données satellites, reçoit, conditionnellement, une erreur de calcul. Sur la base de cette erreur, des modifications sont développées qui sont envoyées via la voiture à la voiture via Internet. La voiture, en tenant compte des corrections reçues lors du calcul des coordonnées par satellites, obtient ses coordonnées avec une précision centimétrique. Bien sûr, pour travailler avec ce système, vous avez besoin d'un bon canal Internet et de bonnes conditions météorologiques pour que le signal GPS soit stable.

Pour obtenir un appareil fonctionnel avec prise en charge RTK sur une voiture ou une station de base, vous avez besoin d'un logiciel. Les bibliothèques fournissant des fonctionnalités RTK RTKLib sont accessibles au public. Il existe différentes variantes avec différentes fonctionnalités. Les bibliothèques nécessitent généralement un environnement Linux et des modules de navigation par satellite qui fournissent des données brutes.

Après avoir mené quelques expériences, prototypé quelques éléments, nous avons obtenu un schéma fonctionnel du bloc de localisation, que nous avons appelé GeoHub.

En plus du module de navigation par satellite spécifié, il existe également un module de mesures inertielles, que nous utilisons dans le système de localisation. Internet arrive maintenant via l'interface Ethernet qui convient à notre infrastructure.





Voici le deuxième appareil, sa deuxième génération et les principales caractéristiques techniques.

Nous avons remplacé le module de mesure inertielle et le module de signal satellite. En conséquence, cela nous a permis de mener une série d'expériences sur une voiture et de choisir le module de mesure inertielle qui est optimal du point de vue de divers paramètres, et comme pour le module de signal satellite, nous avons pu passer à un récepteur bi-bande dans le processus, ce qui a considérablement amélioré la qualité de la détermination de l'emplacement.

Pourquoi développer votre appareil alors que vous pouvez certainement aller sur le marché et acheter quelque chose de similaire? La réponse est que pour nous, l'un des paramètres les plus importants est la flexibilité de l'appareil. En raison de l'évolution rapide des exigences du projet, de l'émergence de nouvelles fonctionnalités, nous devons être en mesure de répondre très rapidement à cela. En ayant seulement dans le projet, en interne, le développement de matériel et de logiciels, nous obtenons une vitesse de développement très élevée de ces changements.

Un autre capteur intéressant du point de vue d'un véhicule sans pilote est la caméra. D'accord, il y a un appareil photo dans chaque téléphone et ordinateur portable. Qu'est-ce qui pourrait être compliqué ici? Mais voyons quels problèmes vous pouvez rencontrer lors de l'utilisation de l'appareil photo dans un drone.



Le premier problème est le scintillement des sources de lumière LED. La plupart des feux de circulation ne sont que de telles sources. La vidéo s'est arrêtée au moment où, en raison du scintillement, le signal rouge a presque disparu.

Pour ce problème, il existe des solutions matérielles intégrées dans le capteur, mais pour fonctionner correctement et avec une qualité élevée, vous devez être en mesure d'interagir activement avec le capteur.

La deuxième exigence pour les caméras est une plage dynamique élevée, c'est-à-dire la capacité de travailler dans toutes les conditions d'éclairage, à la fois la nuit et en plein soleil. La présence de HDR est également importante, c'est-à-dire la possibilité de combiner des images avec un éclairage différent en une seule pour obtenir une meilleure image.



À gauche se trouve un exemple d'image où la fonction HDR est utilisée et à droite où elle est désactivée.



De plus, nous devons bien sûr obtenir une image avec une résolution suffisante et une fréquence d'images suffisante. Sur la diapositive, quelques points supplémentaires sont mis en évidence, inhérents aux véhicules sans pilote, y compris. La caméra doit produire un flux vidéo non compressé, de préférence au format RGB888, car nos réseaux, les algorithmes fonctionnent avec ce format, ils veulent recevoir des images dans ce format.

La plupart des caméras, solutions prêtes à l'emploi sur le marché, fournissent des données compressées - H264, MPEG. Les problèmes ici sont simples: nous perdons de la qualité lors de la compression et introduisons un retard dans la compression et la décompression. Le retard peut être non déterministe, en particulier à des charges système élevées. Une caméra avec une résolution Full HD et une fréquence de 30 images par seconde avec un débit binaire de 16 bits par pixel produit un flux d'environ gigabits par seconde de données vidéo pures.

De plus, les caméras sont généralement situées à distance de l'appareil récepteur, et dans la voiture, en particulier lors de certaines expériences, elles peuvent être généralement situées à l'autre extrémité de la voiture. Nous avions besoin de caméras permettant de transmettre l'intégralité du flux vidéo non compressé à une distance de 6 à 8 mètres, en tenant compte du câblage. Pour une caméra Full HD à 16 bits par pixel, le flux vidéo est de 1 gigabit, ce qui ne permet plus l'utilisation de gigabit Ethernet, car diverses données de service et ainsi de suite sont impliquées dans le transfert. Ethernet à dix gigabits n'est pas tout à fait approprié. Il est cher, consommation d'énergie élevée, dissipation thermique élevée, complexité accrue de l'infrastructure réseau.

Oui, il existe d'autres interfaces intéressantes. J'aimerais parler de deux d'entre eux avec lesquels nous avons travaillé. Ils sont fournis par Maxim Integrated et Texas Instruments. La particularité est que le flux vidéo est sérialisé en données qui vont à un niveau physique simple, dans ce cas via un câble coaxial, à une vitesse de 3-4, parfois 6 gigabits par seconde. De plus, cette interface vous permet d'utiliser le canal de retour pour contrôler la caméra sur le même câble coaxial. Et sur elle, la puissance de la caméra peut aller. Tout ce qui précède rend cette interface très attrayante.



Lorsque nous avons commencé, nous avons trouvé une solution sur le marché qui satisfaisait essentiellement la plupart des exigences. Nous l'avons utilisé pendant un certain temps au début du projet.



Le schéma de principe de la solution est devant vous. Il s'agit d'un capteur à partir duquel les données sont sérialisées vers l'interface GMSL / FPD-Link. Au niveau de la partie réceptrice, qui peut être enlevée jusqu'à 15 mètres, les données sont désérialisées et transmises au récepteur. Dans notre solution, ce récepteur a ensuite fourni des données via l'interface USB 3.0.

Mais en commençant à utiliser cette solution, nous avons rencontré un certain nombre de problèmes désagréables. Le principal problème - la solution a fonctionné extrêmement instable, "tombé" dans le processus, les caméras n'ont pas bien démarré lorsque le pilote automatique a démarré. De plus, la solution n'a pas permis d'ajuster les paramètres des capteurs eux-mêmes afin d'améliorer la qualité d'image. Il y avait également un certain nombre de problèmes. Par exemple, il était difficile d'obtenir l'horodatage exact de la caméra, le temps de prise de vue, ce qui est assez important, car à une vitesse de 15 m / s avec un retard de 100 ms, la voiture parcourt déjà un mètre et demi, ce qui peut affecter très négativement les algorithmes de perception.

Il y avait un autre point intéressant. L'interface de sortie de la solution sélectionnée était USB 3.0, et nous avons constaté qu'elle était extrêmement bruyante. Comment comprenons-nous cela? Nous avions deux voitures connectées à rien. Sur l'un, ils ont lancé la caméra, sur les deux, le signal de navigation par satellite a beaucoup coulé. Ensuite, nous avons commencé à étudier ce qui se passait.

Après avoir analysé toutes ces lacunes en général, après avoir étudié le schéma structurel devant vous et ainsi de suite, nous sommes arrivés à la conclusion que le problème est dans la partie réceptrice. Ensuite, ils ont commencé à penser à quoi en faire. Nous avons examiné ce qui est sur le marché, les solutions d'autres équipes et sommes arrivés à la conclusion que nous devons fabriquer notre propre appareil de réception qui fonctionnera avec la caméra via l'interface GMSL ou FPD-Link.



Nous avons pris des désérialiseurs, qui, en règle générale, ont une sortie d'interface MIPI CSI2, et avons commencé à rechercher un module ou un processeur qui pourrait prendre en charge cette interface. Et nous avons trouvé une solution intéressante avec six interfaces MIPI CSI2, ainsi que des périphériques performants et riches. Cela nous a finalement permis d'utiliser l'interface Ethernet 10 gigabits qui est pratique pour notre infrastructure réseau comme interface de sortie de cet appareil. Après avoir reçu les données GMSL / FPD-Link de 6 caméras (ou, dans certains cas, de 12 caméras), les ayant traitées, l'appareil transfère le flux vidéo déjà traité vers l'ordinateur via Ethernet 10 gigabits.



Voici la solution elle-même et ses principales caractéristiques. Ayant développé une telle chose, nous avons non seulement appris à travailler de manière fiable avec 6 ou 12 caméras, mais nous avons également eu la possibilité de peaufiner les caméras. Cela a permis d'améliorer la qualité de l'image, ce qui a eu un impact positif sur le fonctionnement des algorithmes de perception. Nous avons également bien compris le temps nécessaire pour prendre la photo et appris à gérer ce temps. Et grâce aux processeurs hautes performances, la puissance de calcul du module nous a permis d'effectuer le traitement vidéo initial avec un minimum de retards directement sur le module.

Le codec matériel de ce module a également permis de compresser les données vidéo pour un stockage ultérieur dans les journaux.

Nous avons dû travailler non seulement avec des capteurs de localisation et des caméras. Nous avons dû développer des solutions matérielles pour presque tous les capteurs que nous utilisons. Tout cela a été fait pour résoudre l'augmentation de la fiabilité et de la qualité des données dont dépendent les algorithmes de détection et de perception. Et cela dépend de leur optimisation de la solution émise par le pilote automatique.

D'accord, nous avons appris à conduire une voiture, travaillé sur des capteurs, bien les positionnés, leur avons appris à nous donner une image de haute qualité. Quels autres travaux les ingénieurs des systèmes embarqués, les travailleurs du matériel sur notre projet? Nous surveillons non seulement le développement de capteurs devenus routiniers, mais également des sources alternatives d'informations. Nous explorons constamment des accélérateurs alternatifs de réseaux de neurones et d'autres algorithmes, y compris ceux utilisant des FPGA. Et il est difficile d'imaginer le développement du projet sans interaction avec un constructeur automobile expérimenté.


— , , .

. , . , , , . , .

Source: https://habr.com/ru/post/fr471636/


All Articles