Acquisition de données multi-capteurs pour la perception des véhicules autonomes

Alors que les véhicules automatisés évoluent vers les niveaux SAE 3 à 5, les algorithmes de perception nécessitent des jeux de données reflétant la diversité du monde réel, et non des conditions idéalisées. DARTS-PL relève ce défi en fournissant un jeu de données routières multi-capteurs, haute résolution et parfaitement synchronisé, adapté à l’infrastructure et au climat de l’Europe centrale et orientale. Conçu comme une ressource nationale ouverte, DARTS-PL comble l’écart entre les références mondiales et les réalités locales de conduite.

Introduction

Le projet DARTS-PL est conçu comme une base de données nationale de scénarios routiers dédiée au développement et aux tests d’algorithmes de perception pour véhicules automatisés. Le projet fournira des données multi-capteurs, haute résolution et synchronisées sous une licence d’accès libre.

DARTS-PL vise à créer une base de données nationale de scénarios de test pour les véhicules autonomes (VA), prenant en compte les conditions routières spécifiques à la Pologne.

Une telle base de données nationale de scénarios routiers aide à développer et à tester les algorithmes de perception pour les véhicules automatisés. Le projet fournira des données multi-capteurs, haute résolution et synchronisées sous une licence d’accès libre.

Pour collecter les données pertinentes, nous avons équipé un véhicule d’une suite de capteurs comprenant 4 LiDAR, 7 caméras, 6 radars, un module IMU-GPS-RTK et une caméra thermique.

Les multiples capteurs sont entièrement synchronisés et étalonnés dans le logiciel d’acquisition de données DewesoftX, qui fonctionne comme un système central d’acquisition de données.

Le problème

Depuis son lancement en 2014, la norme SAE J3016™ (Pratique recommandée : Taxonomie et définitions des termes liés aux systèmes d’automatisation de la conduite pour les véhicules routiers à moteur), communément appelée les niveaux SAE d’automatisation de la conduite, est la source la plus citée de l’industrie pour l’automatisation de la conduite.

Selon la norme SAE J3016, les niveaux 3 à 5 des systèmes d’aide à la conduite (ADAS) du véhicule représentent la transition de la conduite surveillée par l’humain à l’autonomie complète du véhicule :

• Niveau 3 (Automatisation conditionnelle) : permet à la voiture de gérer toutes les tâches de conduite dans des conditions spécifiques, avec l’humain comme solution de secours.

• Niveau 4 (Automatisation élevée) : fonctionne sans intervention humaine dans des zones définies,

• Niveau 5 (Automatisation complète) : ne nécessite aucun conducteur humain dans aucune condition.

Alors que l’industrie automobile mondiale se prépare à des niveaux élevés d’automatisation (niveaux SAE 3-5), l’un de ses défis est la disponibilité à grande échelle de jeux de données diversifiés, représentatifs et de haute qualité pour l’entraînement et la validation des algorithmes de perception. Alors que le domaine évolue rapidement, le nombre total de jeux de données est difficile à déterminer.

En 2024, Liu et al. [1] ont identifié 265 jeux de données publiés sur la conduite autonome. Leur étude révèle une caractéristique notable des jeux de données actuels sur la conduite autonome : la plupart d’entre eux reposent fortement sur la détection par caméra, en particulier les caméras monoculares et stéréo (voir Figure 1).

Bien que ces capteurs soient économiques et largement déployables, ils sont intrinsèquement sensibles aux perturbations environnementales, notamment un éclairage médiocre, des reflets, des ombres, la pluie, le brouillard et les occultations. À cet égard, ils présentent des limitations similaires à celles de la vision humaine, que des conditions météorologiques défavorables ou un éclairage difficile peuvent altérer.

Bien que des capteurs complémentaires tels que le LiDAR et le radar soient de plus en plus intégrés pour améliorer la robustesse, les jeux de données dominés par les caméras reflètent une dépendance continue aux systèmes de perception basés sur la vision, qui restent vulnérables aux mêmes types d’incertitudes et d’ambiguïtés qui affectent l’œil humain.

