Open Source French Drone Identification

Et la loi ne s’adresse pas qu’aux drones, mais aux aéronefs sans pilote, de plus de 800 gr, ce qui veut dire aussi, les avions, les planeurs, les hélicoptères, les autogyres, etc…

En effet, et je n’ai jamais écrit qu’il fallait supprimer définitivement la condition de distance, juste que dans mon cas, ça ne se produirait que rarement de faire 10 m/s et je compte bien remettre cette condition quand j’aurai reçu le module GPS commandé :wink:

C’est pas mal. Dommage que l’on puisse pas faire un enregistrement sur une carte µSD de la position tout les 100 ou 200 ms.
J’avais, ou plus exactement, j’ai un module Flytrex qui se connecte sur le GPS d’un contrôleur Naza et qui permet d’enregistrer la position des modèles tout les 1/4 de seconde. Malheureusement, la société qui avait développé le module a arrêté ses serveurs et si le module fonctionne toujours et enregistre bien la position dans la carte µSD, les informations sont codées et seul un passage sur le site du fabricant permettait un décodage et d’exporter un fichier KML ou CSV. Cela me permettait de conserver mes données de vol, et le cas échéant de pouvoir démontrer ma bonne foi. Certes, il était possible de ne pas le brancher, et de faire des vols “illégaux”, mais bon, ce n’était pas le but.

Je viens de tester le décodage de la trame avec ton code “decode balise” implanté sur une carte wemos D1 mini.
Verdict, je reçois bien les trames émise par un autre wemos :grinning:

21:52:05.503 → ID: 00000000000000000-UAS-FR-192xx LAT: 41.88244 LON: 1.88789 ALTmsl: 164
21:52:08.503 → ID: 00000000000000000-UAS-FR-192xx LAT: 41.88241 LON: 1.88789 ALTmsl: 162
21:52:11.503 → ID: 00000000000000000-UAS-FR-192xx LAT: 41.88245 LON: 1.88790 ALTmsl: 164
21:52:14.503 → ID: 00000000000000000-UAS-FR-192xx LAT: 41.88252 LON: 1.88793 ALTmsl: 168
21:52:17.502 → ID: 00000000000000000-UAS-FR-192xx LAT: 41.88255 LON: 1.88793 ALTmsl: 170

Par contre, assez inexplicablement, j’ai du choisir comme carte ‘généric 8266 module’ dans arduino sinon ça plantait…
Merci pour ce programme de décodage !

1 Like

La balise a base d’esp32 fonctionne donc correctement sauf pour l’emission de trames dépendants de la distance parcourue. Si je laisse en l’état le seuil de 30m, j’ai régulièrement un affolement d’émission de trame avec des trames émises sans intervalle entre elles… Pour y remédier, soit j’enlève le test, soit j’augmente le seuil à 3000m… (300m ne suffisant pas). J’ai essayé de comprendre un peu le code mais j’atteint très vite mes limites…
Les trames reçues: Les 3 premières ont le bon intervalle, les suivantes se suivent sans latence.
09:03:30.986 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12262 LON: 2.17793 ALTmsl: 171
09:03:33.986 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12262 LON: 2.17792 ALTmsl: 172
09:03:36.986 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12262 LON: 2.17792 ALTmsl: 172
09:03:36.986 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:36.986 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.033 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.033 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.033 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.033 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.080 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.080 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.080 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.080 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.127 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.127 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.127 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.174 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.174 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172
09:03:37.174 -> ID: 00000000000000000-UAS-FR-18850 LAT: 41.12261 LON: 2.17792 ALTmsl: 172

Bonsoir,

Il semble y avoir quelques erreurs dans la librairie droneID_FR, je l’ai modifiée dans une branche de test : https://github.com/f5soh/balise_esp32/tree/droneID_FR_testing

  • la mise à jour de la position se fait en une seule fois : lat, long et altitude
  • la position de départ (Home) est intégrée dans la librairie, ainsi que le calcul de l’altitude (height) par rapport au point départ.
  • le calcul de la distance depuis la dernière position émise se fait en 3D. (actuellement pour un appareil qui monte à la verticale sa position ne serait émise que toutes les 3s)
  • Après chaque envoi la position est enregistrée : lat, long, altitude dans set_last_send()

Cela me semble mieux et je n’ai plus de trames émises en rafale.

@khancyr Je peux faire un PR si besoin :cold_face:

Bonjour,

Sympa !
Effectivement, j’avais pas fait le calcul de distance en 3D, je peux mettre à jour !
Par contre, je prefère garder la possibilité de rentrer l’altitude séparament, si on a une autre donnée que la donnée GPS c’est mieux !
Pour le calcul de distance, on m’a déja proposé cette solution qui fonctionne par rapport au dernier point émis (en gros une fence de 30m), mais pour ma part je prefère rester sur l’'accumulateur de distance parcouru qui est plus restrictif (notament à cause de imprecision GPS).

