Comparaison entre les technologies du radar 24GHz et l’UWB

Radar 24 GHz

Le radar à 24 GHz utilise des ondes millimétriques pour détecter les mouvements et la présence. Cette fréquence offre un bon compromis entre portée de détection, résolution et pénétration à travers certains matériaux. Du moins, sur le papier. En effet, on se rend vite compte que la portée et la fiabilité sont très limitées en pratique avec les deux modèles que nous utilisons.

  • Avantages : Détection précise (à 10cm près), insensible à la lumière.
  • Applications potentielles : Détection de présence, monitoring d’activité, santé connectée
  • Portée : Variable selon le modèle, aucun n’ayant atteint les performances attendues.

UWB (Ultra-Wideband)

L’UWB est une technologie de communication et de localisation sans fil utilisant une très large bande de fréquences. Nous comparons ici ses performances avec notre système radar 24 GHz.

  • Avantages : très haute précision de localisation, faible consommation, passe sous les fréquences existantes donc déploiement possible à peu près partout…
  • Applications potentielles : Localisation en intérieur, suivi d’objets/personnes, IoT.
  • Portée : Environ 50m max en intérieur sans obstacles.

Comparaison des technologies

L’UWB est bien plus efficace sur de la détection de la localisation spécifique, à quelques centimètres près. Elle peut aussi faire de la gestion 3D bien plus efficace. Le radar 24 GHz est plus limité dans ces aspects mais théoriquement plus simple à mettre en œuvre et plus fiable sur du controle d’entrée/sortie plus traditionnel. Enfin, d’un point de vue fiabilité, les radars 24Ghz se gênent mutuellement si leur rayon d’action entre en contact avec celui d’un autre de leur congénères; et d’un point de vue solidité, l’UWB est plus robuste, mais malheureusement, il sera aussi plus énergivore sur les pics intenses transmission / réception. Cependant, quand il n’est pas utilisé et donc on mode sleep ou deepsleep, sa consommation est absolument dérisoire.

Complémentarité : On peut donc dire que les deux technologies ont leurs forces et faiblesses, et qu’une combinaison des deux pourrait offrir une solution optimale avec assez de temps de développement. L’UWB ne gênant pas les radars 24 GHz, et vice versa, une intégration conjointe pourrait maximiser les avantages de chaque technologie.

Critères de comparaison prévus

Critère Radar 24 GHz UWB
Précision de localisation Aléatoire entre 5 et 10 cm d’erreur (non conforme à l’objectif initial de ±5 cm) Centimétrique (généralement < 2 cm)
Portée de détection ~6 à 7 mètres (max 6,11 m avec BLE et 7 m environ sans BLE) 10 à 50 mètres en intérieur (selon l’environnement)
Détection à travers obstacles Limitée : traverse bois, plastique et carton ; le métal agit comme un réflecteur Excellente : traverse murs, bois et plastique (bloquée par le métal trop épais)
Consommation énergétique Consomme en moyenne 80 mA sous 5 V. Sa consommation peut monter jusqu’à 120 mA en pic d’opération Ultra-faible (souvent < 150 mW, voire < 50 µW en veille)
Coût du matériel de 1 à 3 euros. Se compte en dizaines ou centaines d’euros en fonction des modules choisis
Facilité d’intégration Moyenne : nécessite Python, MQTT pour de l’accessible Élevée : protocoles standards (IEEE 802.15.4z) et écosystème RTLS mature (85% du code d’utilisation déjà créé par le fabricant). Une forte interopérabilité entre marques de capteurs, c’est fiable, documenté et standardisé. Avec des composant prêt à l’emploi comme les puces Decawave.

Galerie photo et vidéos

Aperçu de notre installation et journée de tests labo

Cette section contiendra des photos de notre installation, lors de la journée de tests au laboratoire. On y voit les deux modules sur supports et les différents type de mesures prises.

Ordre d’utilisation et logique derrière les scripts

Voici le rôle précis de chaque élément de la partie de Lilian : le module COM (HLK-LD2420)

README.md : C’est le guide d’utilisation principal. Il explique comment cloner le dépôt, créer l’environnement virtuel Python, installer les dépendances et utiliser le service. On commence par consulter le fichier README.md pour comprendre les prérequis et les étapes d’installation.

install_service.sh : Ce script automatise toute l’installation. Il installe les dépendances système (python3-pip, paho-mqtt, serial), crée un utilisateur dédié nommé radar, prépare les répertoires et installe le fichier de service systemd. On exécute simplement le script install_service.sh pour préparer l’environnement technique.