Pour répondre à ces limitations, les chercheurs développent une gamme de solutions techniques et méthodologiques. L’une des plus importantes est la fusion multi-capteurs, qui combine les caméras avec des technologies complémentaires telles que le LiDAR et le radar. Contrairement aux capteurs visuels, le radar est plus résistant aux intempéries, tandis que le LiDAR fournit des informations géométriques de profondeur précises indépendamment de l’éclairage ambiant.

La fusion de données hétérogènes de capteurs au niveau des caractéristiques, intermédiaire ou décisionnel permet aux systèmes de perception de compenser les faiblesses des modalités individuelles et d’atteindre une robustesse, une fiabilité et une redondance accrues.

Les enquêtes et études de revue identifient systématiquement le besoin de jeux de données plus vastes et plus diversifiés comme base pour les progrès de la recherche sur la conduite autonome [2]. La diversification des jeux de données est particulièrement importante. Élargir la couverture des conditions météorologiques, des régions géographiques, des situations de trafic et des cas limites rares améliore les performances réelles des systèmes de conduite automatisés.

Selon Liu et al. [1], cependant, la plupart des jeux de données existants sont concentrés dans les régions à revenu élevé. Les États-Unis représentent 21 % des jeux de données, tandis que l’Allemagne et le reste de l’Europe représentent chacun 12,6 %. La Chine suit avec 8,4 %, et des pays comme le Canada, la Corée, le Royaume-Uni, le Japon et Singapour ne représentent que de petites parts de 1 à 4 %.

Ce déséquilibre signifie que les jeux de données existants peuvent ne pas représenter adéquatement l’infrastructure, le comportement de conduite et les conditions climatiques typiques de l’Europe centrale et orientale. Une géométrie routière unique, une signalisation locale et des conditions météorologiques telles que la neige abondante, la pluie et le brouillard peuvent tous représenter des défis pour les capteurs des véhicules autonomes.

Jeu de données DARTS-PL – Scénarios de test polonais

Étant donné la sous-représentation des conditions de conduite d’Europe centrale, le Centre national polonais pour la recherche et le développement a financé le projet DARTS-PL dans le cadre du programme GOSPOSTRATEG VIII (numéro de subvention : GOSPOSTRATEG-VIII/0001/2022).

Un consortium d’institutions polonaises de recherche et universitaires de premier plan mène le projet :

• Institut des transports routiers (ITS) : responsable de la définition des exigences des scénarios et de la coordination du processus d’acquisition des données.

• Université de technologie de Varsovie (PW) : réalise le traitement avancé des données, la fusion des capteurs et le processus d’annotation.

Le jeu de données DARTS-PL répond au manque de jeux de données multi-capteurs haute résolution enregistrés dans des conditions de conduite naturelles en Pologne. Il existe un besoin de données orientées VA qui sont synchronisées et couvrent non seulement les scénarios de conduite courants, mais aussi les « cas limites », tels que les zones à taux d’accidents élevé, les machines agricoles sur route et la conduite dans des conditions de faible visibilité.

Les bases de données existantes souffrent souvent d’un « biais géographique » car elles sont principalement enregistrées en Amérique du Nord ou en Europe de l’Ouest. Ce biais entraîne des lacunes dans l’entraînement algorithmique pour :

• Variabilité de l’infrastructure : différences dans les marquages routiers, les infrastructures, les classes de routes et les solutions d’intégration.

• Extrêmes environnementaux : dégradation des performances des capteurs pendant les hivers d’Europe centrale (couverture de neige, embruns de sel), fortes pluies, brouillards, etc.

• Usagers vulnérables de la route (VRU) : interactions avec divers participants, y compris les cyclistes et les animaux, qui nécessitent une annotation 3D de haute fidélité.

Sans données localisées, les systèmes VA déployés en Pologne peuvent ne pas reconnaître des dangers spécifiques, entraînant un « écart de perception » qui entrave l’innovation et la sécurité nationales.