Waouh, Super et merci pour la rapidité ! Je n’ai plus de trames en rafales non plus :sunglasses: Ton nouveau code solutionne bien le problème.

Le principe d’accumuler les distances est surement bon, mais il y a un bug qui provoque des rafales incessantes de trames…

Un grand merci à tout les deux !!

J’essaie de faire téléverser ma carte TT-beam avec Arduino mais en vain, j’ai un problème de communication A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header
Je précise que j’ai pas eu de problème lors de la compilation, apparemment je suis connecter au bon port Port 13:
image

Voici mes paramètres de connexion :
image

J’ai également changé de câble usb mais toujours le même problème.Si quelqu’un peut m’aider je suis preneur car la je sèche.

Finalement problème résolu après plusieurs tentatives sans rien modifier.

Bonjour Pierre,
Pour ma part je ne suis pas trop convaincu par le fait d’accumuler la distance. Si tu prends un appareil qui tourne en rond il va émettre alors sa position avant les 3s alors qu’il ne s’est pas déplacé plus que ça de sa dernière position signalée. De plus, le fait d’accumuler la distance dépend alors du refresh rate du GPS.
Je comprends bien que le fait d’accumuler permet de coller mieux à la trace réelle de l’appareil sur une carte mais je ne pense pas que ce soit le but premier de la balise soit de savoir si tu fais des ronds ou des carrés en l’air.

Le calcul 3D est par contre indispensable, en l’état un multirotor qui monte plein gaz à la verticale ne sera signalé que toutes les 3s. Dans le cas de la proximité avec un aéroport il ne sera clairement pas signalé correctement.

Le texte de loi précise :
“2 envois sont séparés d’au plus 30 mètres.” Pour moi on parle bien d’une distance parcouru.Je pense que c’est surtout pour appareil rapide car en 3s la distance parcouru sera importante.

“De plus, le fait d’accumuler la distance dépend alors du refresh rate du GPS.” ça dépendent de ta source de données ! Si tu prend du mavlink en entré tu aura surement l’estimation d’état de l’EKF plutot que le GPS directement. Mais dans tous les cas, l’actualisation du GPS est limitante comme ça précision : si tu a une donnée par seconde avec une précision de 10m, la balise va donner des données abérantes … mais bon, c’est du GPS …

Bonsoir Pierre,
Dans le cas du GPS seul il faut aussi s’assurer que les données soient réellement mises à jour avant de les envoyer à la librairie. Il faut également tenir compte de la vitesse pour anticiper le prochain point à émettre, quitte à l’envoyer à moins de 30m de distance.

J’ai fait une mise à jour sur https://github.com/f5soh/balise_esp32/tree/droneID_FR_testing , testé en voiture (en dépassant un peu la limitation de vitesse…) à 5Hz et ça fonctionne assez bien :
les deux conditions “2 envois sont séparés d’au plus 3 secondes” et “2 envois sont séparés d’au plus 30 mètres.” sont respectées. (Pas interprétée comme une distance parcourue si parcours en zig-zag.)

Bonsoir,
voici ce que j’ai trouvé sur le site du Ministère : ça complique un peu la chose :slight_smile:
https://www.ecologique-solidaire.gouv.fr/modeles-reduits-et-drones-loisir

Nouveautés et points d’attention

# Dispositif de signalement électronique : saisie dans Alphatango

Le portail AlphaTango intègre dorénavant la possibilité de saisir le numéro d’identification du dispositif de signalement électronique de l’aéronef sans personne à bord, conformément aux dispositions de l’arrêté du 19 octobre 2018 relatif à l’enregistrement des aéronefs civils circulant sans personne à bord. Une notice explicative est disponible ci-dessous. Ces dispositions ne sont applicables qu’aux aéronefs dont la masse au décollage est supérieure à 800 grammes, ou qui sont nativement équipés d’un tel dispositif de signalement électronique.

Important : Seul le constructeur de l’aéronef sans personne à bord ou du dispositif amovible de signalement électronique (“add-on”) est en mesure de fournir ce numéro d’identification. Si cette information ne vous a pas été explicitement fournie par le constructeur (par courriel, sur l’interface/appli proposée par le constructeur ou dans l’emballage du drone ou de l’add-on, par exemple), il convient de s’adresser à lui pour l’obtenir. Si vous ne disposez pas du numéro d’identification ou n’êtes pas certain de ce qu’il convient de saisir, il vous est recommandé de ne saisir aucune information, afin de ne pas vous exposer aux sanctions prévues dans le décret n°2019-1253 du 28 novembre 2019.

Merci pour ce travail remarquable,
j’ai modifié un peu le code pour afficher la home position,
rien n’y fait j’ai “AltHome: -29440 HLAT: 0.00000 HLON: 0.00000” tjs identique avant ou après le setting de la home position par le tracker

