Implémentation rapide d'un système de localisation en temps réel avec une précision de 10 cm

Les systèmes de radiolocalisation sont devenus une fonctionnalité omniprésente dans presque tous les types de dispositifs mobiles et d'applications associées. Parmi les méthodes de radiolocalisation, les systèmes de localisation en temps réel (RTLS) basés sur les communications RF ultralarge bande (UWB) jouent un rôle central pour garantir la disponibilité des données de localisation lorsque les GPS ne peuvent pas fournir de couverture.

Avec la demande croissante en matière de RTLS plus précis, les développeurs sont confrontés à la complexité des méthodes haute précision comme la télémétrie bidirectionnelle et la localisation selon la différence de temps d'arrivée (TDOA).

Un logiciel et un module intégrés de Decawave fournissent aux développeurs une solution RTLS simplifiée pouvant générer des résultats de localisation plus précis en déployant moins d'efforts.

Cet article étudie les applications et algorithmes RTLS, notamment la télémétrie bidirectionnelle et la TDOA, et aborde les compromis d'implémentation liés aux différentes méthodes RTLS. L'article présente ensuite un émetteur-récepteur UWB de Decawave tout en soulignant les exigences spécifiques lors de son utilisation pour la conception. La fin de l'article aborde l'architecture logicielle de Decawave et le développement du micrologiciel complémentaire en illustrant les techniques spécifiques pour développer les applications utilisateur sur la plateforme de Decawave.

Le rôle des systèmes RTLS

Les systèmes RTLS de précision sont devenus une méthode efficace pour déterminer la position des personnes ou des ressources mobiles, ou les suivre dans des bureaux, entrepôts, usines de fabrication et lignes d'assemblage. Dans cette approche, un objet mobile (balise) échange des informations avec des dispositifs fixes (points d'ancrage) à l'aide de formats standard et de technologies UWB spécifiés dans la norme IEEE 802.15.4-2011 pour les réseaux personnels sans fil basse fréquence (LR-WPAN). En déterminant la distance entre la balise et plusieurs points d'ancrage, les applications peuvent déterminer la position relative de la balise par rapport à ces points d'ancrage pour en tirer la position absolue de la balise.

Méthodes RTLS

Les applications RTLS utilisent différentes techniques pour déterminer la distance. Dans le cas de l'approche la plus simple, l'application ou la balise peut utiliser le paramètre d'indicateur d'intensité du signal reçu (RSSI) disponible sur la plupart des émetteurs-récepteurs pour évaluer la position relative de la balise par rapport aux points d'ancrage de transmission. En raison des nombreux facteurs pouvant affecter le bilan de liaison, cette approche fournit au mieux une vaste estimation de la position. Par contraste, de nombreuses applications émergentes basées sur les systèmes RTLS nécessitent la détermination de la position absolue à quelques centimètres près.

Un système RTLS haute précision utilise les méthodes de temps de vol qui sont largement immunisées contre les changements considérables de variation de l'intensité du signal RF. Avec cette approche, la position d'une balise peut être déterminée en mesurant le temps nécessaire à la transmission d'un signal RF de la balise vers plusieurs points d'ancrage. Grâce au temps de propagation donné des signaux RF par liaison radio, les applications RTLS peuvent traduire le temps de vol en distance.

C'est possible par exemple si le temps de vol entre une balise et les trois points d'ancrage respectifs est à chaque fois le même. Cette situation ne se présente rationnellement que si la balise est équidistante des points d'ancrage. Comme l'application connaît la position exacte de chaque point d'ancrage, elle peut déterminer la position absolue de la balise.

Pour mesurer le temps de propagation depuis l'émetteur de balise, cependant, le récepteur du point d'ancrage doit utiliser une base temporelle identique à celle de la balise pour évaluer correctement les informations temporelles intégrées dans le message de la balise. Si la base temporelle du point d'ancrage est en retard ou en avance par rapport à celle de la balise, la distance calculée sera respectivement inférieure ou supérieure à la distance réelle.

