Le forumPico open source

Avis, suggestions, bugs, participez à la mise en forme du forum
Règles du forum
Chers membres, merci de prendre connaissance et respecter les quelques règles de bon sens suivantes avant de poster votre message :
- Vous assurer que vous postez dans la bonne rubrique
- Vérifier qu'il n’existe pas déjà une réponse à votre question ou un sujet identique
- Prendre conscience que vos propos n’engagent que vous et que vous devrez en assumer la paternité
- Vérifier les sources des informations que vous diffusez, en vous assurant le cas échéant de respecter les droits d’auteur qui peuvent être liés aux informations, images ou documents cités
- Prendre soin de respecter vos interlocuteurs et bannir les insultes et autres propos diffamatoires ou dégradants
- Vous assurer de rester autant que faire se peut dans le sujet exposé
- Prendre le temps de vérifier l’orthographe et la grammaire de votre message
Merci par avance de votre contribution à préserver le bon esprit de ce forum.

Etes vous pour un projet de pico open-source

Je suis pour et je veux bien participer
24
32%
Je suis pour
52
68%
Je suis contre
0
Aucun vote
 
Nombre total de votes : 76

dickymoe
Arpette
Arpette
Messages : 260
Inscrit depuis : 12 ans 10 mois
Mon équipement : Moulin Brewferm + Seaux brouwland + Tress inox + Casserole 30l + Cuve ébu 50l + Frigo pour la fermentation secondaire.
Brasseur : Amateur
Localisation : Mérignies
A remercié : 5 fois
A été remercié : 4 fois

Re: Pico open source

Message par dickymoe »

Je lance juste la réflexion afin de permettre de prendre les bonnes décisions et avancer coté logiciel.

Python est un très bon choix, et si on regarde le pad tous les inscrits s'y connaissent en python.
Nodejs avait ses avantages asynchrones et le coté full js utilisé avec angular, mais asyncio peut permettre de d'avantager python.

Pour les micros framework je ne connais pas bottle, en cherchant il y a aussi flask qui existe dans le même style. Après les gros : django avec django rest framework par ex.

Niveau données, on va en avoir quelques une tout de même : données températures de brassage, données de suivi de brassage (courbe de refroidissement du moût, sauvegarde des actions, différentes mesures au fil du temps...), cartographie, paramétrage, données de suivi de température de fermentation, etc...
Avec des données disparates : il faut que le système soit configurable et évolutif assez facilement en fonction du besoin de chacun. Et c'est plus sur ce point que je pensais au nosql, de plus le fonctionnement avec des api json facilitait le travail.
En regardant sur le net je viens de trouver http://unqlite.org/ un SQLite en no sql (bon ca n'a pas l'expérience ni le support qu'a SQLite). D'ailleurs il y avait eu des début de UnQL par les mec de SQLite mais ça à l'air mort (http://unql.sqlite.org/index.html/wiki?name=UnQL). Après il y a toujours les gros moteurs nosql...

Après si on part sur du sql SQLAlchemy pourrait permettre de se découpler du SQL et du moteur utilisé (sqlite / mysql / ...)
Avatar de l’utilisateur
NicoJ
Ch'ti nouveau
Messages : 177
Inscrit depuis : 12 ans 6 mois
Je suis tuteur : oui
Brasseur : Amateur
Localisation : Saint-Denis, La R??union
A remercié : 5 fois
A été remercié : 8 fois
Contact :

Re: Pico open source

Message par NicoJ »

Oui tu as raison il faut faire les bons choix avant de développer. Cela concerne l'architecture mais aussi les outils et les langages.
Coté client je crois que Javascript est incontournable et l'utilisation d'un framework comme AngularJS rend les choses moins douloureuses. Je suis un peu plus réticent sur node.js pour des tas de raisons certainement discutables (manque de maturité du framework, courbe d’apprentissage importante, difficultés à trouver de "vraies" compétences, etc.). Après c'est surement une techno d'avenir et qui trouve sa place dans le contexte d'applications à forte charge. J'ai peur qu'à choisir node.js "pour se faire plaisir avec cette techno" on se perde à monter en compétences (en tout cas pour moi).
Donc python me parait un bon choix, notamment parce qu'on est plusieurs à le connaitre. La force de python c'est aussi la richesse de ses librairies et de ses extensions. Je pense que ça permettra de gagner du temps pour le démarrage du projet. Par exemple je sais pas si tu connais cementcli, mais je verrais bien une interface en ligne de commande pour piloter le démarrage des différents éléments.

