PROJET FINAL_RESQ_Defne, Meritxell, Can, Yorgo, Toufic

DOCUMENTATION DE PROTOTYPAGE

ResQ Emergency

Dispositif de détection d'accident et d'alerte d'urgence automatique

Équipe ResQ

Defne Su KURTOGLU  •  Yorgo EL HADDAD  •  Can GENIS  •  Meritxell ALIÈ FÀBREGAS  •  Toufic BATACHE

Sorbonne Université  —  Cours de Prototypage  —  2025-2026

1. Définition du projet

1.1 Besoin identifié

Les accidents de la route constituent l'une des principales causes de mortalité dans le monde. Chaque année, 1,35 million de personnes perdent la vie sur les routes, soit plus de 3 600 décès par jour. Une part significative de ces décès, estimée à 13,2 %, pourrait être évitée si les secours intervenaient plus rapidement.

Des études montrent que lorsque les secours arrivent en moins de 7 minutes, le taux de mortalité est de 4,9. En revanche, lorsqu'il faut plus de 12 minutes, ce taux augmente à 11,9. La rapidité d'intervention est donc un facteur déterminant.

Le besoin central de ResQ naît d'une double contrainte :

• Les systèmes existants, notamment le système eCall obligatoire dans les véhicules européens depuis 2018, reposent sur les réseaux 3G et 4G, qui sont en cours de décommissionnement au profit du 5G. Cette migration rend progressivement eCall obsolète d'ici 2026, créant un vide critique dans la sécurité routière automatisée.

1.2 Utilisateurs cibles

ResQ est conçu pour être adapté à tout véhicule motorisé ou non motorisé, c’est à dire: 

• Les automobiles (voitures particulières, utilitaires)

• Motos, scooters

• Les vélos 

Cette cible représente 70 millions de véhicules en circulation. 

1.3 Fonctionnalité principale

La fonctionnalité principale de ResQ est la suivante :

1.4 Fonctionnalités secondaires

Fonctionnalités secondaires implémentées dans le prototype

• Géolocalisation GPS/GNSS : Le module SIM7670G intègre un récepteur GNSS permettant de déterminer les coordonnées précises du dispositif en temps réel, transmises avec chaque alerte.

• Détection d'incendie ou d'anomalie thermique : Le capteur infrarouge MLX90614 mesure la température ambiante sans contact. Une élévation anormale déclenche une alerte secondaire indépendante de la détection de choc.

• Connectivité satellite via Swarm (SpaceX) : En l'absence de couverture mobile, le module satellite Swarm prend le relais. Les messages d'urgence sont transmis en 30 à 60 secondes via la constellation de satellites basse orbite de SpaceX, sans frais mensuels supplémentaires.

• Buzzer piézoélectrique, LEDs RGB (4×4) et écran OLED informent l'utilisateur de l'état du dispositif et du déclenchement d'une alerte.

• Fenêtre d'annulation : Lors d'une fausse alarme, l'utilisateur dispose d'une fenêtre de 10 secondes pour annuler l'alerte manuellement via le bouton dédié.

• Déclenchement manuel d'urgence : L'utilisateur peut déclencher manuellement une alerte en maintenant le bouton d'urgence appuyé, même si aucun accident n'a été détecté automatiquement.

• Connectivité Wi-Fi et Bluetooth (BLE) : Permet la synchronisation avec l'application mobile et les mises à jour du firmware.

Fonctionnalités à envisager: 

On a essayé d'implémenter: 

• Module caméra OV2640 : qui nous permettrai de prendre une photographie de l’intérieur de la voiture pour savoir combien de personnes il y a dans le véhicule. Aussi, l’image sera envoyée aux secours pour leur donner encore plus d'informations sur l’accident pour qu’ils soient le mieux préparés. 

On a réussi à l’intégrer dans le prototype mais elle n’est pas fonctionnelle. 

2. Réflexions sur la problématique et veille sur l'existant

2.1 Analyse de la problématique

La réflexion à l'origine de ResQ repose sur un constat paradoxal : malgré les progrès considérables réalisés dans la prévention routière (ceintures de sécurité, airbags, systèmes ABS, contrôle de stabilité), la gestion de l'après-accident reste insuffisamment outillée, en particulier pour les véhicules qui ne disposent pas de systèmes embarqués modernes.

Plusieurs facteurs aggravent ce problème :

• Temps d'intervention trop long : Dans les zones rurales ou isolées, les secours peuvent mettre plus de 15 à 20 minutes à arriver, augmentant drastiquement le risque de décès.

• Victimes incapables d'alerter les secours : Après un impact violent, la victime peut être inconsciente, désorientée ou physiquement incapable d'utiliser son téléphone.

• Absence de solutions universelles et accessibles : Les systèmes de sécurité avancés sont souvent réservés aux véhicules haut de gamme récents, ou nécessitent un abonnement mensuel.

• Multiplication des usages : L'essor des deux-roues, des vélos électriques et des trottinettes crée de nouveaux besoins non couverts par les solutions existantes.

• Déploiement du réseau 5G : La migration vers la 5G conduit les opérateurs à décommissionner progressivement les réseaux 3G et 4G utilisés par le système eCall, le rendant obsolète d'ici 2026.

2.2 Benchmark des solutions concurrentes

Plusieurs solutions existent sur le marché pour pallier le problème de l'alerte d'urgence après un accident. Cependant, chacune présente des limites significatives qui ont motivé la conception de ResQ.

Le système eCall

Obligatoire dans tous les véhicules neufs vendus dans l'Union européenne depuis le 31 mars 2018, eCall est un système intégré qui déclenche automatiquement un appel au numéro d'urgence 112 en cas d'accident grave détecté par les airbags ou d'autres capteurs embarqués.

Limites principales :

• Il repose exclusivement sur les réseaux 2G, 3G et 4G. La migration vers la 5G entraîne le décommissionnement progressif de ces réseaux, ce qui rendra eCall non fonctionnel d'ici 2026 sans mise à jour matérielle des véhicules.

• Il n'est disponible que dans les véhicules neufs équipés dès la fabrication, les véhicules anciens, motos, vélos et scooters en sont exclus.

• Il ne dispose pas de connectivité satellite, en zone sans couverture mobile, il est inopérant.

• Il ne permet pas de notifier les proches ou les contacts d'urgence personnels.

L'Apple Watch (Emergency SOS et Crash Detection)