Le projet DARTS-PL établit une base de données nationale de scénarios routiers. La stratégie principale consiste à enregistrer plus de 100 segments routiers distincts, chacun capturé au moins 8 fois dans des conditions variées (jour/nuit, quatre saisons), couvrant également des cas environnementaux limites tels que de fortes pluies, de la boue sur la route, des marquages recouverts de neige ou de feuilles, et bien d’autres.

Le projet DARTS-PL suit plusieurs principes pour déployer une solution adéquate :

• Synchronisation : les capteurs sont déclenchés par matériel et horodatés.

• Accès ouvert : fourniture des données sous une licence libre d’utilisation à but non lucratif pour les applications commerciales et académiques.

• Normalisation : les données sont dans des formats ouverts pour une intégration transparente dans les environnements de simulation.

Parties prenantes

Les chercheurs de l’Institut des transports routiers ont développé les exigences fonctionnelles et non fonctionnelles pour l’ensemble de mesure. Envibra sp. z o.o. était l’entrepreneur responsable du développement de la plateforme d’acquisition de données DARTS-PL. La société a bénéficié du soutien des ingénieurs de :

• Dewesoft – mises à jour logicielles, caméras, localisation,

• b-plus GmbH – dispositif informatique principal, horodatages généraux, synchronisation,

• SEARCH – Safety Engineering Research – intégration du LiDAR et du radar, y compris le développement de plugins.

L’équipe a résolu collaborativement tous les problèmes rencontrés lors du développement de l’ensemble de mesure. Échangeant d’innombrables messages et rencontrant des problèmes dont les fabricants des composants eux-mêmes n’avaient pas connaissance. Ce projet n’était pas une commande ordinaire, mais un projet de R&D à grande échelle.

Exigences et problèmes potentiels

Développer un système de mesure répondant aux exigences du client était en soi un défi important. Le contrat couvrait la livraison complète, y compris l’installation, la configuration, la mise en service et la formation des utilisateurs pour un kit de mesure multi-capteurs intégré à un logiciel, capable de cartographier et d’enregistrer l’environnement du véhicule à 360 degrés.

DARTS-PL souhaitait enregistrer des scénarios (trajets) axés sur des solutions d’infrastructure spécifiques ou des situations routières pouvant poser problème aux systèmes de conduite automatisés, telles que des conditions météorologiques défavorables, une signalisation peu claire et des usagers vulnérables sur la chaussée.

Un scénario unique, d’environ 20 secondes, devait être extrait d’une seule session d’enregistrement d’environ 10 minutes. Le système de mesure devait enregistrer avec précision tous les paramètres jusqu’à une vitesse maximale du véhicule de 130 km/h.

DARTS-PL a proposé la disposition des capteurs, tandis qu’Envibra et Dewesoft devaient intégrer le système de mesure avec le véhicule. L’ensemble de mesure devait être monté dans la section du toit sous la forme d’un « boîtier », permettant un retrait facile.

Les parties du système de mesure non contenues dans le boîtier ou à l’intérieur de la carrosserie devaient être équipées de plots de montage adhésifs pour permettre une installation facile n’importe où dans le véhicule. Les connexions par câbles doivent permettre à l’ensemble de fonctionner correctement avec les portes et les fenêtres fermées, empêchant l’eau et le froid de pénétrer dans l’habitacle du véhicule pendant les mesures.

Toutes les données enregistrées par le système de mesure, y compris les images capturées par les caméras, doivent être synchronisées avec l’horloge centrale. La plage de température ambiante pour le bon fonctionnement du système de mesure était de -10°C à +40°C, et pour le stockage, de -20°C à +40°C. Le système devait fonctionner correctement dans diverses conditions météorologiques, y compris de fortes pluies ou des vents violents, pendant environ 6 heures le jour de la mesure. Il devait également être résistant à la poussière et à d’autres petites particules en suspension dans l’air.

Exigences des capteurs

Caméras

• Enregistrement vidéo couleur avec une résolution d’au moins 1920 pixels par 1080 pixels à un minimum de 25 images par seconde.

• Technologie HDR avec une fonction d’exposition automatique, avec la possibilité de désactiver indépendamment les deux fonctions.

• Images brutes (non compressées).