Par contre, pour y avoir réfléchi depuis, je te rejoints sur les données et sur l'opportunité d'utiliser une base nosql. Pas trop pour les fonctionnalités de répartition de données ou de cluster qui sont souvent proposées mais plutôt effectivement pour gérer le volume de données qui pourra être important. Par ailleurs, certaines bases comme redis permettent d'implémenter le pattern producteur/consommateur ce qui pourrait être utile pour la communication entre le serveur et les agents ou au sein de l'agent pour gérer les différentes tâches par priorité.
Par contre je n'ai pas trop d'expérience matière de base NoSQL. Redis a l'air très bien mais ne fonctionne qu'en mémoire d'après ce que j'ai vu. J'ai découvert récemment rethinkDB qui m'a l'air comparable à mongoDB, performant, et plutot bien outillé. Par ailleurs, rethinkDB permet de mettre en oeuvre le pattern producteur/consommateur. Plutot un bon candidat donc ...
dickymoe
Arpette
Arpette
Messages : 260
Inscrit depuis : 12 ans 10 mois
Mon équipement : Moulin Brewferm + Seaux brouwland + Tress inox + Casserole 30l + Cuve ébu 50l + Frigo pour la fermentation secondaire.
Brasseur : Amateur
Localisation : Mérignies
A remercié : 5 fois
A été remercié : 4 fois

Re: Pico open source

Message par dickymoe »

Je ne connaissait pas cementcli ça a l'air plus pratique pour gérer la ligne de commande donc pourquoi pas.

Pour le nosql c'est le même problème que nodejs : à la mode. Je ne m'y connais pas mais ça à l'air intéressant de s'y confronter.

Rethinkdb, jamais entendu parlé, ça a l'air d'être plutôt pas mal : assez nouveau mais ya une entreprise derrière donc ça devrait être suivi. A voir si assez mature.
Il y a un plugin pour flask (http://www.rethinkdb.com/docs/examples/ ... bone-todo/), et ya l'air d'avoir aussi des choses avec bootle (http://www.rethinkdb.com/docs/examples/ ... mber-todo/). Candidat très intéressant !!

Petite question : est-ce vraiment utile que chaque agent est sa propre base de donnée ? Pourquoi ne pas envoyer directement les données au serveur ?
Est ce que chaque agent doit pouvoir tourner tout seul ou forcement avec le serveur ?
dickymoe
Arpette
Arpette
Messages : 260
Inscrit depuis : 12 ans 10 mois
Mon équipement : Moulin Brewferm + Seaux brouwland + Tress inox + Casserole 30l + Cuve ébu 50l + Frigo pour la fermentation secondaire.
Brasseur : Amateur
Localisation : Mérignies
A remercié : 5 fois
A été remercié : 4 fois

Re: Pico open source

Message par dickymoe »

Et pour angularjs, je suis partant, j'ai discuté avec un pote qui est développeur web, qui fait du angular pour un projet perso : il trouve ça vraiment puissant mais pour certainez tachez un peu compliqué et donc pas toujours pratique. Si tu sors un peu du fonctionnement ça devient vite galère.
Il dit tout de même que lorsqu'il refait du jquery il a le sentiment d'être libre et pouvoir faire ce qu'il veut.

Après angularjs et jquery marche très bien ensemble.

Voila pour informations.
Avatar de l’utilisateur
Aed
Assistant
Assistant
Messages : 1011
Inscrit depuis : 18 ans 10 mois
Je suis tuteur : oui
Mon équipement : miror 10hl
Brasseur : Pro
Localisation : Mazerier (Auvergne)
A remercié : 8 fois
A été remercié : 60 fois
Contact :

Re: Pico open source

Message par Aed »

Désolé de ne pas être plus actif mais je suis un peu débordé en ce moment...

Plusieurs remarques sur ce que je viens de lire:
1) pourquoi utiliser du noSQL ? ou même une base de donnée ?
pour les mesures on aura systématiquement et seulement 2 champs : temps et data
vu qu'il n'y aura pas de query complexe à faire pourquoi ne pas se contenter de fichiers binaires? 32b pour le temps et 32 pour les data c'est plus que suffisant
ex: pour les logs de températures si on log chaque seconde 5 températures différentes pendant 3h on n'atteint même pas 500KB.
Après pour les recettes etc ok mais pour le process je ne vois pas

