Nuit du Code Citoyen 2017

Cet événement est un Hackhaton dédié aux développements concernant des projets citoyens. Le projet Capteurs de Gulliver et la ville de Rennes est un de ces projets, et a été accepté par les organisateurs de l'événement.

Informations générales

La Nuit du Code Citoyen se tient le week-end des 4 et 5 mars 2017.

À Rennes, elle se tient à la Maison de la Consommation et de l'Environnement, 48 bd Magenta. Elle commence le vendredi soir 3 mars, par une Disco Soup permettant aux équipes projets et aux participants de faire connaissance et tracer le programme de travail du week-end.

Projet Capteurs de Gulliver

Plusieurs lots peuvent faire l'objet d'un travail de codage lors de ce week-end.

Électronique

Les bidouilleurs et autres soudeurs dans l'âme peuvent contribuer au développement d'une station offrant plusieurs sondes (NO², PM,…), dans le cadre du lot Electronique de bord.

L'idée est d'étendre la station Ambassad'Air, actuellement basée sur le boîtier AirBeam, qui ne mesure que les PM.

La MCE et la ville mettent à notre disposition une sonde de bonne qualité, qu'il faut intégrer à une carte Arduino.

Un autre composant est aussi à intégrer : l'ESP8266, qui offre le WiFi et une puissance plus élevée que l'Arduino. Il servirait de “site Web” pour le client de lecture des données temps réel (voir plus bas le lot Client).

FirmWare

Les codeurs en C vont pouvoir travailler sur les programmes de bas niveau gérant l'Arduino et/ou l'ESP8266, dans le cadre du lot Micro-code embarqué.

Il est possible de s'inspirer du firmware de l'AirBeam, pour l'augmenter ou pour faire un code plus générique, paramétrable et plus facilement extensible par des particuliers souhaitant inclure leurs propres données (telles que la vitesse et la direction du vent).

Un autre firmware à développer est celui de l'ESP8266 : il s'agit là de générer à chaque interrogation du composant par wifi une page HTML affichant les dernières valeurs en date des sondes de la station. Le principe serait le suivant : la carte Arduino lit les valeurs des sondes (NO², PM2,5, PM 10, température,…) et les met en forme brute (CSV, par exemple) sur son port série, que lit à son tour l'ESP8266 ; ce dernier garde en mémoire la dernière valeur, qu'il met en forme et retourne au client WiFi quand celui-ci l'interroge.

Serveur

Une réunion va avoir lieu le vendredi matin 3 mars avec le SIG de Rennes Métropole. Le contenu des lots Serveur et Visualisation vont dépendre des problèmes et besoins recensés lors de cette rencontre.

Visualisation

Les différents acteurs publics impliqués s'interrogent sur les applications qui pourraient être faites à partir des données. Il pourrait donc être intéressant de phosphorer sur cela et de faire quelques prototypes ce Week-end…

Nous pouvons exploiter les données géographiques déjà en ligne du SIG de Rennes Métropole : geOrchestra.

Client local

Dans le cadre du lot Affichage à l'utilisateur, deux applications peuvent faire l'objet de travaux lors de la Nuit du Code Citoyen (en plus du service web ESP8266) :

  • l'application Android d'AirCasting nécessite d'être modifiée, pour la franciser, mais aussi pour qu'elle accepte des données à un rythme moins rapide (passer d'une seconde à une ou cinq minutes), et pour résoudre le problème du menu (obsolète dans les dernières versions d'Android). Pour cela, la première étape est de parvenir à la régénérer.
  • une application Bluetooth pour PC en Java a commencé à être développée. Elle nécessite encore du travail, ne serait-ce que pour parvenir à récupérer les données brutes.

Voilà donc un programme alléchant, où chacun devrait trouver son bonheur. Nous choisirons les tâches le vendredi soir, en fonction des présents et de leurs préférences.

Réalisations

DEVs

