Résumé
La pente de la route influence fortement la dynamique des véhicules. Elle impacte aussi la consommation énergétique et la sécurité. Pourtant, dans la plupart des simulateurs ou outils de mobilité, ce facteur est ignoré ou trop simplifié.
Dans le cadre du projet RoadSimulator3 (RS3), nous avons construit une chaîne complète d’analyse altimétrique. En effet, cette chaîne permet d’évaluer, comparer et servir différentes sources de données d’altitude à haute fréquence.
Cet article raconte la démarche. Nous partons de la comparaison des modèles numériques de terrain (MNT). Puis nous allons jusqu’à un micro-service Docker capable de répondre à des milliers de requêtes par seconde, en 10 Hz.
Introduction : pourquoi la pente est critique
Un conducteur le ressent immédiatement. Rouler à 80 km/h en côte ou en descente n’a rien à voir. L’effort moteur n’est pas le même. Le freinage non plus.
La pente modifie la charge mécanique, la dépense d’énergie et le risque en cas d’urgence. De plus, une descente longue peut chauffer les freins. À l’inverse, une côte raide fait grimper la consommation.
Pour un simulateur, ignorer la pente revient à tronquer une partie de la physique du véhicule. Par conséquent, on perd une part essentielle du réalisme.
👉 Exemple concret :
• Assurance : estimer la sévérité potentielle d’un freinage brusque en descente.
• Smart city : estimer finement les émissions de CO₂ le long d’un itinéraire vallonné.
• Flottes de livraison : prévoir le surcoût énergétique des tournées en côte.
La simulation haute fréquence (10 Hz, soit une mesure tous les 0,1 s) impose donc des données précises, rapides et stables. C’est précisément ce que nous avons voulu démontrer avec RS3.
Sources altimétriques et précision
Pour modéliser correctement la pente, il faut des données d’altitude fiables. Nous avons retenu quatre bases principales :
• IGN RGE ALTI® 1 m : la référence en précision (jusqu’au décimètre). Cependant, ce jeu de données est très lourd à manipuler.
• IGN RGE ALTI® 5 m : un compromis intéressant entre taille et qualité.
• SRTM 30 m : modèle global produit par la NASA. Il est plus léger, mais moins précis.
• SRTM 90 m : couverture mondiale, mais résolution faible.
Ainsi, toutes ces données ont été converties en Cloud Optimized GeoTIFF (COG).
De plus, ce format offre plusieurs avantages :
• accès rapide par tuiles,
• compatibilité directe avec Rasterio / GDAL,
• format ouvert pensé pour une exécution dans le cloud.
En pratique, nous pouvons interroger une tuile altimétrique à partir de coordonnées GPS ponctuelles. Nous n’avons pas besoin de charger des gigaoctets en mémoire.
Calcul de la pente réaliste
Calculer la pente à partir d’altitudes brutes semble simple. Cependant, la réalité est plus complexe. Le bruit GPS, les imprécisions de mesure et les discontinuités du MNT peuvent s’additionner. Ils créent alors des valeurs aberrantes.
Nous avons donc adopté une méthodologie pragmatique :
• Fenêtrage distance (20 à 30 m) : nous calculons la pente moyenne sur un segment, et non point par point.
• Lissage EMA (Exponential Moving Average) : ce lissage supprime le bruit sans perdre la réactivité.
• Clipping à ±30 % : toute pente au-delà de ±30 % est considérée comme aberrante. Elle est tronquée.
En effet, cette combinaison donne des pentes réalistes et stables. Elle reste exploitable pour une simulation dynamique à 10 Hz.
Architecture technique RS3
Le projet RS3 repose sur une architecture modulaire. De plus, chaque brique est clairement isolée en termes de licence et de rôle :
• Core RS3 (AGPL) : moteur de pipeline inertiel.
• Contracts (MIT) : interfaces neutres et réutilisables.
• Plugin Altitude (AGPL) : accès aux MNT et génération altitude/pente.
• Plugin Fleet (MIT) : simulation multi-véhicules.
Nous avons ensuite industrialisé cette brique sous la forme d’un service Flask. Le service est packagé avec Docker Compose.
Ce service expose deux endpoints principaux :
• /health → vérification des providers disponibles.
• /sample?lat=..&lon=..&provider=.. → retourne l’altitude pour un point donné.
Enfin, nous avons mesuré les performances avec un script bench_curl.sh.
• Latence moyenne ≈ 54 ms sur 500 requêtes concurrentes (16 threads).
• Débit ≈ 300 requêtes/s, extensible via scaling horizontal.
Ces résultats sont suffisants pour alimenter une flotte de plusieurs dizaines de véhicules en temps réel. Par conséquent, la mise à l’échelle ne dépend plus d’un fournisseur externe. Elle reste sous ton contrôle.
Résultats : précision et performance
Voici un exemple observé près de Rouen (49.45, 1.1) :
• RGE 1 m : 55.28 m
• RGE 5 m : 55.27 m
• SRTM 30 m : 56.0 m
• SRTM 90 m : 56.0 m
👉 L’écart IGN–SRTM reste modeste (environ 1 m). En effet, l’IGN offre surtout une bien meilleure granularité dans les variations locales.
Nous avons enrichi un trajet GPS map-matché (≈ 567k points). Chaque point a reçu l’altitude issue de chaque provider. Puis nous avons calculé la pente.
Les résultats sont les suivants :
• L’écart relatif IGN RGE1 vs IGN RGE5 est inférieur à 2 %.
• L’écart avec SRTM peut dépasser 10 % dans les zones vallonnées.
De plus, aucun timeout n’a été observé sur 500 requêtes concurrentes. Le temps de réponse reste stable (moins de 100 ms). Enfin, la consommation CPU est d’environ 20 % sur un Beelink N100 (quad‑core).
Applications métier
Assurance. Estimer la sévérité potentielle d’un accident en fonction de la pente au moment du freinage. Par conséquent, on peut mieux catégoriser le risque.
Smart city. Cartographier les émissions de CO₂ le long d’un itinéraire. De plus, la pente permet d’isoler les zones où un véhicule consomme anormalement.
Flottes de livraison. Optimiser la consommation énergétique et les temps de parcours. En effet, une tournée avec fortes côtes n’a pas le même coût qu’une tournée plate.
Recherche académique. Valider des modèles inertiels (IMU) avec un “ground truth” altimétrique fiable. Cela permet de rapprocher simulation et mesure terrain.
Conclusion : énergie, usure et sécurité
En combinant la pente, l’altitude et les signaux inertiels à 10 Hz, nous pouvons mieux comprendre la dépense énergétique. Nous pouvons aussi anticiper l’usure mécanique et évaluer le risque de conduite.
Cette brique RS3 ouvre la voie à un pilotage énergétique intelligent pour les flottes, pour la recherche et pour la sécurité routière.
👉 À lire aussi :
– Simulation inertielle 10 Hz – RoadSimulator3
– Virtual sensing consommation flotte sans CAN
– Détection d’événements de conduite par IMU embarquée