• Réglage et verrouillage de la mise au point et de la balance des blancs à une position donnée.

• Couverture d’au moins 20 degrés par rapport à l’horizon avec le véhicule en position horizontale.

• Technologie d’obturateur global.

• Utilisation de capteurs (matrices) d’au moins 1/2".

• Les paramètres d’enregistrement d’image, en particulier l’exposition (vitesse d’obturation et gain), doivent être enregistrés pour chaque image.

LiDAR – moyenne portée

• Au moins 128 faisceaux laser.

• Fréquence minimale de 20 Hz (la fréquence doit être configurable à partir de 10 tours par seconde).

• Portée d’au moins 200 m, une portée verticale d’au moins 30°, et une portée horizontale de 360 degrés (rotationnelle).

• Précision de 3 cm ou meilleure et une résolution de balayage horizontale de 0,25° ou meilleure.

LiDAR – longue portée

• Capturer la zone centralement devant le véhicule et le placer sur son axe.

• Fréquence minimale de 20 Hz (il est recommandé que la fréquence soit configurable).

• Portée de mesure d’au moins 200 m, une portée horizontale d’au moins 20°, et une portée verticale d’au moins 15°.

• Précision de 3,5 cm ou meilleure et une résolution de balayage horizontale de 0,26° ou meilleure.

LiDAR – courte portée

• Portée horizontale suggérée de 120° ou plus, avec un angle d’élévation minimal suggéré de -75° à +15°.

• Fréquence minimale de 20 Hz (fréquence configurable recommandée).

• Au moins 64 faisceaux laser.

• Portée de mesure d’au moins 30 m.

Radars – coins

• Portée de 1 à 30 m.

• Fréquence minimale de 13 Hz.

• Portée horizontale d’au moins 75° et une portée verticale d’au moins 15°.

Radars – avant et arrière

• Portée d’au moins 80 m.

• Fréquence minimale de 13 Hz.

• Portée horizontale d’au moins 60° et une portée verticale d’au moins 15°.

Systèmes de navigation inertielle (INS, IMU) et RTK

• Précision de navigation utilisant la méthode RTK n’est pas pire que 10 cm horizontalement.

• Prise en charge de la mesure de cap avec une précision dynamique d’au moins 0,1°.

• Mesurer la vitesse avec une précision d’au moins 0,05 m/s jusqu’à au moins 200 km/h.

• Taux d’échantillonnage GPS d’au moins 100 Hz.

• Données enregistrées par l’IMU :

  Vecteur d’accélération linéaire (x, y, z) dans le cadre de l’IMU en m/s².

  Vitesse angulaire en rad/s autour des axes x, y et z, respectivement, dans le cadre de coordonnées de l’IMU.

  Position du véhicule : vecteur d’accélération dans le cadre du véhicule EGO en m/s², vecteur de rotation (orientation) dans le cadre du véhicule EGO.

Caméra thermique

• Résolution d’au moins 640x480 pixels.

• Minimum de 25 images par seconde.

• Sensibilité thermique de 50 mK ou moins.

Alimentation électrique des capteurs

• Capacité à alimenter indépendamment un système de mesure fonctionnel pendant au moins 4 heures.

• L’alimentation électrique ne doit pas être montée en permanence dans le véhicule pour éviter le retrait.

• Recharge sur le secteur.

• Ne doit pas être alimentée directement par le système électrique du véhicule, mais peut être rechargée à partir d’une prise allume-cigare 12V (avec des restrictions appropriées).

• Si les dispositifs du système de mesure nécessitent une alimentation en courant alternatif, ils doivent être des dispositifs à onde sinusoïdale pure.

Équipement d’acquisition et de mesure des données

Envibra a choisi d’équiper le véhicule de recherche de 19 capteurs. Le nombre de capteurs ne cesse de croître et est intégré via le logiciel DewesoftX. Ils ont sélectionné les composants suivants pour répondre à nos exigences (dans certains cas, dépassant les exigences, par exemple, voir le LiDAR à courte portée – OS Dome).

Enregistreur de données

Enregistreur de données b-Plus Brick2 avec module BMC et carte BMC ETH6000.