Le code a été poussé sur GitLab : https://gitlab.com/AmbassadAir/GullivAir

Un Pad a été alimenté au fur et à mesure de la journée : https://mensuel.framapad.org/p/gulliver_ncc

Principaux travaux

  • des ESP8266 fonctionnels
  • un code serveur web avancé pour ESP : sources
  • une première gestion des données série sur l'ESP : même projet GitLab
  • quelques explorations de l'affichage sur OSM

Framapad du week-end

Nuit du Code Citoyen - Gulliver / Ambassad'Air : http://gulliver.eu.org/nuit_code_citoyen_2017

Le point de départ :

Il y a une demande citoyenne pour mesurer la qualité de l'air extérieur (ou intérieur), en utilisant des capteurs open-source
On voit émerger des capteurs ou des projets sur ces problématiques (comme la démarche Smart Citizen à Barcelone https://smartcitizen.me/ , Making Sense à Amsterdam http://making-sense.eu/urban-airq-citizens-measuring-air-quality-themselves/ ). Qui constituent des expérimentations qui nourrissent notre réflexion
Ville de Rennes / MCE & Gulliver se sont lancés (courant 2016) dans le projet Ambassad'Air : http://www.wiki-rennes.fr/Ambassad%27Air qui vise à développer la mesure citoyenne (via capteur opensource) de qualité de l'air (extérieur).
La MCE a pu tester quelques capteurs existants (été 2016) et il a été arrêté que le capteur Air Beam / Air Casting correspondait le plus aux besoins
Depuis fin janvier 2016, 16 volontaires (préalablement formés à la pollution de l'air / à la mesure avec Air Beam) sont équipés de capteurs Air Beam et effectuent des mesures sur 2 quartiers
Le projet repose sur un produit existant http://aircasting.org/ le capteur Air Beam / appli (sous Android) Air Casting / données intégrées au serveur Air Casting https://github.com/HabitatMap/AirCasting

Ambassad'Air à la Nuit du Code Citoyen

Souhait d'améliorer : le boîtier de mesure (étendre les paramètres possibles), la transmission (réseau LoRa ?), le stockage des données (serveur iot de Rennes Métropole, format SOS Server Observation Service), la visualisation (à créer). Définis par l'asso Gulliver : http://gulliver.eu.org/capteurs_citoyens_descriptif / https://gitlab.com/AmbassadAir/AirBeam

Présents / contacts:

  1. Vincent (Gulliver),
  2. Jack (Gulliver & volontaire Ambassad'Air),
  3. Jacques (animateur Ambassad'Air),
  4. Philéas (étudiant INSA, le samedi matin).
  5. Arthur (C++, image, web, le samedi après midi / dimanche matin)
  6. RZR (Philippe, le samedi après midi) rzr at gna.org
  7. Théo (le dimanche)

Au regard des forces en présence à la Nuit du Code Citoyen, deux sous-projets se détachent :

  1. codage du serveur Web de l'ESP8266 (en cours) : comment se gère Flash, pour éviter de ré-générer la page web ? Voir dans IDE Arduino ?
  2. quoi faire des données ? brainstorming visualisation (pas encore engagé)

Problématique des cas d'utilisation :

  1. mobile ⇒ fréquence de capture élevée mais durant un temps limité (trajet)
  2. fixe ⇒ émission des données : soit WiFi (mais il faut modifier le firmware pour chaque utilisateur) soit bluetooth (mais il faut un smartphone) soit LoRa

SAMEDI MATIN

10h Vincent assemble les composants sur la carte Arduino. Mais souci de surchauffe (inversion de fil d'alimentation + / -), qui a grillé le système. Mais pas assez de ports pour tout mettre (LoRa, ESP, Bluetooth) sur la carte Arduino. Et on a que 2 (ballot…)

Problème à 11h00 : le montage de l'ESP ne fonctionne pas

11h40 : après vérif des cablages, l'ESP fonctionne et affiche sa première page YES !!!! web access point (ci-dessous). Appel ID serveur. Mis à jour automatique

SAMEDI APRES MIDI

Planification des travaux :

  1 - page web simple
  2 - rafraîchissement auto
  3 - lecture données RX/TX (envoyées via USB)
  4 - reroutage données USB AirBeam

brainstorming sur le circuit de circulation de la donnée. Qui varie selon les stations fixes OU stations mobiles STATION DE MESURE : qui fait la mesure, et envoie la donnée. On butte sur le système de communication des données. Quel système retenir ? Pour les stations fixes, il parait possible d'utiliser le réseau LoRa (pas encore opérationnel à Rennes), car les fichiers sont moins lourds (fréquence d'acquisition de données moindre) ? Wifi, mais pas forcément facile pour un usager lambda.

SERVEUR : données envoyées par la station (via réseau LoRa) API : appli qui permet la visualisation des données / rendu utilisateur (en direct). Plutôt que de développer des applis iOS / Android (complexe), il est plus facile que l'API interroge l'ESP (car web, plus standardisé) éventuellement solution iot pour versions ultérieures avec IoTivity (présentation de RzR)

SAMEDI FIN D'APRES MIDI & SOIR

Arthur a codé un serveur web dont la page est active et le service récupère les dernières valeurs pour les données et les rafraichit. Il a commité sur le GitLab Ambassad'Air, dans le projet Gulliv'Air :https://gitlab.com/AmbassadAir/GullivAir RZR et VinCIv ont avancé le code de la lecture du port série, qui s'affiche maintenant dans la page web Théo a pu afficher des données sur OSM RzR a intégré le code d'Arthur ⇒ un affichage un peu sophistiqué, commité et pushé sur GitLab à 1h00

Théo : Comment intégrer des mesures dans OpenStreetMap depuis un fichier geoJSON

  Wiki pour ajouter des données sur le calque http://wiki.openstreetmap.org/wiki/FR:UMap/Guide/Importer_un_fichier_de_donn%C3%A9es
  prochaine étape -> trouver comment personnaliser l'aspect du marqueur via le fichier geoJSON => J'ai créé des points avec différentes couleurs puis j'ai exporté le calque en format geoJSON pour voir comment jouer avec l'aspect du marqueur. Mais je ne réussi pas à l'importer pour créer des nouveaux points sur le calque, la string qui introduit les caractéristiques du marqueur n'est pas reconnue https://forum.openstreetmap.fr/viewtopic.php?f=19&t=4826  = solution avec importation de fichier csv et marqueur prédéfini
  Trouver comment envoyer le fichier geoJSON automatiquement sur Umap
  Exemple de fichier geoJSON uploadé sur le umap
  {
              "type": "Feature",
              "properties": {
              "temperature": "21",
              "humidity": "3"
              "_storage_options": { //non reconnu à partir d'ici
                "color": "DarkRed",
                "iconClass": "Circle",
                "iconUrl": "/uploads/pictogram/baseball-24.png"
              }
            },
            "geometry": {
              "type": "Point",
              "coordinates": [
                49.99881684780121,
                69.99988326700364
              ]
            }
          }
  Représentation intéressante avec leafletjs.com en fonction des valeurs mesurées / Intégration de la carte sur une page HTML et données rentrées directement sur cette page ou depuis une base de données (voir le hackpad DAISEE)  Surement plus simple de traiter les données de la bdd avec un protocole javascript pour les traiter. Leaflet est une bibliothèque JavaScript libre de cartographie en ligne. Ellea remplacé OpenLayers sur les projet d'OpenStreetMap

Comprendre comment est créé le fichier pour geoJSON pour exploiter les valeurs relevées et adapter l'aspect du marqueur en fonction (ex: température de 45° marqueur rouge. 0°⇒bleu ⇒ Réponse, les données sont stockées dans la bdd en brut, en fichier .sos

Voir comment réagit le calque avec bcp de données/comment le personnaliser/le rendre accessible Trouver si on peut filtrer les propriétés des marqueurs ex: carte de température / carte de pression…

DIMANCHE MATIN

Réflexion sur le codage JSON des données brutes :

  1. notion d'identifiant de la donnée
  2. besoin de généricité / réutilisabilité ⇒ “standard”
  3. LoRa éventuel ⇒ compacité des codes

⇒ un premier standard pour les principales mesures envisageables :

  1. Temp pour la température
  2. Hum pour l'humidité
  3. PM10 et PM25 pour les particules
  4. NO2, SO2, O3, CO, … pour les gaz
  5. VOC pour la donnée moyenne sur les composants organiques volatiles (un codage spécifique devra être mis au point dans le cas de mesures séparées)
  6. WSp pour la vitesse du vent, WDir pour sa direction (a priori, une mesure d'angle en degrés)
  7. Rad pour le radon (besoin émis par le réseau Sortir du Nucléaire)

Transfert de données en série au format JSON d'une carte arduino vers EPS


/ Transfert de données d'une carte arduino à une autre Emission des données via le port Série Logiciel : Ce sketch envoie d'une chaine JSON à une carte connectée via le port série logiciel Branchements : * RX connecté sur pin 8 (connecté à TX sur l'autre carte) * TX connecté sur pin 9 (connect à RX sur l'autre carte) * Et ne pas oublier de relier les masses des 2 cartes (GND) Activer d'abord la carte d'émission, puis la réception en les rebranchant dans cet ordre / #include <SoftwareSerial.h> #include <ArduinoJson.h> int led = 13; SoftwareSerial mySerial(8, 9); RX, TX char strJson[]= ”{\”sensor\”:\”gps\”,\”time\”:1351824120,\”data\”:[48.756080,2.302038]}”; char strJson[]= ”{\”temp\”:\”gps\”,\”time\”:1351824120,\”data\”:[48.756080,2.302038]}”; void setup() { – définition du port Série Logiciel mySerial.begin(57600); pinMode(led, OUTPUT); } void loop() – Toutes les 2 secondes envoi d'un message { if (mySerial.available()) {digitalWrite(led, HIGH); – Pendant l'envoi allume la LED mySerial.write(strJson); envoi de la chaine JSON } digitalWrite(led, LOW); delay(2000); – Attente de 2 secondes avant de recommencer } Partie réception de la chaine JSON ——————————————- / Transfert de données d'une carte arduino à une autre Réception de données via le port Série Logiciel : Ce sketch reçoit le message Hello Word d'une autre carte connectée via le port série logiciel Branchements : * RX connecté sur pin 8 (connecté à TX sur l'autre carte) * TX connecté sur pin 9 (connect à RX sur l'autre carte) * Et ne pas oublier de relier les masses des 2 cartes (GND) Activer d'abord la carte d'émission, puis la réception en les rebranchant dans cet ordre ***/ – Déclaration du port Série Logiciel #include <SoftwareSerial.h> SoftwareSerial mySerial(8, 9); RX, TX – Mise en fonction de la LED lorsqu'un message est reçu int led = 13; – Setup void setup() { – Initialisation de la LED pinMode(led, OUTPUT); – Ouverture du port Série de la carte pour le moniteur Serial.begin(9600); while (!Serial) {;} – Pour Leonaro nécessaire Serial.println(“Attente réception !”); – Définition et ouverture du port logiciel mySerial.begin(57600); } – Affichage de la communication void loop() { – Si des données sont présentes if (mySerial.available()) {– Affichage sur la console des données Serial.write(mySerial.read());} }

 
nuit_code_citoyen_2017.txt · Dernière modification: Le 17/03/2017 à 22:20 par vinciv     Haut de page
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki Design by Chirripó