Une méthode RTLS applique une approche directe pour résoudre ce problème en effectuant une synchronisation temporelle de l'émetteur de balise et des récepteurs des points d'ancrage tout en veillant à ce que chaque point d'ancrage reçoive le message suivant une base temporelle identique à celle de la balise. La mise en œuvre de la synchronisation temporelle peut représenter un défi dans le meilleur des cas et être tout simplement impossible dans les applications RTLS impliquant des balises sans fil en mouvement.

Une autre méthode, la TDOA (différence de temps d'arrivée), synchronise uniquement les points d'ancrage pour éliminer la difficulté associée à la synchronisation des balises mobiles. Pour déterminer la position, l'application RTLS utilise les différences entre les temps d'arrivée d'un signal de balise mesurés au niveau de plusieurs points d'ancrage. Prenons par exemple le cas des trois points d'ancrage (A₁, A₂ et A₃) cité précédemment, qui sont disposés de manière équidistante autour d'une balise. Après le déplacement de la balise, si la TDOA de chaque point d'ancrage s'avère être 0, 1 nanoseconde (ns), 0 respectivement, cela signifie que la balise s'est éloignée du point d'ancrage A₂ sur une distance de 30 cm environ en suivant une ligne directe (en supposant une propagation RF à la vitesse de la lumière). La nécessité d'une synchronisation des points d'ancrage dans la TDOA représente un problème considérablement plus simple à résoudre qu'une tentative de synchronisation des points d'ancrage et des balises. Malgré cela, la précision de cette approche dépend d'une synchronisation très précise. Même une différence d'une nanoseconde dans la synchronisation peut se traduire par une différence de plusieurs centimètres dans la mesure de la position.

Télémétrie bidirectionnelle

Les méthodes RTLS à télémétrie bidirectionnelle éliminent totalement la nécessité d'une synchronisation temporelle précise, mais exigent une fonctionnalité de transmission au niveau de la balise. Cette approche évite l'incertitude des bases temporelles différentes en permettant une communication des informations de temporisation entre la balise et les points d'ancrage. Au lieu de synchroniser leurs bases temporelles, la balise et les points d'ancrage utilisent un protocole de messagerie bidirectionnelle courte permettant de déterminer avec précision le temps de vol et de calculer la position précise de la balise.

Dans le cadre de cette approche, une balise transmet un bref signal d'identification pour indiquer sa présence aux points d'ancrage environnants. Chaque point d'ancrage recevant le message d'identification initial de la balise effectue par la suite une communication de données bidirectionnelle courte avec la balise, pour déterminer le temps de vol, indépendamment des différences de bases temporelles entre les points d'ancrage et la balise proprement dite.

Dans son protocole RTLS bidirectionnel, Decawave définit ce processus en termes de phase de détection et de phase de télémétrie (Figure 1). Lors de la phase de détection, une balise transmet périodiquement un bref signal d'identification ou un clignotement et attend la réponse d'un point d'ancrage. Après leur reconnaissance mutuelle, la balise et le point d'ancrage jumelés utilisent un bref échange bidirectionnel de messages contenant les informations nécessaires pour le calcul de la distance.

Figure 1 : Dans le protocole de télémétrie bidirectionnelle de Decawave, les balises et les points d'ancrage échangent une série de messages pour réaliser la détection et fournir les informations de télémétrie. (Source de l'image : Decawave)

Pour les développeurs, les défis associés à l'implémentation de ces protocoles de communication de messages à temporisation précise et de leurs sous-systèmes radio UWB sous-jacents peuvent s'avérer difficiles. À l'aide du module DWM1001 de Decawave, cependant, les développeurs peuvent rapidement ajouter des fonctionnalités RTLS précises à leurs applications avec un minimum d'efforts supplémentaires.

Module RTLS intégré