2)
BBB a un processeur monothread
? tu t'y connais sans doute mieux que moi mais les Cortex-A8 gèrent le multi-threading même si il n'est pas multi-core, ARM est censé être ultra efficace en gestion de la cache donc ca ne devrait pas être pénalisant
dans mon idées les différents threads de contrôles seront ultra simples avec des tempo qui sont géré facilement par la cache (ex : boucle sur : if temp>T1 then chauffage.off() else if temp<T2 then chauffage.on(), wait 1s)
à moins que vous ayez prévu d'automatiser cela via des circuits? (la dessus je passe...)

3) le python : super pour scripter le process en fonction de l’équipement et de la recette, mais pour la gestion des drivers bas niveau il faudra peut être faire des extensions en C non?

[edit] 4) Je suis une grosse quiche en développement web mais j'ai toujours du mal à comprendre l'utilisation de ces frameworks ultra complexes et bourrés de fonctionnalités inutiles et buggés... Par contre pour le rendu des IHM ok pour le html 5
Righ'Beern Brew association brassiculturelle
Avatar de l’utilisateur
NicoJ
Ch'ti nouveau
Messages : 177
Inscrit depuis : 12 ans 6 mois
Je suis tuteur : oui
Brasseur : Amateur
Localisation : Saint-Denis, La R??union
A remercié : 5 fois
A été remercié : 8 fois
Contact :

Re: Pico open source

Message par NicoJ »

1) Effectivement il n'y a pas forcément besoin d'une base de données coté agent. Le volume et la structure des données permettent d'envisager un stockage plus simple comme tu l'indiques. Par contre il faut bien prévoir un stockage persistant. Je pense qu'il vaut mieux eviter que les agents renvoient les données 1 par 1 au serveur (pb de perf...). Il vaut prévoir un petit tampon (mémoire et/ou disque) sur l'agent avec une transmission régulière ou à la demande vers le serveur.
C'est plutot coté serveur qu'il faut prévoir une structure de données plus adaptée au stockage et à la gestion des données par l'IHM.

2) Je ne suis pas non plus spécialiste du Cortex-A8, c'est ce qu'indique wikipedia. Le processeur est mono-coeur: ça ne l'empêche pas de gérer plusieurs threads et plusieurs processus (heureusement !) c'est juste qu'à un instant donné il n'y a qu'un seul processus qui a la main. Donc la parallélisation n'apportera aucun gain. Par contre la programmation asynchrone permet d'utiliser les temps d'attente d'I/O pour du temps processeur.
En programmation classique, lorsque tu interroges un capteur via un bus I2C ou un ADC, le CPU est "bloqué" en attente du retour du matériel (même fonctionnement avec des I/O sur disques ou réseau). En programmation asynchrone, tu profites de ce temps d'attente pour exécuter un autre traitement. La librairie asyncio de python 3.4 (et node.js par défaut) permet ce type de programmation.
Pour info, j'ai testé la semaine dernière (avant de griller ma carte BBB) d'interroger un capteur de température DS18B20. Par un bus 1-wire il faut environ 1/2 seconde pour avoir la réponse (à revérifier ...). C'est dommage de perdre ce temps. Il pourrait être utilisé pour convertir une donnée précédemment capté, gérer une commande, dialoguer avec le serveur, ...

3) La gestion des driver bas niveau est laissée au noyau. Pour moi on devrait pouvoir attaquer les composants via les différents bus et système de fichier /sys. Après si il faut faire des extensions en C, l'appel depuis Python ne pose pas de soucis. Sachant qu'il existe déjà des librairies python pour communiquer en I2C par exemple.
Avatar de l’utilisateur
NicoJ
Ch'ti nouveau
Messages : 177
Inscrit depuis : 12 ans 6 mois
Je suis tuteur : oui
Brasseur : Amateur
Localisation : Saint-Denis, La R??union
A remercié : 5 fois
A été remercié : 8 fois
Contact :