mqtt_service.py : C’est le cœur du système. Cette classe gère la connexion série avec le module radar, décode les trames reçues (détection, distance, énergie par « gate »), publie ces données sur MQTT et écoute les commandes (reboot, changement de paramètres) envoyées par l’utilisateur.

MQTT_TOPIC.md : Ce fichier répertorie tous les « canaux » (topics) MQTT utilisés. Il documente le format des messages JSON envoyés par le radar (comme radar/{sn}/measurements/distance) et les commandes acceptées par le service. On se réfère à MQTT_TOPIC.md pour savoir comment les données vont circuler.

main.py : C’est le point d’entrée du programme. Il analyse les arguments de la ligne de commande (port série, adresse du broker MQTT, identifiants) et lance la boucle principale du service radar. On utilise main.py (qui s’appuie sur mqtt_service.py) pour vérifier que le radar communique bien.

radar-mqtt.service : C’est un fichier d’unité pour Linux (systemd). Il permet au script de se lancer automatiquement au démarrage de la machine et de redémarrer tout seul s’il plante. On utilise radar-mqtt.service pour que le programme tourne tout seul en arrière-plan.

Voici le lien GitHub du tutoriel que nous a fait Lilian !

Et ici, un résumé concis de la partie de Tristan : le module BLE (HLK-LD2410)

Le script Python conçu par Tristan Gouennou constitue le pilier technique de l’acquisition de données pour le module radar HLK-LD2410, s’appuyant sur les bibliothèques asyncio et Bleak pour piloter la communication Bluetooth Low Energy (BLE) et sur paho.mqtt pour l’export des résultats vers le broker de l’IUT.

Le processus débute par un scan itératif visant à localiser le périphérique par son nom (« HLK ») ou son adresse MAC, suivi d’une phase d’authentification et de configuration logicielle permettant de déverrouiller le mode ingénierie du radar via l’envoi de commandes hexadécimales spécifiques.

Le flux de données est ensuite traité en temps réel par un décodeur de trames qui valide l’intégrité binaire des paquets (vérification des en-têtes F4F3F2F1 et des pieds de page F8F7F6F5) pour extraire les distances de détection mobile et statique ainsi que les niveaux d’énergie associés. Pour pallier l’instabilité inhérente aux signaux radar, le code implémente un filtre de moyenne mobile basé sur une fenêtre de cinq échantillons, garantissant que seule la tendance majoritaire de l’état de présence et des distances lissées soit retenue.

Enfin, le script assure la publication des mesures sur le réseau MQTT de manière optimisée : les messages ne sont transmis que si une durée minimale s’est écoulée, si une variation de distance d’au moins 10 cm est constatée ou si un changement d’état survient, alimentant ainsi les topics structurés par numéro de série pour une exploitation immédiate par l’interface utilisateur du projet.

Enfin, dans cette troisième partie, on va voir un résumé de la partie de Marc : l’acquisition et le traitement des données envoyées sur le serveur MQTT

Ce script Python (graphique.py) a été conçu pour servir d’interface de monitoring en temps réel pour les mesures de distances issues du radar 24 GHz, une étape indispensable pour valider le comportement du capteur durant nos phases de tests. Techniquement, le programme s’appuie sur une architecture d’abonnement via le protocole MQTT, se connectant au broker de l’IUT pour intercepter les flux JSON circulant sur les topics du projet.

L’un des points clés de ce développement est la gestion de la « stabilité » des données : le signal des radars 24GHz étant naturellement sujet à du bruit ou des sauts de valeurs, nous avons implémenté un filtrage par moyenne glissante (sur 10 échantillons) pour lisser la courbe de détection.

Le script propose une expérience flexible dès le démarrage, c’était le point impératif attendu pour les différents tests et analyses, laissant l’utilisateur configurer la profondeur de l’historique (le nombre de lignes que l’on va chercher dans le fichier de log)et la taille de la fenêtre d’affichage (avant que la fenêtre glissante ne commence à faire avancer la courbe vers la droite, effaçant au fur et à mesure de l’écran les X premières lignes).

Parallèlement à la visualisation dynamique générée sous Matplotlib, le code assure la persistance des données en archivant chaque mesure reçue, selon un pré-traitement, dans un fichier NDJSON (le fichier de log en question), ce qui nous permet de conserver une trace propre pour des analyses ultérieures.

Enfin, en intégrant également une couche de sécurité SSL/TLS pour la communication et la connexion avec le serveur en MQTTS, cet outil ne se contente pas d’afficher des chiffres, mais stabilise et sécurise l’acquisition, facilitant ainsi l’interprétation des résultats que l’on a accumulés lors de notre preuve de concept.