Navigation inertielle

Système de navigation inertielle Dewesoft NAVION i2 (INS) avec un taux d’échantillonnage de 100 Hz pour les données de positionnement en temps réel. L’unité Navion i2 intègre un capteur GNSS avec une précision inférieure à 10 cm en utilisant un service de correction RTK via des stations de base RTK.

Imagerie

Sept caméras haute vitesse Dewesoft DS-CAM-640c sont utilisées, dont six couvrent un champ de vision horizontal de 360° et une caméra centrale avec un objectif différent dédié à la vision loin devant.

Caractéristiques des caméras :

• Capteur d’imagerie : Sony IMX252 CMOS.

• Résolution maximale de 2048 x 1536 px avec une fréquence d’images de 200 fps.

• Comporte un obturateur global avec des temps d’exposition allant de 1 µs à 60 secondes.

• Plage dynamique : 71 dB.

Capteurs LiDAR

Quatre capteurs LiDAR sont installés :

• Ouster OS1 – placé centralement dans l’axe du véhicule, champ de vision de 360°

• Champ de vision horizontal de 360° et un champ de vision vertical de 45°.

• Résolution verticale de 128 faisceaux.

• Résolution de balayage horizontale de 0,25°, avec une précision de ±0,1°.

• Portée opérationnelle maximale de 200 m.

• Fréquence réglée à 20 Hz.

• Ouster OS2 – placé centralement dans l’axe du véhicule, application à longue portée,

• Champ de vision horizontal de 360° et un champ de vision vertical de 22,5°.

• Résolution verticale de 128 faisceaux.

• Portée opérationnelle maximale de 350 m.

• Fréquence de 20 Hz, configurable à 10 Hz.

• Deux Ouster Dome – placés en diagonale aux bords latéraux du véhicule,

• Champ de vision vertical de 180°.

• Résolution verticale de 128 faisceaux.

• Résolution de balayage horizontale de 0,7°.

• Portée opérationnelle maximale de 45 m.

Capteurs radar

Six capteurs radar sont installés :

• Deux DRVEGRD 152 – enregistrant l’espace devant et derrière le véhicule à longue distance

• Fonctionne dans la bande de 76 à 77 GHz.

• Taux d’échantillonnage de 16,6 Hz.

• Portée d’un minimum de 0,9 m à un maximum de 200 m.

• Fournit un angle horizontal de 100° et un angle vertical de 20°.

• Vitesses de suivi allant de -400 km/h à +200 km/h.

• Précision de distance évaluée à <0,45 m.

• Quatre DRVEGRD 169 – placés aux coins du véhicule

• Fonctionne dans la bande de 77 à 81 GHz.

• Le taux d’échantillonnage est de 16,6 Hz.

• Fonctionnement d’un minimum de 0,6 m à un maximum de 56 m.

• Fournit un angle horizontal de 130° et un angle vertical de 15°.

• Vitesses de suivi allant de -340 km/h à +140 km/h.

• Précision de distance évaluée à <0,3 m.

De plus, le système contient un système de gestion de l’alimentation et de la batterie basé sur REDARC.

Problèmes et solutions

Nous avons répondu aux exigences matérielles en sélectionnant des composants compatibles avec la plateforme DewesoftX. Le principal défi était l’intégration des capteurs LiDAR et radar, qui n’avaient pas été utilisés auparavant avec le logiciel.

Pour résoudre ce problème, les ingénieurs de Search, Dewesoft et Envibra ont conjointement développé un plug-in personnalisé qui a permis un contrôle direct des capteurs dans DewesoftX, éliminant ainsi le besoin de recourir à Ouster Studio, le logiciel natif des capteurs. Cela a pris un temps significatif en raison de la documentation limitée et de la complexité de la coordination avec les équipes responsables des fonctions individuelles de DewesoftX.

Voici un aperçu des principaux défis et de la manière dont ils ont été abordés.

Problème 1 : Extraire des scénarios courts à partir d’enregistrements plus longs

Résolu. DewesoftX prend déjà en charge la découpe de scénarios d’environ 20 secondes à partir de sessions d’enregistrement plus longues d’environ 10 minutes.