L'Apple Watch Ultra 2 et certains modèles récents disposent d'une fonction de détection de chute et de détection d'accident, ainsi que d'une connectivité satellite via GlobalStar pour envoyer des alertes en zones sans réseau.

Limites principales :

• Tarif prohibitif : Entre 400 € et 800 € selon le modèle, ce qui la rend inaccessible à une large partie de la population.

• La connectivité satellite gratuite est limitée à 2 ans puis facturée environ 69 €/an, sans garantie de service.

• Le réseau GlobalStar utilisé peut prendre jusqu'à 2 minutes pour transmettre un message d'urgence, contre 30 secondes pour Swarm (technologie intégrée à ResQ).

• Elle ne détecte pas les incendies ni les anomalies de température.

• Elle est fixée au poignet de l'utilisateur, dans un choc violent, elle peut se désolidariser ou être projetée.

Les dashcams intelligentes

Les caméras de tableau de bord modernes peuvent détecter des événements sur la route et enregistrer les images. Certaines disposent d'une connectivité mobile pour envoyer des notifications.

Limites principales :

• Elles ne déclenchent pas d'alerte automatique aux services d'urgence, elles enregistrent mais n'apportent pas.

• Elles sont exclusivement réservées aux véhicules à quatre roues avec un tableau de bord, et ne sont pas adaptées aux deux-roues ou aux vélos.

• Elles ne disposent pas de connectivité satellite.

• Leur batterie interne est généralement insuffisante pour fonctionner indépendamment du véhicule.

Les applications mobiles d'urgence (ex. : iSOS, bSafe, Life360)

Ces applications utilisent le GPS du smartphone et permettent de partager sa position avec des proches ou de déclencher une alerte manuelle.

Limites principales :

• Elles nécessitent que l'utilisateur soit conscient et capable d'utiliser son téléphone après l'accident.

• Elles dépendent entièrement de la couverture réseau mobile du smartphone.

• Elles ne peuvent pas détecter automatiquement un accident, elles sont purement réactives.

• Le smartphone peut être endommagé, éjecté ou hors de portée après un choc violent.

Les casques connectés pour motards (ex. : MET Helmet, Abus)

Certains casques de motocycliste intègrent des capteurs d'impact et une connectivité mobile pour alerter les secours en cas d'accident.

Limites principales :

• Ils sont exclusivement réservés aux motards et ne couvrent pas les autres types de véhicules.

• Leur fonctionnement est conditionné au port du casque, aucun bénéfice pour les conducteurs de voitures ou de vélos sans casque.

• Ils ne disposent pas de connectivité satellite.

• Le coût d'un casque connecté est élevé.

Le tableau comparatif suivant synthétise les forces et faiblesses de chaque solution par rapport à ResQ :

3. Explication des choix techniques

Chaque composant de ResQ a été sélectionné après une analyse comparative rigoureuse des alternatives disponibles sur le marché, en tenant compte de critères de performance, de coût, de taille et d'intégration dans l'écosystème du prototype.

3.1 Microcontrôleur principal : ESP32-S3

Le microcontrôleur ESP32-S3 (sous la forme du module Waveshare ESP32-S3-SIM7670G-4G) constitue le cerveau du dispositif. Ce choix repose sur plusieurs arguments :

• Connectivité intégrée : L'ESP32-S3 embarque nativement le Wi-Fi 802.11 b/g/n et le Bluetooth 5.0 (BLE), éliminant le besoin de modules séparés et réduisant la surface de la carte.

• Puissance de calcul : Avec deux cœurs Xtensa LX7 cadencés à 240 MHz et 512 Ko de RAM interne (extensible), il gère simultanément la lecture des capteurs, le traitement des données, la communication réseau et le contrôle de l'interface utilisateur.

• Accélération neuronale : L'ESP 32-S3 intègre des instructions d'accélération pour les réseaux de neurones, ouvrant la voie à une détection d'accident plus intelligente dans les versions futures.