Le module DWM1001 de Decawave fournit une implémentation complète du système RTLS. Il intègre un émetteur-récepteur DW1000 de Decawave dans un microcontrôleur sans fil NRF52832 de Nordic Semiconductor, ainsi qu'un détecteur de mouvement à trois axes LIS2DH12 de STMicroelectronics. Tandis que le DW1000 fournit une signalisation RF conforme à IEEE 802.15.4-2011, le microcontrôleur NRF52832 exécute un micrologiciel intégré pour les applications RTLS. Le capteur LIS2DH12 joue un rôle important dans la gestion de l'alimentation.

Dans les applications RF sophistiquées, la conception RF génère typiquement des défis majeurs, en particulier dans les applications mobiles nécessitant une empreinte et une consommation énergétique minimales. Le module DWM1001 répond à ces problématiques en tirant pleinement parti de la conception RF intégrée fournie par l'émetteur-récepteur DW1000 (Figure 2).

Figure 2 : L'émetteur-récepteur DW1000 de Decawave intègre des trajets de signal radio et une logique de contrôle numérique pour fournir un système complet conforme à IEEE 802.15.4-2011. (Source de l'image : Decawave)

Le DW1000 fournit un émetteur-récepteur UWB complet qui intègre un circuit d'entrée RF pouvant prendre en charge six canaux IEEE 802.15.4-2011 de 3,5 GHz à 6,5 GHz, à des débits standard de 110 kbit/s, 850 kbit/s et 6,81 Mbit/s. Le sous-système de contrôle numérique intégré du dispositif gère l'émetteur-récepteur et prend en charge les deux systèmes RTLS TDOA et à télémétrie bidirectionnelle avec une précision de localisation à 10 cm. Une mémoire programmable une seule fois (OTP) intégrée permet aux développeurs de stocker les données utilisées pour l'étalonnage et la correction des erreurs, tandis que la mémoire toujours active configurable (AON) du dispositif conserve les données de configuration pendant les états basse consommation du dispositif, décrits ci-dessous.

Lorsqu'il est actif, le dispositif transmet et reçoit des trames IEEE 802.15.4-2011 constituées d'un en-tête de synchronisation (SHR), d'un en-tête de couche physique (PHR) et jusqu'à 127 octets de données qui constituent l'ensemble de l'unité de données de service PHY (PSDU). Outre la trame standard, le dispositif prend également en charge un format de trame propriétaire fournissant jusqu'à 1 023 octets de données pour les applications qui doivent envoyer de plus grandes charges utiles de données et qui n'ont pas besoin d'être conformes à IEEE 802.15.4-2011.

Pour les applications conformes, les développeurs peuvent choisir parmi une variété de modes de fonctionnement avec des combinaisons prédéfinies du débit, de la taille de charge utile et de la longueur de préambule, préconfigurées pour s'adapter à des cas d'utilisation spécifiques pour les opérations de télémétrie bidirectionnelle et de TDOA. Par exemple, les modes destinés aux applications longue portée combinent faible débit et longs préambules pour simplifier la détection et la télémétrie malgré les interférences ou les faibles signaux. Inversement, les modes à hauts débits et courts préambules prennent en charge les applications courte portée. Les autres modes prennent en charge ces caractéristiques longue et courte portée avec des charges utiles de données de tailles différentes.

Réduction de l'alimentation

En pratique, les développeurs préfèrent les modes de fonctionnement présentant une taille de trame aussi petite que possible pour réduire la consommation globale et remettre rapidement le dispositif à l'état basse consommation. Le DW1000 offre plusieurs modes basse consommation. Pendant les périodes d'inactivité, le dispositif peut passer en mode de veille, qui consomme seulement 19 milliampères (mA). Pour de longues périodes d'inactivité, les développeurs peuvent faire passer le dispositif en mode veille basse consommation, avec une consommation d'environ 1 microampère (μA) seulement, ou en mode de veille prolongée, avec une consommation maximale de 100 nanoampères (nA) (consommation typique de 50 nA).

Cependant, à l'instar de la conception RF, la consommation énergétique augmente considérablement pendant le fonctionnement de l'émetteur-récepteur. Pour transmettre une trame conforme à IEEE 802.15.4-2011, par exemple, les composants à trame plus longue comme l'en-tête de synchronisation et le paquet de données sont à l'origine de la majeure partie de la consommation énergétique (Figure 3).

Figure 3 : La transmission d'une trame RTLS via le DW1000 de Decawave produit de considérables augmentations de la consommation énergétique au niveau de chaque composant de la trame. Cela pousse les développeurs à choisir des modes de fonctionnement présentant un en-tête de synchronisation et une charge utile de données les plus courts qui soient. (Source de l'image : Decawave)

Une consommation énergétique accrue relative aux opérations du récepteur représente un défi supplémentaire pour les conceptions à alimentation limitée (Figure 4). Les développeurs peuvent programmer le DW1000 pour repasser à l'un des états basse consommation après une transmission ou une réception. Malgré cela, les options de réduction de l'alimentation pendant les opérations de trame sont limitées en raison de la nature du protocole standard et de la trame.

Figure 4 : La réception d'une trame impose des besoins d'alimentation plus élevés que pour la transmission, essentiellement en raison de la durée prolongée de la phase de recherche du préambule. (Source de l'image : Decawave)

Le DW1000 fournit une fonctionnalité écoénergétique unique pour réduire l'alimentation pendant la phase de réception du préambule. Au lieu de laisser le récepteur en marche, les développeurs peuvent programmer le dispositif avec un mode de détection de préambule spécial. Dans ce cas, le DW1000 alimente périodiquement le récepteur, recherche le préambule et repasse à l'état de veille si aucun préambule n'est détecté (Figure 5).

Figure 5 : Les développeurs peuvent réduire la consommation énergétique liée aux opérations du récepteur en utilisant la fonction de détection du DW1000, qui alterne entre le mode de veille et le mode actif du récepteur. (Source de l'image : Decawave)

Les fonctionnalités comme la détection de préambule sont particulièrement importantes pour les balises alimentées par batterie. Les développeurs peuvent appliquer différents types de méthodes pour réduire l'alimentation pendant les opérations RTLS. L'une de ces approches tire parti des différents retards connus existant dans le protocole de télémétrie bidirectionnelle illustré à la Figure 1.

Par exemple, la réponse d'initiation de télémétrie du point d'ancrage au clignotement d'une balise pendant la phase de détection s'effectue après un certain retard. Les développeurs peuvent estimer ce retard en fonction de la fréquence de trame et d'autres paramètres, mesurer sa valeur réelle dans leurs conceptions de points d'ancrage ou même définir un temps de retard de réponse spécifique dans leurs conceptions de points d'ancrage. Ils peuvent ensuite désactiver le récepteur de la balise en toute sécurité pendant le temps de retard prévu, l'activer pour rechercher une réponse, puis le désactiver de nouveau en cas de non-réception de la réponse d'initiation de télémétrie après une période raisonnable.

Les développeurs peuvent également prendre des mesures pour limiter le temps d'activation radio nécessaire pendant le processus de télémétrie. Par exemple, ils peuvent précharger toutes les données nécessaires dans le dispositif et utiliser un accès direct à la mémoire pour accélérer le transfert de données entre le DW1000 et la mémoire hôte.

Même si ces optimisations de bas niveau peuvent fournir des économies d'énergie incrémentielles, les développeurs peuvent bénéficier de meilleurs résultats en modifiant de manière dynamique la fréquence de mise à jour de la position. Après l'immobilisation d'une balise, il n'y a aucun avantage à procéder à des phases de découverte et de télémétrie consommatrices d'énergie. La balise peut passer à l'état de veille basse consommation en toute sécurité et se réactiver pour reprendre les mises à jour à un débit nominal lorsqu'elle se remet en mouvement.

Le module DWM1001 prend en charge un réglage dynamique de la fréquence grâce à son détecteur de mouvement LIS2DH12 intégré et à sa prise en charge de deux modes de fonctionnement liés au mouvement : basse consommation et réactif. Les développeurs peuvent configurer le module de manière à faire fonctionner l'émetteur-récepteur DW1000 en mode basse consommation lorsque le capteur LIS2DH12 détecte que le module est stationnaire. Lorsque le LIS2DH12 détecte un mouvement, l'émetteur-récepteur DW1000 peut repasser en mode réactif et reprendre sa fréquence de mise à jour normale.

Les développeurs peuvent optimiser davantage leurs applications RTLS en contrôlant la fréquence de mise à jour en fonction de la vitesse et de l'accélération de l'objet. Par exemple, il se peut qu'une balise lente nécessite uniquement des mises à jour rares pour assurer le niveau de précision voulu pour la position. À mesure que la balise accélère, l'application peut s'adapter en augmentant la fréquence de mise à jour de la position.

Développement d'un système RTLS

Outre sa capacité à prendre en charge les fonctionnalités RTLS comme les fréquences de mise à jour dynamiques, le module offre un avantage essentiel pour le développement d'un système RTLS. Par exemple, l'émetteur-récepteur DW1000 impose plusieurs exigences spécifiques à l'interface pour le découplage de l'alimentation, l'adaptation d'antenne réseau, l'oscillateur de référence, etc. (Figure 6). De même, le microcontrôleur sans fil NRF52832 et le détecteur de mouvement LIS2DH12 présentent leurs propres exigences pour la conception de l'interface.

Figure 6 : L'émetteur-récepteur DW1000 de Decawave impose des exigences strictes relatives à l'interface pour garantir la fiabilité de l'alimentation et des signaux RF et de temporisation. (Source de l'image : Decawave)

Même si ces types de dispositifs avancés présentent une conception très simplifiée, les développeurs peuvent néanmoins faire face à un défi considérable lors de l'optimisation de leur intégration dans des conceptions nécessitant des performances maximales avec une alimentation minimale. Le module DWM1001 limite les exigences relatives à l'intégration à quelques connexions destinées à l'alimentation, la mise à la terre et les interfaces numériques (Figure 7).

Figure 7 : Le module DWM1001 de Decawave simplifie le développement d'un système RTLS en fournissant une conception entièrement intégrée qui combine l'émetteur-récepteur DW1000 avec un détecteur de mouvement et un microcontrôleur sans fil. (Source de l'image : Decawave)

Modèle logiciel

De même, le module simplifie radicalement le développement logiciel et l'intégration grâce à son micrologiciel préchargé conçu pour la bibliothèque de pile de positionnement et de mise en réseau (PANS) de Decawave. Conçue sur la pile BLE (Bluetooth Low-Energy) sur puce du microcontrôleur, la bibliothèque PANS inclut le système d'exploitation en temps réel open-source (RTOS) eCos, une couche réseau et des couches d'applications prenant en charge les services BLE, les services de gestion RTLS et le moteur de localisation à télémétrie bidirectionnelle (TWR) (Figure 8).

Figure 8 : La bibliothèque de pile de positionnement et de mise en réseau (PANS) de Decawave offre une plateforme riche pour les applications RTLS en combinant une pile Bluetooth, un RTOS, une couche réseau et une couche de services d'applications. (Source de l'image : Decawave)

Dans la conception des applications micrologicielles à exécuter sur le microcontrôleur du DWM1001, les développeurs accèdent à la bibliothèque PANS via une interface de programmation d'applications (API) complète qui fournit les points d'entrée adaptés à chaque module PANS pour configurer et contrôler le module. L'API PANS comprend plusieurs ensembles d'API pour différents modules, notamment le code C de développeur, des bibliothèques d'interface série (CPI et UART) et une bibliothèque BLE (Figure 9).

Les applications fonctionnent directement avec ces quatre API de haut niveau. Ces dernières accèdent à la bibliothèque PANS via un analyseur générique d'API qui convertit les demandes en demandes API génériques vers la bibliothèque PANS. Dans ce cas, la couche générique fournit une interface commune à la bibliothèque PANS.

Figure 9 : Decawave déploie la bibliothèque PANS via des API extensives fournissant chacune un accès simplifié au modèle d'exécution à threads sous-jacent. (Source de l'image : Decawave)