Problème 2 : Intégrer le système de mesure dans le véhicule

Résolu. Dans la mesure du possible, le système a été installé sans modifier la structure du véhicule. Par exemple, les radars ont été montés derrière les pare-chocs sans affecter l’extérieur du véhicule. Les capteurs installés n’interfèrent pas non plus avec les systèmes d’assistance à la conduite du véhicule.

Problème 3 : Monter le système sur le toit dans une enceinte amovible

Résolu. Nous avons conçu un dôme dédié monté sur un cadre, qui a ensuite été fixé à la galerie de toit en utilisant les rails de toit existants du véhicule. Cela a rendu l’ensemble de l’installation amovible.

Problème 4 : Monter les composants externes avec des plots adhésifs

Résolu. Les composants situés à l’extérieur du dôme ou de la carrosserie du véhicule ont été équipés à l’aide de solutions de montage adhésives. Cette approche est utilisée, par exemple, pour les antennes de navigation.

Problème 5 : Synchroniser toutes les données enregistrées avec une horloge centrale

Résolu. Tous les composants partagent la même référence temporelle. Nous avons mis en œuvre une architecture maître-esclave, la première caméra agissant comme maître et les composants restants comme esclaves. Dans la mesure du possible, la synchronisation a été gérée via le protocole de communication PTP.

Problème 6 : Acheminer les câbles tout en gardant les portes et les fenêtres fermées

Résolu. Nous avons conçu une gaine dédiée pour protéger et acheminer les câbles. La vitre de la porte arrière gauche a été retirée et remplacée par un panneau en plexiglas présentant une ouverture pour le tuyau de câbles. L’ensemble de l’assemblage a été scellé, et suffisamment de mou a été laissé dans les câbles pour permettre à la porte de s’ouvrir facilement. En conséquence, cette vitre n’est plus fonctionnelle.

Problème 7 : Fonctionner à des températures allant de -10°C à +40°C

Partiellement résolu. Le chauffage de 40 W installé à l’intérieur du dôme n’a pas fourni suffisamment de chaleur pour maintenir une température de fonctionnement appropriée dans des conditions très froides. En pratique, cela signifie que le système ne peut pas être utilisé en dessous de -5°C. Les performances de stockage restent non vérifiées, bien que le véhicule soit garé dans un garage.

Problème 8 : Enregistrer avec précision à des vitesses allant jusqu’à 130 km/h

Résolu. La galerie de toit est certifiée pour des vitesses allant jusqu’à 130 km/h, ce qui répond à l’exigence. Cependant, pour des raisons de sécurité, le véhicule n’est pas conduit à plus de 110 km/h pendant le fonctionnement.

Problème 9 : Fonctionner de manière fiable par mauvais temps pendant jusqu’à six heures

Résolu. Nous avons utilisé des capteurs, LiDAR et radars de qualité automobile conçus pour une utilisation en extérieur dans des conditions météorologiques exigeantes. Les caméras étaient logées à l’intérieur d’un dôme métallique scellé pour les protéger de l’humidité et de la poussière, tandis que la gaine de la vitre protégeait l’acheminement des câbles du vent et d’autres facteurs environnementaux.

Problèmes supplémentaires

• Poids du véhicule – après tous les assemblages, la voiture s’est avérée trop lourde. Elle est donc désormais immatriculée pour 3 passagers au lieu de 5.

• Objectifs des caméras qui s’embuent – en raison de la différence de température entre l’intérieur et l’extérieur du dôme, les trous des objectifs des caméras s’embuaient. Nous avons dû placer un absorbeur d’humidité dans le dôme.

• Commutateur de temps DewesoftX – lorsque la source de temps passe du GPS à l’oscillateur interne Brick2, alors le temps interne DewesoftX passe de l’UTC à l’TAI.

• HDR dans les caméras – malgré les informations dans les spécifications techniques, les caméras ne prenaient pas en charge le HDR/12 bits. Nous n’avons pas pu résoudre le problème.

