Les personnes qui cherchent un WiFi sensing dataset veulent souvent des données CSI publiques, un benchmark de modèles ou des exemples réalistes pour tester une démo sans caméra. Ces besoins sont proches, mais pas identiques.
Pour RuView, le dataset est la couche qui détermine ce que le modèle a réellement appris. La démo montre l’interface, GitHub montre le code, ESP32 explique la capture, mais les données fixent les limites de validation.
Ce qu’un bon dataset WiFi sensing doit contenir
Un bon dataset WiFi sensing documente la capture CSI, pas seulement les classes. Il doit préciser matériel, bande WiFi, antennes, cadence de paquets, pièce, participants, protocole, synchronisation et split d’évaluation.
La tâche reste le critère principal. La reconnaissance d’activité exige des actions répétées, la présence exige des essais pièce vide et occupée, la respiration exige une référence indépendante, et le multi-utilisateur exige des labels d’interaction.
- Privilégiez les datasets avec matériel, pièce, participants et labels explicites.
- Cherchez des baselines vides et des essais négatifs.
- Vérifiez si le split sépare personnes, pièces, sessions ou appareils.
Benchmarks publics à comparer
Les ressources publiques ont des rôles différents. Awesome-WiFi-CSI-Sensing sert de répertoire. SenseFi aide à comparer des modèles PyTorch. WiMANS couvre l’activité multi-utilisateur. CSI-Bench se rapproche des tests en conditions réelles.
Ne les traitez pas comme équivalentes. Un répertoire aide à trouver, une bibliothèque aide à reproduire, et un dataset terrain aide à mesurer la robustesse.
| Ressource | Meilleur usage | À vérifier |
|---|---|---|
| Awesome-WiFi-CSI-Sensing | Trouver papers et datasets | Accès et documentation |
| SenseFi | Benchmark de modèles | Datasets, modèles et splits |
| WiMANS | Activité multi-utilisateur | Labels, utilisateurs et vidéo |
| CSI-Bench | WiFi sensing réaliste | Tâches, appareils et accès |
Choisir des données pour RuView
Commencez par la question RuView à valider. Pour la présence, évitez un dataset de gestes fins. Pour la généralisation, évitez les splits issus d’une même session.
La checklist utile contient CSI brut, métadonnées, labels, baselines et splits. Sans cela, une bonne précision peut seulement refléter une pièce mémorisée.
- Capturez une baseline locale même avec des données publiques.
- Gardez le timing et les essais négatifs pour mouvement ou pose.
- Documentez consentement et accès si une vidéo synchronisée existe.
Erreurs fréquentes
L’erreur classique consiste à croire qu’une bonne précision sur un dataset garantit une autre pièce. Le CSI dépend des murs, meubles, antennes, firmware et trafic.
Autre erreur : mélanger les tâches. Un dataset de gestes ne prouve pas la présence multi-utilisateur, et un dataset avec vidéo peut être trop sensible pour une démo légère.
| Erreur | Risque | Approche plus sûre |
|---|---|---|
| Une seule pièce | Le modèle mémorise le multipath | Tester pièces et sessions distinctes |
| Pas de baseline | Faux positifs invisibles | Capturer vide et négatifs |
| Vie privée ignorée | Vidéo et routines sensibles | Décrire consentement et accès |
| Tâches incompatibles | Labels non comparables | Choisir par tâche |
Petit plan de collecte avec ESP32 et RuView
Si aucun dataset public ne convient, créez un petit corpus local : pièce vide, entrée, sortie, marche, assise, porte sans personne et trafic routeur sans mouvement.
Séparez CSI brut, features filtrées, labels, notes de pièce et splits. Chaque prédiction doit rester traçable jusqu’à une session.
- Nommez les sessions par date, pièce, placement, bande et scénario.
- Gardez CSI brut et features séparés.
- Réservez une session ou une pièce au test.
Pourquoi cette page ne cannibalise pas les autres pages RuView
Cette page ne remplace pas la home, le manuel GitHub, le manuel ESP32 ni la page motion capture. Elle traite des datasets, benchmarks, labels, splits et validation.
Une recherche “ruview github” doit aller vers le manuel GitHub. Une recherche “wifi sensing dataset” a besoin de critères de données avant de choisir RuView, ESP32 ou un corpus public.
Carte d'intention : dataset, benchmark, tutoriel ou capture locale
La requête WiFi sensing dataset peut désigner un corpus CSI, une bibliothèque benchmark, un jeu tutoriel ESP32 ou un plan de validation pour une démo RuView.
Pour apprendre, choisissez un benchmark documenté. Pour valider un produit, capturez une baseline locale. Pour HAR, exigez des labels répétés. Pour la présence, priorisez pièce vide et faux positifs.
| Intention | Meilleur choix de données | À éviter |
|---|---|---|
| Apprendre le pipeline | SenseFi ou un benchmark CSI public documenté | Archives zip non documentées sans séparation |
| Valider une pièce | Petit dataset ESP32 local avec des baselines | Utiliser uniquement des données publiques d'un autre bâtiment |
| Reconnaissance d'activités humaines | Essais répétés d'activités annotées | Datasets limités à la présence |
| Évaluer la démo RuView | Données séparant limites, contrôles négatifs et captures d'écran | Prendre le succès de l'interface pour une preuve du modèle |
Dataset WiFi CSI ou benchmark : choisir selon la tâche
Les recherches de dataset CSI mélangent souvent téléchargement et comparaison de benchmarks. Un dataset WiFi CSI contient des données brutes ou labellisées ; un benchmark de sensing WiFi ajoute une tâche, un split et un protocole d’évaluation définis. Décidez d’abord de votre besoin.
Pour un test de pièce de type RuView, les datasets WiFi CSI publics servent de point de départ, pas de remplacement à la capture locale. Faites correspondre matériel, labels, pièce et tâche, puis gardez une baseline de pièce vide et une session mise de côté.
- Choisir un benchmark pour un split et une comparaison documentés.
- Capturer des données CSI locales si la pièce ou le matériel diffère.
- Rendre labels, données brutes, baselines et splits traçables.
Sources et références de datasets
Questions fréquentes sur les datasets WiFi sensing
Quel dataset choisir pour débuter ?
Pour apprendre les modèles, commencez avec un benchmark documenté comme SenseFi. Pour une démo RuView réelle, ajoutez une baseline locale.
Puis-je entraîner RuView avec n’importe quel dataset CSI ?
Pas sans vérification. Le matériel, la pièce, les labels et la tâche doivent correspondre.
Pourquoi la pièce vide compte-t-elle ?
Elle révèle les changements dus à l’environnement et réduit les faux positifs.
Ces datasets sont-ils sensibles ?
Oui. Le CSI peut révéler présence et routines, et les vidéos synchronisées exigent plus de prudence.
Faut-il utiliser un dataset public ou collecter le sien ?
Utilisez les données publiques pour apprendre et comparer, mais collectez une baseline locale pour un résultat RuView dans une pièce précise.
Quelle est la différence entre un dataset WiFi CSI et un benchmark ?
Un dataset WiFi CSI est un ensemble de données de canal brutes ou labellisées. Un benchmark ajoute une tâche, un split, des métriques et un protocole de comparaison. Pour un test RuView, les données publiques apprennent le pipeline, mais une baseline locale reste nécessaire.