Coté decode_balise.ino, avec ajout après
//Altitude msl
Serial.print(" ALTmsl: “); printAltitude(offset, TLV_LENGTH[ALTITUDE] , snifferPacket->data);
offset += TLV_LENGTH[ALTITUDE];
//ajout
Serial.print(” AltHome: "); printAltitude(offset, TLV_LENGTH[HEIGTH] , snifferPacket->data);
offset += TLV_LENGTH[HEIGTH];

Serial.print(" HLAT: "); printCoordinates(offset, TLV_LENGTH[HOME_LATITUDE] , snifferPacket->data);
offset += TLV_LENGTH[HOME_LATITUDE]+2;

Serial.print(" HLON: "); printCoordinates(offset, TLV_LENGTH[HOME_LONGITUDE] , snifferPacket->data); Serial.println();

Le serial monitor affiche :

ID: ILLEGAL_DRONE_APPELEZ_POLICE17 LAT: 48.78137 LON: -3.03456 ALTmsl: 256 AltHome: -29440 HLAT: 0.00000 HLON: 0.00000
ID: ILLEGAL_DRONE_APPELEZ_POLICE17 LAT: 48.78137 LON: -3.03456 ALTmsl: 256 AltHome: -29440 HLAT: 0.00000 HLON: 0.00000
ID: ILLEGAL_DRONE_APPELEZ_POLICE17 LAT: 48.78137 LON: -3.03456 ALTmsl: 256 AltHome: -29440 HLAT: 0.00000 HLON: 0.00000
ID: ILLEGAL_DRONE_APPELEZ_POLICE17 LAT: 48.78137 LON: -3.03456 ALTmsl: 256 AltHome: -29440 HLAT: 0.00000 HLON: 0.00000

Coté du tracker , avec ajout après
if (!has_set_home && gps.satellites.value() > 6 && gps.hdop.hdop() < 2.0) {
Serial.println(“Setting Home Position”);
drone_idfr.set_home_lat_lon(gps.location.lat(), gps.location.lng());
has_set_home = true;
home_alt = gps.altitude.meters();
//ajout
Serial.print(gps.location.lat(),DEC);
Serial.println(gps.location.lng(),DEC);

Je vérifie que serial monitor affiche bien
Setting Home Position
48.7813728330-3.0346040000
et c’est le cas, avez vous une piste ?

Bonjour,
C’est un comportement “normal” du sniffer, le buffer de la trame reçue est limité. (voir README)
Le decode_balise n’ira pas plus loin que la valeur “Altmsl” à la condition que le ssid de la balise soit court (il n’est pas utilisé par la balise elle-même) et peut donc être mis à “AP” pour faire court.

Chez moi, tout fonctionne…
Je viens de recevoir la carte TTGO Tbeam (en V1.0) et j’ai injecté le code de khancyr. Cela fonctionne parfaitement à la condition de choisir un id de 30 caractères sinon j’ai des lettres qui allongent l’id.
La trame est bien décodée avec le module ESP01 contenant le code de f5soh :sunglasses:
Il n’y a pas d’émission de trames indésirables avec la carte TTGO. Mais comme cela est résolu avec la dernière version du code pour l’ESP01, c’est juste pour info.
Ma préférence va assez naturellement à la solution ESP01 + module GPS du fait de la compacité finale :grinning:

Je n’avais pas bien compris comment remplir dans AlphaTango le champ concernant le signalement électronique, en fait il s’agit d’y mettre la trame émise par la balise si on l’achète car dans ce cas elle émet un id préprogrammé qu’il faut évidemment renseigner dans AlphaTango…
Dans le cas du DIY, on peut émettre un Id bien plus pertinent mais que renseigner dans AlphaTango puisque l’on peut émettre directement son identifiant AlphaTango ?

Merci pour cette réponse rapide, c’est dommage mais c’est suffisant pour vérifier l’ID et cela donne la position courante du GPS ce qui est précieux en cas de crash.

Bonjour,
J’ai porté sur un ESP32 l’application decode_balise qui peut maintenant afficher la totalité de la trame balise reçu :
len=144 ID: ILLEGAL_DRONE_APPELEZ_POLICE17 LAT: 48.78136 LON: -3.03459 ALT ABS: 19 HAUTEUR: 2 LAT DEP: 48.78140 LON DEP: -3.03456 VITESSE HOR: 0 DIR: 1

Le code se trouve ici : https://www.dropbox.com/s/yx0l9q11isg1ve7/Decode_balise_ESP32.zip?dl=0
Il se compile avec une carte “ESP32 Dev Module”

Fred

La touche final :wink: : https://github.com/dev-fred/Decode_balise_ESP32

2 Likes

Merci pour le partage !
Le code fonctionne très bien sur la carte TT GO T-Beam :sunglasses:
Je vais pouvoir utiliser cette carte pour avoir un récepteur portable. Il faudrait juste sortir sur le bluetooth les infos pour les afficher sur un smartphone :wink: