Le dépôt officiel RuView sur GitHub est le meilleur endroit pour vérifier le code source, les tickets, les notes d’installation, le parcours Docker, les références de modèles et l’historique du projet. La page d’accueil ruview.blog reste la voie la plus rapide pour lancer la démo hébergée ; cette page fait le lien pour les développeurs qui veulent passer de l’interface au dépôt puis à une expérience locale.
RuView est un projet open source de WiFi sensing et d’intelligence spatiale, pas un moniteur médical ni un produit de sécurité finalisé. Lisez le dépôt comme un projet d’ingénierie : vérifiez les changements récents, comparez la démo au code actuel et validez les hypothèses matérielles avant de croire des sorties de présence, mouvement, respiration ou pose.
Où trouver le dépôt GitHub officiel de RuView
Le dépôt public est github.com/ruvnet/RuView. Considérez cette URL comme la source canonique pour le code, la documentation, les tickets, les versions et les changements d’installation. Si vous arrivez depuis un miroir, une vidéo ou un README en cache, revenez au dépôt avant de copier des commandes.
La démo hébergée sur ruvnet.github.io/RuView/ aide à explorer l’interface, mais elle ne remplace pas le dépôt. La démo montre le parcours utilisateur ; GitHub montre l’implémentation, les dépendances, les commits récents et les limites encore ouvertes.
- Ouvrez le README, puis consultez les tickets et les versions.
- Citez l’URL du dépôt lorsque vous documentez RuView.
- Gardez ruview.blog pour les vérifications rapides dans le navigateur.
Ce qu’il faut vérifier d’abord dans ruvnet/RuView
Un premier passage peut prendre moins de dix minutes. Lisez le README, parcourez l’arborescence du projet et repérez les dossiers frontend, firmware, modèles, Docker et documentation. Vérifiez ensuite les commits et tickets récents pour savoir si les consignes sont stables.
Ne commencez pas par les promesses de précision. Pour le WiFi sensing, les contraintes pratiques passent d’abord : matériel capable de fournir du CSI, capture répétable, calibration documentée et environnement comparable à votre pièce de test.
| Zone du dépôt | Ce qu’elle indique | Pourquoi c’est important |
|---|---|---|
| README et docs | Commandes, objectif, chemins pris en charge | Évite les instructions obsolètes |
| Tickets et versions | Bogues connus, feuille de route, retours | Distingue l’expérimental du stable |
| Docker ou déploiement | Chemin local et dépendances | Permet de reproduire sans deviner |
| Firmware ou notes CSI | Nœuds attendus et capture | Sépare le CSI réel du RSSI |
Démo hébergée ou installation locale
Utilisez la démo hébergée pour inspecter l’interface, expliquer le concept ou confirmer que l’expérience navigateur se charge. Utilisez une installation locale pour modifier le code, lire les journaux, connecter du matériel ou comprendre pourquoi un scénario WiFi n’est pas répétable.
Le parcours le plus sûr est progressif : ouvrez la démo ruview.blog, ouvrez GitHub, lisez le README, lancez le chemin local le plus simple, puis connectez le matériel CSI réel.
- Démo d’abord pour l’orientation.
- Dépôt ensuite pour les commandes exactes et les limites actuelles.
- Installation locale pour le code, les journaux et les tests matériels.
Réalité matérielle et WiFi CSI
RuView dépend du détail du signal. Beaucoup d’appareils WiFi exposent du RSSI ou des statistiques de connexion, mais pas le Channel State Information nécessaire à une détection sérieuse. Les expériences ESP32 CSI sont un point d’entrée économique ; la recherche avancée peut exiger plusieurs nœuds, de la synchronisation et des données étiquetées.
Avant d’interpréter les résultats, enregistrez une ligne de base de la pièce, notez le canal WiFi, stabilisez le rythme des paquets et documentez la position des capteurs. La présence dans une pièce fixe est beaucoup plus simple que la pose, la respiration, le risque de chute ou le suivi multi-personnes.
| Objectif | Point de départ probable | Note de validation |
|---|---|---|
| Ouvrir la démo | Navigateur et GitHub Pages | Confirme seulement l’interface |
| Lancer localement | Setup du dépôt ou Docker | Confirme l’environnement logiciel |
| Capturer du CSI | ESP32 compatible ou matériel de recherche | Confirme la disponibilité du signal |
| Évaluer le sensing | Essais répétés et étiquetés | Confirme la correspondance avec la réalité |
Checklist pratique avant de cloner
Avant de cloner le dépôt, définissez le type de test. Une revue navigateur demande seulement la démo hébergée et le README. Une revue locale exige Python, Node, Docker ou le runtime indiqué par le README actuel. Une revue de sensing exige du matériel WiFi compatible, une pièce reproductible et une méthode pour étiqueter chaque essai. Séparer ces objectifs évite de déboguer le matériel avant de savoir si le logiciel tourne.
Gardez une fiche de notes pour chaque expérience. Notez le commit ou la version, le système, le navigateur, l’image Docker ou les paquets, la carte capteur, le firmware, le canal WiFi, les positions, la taille de la pièce et le scénario exact. Ces détails rendent les essais RuView comparables et expliquent pourquoi un résultat de présence fonctionne dans une pièce mais pas dans une autre.
- Vérifiez le README actuel avant de copier des commandes externes.
- Choisissez un objectif : démo, exécution locale ou capture CSI réelle.
- Notez commit, versions, matériel, canal, placement et ligne de base.
Comment valider un résultat RuView prudemment
La validation doit rester visible et prudente. Pour la présence, testez pièce vide, entrée d’une personne, personne assise, porte qui bouge sans personne et entrées depuis plusieurs directions. Pour la pose ou le mouvement, vérifiez si le système répond au corps visé ou seulement à un changement multipath fort près de l’antenne. Pour respiration ou signes vitaux, traitez tout nombre comme signal de recherche jusqu’à comparaison avec une référence indépendante.
Un bon flux RuView GitHub inclut aussi des exemples négatifs : périodes sans événement, trafic routeur irrégulier, meubles déplacés, plusieurs personnes et capteur légèrement bougé. Ces cas révèlent si le pipeline est robuste ou seulement adapté à une démo propre. Des limites documentées valent mieux qu’une capture flatteuse sans contexte.
- Testez les pièces vides et les faux positifs.
- Comparez les signaux de santé avec des références indépendantes.
- Gardez les limites à côté des captures, rapports et démos.
Erreurs fréquentes autour de RuView GitHub
L’erreur la plus fréquente consiste à traiter une vidéo, une démo ou un article comme plus récent que le dépôt. Une autre consiste à penser qu’une démo fonctionnelle garantit qu’un montage matériel précis fonctionnera dans votre pièce. Enfin, RuView ne doit pas être utilisé comme produit médical, de chute ou de sécurité certifié.
La frontière d’intention est claire : la page d’accueil cible RuView et la démo, le guide ESP32 explique la capture du signal, et cette page explique comment utiliser GitHub comme référence technique fiable.
- Ne copiez pas de commandes anciennes sans vérifier GitHub.
- N’appelez pas CSI des données limitées au RSSI.
- N’interprétez pas des signaux de santé sans validation indépendante.
Liens officiels et références techniques
FAQ RuView GitHub
Où se trouve le dépôt officiel RuView GitHub ?
Le dépôt public officiel est https://github.com/ruvnet/RuView. Utilisez-le pour le code actuel, les notes de configuration, les tickets et l’état du projet.
La démo hébergée est-elle identique au dépôt ?
La démo hébergée permet d’inspecter l’expérience navigateur ; GitHub contient le code, la documentation, les dépendances et l’historique de développement.
Puis-je utiliser RuView sans matériel ESP32 ?
Vous pouvez consulter la démo et parfois lancer des chemins logiciels sans matériel, mais le sensing réel nécessite un matériel compatible qui expose un CSI utile.
RuView est-il prêt pour des décisions médicales ou de sécurité ?
Non. RuView est un logiciel de recherche et de prototypage open source. Les usages santé, chute, sécurité ou sûreté exigent une validation indépendante.