• La caméra thermique n’envoie pas d’horodatages et ne prend pas en charge les protocoles de synchronisation – nous ne pouvons la synchroniser que de manière externe, et la synchronisation est instable.

• Les paramètres de balance des blancs des caméras dans certaines conditions (nuit, faible luminosité) se sont avérés changer spontanément même lorsque nous avons réglé l’option « Balance des blancs automatique » sur « Désactivé ». Le problème ne se produisait que lors du démarrage des caméras dans des conditions de très faible luminosité, et il n’affectait qu’une seule caméra dans le système (pas toujours la même caméra, et pas toutes les caméras en même temps). Nécessite une investigation plus approfondie.

• Pertes de signal – en quittant des zones sans connexion GSM (par exemple, dans des tunnels), le RTK n’est pas toujours capable de rétablir lui-même la communication GSM et nécessite une réinitialisation manuelle.

• Dans des conditions de faible luminosité, les caméras ajustent automatiquement l’exposition, augmentant le temps d’exposition. Auparavant, nous avions incorrectement réglé le temps d’exposition maximal à 1s/taux de rafraîchissement, ce qui ne laissait pas assez de temps pour terminer une image avant de commencer la suivante. Cette erreur a provoqué la perte de synchronisation de toutes les caméras. Nous avons résolu le problème en réduisant le temps d’exposition maximal de 100 microsecondes.

• Brick2 n’utilise pas NAVION i2 comme source de temps – après plus de 1,5 mois de tests et de développement, nous avons dû changer de concept. Maintenant, Brick2 utilise son propre GPS pour définir l’heure maître du système, avec NAVION i2 fonctionnant comme esclave. En raison de plusieurs autres problèmes, nous travaillons maintenant avec DS-IMU2.

• Des problèmes de synchronisation sporadiques provoquent des pertes de données LiDAR de l’ordre de la sous-seconde, bien qu’elles soient reçues et enregistrées à des fins d’aperçu ; nous n’avons pas encore résolu le problème.

Exemples d’enregistrements de capteurs

Le projet DARTS-PL va livrer une solution complexe pour le développement et les tests des algorithmes de perception des véhicules automatisés :

• Données brutes et annotées : un dépôt massif de données de conduite multimodales. À la fin du projet (05/2027), il y aura au moins 840 scénarios issus de plus de 100 segments d’infrastructure choisis.

• Portail web : un service de filtrage et de téléchargement pour des types de scénarios spécifiques (par exemple, « Nuit + Piéton »).

• Logiciel d’auto-annotation : des outils propriétaires pour le suivi des objets et l’étiquetage automatisé afin de réduire le travail manuel dans le développement ultérieur de la base de données.

Dans le projet, nous utilisons DewesoftX pour la capture des scénarios et l’exportation des données. Le logiciel aide à générer des données conformément aux règles spécifiques du projet. Ci-dessous, nous présentons plusieurs scènes exemples visualisées dans le logiciel DewesoftX :

Conclusion

DARTS-PL, en fournissant un jeu de données haute résolution, synchronisé et « spécifique à la Pologne », comble l’écart entre le code théorique et les conditions routières réelles. La nature en accès libre de la base de données garantit qu’elle servira d’infrastructure fondamentale pour les tests de perception des véhicules autonomes en Pologne et en Europe pendant de nombreuses années, favorisant l’innovation tout en garantissant les normes de sécurité les plus élevées.

Le projet est actuellement en phase d’acquisition de données et les premiers processus d’annotation commencent. Nous prévoyons de rendre les premières données disponibles au troisième trimestre 2026, et la base de données complète sera prête au premier semestre 2027.

Bibliography

1. Liu M, Yurtsever E, Fossaert J, et al. A survey on autonomous driving datasets: statistics, annotation quality, and a future outlook. IEEE Trans Intell Veh. 2024;9(11):7138-7164. doi:10.1109/TIV.2024.3394735

2. Hossain M, Islam MZ, Islam MS, et al. A comprehensive review on traffic datasets and simulators for autonomous vehicles. arXiv. Preprint posted online December 18, 2024. doi:10.48550/arXiv.2412.14207