Architecture à threads

Dans cette architecture, le programme du micrologiciel DWM1001 utilise un modèle à threads et fournit essentiellement un thread distinct pour chaque module et bibliothèque de la pile. Les threads des quatre modules respectifs en haut de la pile transmettent les demandes d'analyse au thread de l'analyseur d'API, qui valide chaque demande et envoie un appel à la bibliothèque PANS pour générer une réponse adaptée. Le thread d'API générique utilise alors une fonction de rappel fournie dans l'appel initial pour renvoyer le résultat au module appelant en haut de la pile.

Malgré la complexité apparente de ce système multicouche, le modèle de programmation est relativement simple pour le développeur. L'utilisation des appels d'API avec des rappels de threads indépendants permet d'optimiser l'utilisation des ressources et les performances globales de l'application.

Parallèlement, la complexité sous-jacente est masquée par une série d'API qui transforment les demandes d'application de haut niveau en opérations de thread spécifiques optimisées qui interagissent avec le matériel DWM1001. Le modèle de programmation DWM1001 simplifie davantage l'interaction du développeur avec ce système. Au lieu d'interagir avec plusieurs threads et API, les développeurs utilisent un thread d'application utilisateur dédié qui est intégré au système.

Comme indiqué dans la Liste 1, les développeurs appliquent le thread d'application utilisateur avec une simple demande d'API (dwm_thread_create), qui enregistre la fonction du thread d'application utilisateur (app_thread_entry).