Re: Pico open source

Message par NicoJ »

Salut,

Ci-joint un schéma plus simple illustrant également les différentes options de déploiement possibles.
Pièces jointes
configurations brewbox.pdf
(122.65 Kio) Téléchargé 259 fois
dickymoe
Arpette
Arpette
Messages : 260
Inscrit depuis : 12 ans 10 mois
Mon équipement : Moulin Brewferm + Seaux brouwland + Tress inox + Casserole 30l + Cuve ébu 50l + Frigo pour la fermentation secondaire.
Brasseur : Amateur
Localisation : Mérignies
A remercié : 5 fois
A été remercié : 4 fois

Re: Pico open source

Message par dickymoe »

@Aed : ne pas avoir de base coté agent on est a peu près d'accord. Pas contre coté serveur cela est plus que recommandé afin de faciliter le traitement des données.
Niveau gestion de l'électronique, je pense que python peut faire l'affaire et sinon oui il y a toujours la C mais pas sur qu'on en ai vraiment besoin vu les libs python disponible.

@NicoJ : pour ma part je trouve que ton schéma est correct. Je met a jour vite fait le pad.
Avatar de l’utilisateur
NicoJ
Ch'ti nouveau
Messages : 177
Inscrit depuis : 12 ans 6 mois
Je suis tuteur : oui
Brasseur : Amateur
Localisation : Saint-Denis, La R??union
A remercié : 5 fois
A été remercié : 8 fois
Contact :

Re: Pico open source

Message par NicoJ »

Salut,

Pour info, je viens de pousser un squelette de projet Python sous github : https://github.com/beerfactory/brewbox-software.
Pour le moment evidemment il n'y a pas grand chose, mais ça intègre déjà la configuration du packaging, l'exécution des tests unitaires et l'intégration continue avec travis-ci.
Si vous n'êtes pas habitué de git et du processus git-flow, jetez un oeil à cette page : http://nvie.com/posts/a-successful-git-branching-model/
Avatar de l’utilisateur
Cede
Maître Brasseur
Maître Brasseur
Messages : 4199
Inscrit depuis : 18 ans 7 mois
Je suis tuteur : oui
Mon équipement : Un peu trop :)
Brasseur : Amateur
Localisation : Clapham / xToulouse
A remercié : 28 fois
A été remercié : 147 fois
Contact :

Re: Pico open source

Message par Cede »

Mon idée du threading, c'est pour justement que l'on n'ait pas a attendre dans le programme que les capteurs renvoient leurs données.
Dans un système de supervision de puits de géothermie, j'avais un thread dédié aux échanges avec les capteurs et deux buffers circulaires. Un pour les commandes, l'autre pour les résultats.
Un autre thread pour la sauvegarde sur carte.
Le traitement n'est bien évidement pas réellement parallèle, mais on récupère des cycles pour gérer autre chose et je trouve ça beaucoup plus simple à programmer.

Dans les microcontroleurs, je travaille un peu de la même façon avec des interruptions.

Pour les capteurs DS18B20, ils sont lents quand on monte en résolution. Temps de conversion: 9 bits => 93.75ms, 12 bits => 750ms.
Et quand tu en as une flopée, heureusement que l'on peut demander la conversion en broadcast :)
Le bus 1 wire reste tout de même lent bien que très pratique et on peut tirer une certaine longueur avec quelques précautions.

J'ai reçu certains composants et je vais voir si ça va bien avec les circuits que j'ai dessinés, ensuite on passera à la réalisation pratique avec la commande des circuits imprimés :)
http://www.minibrasse.ca
En cours: Oud bruin 2020 Phase2, PA Jericho, Rousse Québécoise, Krispy Lager
Répondre

Créer un compte ou se connecter pour rejoindre la discussion

Vous devez être membre pour pouvoir répondre

Créer un compte

Vous n‘êtes pas membre ? Inscrivez-vous pour rejoindre notre communauté
Les membres peuvent créer leurs propres sujets et s‘abonner à des sujets
C‘est gratuit et cela ne prend qu‘une minute

Inscription

Se connecter