• Compatibilité : Il supporte nativement le protocole I²C (pour le MPU-6050, le MLX90614 et l'écran), SPI, UART et l'interface caméra DVP (pour l'OV2640), simplifiant considérablement le câblage.

• Écosystème Arduino/ESP-IDF : La disponibilité de bibliothèques matures (Arduino Json, Adafruit NeoPixel, Adafruit GFX) a accéléré le développement du prototype.

• Rapport qualité/prix : À environ 49 $, il offre un rapport performance/coût imbattable pour ce type d'application.

Alternative considérée : Le Raspberry Pi Pico W a été écarté en raison de son absence de support natif BLE 5.0 et de sa RAM limitée. L'Arduino Mega a été exclu car il ne dispose ni de Wi-Fi ni de Bluetooth intégrés.

3.2 Module LTE et GPS : SIM7670G

Le module SIM7670G est intégré directement sur la carte Waveshare, couplée avec l'ESP 32-S3. Il assure deux fonctions critiques :

• Connectivité cellulaire LTE Cat-1 : Permet l'envoi de données (position GPS, heure, image) via le réseau mobile 4G en zone couverte. Le Cat-1 a été choisi car il offre un excellent équilibre entre débit (10 Mbps en downlink), consommation énergétique et coût, comparé au Cat-4 (plus gourmand) ou au NB-IoT (trop lent pour transmettre des images).

• Récepteur GNSS intégré : Le SIM7670G embarque un récepteur GPS/GNSS multi-constellation (GPS, GLONASS, BeiDou) qui fournit les coordonnées géographiques précises transmises avec chaque alerte. L'intégration du GPS dans le même module que le LTE évite le recours à un module GPS séparé, simplifiant le câblage et réduisant les coûts.

Justification du choix : L'alternative d'un module SIM800L (2G) a été écartée en raison de l'obsolescence programmée des réseaux 2G en France. Un module SIM 7600 (LTE Cat-4) a été considéré mais son coût plus élevé n'était pas justifié pour les besoins de ce prototype.

3.3 Capteur de mouvement : MPU-6050

Le MPU-6050 est le capteur central de détection d'accident. Il combine sur une seule puce :

• Un accéléromètre 3 axes (plage configurable : ±2g, ±4g, ±8g, ±16g)

• Un gyroscope 3 axes (plage configurable : ±250, ±500, ±1000, ±2000 °/s)

• Un processeur de mouvement numérique (DMP) permettant le calcul de la fusion des données capteurs directement sur la puce

Son interface I²C simplifie le câblage (seulement 2 fils SDA/SCL en plus de l'alimentation). Il est connecté sur les GPIO 42 (SDA) et 1 (SCL) de l'ESP 32-S3, avec une fréquence de bus I²C de 100 kHz (paramétrable à 400 kHz).

La détection d'accident repose sur l'analyse en temps réel des valeurs d'accélération et de rotation. Un seuil de détection de choc (shock threshold) est défini dans le firmware : si les valeurs mesurées dépassent ce seuil sur une ou plusieurs axes, la procédure d'alerte est déclenchée.

Justification : Le MPU-6050 est très répandu, bien documenté, et ses bibliothèques Arduino sont matures. Son coût (environ 2 €) le rend idéal pour un prototype. Pour la version de production, un capteur industriel comme le LSM6DSO32 (STMicroelectronics) pourrait offrir de meilleures performances en termes de robustesse et de précision.

3.4 Capteur de température infrarouge : MLX90614

Le MLX90614 est un thermomètre infrarouge sans contact. Il mesure la température ambiante et la température de l'objet visé dans une plage de -70°C à +380°C avec une précision de ±0,5°C.

Dans ResQ, il est utilisé pour détecter les anomalies thermiques qui pourraient indiquer un début d'incendie dans ou autour du véhicule. Son interface I²C lui permet de partager le bus avec le MPU-6050.

Justification : Aucun contact physique n'est nécessaire pour la mesure, ce qui le rend robuste aux vibrations et aux contaminations. Son faible coût (environ 5 €) et sa disponibilité immédiate en ont fait le choix naturel pour ce prototype.

3.5 Module satellite : Swarm (SpaceX)

Le module Swarm est la composante la plus innovante de ResQ. Il permet de transmettre des messages d'urgence via la constellation de 150 nano-satellites en orbite basse (LEO) exploitée par Swarm Technologies, filiale de SpaceX.

• Couverture globale : Les satellites Swarm couvrent l'intégralité de la surface terrestre, permettant l'envoi de messages depuis n'importe quel endroit du globe, y compris en montagne, en mer ou dans des zones rurales sans couverture mobile.

• Délai de transmission : En moyenne 30 à 60 secondes, nettement inférieur aux 2 minutes du réseau GlobalStar utilisé par Apple Watch.

• Coût inclus : Contrairement aux systèmes concurrents qui facturent un abonnement mensuel, le coût de la connectivité satellite est inclus dans le prix d'achat du dispositif ResQ.

• Basse consommation : Le module Swarm est conçu pour les applications IoT basse consommation, compatible avec une alimentation sur batterie.

3.6 Interface utilisateur

LEDs RGB NeoPixel (4×4 = 16 LEDs)

La grille de 16 LEDs RGB adressables (type WS2812B, connectées sur le GPIO 41) constitue l'indicateur visuel principal. Les couleurs et animations sont programmées pour signaler différents états : veille, alerte en cours, envoi du message, confirmation. La bibliothèque Adafruit NeoPixel (version 1.12.5) est utilisée pour le contrôle.

Buzzer piézoélectrique

Le buzzer produit des signaux sonores d'alerte lors du déclenchement de la procédure d'urgence. La bibliothèque Non-Blocking Melody (version 1.0.4) permet de jouer des mélodies sans bloquer la boucle principale du programme.

Écran OLED SSD1306

Un écran OLED (piloté via I²C, bibliothèque Adafruit GFX version 1.12.0) affiche en temps réel l'état du dispositif : mode veille, données capteurs (accélération X/Y/Z, température), état de connexion (LTE/satellite), et messages de statut. À l'initialisation, l'écran affiche successivement les confirmations de démarrage de chaque module.

Boutons physiques

Trois boutons sont intégrés au dispositif :

• Bouton d'annulation (Cancel) : permet d'annuler une alerte dans la fenêtre de 10 secondes.

• Bouton menu : permet de naviguer dans l'interface de l'écran.

• Bouton multifonction : déclenche manuellement une alerte d'urgence.

3.7 Module caméra : OV2640

Le module caméra OV2640 (résolution 2 mégapixels) est connecté à l'interface DVP de l'ESP32-S3. Il peut capturer une image au moment de l'incident pour la transmettre avec le message d'alerte. La bibliothèque base64_encode (version 2.0.4) est utilisée pour encoder l'image avant transmission via MQTT.

Remarque : Dans la version actuelle du prototype, la transmission de l'image est fonctionnelle via Wi-Fi/MQTT mais pas encore intégrée à la transmission satellite (contrainte de taille du message).

3.8 Alimentation : batterie 18650 Li-ion

Le prototype est alimenté par une batterie rechargeable 18650 (3.7 V, 6 800 mAh). Le circuit de gestion de charge (TP4056 ou MAX17048G) assure la supervision de la charge et décharge, ainsi que la protection contre les surcharges. La capacité choisie garantit une autonomie suffisante pour une utilisation continue.

3.9 Architecture logicielle

Le firmware est développé en C++ sous l'environnement Arduino IDE pour ESP32. L'architecture modulaire repose sur des fichiers header séparés pour chaque fonctionnalité :

• at lte.h : Gestion du modem SIM7670G (connexion réseau, envoi de données, lecture GPS)

• at wlan client.h : Gestion de la connexion Wi-Fi

• at_mqtt.h : Communication cloud via le protocole MQTT

• at camh : Contrôle du module caméra

• at MLX90614.h : Lecture du capteur de température

• src/imu.h : Lecture et traitement des données du MPU-6050

• src/display.h : Contrôle de l'écran OLED

• src/flow.h : Machine à états principale (logique de détection et d'alerte)

• src/buttonDsk.h : Gestion des interruptions des boutons

La boucle principale (loop()) s'exécute en continu et appelle la fonction flow() qui implémente la machine à états : surveillance → détection de choc → fenêtre d'annulation → envoi d'alerte → retour en veille.

3.10 Détail de la machine à états : src/flow.h

Le fichier src/flow.h constitue le cœur logique du firmware. Il implémente la fonction flowadnan(), appelée en boucle continue dans loop(), qui gère l'ensemble des transitions entre les différents états du système via une machine à états finis.

Les états définis (STATE) sont les suivants :

• OPERATE - Mode surveillance normale : les valeurs des 6 axes (gyroX, gyroY, gyroZ, accelX, accelY, accelZ) sont lues en continu et affichées sur l'écran OLED. Si abs(valeur) > 4 sur l'un des axes, la variable kaza (kaza signifie « accident » en turc) passe à true et le système bascule en WAIT_ACC.

• WAIT_ACC - Choc détecté automatiquement : un compte à rebours de 10 secondes (stateTO.set(10)) est lancé. L'utilisateur peut annuler via le bouton CANCEL. Sans réaction, la fonction ACCIDENT() est appelée et l'écran affiche "Sending Message".

• WAIT_SOS - Déclenchement manuel via le bouton SOS : compte à rebours de 1 seconde avant envoi de l'alerte via la fonction SOS().

• ACCIDENT / SOS - Alerte envoyée : le système attend 300 secondes avant de retourner en mode OPERATE. L'utilisateur peut également annuler via CANCEL, ce qui déclenche la fonction NOPROBLEM().

• MENU - Menu de configuration du mode véhicule, avec timeout automatique de 15 secondes. Trois modes sont disponibles : Car (voiture), Scooter, et Kid (enfant). Ce dernier mode illustre la polyvalence du dispositif, qui peut être adapté à des usages spécifiques avec des seuils de détection différents selon le type de véhicule.

Diagramme de transitions :

OPERATE

  ├─ choc détecté (kaza=true)  ──► WAIT_ACC ──► (10s sans annulation) ──► ACCIDENT

  ├─ bouton SOS pressé         ──► WAIT_SOS ──► (1s sans annulation)  ──► SOS

  └─ bouton MENU pressé        ──► MENU ──► (sélection mode véhicule) ──► OPERATE

WAIT_ACC / WAIT_SOS

  └─ bouton CANCEL             ──► OPERATE (alerte annulée)

ACCIDENT / SOS

  ├─ timeout 300s              ──► OPERATE

  └─ bouton CANCEL             ──► OPERATE + NOPROBLEM()

MENU

  ├─ timeout 15s               ──► OPERATE

  ├─ bouton CANCEL             ──► OPERATE

  └─ bouton MENU (confirmer)   ──► OPERATE (workMode mis à jour)

Cette architecture garantit qu'aucune action humaine n'est requise pour déclencher l'alerte d'urgence : si l'utilisateur est inconscient après un choc, le système procède automatiquement à l'envoi du message au terme du compte à rebours. 

Le Code: 

void flowadnan() { 

   int bts = 0;

   bool kaza = false;

#ifdef buttonDsk

   bts = checkBtnState();

   //if (bts==1) alert.accepted();

   //if (bts==2) alert.refused();

   //if (bts==3) alert.done();

#endif

#define BTN_SOS    (checkBtnState() == 1)

#define BTN_CANCEL (checkBtnState() == 2)

#define BTN_MENU   (checkBtnState() == 3)

#ifdef DSP

   //display_show();

   LOGI("\nFLOW ---- LOOP\n");

#endif

   if (state == STATE::OPERATE) {

#ifdef DSP

       display.clearDisplay();

       display.setTextSize(1);

       display.setCursor(0, 0);

       display.print("State=");

       display.println(int(state));

       display.setCursor(45, 0);

       display.print("bts=");

       display.println(bts);

       display.setCursor(85, 0);

       if(workMode == 1) display.print("CAR");

       if(workMode == 2) display.print("SCTOR");

       if(workMode == 3) display.print("KID");

       display.display();

#endif

#ifdef  IMU_SENS

       int dumm = gyroData.gyroX;

       if (abs(dumm) > 4) kaza = true; 

#endif

#ifdef DSP

       display.setCursor(10, 10); 

       display.print("x=");

       display.print(dumm);

#endif

#ifdef  IMU_SENS

       dumm = gyroData.gyroY;

       if (abs(dumm) > 4) kaza = true;

#endif

#ifdef DSP

       display.setCursor(55, 10);

       display.print(" Y=");

       display.print(dumm);

#endif

#ifdef  IMU_SENS

       dumm = gyroData.gyroZ;

       if (abs(dumm) > 4) kaza = true;

#endif

#ifdef DSP

       display.setCursor(80, 10);

       display.print(" Z=");

       display.print(dumm);

       display.display();

#endif

#ifdef  IMU_SENS

       dumm = accelData.accelX;

       if (abs(dumm) > 4) kaza = true;

#endif

#ifdef DSP

       display.setCursor(10, 20);

       display.print(" Ax=");

       display.print(dumm);

       display.display();

#endif

#ifdef  IMU_SENS

       dumm = accelData.accelY;

       if (abs(dumm) > 4) kaza = true;

#endif

#ifdef DSP

       display.setCursor(55, 20);

       display.print(" Ay=");

       display.print(dumm);

       display.display();

#endif

#ifdef  IMU_SENS

       dumm = accelData.accelZ;

       if (abs(dumm) > 4) kaza = true;

#endif

#ifdef DSP

       display.setCursor(80, 20);

       display.print(" Az=");

       display.print(dumm);

       display.display();

#endif

       bts = checkBtnState();

       if (kaza == true) {

           zaman = millis(); 

           alert.wait();

           stateTO.set(10);

           state == STATE::WAIT_ACC;

       } else if (BTN_SOS) {

           zaman = millis(); 

           alert.wait();

           stateTO.set(1);

           state == STATE::WAIT_SOS;

       } else if (BTN_MENU) {

           state = STATE::MENU;

           menuzaman = millis();

           menusecim = 1;

           menusecimold = 0;

           clearBtnState();

       }

   }

   else if (state == STATE::WAIT_ACC) {

       if (stateTO()) {

           ACCIDENT();

#ifdef DSP

           display.clearDisplay();

           display.setTextSize(2);

           display.setCursor(0, 0);

           display.print("Sending");

           display.setCursor(0, 40);

           display.print("Message");

           display.display();

#endif

           alert.alarm();

           state = STATE::ACCIDENT;

           stateTO.set(300); // 300 second wait in alarm state

       }

       else if (BTN_CANCEL) {

           state = STATE::OPERATE;

           alert.stop();

       }

   }

   else if (state == STATE::WAIT_SOS) {

       if (stateTO()) {

           SOS();

#ifdef DSP

           display.clearDisplay();

           display.setTextSize(2);

           display.setCursor(0, 0);

           display.print("Sending");

           display.setCursor(0, 40);

           display.print("Message");

           display.display();

           alert.alarm();

#endif

           state = STATE::ACCIDENT;

           stateTO.set(300); // 300 second wait in alarm state

       }

       else if (BTN_CANCEL) {

           state = STATE::OPERATE;

           alert.stop();

       }

   }

   else if (state == STATE::ACCIDENT || state == STATE::SOS) {

       if (stateTO()) {

           state = STATE::OPERATE;

           alert.stop();

       }

       else if (BTN_CANCEL) {

           state = STATE::OPERATE;

           alert.stop();

           NOPROBLEM();

       }

   } 

   else if (state == STATE::MENU) {

       if((millis() - menuzaman) > 15000) {

           state = STATE::OPERATE;

       }

       bts = checkBtnState();

       if (menusecimold != menusecim) {

           if (menusecim == 1) {

#ifdef DSP

               display.clearDisplay();

               display.setTextSize(1);

               display.setCursor(60, 0);

               display.print("MENU");

               display.setCursor(0, 10);

               display.print("->Car");

               display.setCursor(0, 20);

               display.print("--Scooter");

               display.setCursor(0, 30);

               display.print("--Kid");

               display.display();

#endif

               menusecimold = 1;

           }

           if (menusecim == 2) {

#ifdef DSP

               display.clearDisplay();

               display.setTextSize(1);

               display.setCursor(60, 0);

               display.print("MENU");

               display.setCursor(0, 10);

               display.print("--Car");

               display.setCursor(0, 20);

               display.print("->Scooter");

               display.setCursor(0, 30);

               display.print("--Kid");

               display.display();

#endif

               menusecimold = 2;

           }

           if (menusecim == 3) {

#ifdef DSP

               display.clearDisplay();

               display.setTextSize(1);

               display.setCursor(60, 0);

               display.print("MENU");

               display.setCursor(0, 10);

               display.print("--Car");

               display.setCursor(0, 20);

               display.print("--Scooter");

               display.setCursor(0, 30);

               display.print("->Kid");

               display.display();

#endif

               menusecimold = 3;

           }

       }

       if (BTN_SOS) {

           menusecim = menusecim + 1;

           menuzaman = millis();

           if (menusecim > 3)menusecim = 1;

       }

       if (BTN_CANCEL) {

           state = STATE::OPERATE;

       }

       if (BTN_MENU) {

           workMode = menusecim;

           state = STATE::OPERATE;

       }

   }

   clearBtnState();

4. Gestion de projet

4.1 Minimum Viable Product (MVP)

Le concept de Minimum Viable Product (MVP) désigne la version la plus réduite du produit qui permet de valider les hypothèses fondamentales du projet et de tester la réponse des utilisateurs. Pour ResQ, le MVP a été défini comme suit :

Ce MVP exclut délibérément les fonctionnalités secondaires complexes (connectivité satellite, transmission d'image, détection de passagers) pour se concentrer sur la validation du concept core : détection → alerte → transmission.

4.2 Planification du projet

Le projet a été développé en plusieurs phases successives, depuis la conception jusqu'au prototype final :

4.3 Répartition des tâches

5. Croquis et dimensions

Cette section présente les croquis conceptuels du dispositif ResQ et les dimensions clés retenues pour la conception du boîtier. Les visuels détaillés (photos, plans cotés) sont disponibles dans les diapositives de présentation accompagnant cette documentation.

5.1 Dimensions du boîtier

5.2 Principes de design

Dès la conception, la priorité a été donnée à la compacité et à la discrétion. Le boîtier a été pensé pour s'intégrer harmonieusement dans n'importe quel habitacle ou cadre de vélo, sans encombrer l'espace de conduite.

• Face avant : écran OLED (1,83 pouces), grille de LEDs RGB 4×4, buzzer

• Face latérale gauche : bouton d'annulation (rouge, bien visible)

• Face latérale droite : bouton multifonction / déclenchement manuel

• Face inférieure : connecteur USB-C pour la charge, antenne externe pour le LTE et le GPS

• Face arrière : interface de fixation (système magnétique ou vis)

Le choix du polycarbonate (PC) pour le boîtier est motivé par ses propriétés mécaniques exceptionnelles : résistance aux chocs équivalente aux casques de moto, légèreté, stabilité thermique entre -40°C et +120°C, et bonne résistance aux UV pour un usage en extérieur prolongé.

Note : Les croquis cotés et les fichiers de conception 3D (format STL/STEP) sont présentés dans les diapositives de la section 7.

6. Liste du matériel

Le tableau suivant recense l'ensemble des composants utilisés dans le prototype ResQ, avec leurs références, coûts estimés unitaires et quantités. Les prix sont donnés à titre indicatif pour une production unitaire (prototype) — les coûts de série sont significativement inférieurs.

6.1 Bibliothèques logicielles utilisées

Les bibliothèques suivantes ont été utilisées dans le développement du firmware :

6.2 Coût total du prototype (unité)

7. Fichiers de conception et étapes de création

7.1 Conception du boîtier — CAO 3D

Le boîtier de ResQ a été conçu sous Fusion 360 (D'autodesk), un logiciel de CAO paramétrique accessible gratuitement pour les étudiants. Les étapes de conception ont été les suivantes :

• Étape 1 — Modélisation des contraintes : mesure de tous les composants internes (PCB, batterie, écran, LEDs) pour définir les dimensions minimales du boîtier.

• Étape 2 — Conception de la coque inférieure : modélisation de la base avec les supports de visserie pour le PCB, les passages pour les câbles et le connecteur USB-C.

• Étape 3 — Conception du couvercle supérieur : intégration des ouvertures pour l'écran OLED, la grille de LEDs, le buzzer et les trois boutons.

• Étape 4 — Système de fixation : conception d'une interface de montage compatible avec une fixation magnétique et une fixation par vis M3 pour différents types de supports.

• Étape 5 — Impression 3D : fabrication du boîtier sur imprimante FDM (PLA dans un premier temps pour le prototype, polycarbonate prévu pour la version finale) avec des paramètres de remplissage à 30 % et une épaisseur de paroi de 2 mm.

7.2 Conception du PCB

Le schéma électronique et le routage du PCB ont été réalisés sous KiCad (logiciel libre). La fabrication a été confiée à NextPCB (Shenzhen, Chine), partenaire sélectionné pour ses délais compétitifs et son interface de devis en ligne.

Les principales étapes de conception du PCB :

• Schéma électronique : définition de toutes les connexions entre l'ESP 32-S3, le MPU6050, le MLX90614, les LEDs, le buzzer, l'écran et les boutons.

• Attribution des empreintes (footprints) : chaque composant a été associé à son empreinte physique dans la bibliothèque KiCad.

• Routage des pistes : définition des largeurs de pistes (0,25 mm minimum pour les signaux, 0,8 mm pour les alimentations), respect des règles de design (DRC).

• Génération des fichiers Gerber : exportation des fichiers de fabrication (couches cuivre, masque de soudure, sérigraphie, perçages)

Figure 1 - Schéma électronique du dispositif ResQ (KiCad)

Figure 2 - Routage du PCB ResQ (KiCad)

7.3 Structure du firmware

Le firmware est organisé en modules indépendants, chacun responsable d'une fonctionnalité spécifique. Le fichier principal (ResQ dsk copy.ino) initialise tous les modules dans setup() et appelle la fonction flow() dans loop() :

8. Analyse des tests

8.1 Tests du prototype - Accéléromètre et gyroscope (MPU-6050)

Les tests ont porté sur la vérification du bon fonctionnement du capteur MPU-6050, qui constitue le cœur de la détection d'accident. Le module combine un accéléromètre 3 axes et un gyroscope 3 axes, dont les valeurs sont lues en temps réel par l'ESP32-S3 et affichées en continu sur l'écran OLED du prototype (axes gyroX, gyroY, gyroZ et accelX, accelY, accelZ).

Figure 3 - Prototype en mode veille : écran OLED affichant "ResQ"

Figure 4 - Prototype en mode alerte : LEDs RGB allumées en rouge, écran affichant "Sending message"

Vérification du fonctionnement de l'accéléromètre et du gyroscope

En position de repos, les six valeurs affichées sur l'écran se stabilisent autour de zéro, ce qui confirme la bonne initialisation et la calibration correcte du capteur. Lors de mouvements brusques appliqués manuellement au prototype (secousses, chocs sur la table, rotations rapides), les valeurs sur les axes concernés réagissent de façon immédiate et cohérente, validant la sensibilité et la réactivité du MPU-6050.

Seuil de détection et logique d'alerte

Dans le firmware du prototype, la détection d'un accident est déclenchée dès que la valeur absolue de l'un des six axes (gyroX, gyroY, gyroZ, accelX, accelY, accelZ) dépasse le seuil de 4 :

• if (abs(valeur) > 4) → kaza = true  (kaza signifie « accident » en turc)

• La condition est évaluée indépendamment sur chacun des six axes — un seul axe suffisant à déclencher l'alerte.

Test de détection de choc et envoi du message d'urgence

Une fois le bon fonctionnement des capteurs confirmé, des tests de détection ont été réalisés en appliquant des impacts physiques sur le prototype. Lorsqu'un choc dépassant le seuil est détecté sur au moins un axe :

• Le dispositif bascule immédiatement en état d'alerte — les LEDs RGB s'allument et le buzzer retentit.

• Une fenêtre de 10 secondes s'ouvre pour permettre l'annulation manuelle.

• En l'absence d'annulation, le message d'urgence (contenant les coordonnées GPS et un horodatage) est envoyé automatiquement via LTE.

9. Conception et impression 3D du boitier

La conception et la fabrication du boîtier ont constitué une étape centrale du prototypage. Le boîtier doit protéger l'électronique, accueillir tous les composants, et offrir un accès ergonomique aux boutons, à l'écran et aux connecteurs.

9.1 Logiciel de tranchage : Prusa Slicer

Le fichier de conception CAO a été importé dans Prusa Slicer pour générer le code envoyé à l'imprimante Prusa MK4S.

9.2 Paramètres d'impression

Figure 5 - Impression 3D du boitier sur imprimante Prusa MK4S

9.3 Evolution du boîtier - 3 versions

Trois versions du boîtier ont été conçues et imprimées successivement. Chaque itération a permis de corriger les problèmes identifiés lors de l'assemblage de la version précédente.

Version 1 - Premier boitier

Le premier boîtier a été conçu à partir des dimensions théoriques des composants. Lors de l'assemblage, il s'est avéré trop petit pour accueillir l'ensemble des composants avec les câbles de connexion.

Figure 6 - Version 1 du boîtier (PLA noir)

Version 2 - Boîtier agrandi (PLA rouge)

Contrairement à la première version réalisée de manière amateur, cette itération s'est concentrée sur une méthodologie rigoureuse. Grâce à un accompagnement technique ponctuel du Fablab de Dassault Systèmes, nous avons pu clarifier les étapes de conception nécessaires avant de passer à la modélisation 3D.

Les modifications majeures apportées sont les suivantes :

• Optimisation de l'espace interne : Création d'une zone libre plus spacieuse pour permettre aux câbles de se loger librement sans contrainte mécanique.

• Interface utilisateur : Intégration de découpes hexagonales pour les boutons afin d'assurer une meilleure compatibilité ergonomique et esthétique.

• Positionnement du buzzer : Réajustement des dimensions pour un placement optimal et une meilleure diffusion sonore.

Figure 7 - Version 2 du boîtier (PLA rouge) avec les composants électroniques

Version 3 - Boitier final (en cours d'impression)

La version 3 constitue l'aboutissement du processus itératif, intégrant les corrections des versions précédentes pour un prototype fonctionnel complet.

Figure 8 - Version 3 du boîtier (PLA gris)

Les améliorations clés incluent :

• Design asymétrique et diagonal : Introduction d'une ouverture diagonale sur la partie supérieure du boîtier. Cette modification permet une visibilité directe et optimale du panneau LED d'alerte tout en offrant un aspect plus technologique.
  
  

• Correction des ouvertures : Réajustement précis du diamètre des découpes hexagonales et circulaires pour correspondre parfaitement aux composants réels.
  
  

• Finalisation de la façade : Préparation du design pour une couverture en PMMA transparent, validant l'alignement final entre l'électronique et la coque.

9.4 Leçons apprises

Ce processus itératif, passant de la version 1 à la version 3, nous a permis de tirer des conclusions fondamentales pour le prototypage rapide d'un dispositif électronique embarqué :

• Gestion de l'encombrement réel : Nous avons appris que les dimensions théoriques des composants ne suffisent pas à définir le volume interne du boîtier. Il est impératif de prendre en compte le volume occupé par le câblage, les connecteurs et les marges de manœuvre nécessaires à l'assemblage manuel.
  
  

• Importance des tolérances d'impression : La version 2 nous a montré que les diamètres des découpes (notamment hexagonales) doivent inclure une marge de tolérance (offset) pour compenser la rétraction du plastique ou l'imprécision de l'imprimante 3D.
  
  

• Optimisation de l'angle de vue : L'ajout de la découpe diagonale en version 3 a démontré que le design industriel ne doit pas être seulement protecteur, mais doit activement servir l'interface utilisateur (UI) en facilitant la lecture des signaux d'alerte (LED et OLED).
  
  

• Anticipation de la fabrication multi-matériaux : Le passage d'un boîtier entièrement fermé à un système avec une couverture transparente en PMMA (découpe laser) nous a appris à gérer les interfaces entre deux méthodes de fabrication différentes (impression 3D et laser) pour obtenir un produit fini professionnel.
  
  

• Méthodologie de conception (CAD) : L'utilisation de la conception paramétrique sous Fusion 360 s'est avérée indispensable pour ajuster rapidement les dimensions globales sans avoir à reconstruire l'intégralité du modèle à chaque itération.

10. Conception et découpe laser d’une couverture pour le boitier

En parallèle de la conception du boîtier imprimé en 3D, nous avons exploré la possibilité de fabriquer une couverture transparente par découpe laser. Cette approche permet d’obtenir une couverture solide mais non opaque, à travers laquelle il est possible de voir le contenu du dispositif, en particulier l’écran et les LEDs, tout en apportant au produit une esthétique plus technologique et avancée.

Une première version de la façade a été conçue en parallèle de la version 2 du boîtier, qui ne comportait pas encore d’inclinaison sur sa partie supérieure. La couverture pouvait donc être réalisée sous forme d’une seule pièce plane. Afin de valider rapidement les dimensions et le positionnement des éléments, cette version a été prototypée en bois MDF 6mm par découpe laser.

Cette première façade comprenait deux ouvertures hexagonales pour les boutons, correspondant à la configuration du boîtier V2 et le logo ResQ était gravé sur la surface afin de tester le rendu visuel de la gravure. Ce prototype rapide nous a permis de vérifier l’alignement des ouvertures et les proportions générales avant d’itérer sur le design.

Figure 9 - Prototype de couverture de la version 2 du boîtier (bois MDF 6mm)

Suite à cette première itération, la version 3 du boîtier a introduit une inclinaison sur la partie supérieure, ce qui ne permettait plus d’utiliser une seule plaque plane. La façade a donc été redessinée en deux pièces distinctes, chacune correspondant à une surface du boîtier. Comme précédemment, cette version a également été prototypée en bois MDF 6mm afin de valider la géométrie et l’ajustement des pièces avant la fabrication finale dans le matériau définitif.

Dans un premier temps, seule une des deux pièces de la façade a été réalisée pour ce test. Cette pièce ne constituait pas encore une version finale du prototype : elle comprenait uniquement les découpes principales (cutouts) nécessaires pour vérifier les dimensions et le positionnement des éléments. Les détails de finition, tels que le logo gravé, les rayons d’arrondi des coins ou les ajustements esthétiques, n’ont pas été intégrés à ce stade. L’objectif était simplement de valider rapidement les dimensions et l’alignement des ouvertures avant de produire une version complète.

Figure 10 - Prototype de couverture en une seule pièce, pour version 3 du boitier (bois MDF 6mm)

Dans un second temps, les deux pièces de la façade ont été réalisées correctement, en intégrant cette fois l’ensemble des éléments de la version finale. Cette nouvelle configuration comprend une seule ouverture pour le bouton situé sur la façade, ainsi que deux ouvertures circulaires destinées à la caméra et au microphone. Le logo ResQ a également été gravé, comme prévu dans le design final.

Figure 11 - Prototype de couvertures de la version 3 du boîtier (bois MDF 6mm)

Après validation du design, la version finale a été découpée au laser dans du PMMA extrudé transparent 3mm. Ce matériau a été choisi pour sa rigidité, sa transparence et la qualité de finition obtenue lors de la découpe laser. Cette couverture permet de voir les éléments internes du dispositif, notamment l’écran et les LEDs, tout en protégeant l’électronique. La pièce finale comprend les ouvertures précises pour le bouton, la caméra et le microphone, ainsi que le logo ResQ gravé, donnant au prototype un aspect plus propre et plus professionnel.

Figure 12 - Version finale de couvertures de la version 3 du boîtier (PMMA extrudé 6mm)

11. Réflexions sur les pistes d'amélioration et d'évolution

11.1 Améliorations techniques du prototype actuel

L'analyse des tests et du développement du prototype a mis en évidence plusieurs axes d'amélioration prioritaires :

Amélioration de l'algorithme de détection d'accident

L'algorithme actuel repose sur un simple seuil des valeurs brutes de l'accéléromètre. Des approches plus sophistiquées seraient bénéfiques :

• Fusion de capteurs (sensor fusion) : combiner les données de l'accéléromètre, du gyroscope et potentiellement d'un baromètre pour différencier plus précisément les types d'événements (chute, collision frontale, tonneau).

• Apprentissage automatique : l'ESP32-S3 dispose d'un accélérateur neuronal qui permettrait d'implémenter un modèle ML léger (TinyxML) entraîné sur des données d'accidents réels, réduisant ainsi les faux positifs.

• Analyse temporelle : la détection ne doit pas se baser uniquement sur un instant, mais sur une séquence de valeurs pour distinguer un impact réel d'une vibration passagère.

Intégration de la transmission d'image via satellite

La version actuelle peut transmettre une image via Wi-Fi/MQTT, mais pas encore via le module satellite Swarm (contrainte de taille des messages — Swarm est optimisé pour les petits paquets IoT). Des solutions envisagées :

• Compression d'image agressive (JPEG basse résolution, ~20 Ko) pour réduire la taille en dessous du seuil Swarm.

• Envoi différé : si LTE n'est pas disponible au moment de l'accident, mettre l'image en file d'attente et l'envoyer dès la reconnexion.

Optimisation de la consommation énergétique

Pour les utilisateurs de vélos ou de scooters qui ne peuvent pas recharger le dispositif depuis le véhicule :

• Implémentation des modes deep sleep de l'ESP 32-S3 entre les cycles de mesure.

• Réveil sur interruption du MPU-6050 (motion interrupt) pour minimiser la consommation en veille.

• Intégration d'un panneau solaire de petite taille (comme mentionné dans les spécifications initiales) pour l'autonomie en plein air.

Miniaturisation et robustesse mécanique

Le prototype actuel reste volumineux. Pour la version commerciale :

• Conception d'un PCB personnalisé avec composants CMS (montage en surface) réduisant la taille de 60 à 70 %.

• Certification IP67 réelle avec un boîtier étanche surmoulé.

• Tests de résistance aux vibrations selon les normes IEC 60068-2-6 pour valider la fiabilité en conditions d'utilisation prolongée.

11.2 Évolutions fonctionnelles à moyen terme

• Application mobile complète : Le développement de l'application ResQ (iOS et Android) est prévu pour la phase suivante. Elle permet la configuration des contacts d'urgence, l'historique des alertes, les mises à jour OTA (Over The Air) et l'intégration de contenus éducatifs.

• Intégration microphone : L'ajout d'un microphone MEMS permettrait une communication vocale bidirectionnelle avec les secours après le déclenchement d'une alerte, augmentant considérablement la valeur ajoutée pour les victimes conscientes mais immobilisées.

• Détection du nombre de passagers : L'amélioration du traitement d'image (intégration d'un modèle de détection de personnes TinyxML) permettrait d'estimer le nombre d'occupants du véhicule, information précieuse pour les secours.

• Partenariats B2B : L'intégration de ResQ dans les flottes de livraison (Uber Eats, Deliveroo, Stuart) représente une opportunité commerciale majeure, avec des volumes d'unités importants et une installation systématique sur tous les véhicules de la flotte.

11.3 Vision à long terme : du produit à la licence technologique

La feuille de route ResQ prévoit une évolution stratégique en 7 ans :

• Années N+2 : Partenariats avec des constructeurs automobiles (Peugeot, Citroën) pour la validation du produit en conditions industrielles.

• Années N+3 : Expansion européenne via le réseau de distribution ET Group (présent dans 25+ pays).

• Années N+5 : Entrée sur les marchés internationaux (Asie, Moyen-Orient, Amérique latine).

• Année N+7 : Transition vers un modèle de licence technologique — intégration de la technologie ResQ directement dans les véhicules à la fabrication, à l'image du GPS ou du Bluetooth aujourd'hui. Cette étape nécessite le dépôt d'un brevet sur l'algorithme de détection et le protocole de communication.

12. Sources, tutoriels et ressources utilisées

12.1 Sources statistiques et problématique

• Organisation Mondiale de la Santé (OMS) — Rapport mondial sur la prévention des traumatismes dus aux accidents de la route : https://www.who.int/publications/i/item/9241562609

• Recherche sur les capteurs de choc et placement : https://www.researchgate.net/publication/286112060_Preference_and_placement_of_vehicle_crash_sensors

• Statistiques des accidents de la route en France 2022 : https://www.lindependant.fr/2023/02/01/accidents-de-la-circulation-en-france-3541-morts-surles-routes-en-2022-plus-de-victimes-chez-les-hommes-et-les-cyclistes-10966912.php

• Statistiques du parc automobile français 2024 : https://www.statistiques.developpement-durable.gouv.fr/393-millions-de-voitures-en-circulation-en-france-au-1er-janvier2024

12.2 Composants et datasheets techniques

• ESP32-S3-SIM7670G-4G (Waveshare) : https://www.waveshare.com/esp32-s3-sim7670g-4g.htm

• MPU-6050 datasheet (InvenSense/TDK) : https://invensense.tdk.com/products/motion-tracking/6-axis/mpu-6050/

• MLX90614 datasheet (Melexis) : https://www.melexis.com/en/product/MLX90614/Digital-Plug-Play-Infrared-Thermometer-TO-Can

• SIM7670G AT Commands manual (SIMCOM) : https://www.simcom.com/product/SIM7670G.html

• OV2640 datasheet (OmniVision) : https://www.uctronics.com/download/cam_module/OV2640DS.pdf

• 18650 Li-ion battery specifications : https://www.18650batterystore.com/blogs/18650-battery-store-blog/what-is-an-18650-battery

12.3 Bibliothèques et ressources de développement

• Bibliothèque ArduinoJson (Benoît Blanchon) : https://arduinojson.org/

• Bibliothèque Adafruit NeoPixel : https://github.com/adafruit/Adafruit_NeoPixel

• Bibliothèque Adafruit GFX : https://github.com/adafruit/Adafruit-GFX-Library

• Documentation ESP32-S3 (Espressif) : https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/index.html

• Tutoriel MPU-6050 avec ESP32 : https://randomnerdtutorials.com/esp32-mpu-6050-accelerometer-gyroscope-arduino/

• Documentation MQTT (Eclipse Mosquitto) : https://mosquitto.org/documentation/

• Protocole Swarm Technologies (SpaceX) : https://swarm.space/

12.4 Sources de certification et réglementation

• CE Marking — Coûts et procédures : https://cemarking.net/what-are-the-costs-of-ce-certification/

• CE Marking — Commission européenne : https://europa.eu/youreurope/business/product-requirements/labels-markings/ce-marking/index_en.htm

• Homologation UTAC (France) : https://www.utac.com/your-needs/type-approval/

• RED — Radio Equipment Directive (TÜV SÜD) : https://www.tuvsud.com/en/services/product-certification/radio-equipment-directive

• RoHS Compliance testing : https://www.jjrlab.com/news/how-much-does-a-rohs-testing-report-cost.html

• IP Rating — Intertek : https://www.intertek.com/lighting/performance/ingress-protection/

• EMC/EMI Testing — Eurofins : https://www.eurofins.com/electrical-and-electronics/services/testing/electromagnetic-compatibility-emc/

12.5 Outils de conception

• KiCad (schéma électronique et PCB) : https://www.kicad.org/

• Autodesk Fusion 360 (CAO 3D boîtier) : https://www.autodesk.com/products/fusion-360/

• Arduino IDE (développement firmware) : https://www.arduino.cc/en/software

• NextPCB (fabrication PCB) : https://www.nextpcb.com/

• Viasion Technology (assemblage PCB) : https://viasion.com/

12.6 Ressources compétitives

• Système eCall européen : https://www.eecallrecast.eu/

• Apple Watch — Emergency SOS via satellite : https://support.apple.com/en-us/111843

• MET Helmet smart helmets : https://www.met-helmets.com/

• B01 sensor (Beltee) : https://www.beltee.com/