Copier

/* Create thread */

rv = dwm_thread_create(THREAD_APP_PRIO, app_thread_entry, (void*)NULL, "app", THREAD_APP_STACK_SIZE, &hndl);

APP_ERR_CHECK(rv);

/* Start the thread */

dwm_thread_resume(hndl);

Liste 1 : Grâce au modèle de thread de Decawave, les développeurs enregistrent et démarrent leur thread d'application utilisateur simplement avec une double demande à l'API. (Source du code : Decawave)

Decawave fournit un échantillon de code pour le thread d'application utilisateur et le rappel. L'échantillon de code est intégré dans une image de machine virtuelle pour Oracle Virtual Box, qui comprend une chaîne d'outils complète, des bibliothèques et une application d'exemple simple. Conçu pour une utilisation avec la carte de développement DWM1001-DEV de Decawave connectée à un PC Windows, le progiciel fournit un cadre pour la création de logiciels d'applications RTLS personnalisés.

L'échantillon de code inclus dans le progiciel présente des modèles de conception clés pour la fonction de thread utilisateur (Liste 2). Dans cet échantillon, la fonction de thread utilisateur (app_thread_entry) définit les paramètres de configuration spécifiques à l'application tels que la fréquence de mise à jour et enregistre son rappel à l'aide de la fonction d'API dwm_evt_cb_register avec le nom de sa fonction de rappel (on_dwm_evt). Après l'enregistrement du rappel, l'échantillon de thread entre dans sa boucle principale. Dans ce cas, il s'agit d'une série de demandes adressées à la fonction de retard utilisée pour réduire l'utilisation des ressources.

Copier

void app_thread_entry(uint32_t data)

{

.

.

.

/* Update rate set to 1 second, stationary update rate set to 5 seconds */

APP_ERR_CHECK(dwm_upd_rate_set(10, 50));

/* Register event callback */

dwm_evt_cb_register(on_dwm_evt, 0);

.

.

.

while (1) {

/* Thread loop */

dwm_thread_delay(100);

}

}

