Pi RuView n’est pas un produit séparé. C’est une intention de recherche autour de RuView sur Raspberry Pi ou petit ordinateur edge. La méthode sûre est progressive : démo hébergée, dépôt GitHub officiel, puis Pi comme hôte edge seulement après avoir séparé logiciel, modèle, firmware et capture CSI réelle.
Cette page complète les guides GitHub et ESP32 CSI. Elle explique le rôle du Raspberry Pi, ce qui reste aux nœuds ESP32, ce que Docker ou les modèles impliquent, et comment ne pas confondre démo chargée et sensing validé.
Ce que signifie généralement “Pi RuView”
La recherche pi ruview regroupe souvent trois questions différentes : ouvrir la démo dans un navigateur Raspberry Pi, exécuter le logiciel ou Docker de RuView sur Pi, ou remplacer un nœud ESP32 CSI par un Pi. Ces questions doivent rester séparées pour éviter de mauvais diagnostics.
Raspberry Pi peut servir d’hôte local, de tableau de bord, de passerelle MQTT/Home Assistant ou de petit ordinateur edge si le dépôt actuel le permet. Il n’est pas automatiquement un capteur CSI. Pour la capture réelle, vérifiez le dépôt et les documents ESP32 avant de supposer que le WiFi du Pi expose les données nécessaires.
- Utiliser la démo pour l’orientation.
- Utiliser GitHub pour les commandes et limites actuelles.
- Utiliser ESP32 ou matériel compatible pour la CSI réelle.
- Utiliser le Pi comme hôte après validation du runtime.
Étape 1 : ouvrir d’abord la démo hébergée
La première vérification est la démo hébergée de RuView. Elle confirme l’interface, le chargement du navigateur et la manière dont le projet présente présence, mouvement, respiration, rythme cardiaque et intelligence de pièce. Elle ne prouve pas que votre matériel local peut mesurer une pièce.
Sur Raspberry Pi Desktop, un navigateur Chromium récent suffit généralement. Si la page est lente, testez aussi depuis un autre ordinateur avant de modifier le code capteur.
- Revue navigateur : ouvrir démo et docs.
- Hôte local : lancer seulement si l’architecture est supportée.
- Passerelle : recevoir ESP32/MQTT et afficher.
| Question | Action | Preuve |
|---|---|---|
| Demo | Open demo | Interface |
| Software | Check GitHub | Setup |
| Sensing | Validate CSI | Signal |
Étape 2 : vérifier GitHub avant de copier des commandes
La source officielle est github.com/ruvnet/RuView. Consultez README, commits récents, issues, Docker, modèles et architecture avant d’exécuter une commande sur Pi. Un extrait de blog peut être obsolète rapidement.
Pour Pi, vérifiez linux/arm64, images multi-arch, versions Python ou Node, notes Rust, taille des modèles et mémoire. Une commande x86 ou GPU ne doit pas être supposée compatible.
- README pour le chemin actuel.
- Docker pour arm64 ou multi-arch.
- Modèles pour taille, quantification et CPU.
| Area | Check | Reason |
|---|---|---|
| README | Current path | Fresh instructions |
| Docker | arm64 | Compatible image |
| Model | CPU/memory | Realistic edge use |
Étape 3 : décider du rôle du Raspberry Pi
Un bon setup commence par un rôle limité. Le Pi est souvent utile comme hôte toujours allumé, UI locale, pont Home Assistant, récepteur de flux capteurs ou petit serveur edge. Pour les modèles, un Pi 5 est plus plausible, mais mémoire, refroidissement et CPU doivent être mesurés.
Ne donnez pas tous les rôles au Pi en même temps. Testez l’UI sans matériel, Docker avec données simulées ou enregistrées, puis la capture CSI séparément.
- Séparer UI, runtime, bridge et inférence.
- Mesurer mémoire, CPU et latence.
- Tester des données enregistrées avant le live.
Étape 4 : séparer capture ESP32 CSI et hébergement Pi
Le sensing RuView dépend de Channel State Information, pas seulement du WiFi ordinaire. Les ESP32 sont une voie économique parce que ESP-CSI et ESP32 CSI Tool exposent des données de canal. Le Pi peut héberger ou relayer, mais ne doit pas être traité comme capteur sans preuve CSI.
Architecture propre : ESP32 capture, Pi héberge ou transmet, RuView affiche confiance et limites. Si le log CSI est vide, corrigez les capteurs; si Docker échoue, corrigez le runtime; si les résultats exagèrent, corrigez validation et texte.
- Séparer capture, hosting, pipeline et affichage.
- Conserver baseline vide et faux positifs.
- Éviter les décisions santé, sûreté ou sécurité.
Étape 5 : utiliser les modèles préentraînés avec prudence
Le README pointe vers des ressources WiFi DensePose sur Hugging Face. Ce sont des artefacts de modèle, pas la preuve que votre pièce, votre carte ou votre Pi donnera le même résultat. Testez un échantillon enregistré et comparez avec vos labels.
Sur Pi, surveillez taille, CPU, quantification, mémoire, temps de démarrage et comportement face à la CSI bruitée. La vraie validation vient de vos captures.
Checklist sûre pour Pi RuView
Notez commit, modèle de Pi, OS, navigateur, tag Docker, modèle, carte capteur, firmware, canal WiFi, pièce et labels. Ces notes expliquent les changements futurs.
Première session : pièce vide, entrée d’une personne, personne immobile, marche, mouvement de porte sans personne, déplacement léger. Sans rejet des faux positifs, pas d’usage sérieux.
- Noter versions avant matériel.
- Tester données enregistrées avant live.
- Afficher limites et incertitude.
Comment cette page évite la cannibalisation
Cette page couvre Pi et Raspberry Pi setup. Le guide GitHub reste pour ruview github. Le guide ESP32 CSI reste pour capture et firmware. La page WiFi human detection reste pour fiabilité et faux positifs.
Ces limites aident les utilisateurs et les moteurs à choisir la bonne page.
Sources officielles et références techniques
FAQ configuration Pi RuView
Pi RuView est-il un projet officiel séparé ?
Non. C’est une expression de recherche pour utiliser RuView avec Raspberry Pi. La source officielle reste github.com/ruvnet/RuView.
Raspberry Pi peut-il capturer la CSI WiFi ?
Ne le supposez pas. Le Pi peut héberger, mais la CSI dépend du matériel et des pilotes.
Puis-je exécuter RuView sans matériel ?
Vous pouvez inspecter la démo et parfois lancer le logiciel, mais le sensing réel exige une entrée CSI validée ou des données enregistrées.
Que tester en premier ?
Démo, README officiel, chemin logiciel simple avec données enregistrées, puis ESP32 CSI.
Est-ce adapté aux décisions santé ou sécurité ?
Non. Traitez-le comme recherche et prototype avec validation indépendante.