Liste 2 : Dans cet extrait du pack de développement micrologiciel de Decawave, l'échantillon de code illustre des modèles de conception de base pour l'enregistrement du rappel et l'exécution de la boucle principale dans la routine du thread d'application utilisateur. (Source du code : Decawave)

L'échantillon de la fonction de rappel (on_dwm_evt) présente un gestionnaire d'événement de base qui est invoqué lorsqu'un événement se produit (Liste 3). Dans cet échantillon de code, le seul événement valide est la disponibilité de nouvelles informations sur la position (DWM_EVT_NEW_LOC_DATA). Dans le gestionnaire de l'événement, le code présente un ensemble de demandes simplifiées, nécessaires pour récupérer les données de position générées par les points d'ancrage disponibles. Après la réalisation des tâches de traitement de l'événement, la fonction de rappel se met simplement en veille.

Copier

/**

* Event callback

*

* @param[in] p_evt  Pointer to event structure

* @param[in] p_data Pointer to user data

*/

void on_dwm_evt(dwm_evt_t *p_evt, void *p_data)

{

int i;

switch (p_evt->header.id) {

/* New location data */

case DWM_EVT_NEW_LOC_DATA:

/* Process the data */

printf("\nT:%lu ", dwm_systime_us_get());

if (p_evt->data.loc.p_pos == 0) {

/* Location engine is disabled */

} else {

printf("POS:[%ld,%ld,%ld,%u] ", p_evt->data.loc.p_pos->x,

p_evt->data.loc.p_pos->y, p_evt->data.loc.p_pos->z,

p_evt->data.loc.p_pos->qf);

}

for (i = 0; i < p_evt->data.loc.anchors.dist.cnt; ++i) {

printf("DIST%d:", i);

printf("0x%04X", (unsigned int)(p_evt->data.loc.anchors.dist.addr[i] & 0xffff));

if (i < p_evt->data.loc.anchors.an_pos.cnt) {

printf("[%ld,%ld,%ld]",

p_evt->data.loc.anchors.an_pos.pos[i].x,

p_evt->data.loc.anchors.an_pos.pos[i].y,

p_evt->data.loc.anchors.an_pos.pos[i].z);

}

printf("=[%lu,%u] ", p_evt->data.loc.anchors.dist.dist[i],

p_evt->data.loc.anchors.dist.qf[i]);

}

printf("\n");

break;

default:

break;

}

/* Indicate the application has finished the tasks and can now */

dwm_sleep();

}

Liste 3 : Cet extrait d'une application d'exemple de Decawave illustre un rappel fournissant un gestionnaire d'événement de base pour accéder aux nouvelles données de position. (Source du code : Decawave)

Par exemple, dans une application RTLS complète pour l'Internet des objets (IoT), les balises et les points d'ancrage communiquent via des points d'ancrage de routage reliés à un système de passerelle connecté à Internet. Decawave prépare une deuxième version de son pack micrologiciel qui inclura une prise en charge de passerelle via un progiciel basé sur Linux utilisant des protocoles de messagerie IoT familiers, notamment HTTP, WebSockets, MQTT et AMQP.

Conclusion

Le système RTLS joue un rôle de plus en plus important dans une vaste gamme d'applications. Même si les méthodes RTLS se basent sur des principes relativement simples, leur implémentation nécessite une conception RF/analogique, une conception système et un développement logiciel sophistiqués pour garantir une précision maximale avec une consommation énergétique minimale.

Le module DWM1001 de Decawave fournit un système RTLS complet qui combine l'émetteur-récepteur UWB DW1000 intégré de Decawave avec un microcontrôleur sans fil et un détecteur de mouvement. Grâce à ce module et au progiciel complémentaire, les développeurs peuvent rapidement implémenter des systèmes RTLS alimentés par batterie haute précision.