Le forum ⇒ Pico open source

[NicoJ]

Salut,

Histoire de tenter de relancer ce sujet et motiver les troupes toujours intéressés par ce projet, j'ai essayé de décrire un peu les idées que j'avais en tête sur les fonctionnalités et l'architecture du projet. J'ai formalisé tout ça sur les pages que vous trouverez ici. C'est en anglais, histoire de toucher un public plus large ...
N'hésitez pas à me faire de vos remarques, suggestions, critiques, etc.

[gremlinz]

Bonjour,
Ce projet semble très intéressant, je me permet d'apporté mes expériences sur différent projet que j'ai fait sur arduino et raspberry.
Souvent le plus simple et de scinder le système en 2, un carte qui contrôle la température, les moteur etc... et qui renvoie les informations a un serveur avec le quel on interagit.
dans mes tests pour automatiser ma future brasserie, je travail avec un raspberry qui est relier au différents capteur et relais, celui-ci envois/reçoit ces informations via un câble réseau relié au serveur qui stock les informations ( courbe de température, vitesse de rotation des moteur, fonctionnement de la pompe, etc...) et qui permet un affichage sur n'importe quel périphérique via un serveur web.

Si vous avez besoin d'aide sur ce projet, je peux vous apporter mes compétences en Linux, php, mysql, python, arduino etc ...

[Cede]

Bon, en fait j'avais ouvert un autre fil qui rejoint celui-ci puisque je pensais aussi partir sur du beaglebone plutôt que du adruino ou autre microcontrôleur.
Pas que je n'aime pas adruino, je ne travaille pas vraiment avec au niveau pro et dans mes loisirs, je suis plus microchip car ça fait un bail que j'ai commencé là dessus.

Le raspberry c'est bien, mais au niveau des ports directs sur le proc et temps réel c'est plus limité qu'un beaglebone.
Et le beaglebone embarque comme deux adruinos... Pas faciles à dompter, mais une fois qu'on a pris le coup de main, ça s'avère très utile.


Alors dans mes cordes:
- design de cape pour le BBB avec la partie dtb qui va avec
- entrées / sorties, i2c, 1 wire etc... j'ai déjà fait des slaves 1 wire pour des débimètres
- convertisseurs AD/DA, le DA peut être intéressant pour piloter des vannes 0-10V
- code pour les PRUSS, pour le PWM bien synchro avec le réseau ça marche nickel et ça évite de chauffer les SSR

En gros, l'électronique c'est une partie de mon métier.

La programmation ce n'est pas ma force.
Python je connais, mais j'en ai tellement fait à en vomir, que j'y touche le moins possible, ça me file des boutons.
Objective C, je me débrouille. J'ai des softs qui tournent avec des transmissions de données en bluetooth avec des cartes, remise sur un serveur web, etc...
C/C++ bien sur

Donc voilà si je peux servir à quelquechose, ça me fera plaisir.

[gremlinz]

Je connaissais pas le beaglebone, ça ressemble beaucoup au raspeberry?
J ai prévu 2 ds18b20 pour la prise de température, un relais 30A pour gérer la résistance en on/off.
Je travail actuellement sur le programme de gestion, pour le moment sur arduino, car la gestion des gpio sous raspberry c est pas gagner !!!

[Cede]

Je connaissais pas le beaglebone, ça ressemble beaucoup au raspeberry?

Ça ressemble, oui, mais pas tant que ça.
Le beaglebone a un proc Arm8 à 1GHZ, 2 ou 4G de emmc, donc exit la carte SD, même si on peut booter depuis une carte SD pour faire des tests sur un os différent ou une autre version de kernel.

Et surtout, précieux pour moi, le nombre de GPIO.

Sous raspberry comme sous les autres Soc, c'est pas si difficile de gérer les GPIO.
Il existe tout un tas de librairies pour différents langages.

Ce qui m'a fait oublier le Pi, c'est justement le nombre de GPIO dispos et surtout la latence d'accès aux ports en passant par le kernel et que le temps soit variable.
J'ai besoin de basculer des broches à 2Mhz et ça c'est impossible du userland.

Avec un adruino, c'est plus simple, tu as directement accès. J'ai utilisé un temps des Atmega mais en programmation directe sans passer par la partie adruino, tout simplement parceque ça n'existait pas encore

[gremlinz]

Effectivement, c est un problème quand tu veux travailler en temps réel.
Je n'ai pas encore ces besoins la, c est pour ça que pour l arduino a été mon 1 er choix.
J ai voulu passer sur le Pi pour héberger le site web et la base de données sur le même controleur, mais je m aperçoit que c est pas une bonne idées, car sa rame beaucoup et je suis juste sur les gpio.

[NicoJ]

Salut,

Je partage vos avis sur le beaglebone. Je n'ai pas essayé le raspberry, mais la carte BeagleBone Black m'a convaincue de part ses caractéristiques et bien sur le coté open-source.

Sur l'architecture de la carte, à la base j'étais parti pour exploiter au maximum les capacités des ports P8 et P9 (principalement GPIO,I2C, SPI, DAC) en développant une carte d'extention (Cape). Dans la pratique j'ai l'impression qu'il y a déjà pas mal de ports "réservés pour le HDMI et les MMC. Du coup je ne sais pas si il y a vraiment tant de ports que cela disponibles (même en configurant les ports avec le device tree). Cede, peux-tu confirmer ?
Si oui, j'ai tendance à penser qu'une architecture basée sur 2 cartes serait plus adaptée : 1 carte "interface" avec un arduino ou un autre micro" qui gère les interfaces + 1 carte BBB (ou raspberry) qui fait tourner le logiciel et gère la communication avec la carte (par I2C, USB, ou autre). A voir, en fonction de votre retour.

Sur les aspects temps réel, latence, je suis un peu sceptique par rapport à vos remarques. L'objectif n'est pas de piloter une fusée, donc franchement je ne pense pas qu'un léger temps de retard sur la commande d'une résistance ou d'une vanne mette en cause la qualité de la bière, surtout vu l'inertie du processus. Bref, j'ai tendance à penser que le pilotage des E/S via le noyau devrait suffire.

Je note les connaissances appréciables de Cede sur l'électronique. Pour ma part, mes connaissances remontent à quelques années, mais c'est avec plaisir que je me replonge dans ces sujets. Par contre pas de soucis pour moi sur le dev.

Sur le pilotage des vannes ou des pompes, plutot que la conversion DAC, on peut aussi utiliser les fonction PWM des ports GPIO. En modulant la fréquence on créé une tension moyenne variable applicable sur le moteur d'une pompe par exemple.

[Cede]

Sur le beaglebone, effectivement la emmc et le hdmi ou lcd prennent pas mal de broches, mais il en reste quand même pas mal.

Comme tu dis, on ne pilote pas une fusée, donc le temps réel pour les IOs on s'en passe et on peut attaquer directement depuis la couche logicielle.
Et si on a besoin d'un grand nombre d'ES, on met des extensions en i2c.
Pour les sorties ca prends deux fils, et pour les entrées, je dirais 1 fil de plus par extension pour gérer les interruptions lors d'un changement d'état sur une entrée.

Pour le PWM qui commande les resistances, le mieux c'est toujours de faire du zero crossing, le relais SSR aime bien ça car il chauffe moins.
Le zero crossing étant de passer le relais en mode fermé lorsque le voltage passe à 0 volts.
Et ça on peut le faire les doigts dans le nez avec justement les PRUSS embarqués dans le processeur ARM.

En gros, on lance un programme sur un PRU qui va s'occuper de commuter les relais au bon moment en fonction de la valeur qu'on lui passe dans une zone mémoire réservée.

Pour les ADC, je préfère utiliser d'autres que ceux sur le board, car ils sont un peu bruités, et sont limités en 0-3,3V en entrée.
Il y en a des très bien en spi ou i2c.
Pour les DAC, je préfère aussi le faire avec des circuits spécialisés. On peut le faire avec un PWM et faire un circuit intégrateur, mais je trouve ça plus lourd.

Pour les capteurs de température, ds18B20, PT100, K peu importe, on arrivera à les lire

Dans ma tête, je pensais y aller par module qui se branche sur un bus.
Tu veux chaufffer électrique, branche un module electrique avec une sortie SSR, une entrée sonde de température
Tu veux mettre un rims ou un herms, branche un module recirculation avec les E/S adaptées.
Tu veux brancher une bouilloire, branche un module pour la bouilloire.

L'avantage que j'y vois, c'est que l'on n'est pas obligé de tout mettre sur le même circuit et qu'il est adaptable pour chaque configuration de pico.
Chaque module pourrait avoir une adresse ou quelquechose dans le genre, que le programme pourrait reconnaître, et qui lui dirait à quel type de module il a à faire.

C'est que que l'on peut aussi y aller avec un adruino tampon, mais je pense qu'on y perdrait en modularité, et ça couterais un adruino de plus et à programmer.
Je pense que c'est un peu doublon à moins de vouloir utiliser n'importe quel ordinateur derrière.

Avec le beaglebone, on peut facilement le connecter au réseau, ouvrir des ports pour avoir une IHM sur n'importe quel mobile ou ordinateur distant.

Voilà ma vision des choses pour le moment

[NicoJ]

Pour le PWM qui commande les resistances, le mieux c'est toujours de faire du zero crossing, le relais SSR aime bien ça car il chauffe moins.
Le zero crossing étant de passer le relais en mode fermé lorsque le voltage passe à 0 volts.
Et ça on peut le faire les doigts dans le nez avec justement les PRUSS embarqués dans le processeur ARM.

En fait je voyais plus le PWM pour la commande des pompes et en particulier la gestion de la vitesse de rotation en jouant sur le rapport cyclique du PWM. Pour la commande des résistances je ne sais pas si les SSR sont capables de commuter suffisamment rapidement. Sur la commande de température, je voyais une régulation calculée par logiciel avec une commande TOR (Tout Ou Rien) vers le SSR. Vu l'inertie du chauffage soit doit suffire pour réguler.

Sur l'aspect modulaire, as-tu pensé physiquement à quoi ça pourrait ressembler. On va déjà avoir une carte enfichée sur le BBB plus des modules autours. Ca risque de faire sapin de noël tout ça. A mon avis, il vaut mieux partir sur une unique carte qui dispose de l'ensemble des connecteurs. Pour cela, je pense qu'il faut recenser les besoins en étant le plus large possible, libre ensuite à chacun d'utiliser ou non les différents ports. Le soft devra être configuré pour savoir ou et comment accéder aux données des capteurs et piloter les différents actionneurs. Voici les besoins d'E/S que j'avais recensé :

• Sortie TOR 5V : utilisé pour commander un triac ou un relai, permettant ainsi la commande de résistances (en TOR), voyant, electrovannes, pompe.
• Entrée TOR 5V : géré par un mécanisme d'interruptions, ces entrées peuvent permettre de brancher des boutons, poussoirs, d'urgence etc.
• Sortie TOR 5V avec PWM : commande et régulation du débit des pompes, régulation des résistances (si PWM gérable par SSR)
• Entrée analogique : via ADC, ces entrées permettent récupérer les données provenant de capteurs analogiques (température, pH ?, liquide)...
• Sortie analogique : si besoin non couvert par PWM ...
• Bus I2C : sondes de températures
• Bus SPI
• Bus 1-wire : sonde de températures, ...
• Impulsion : entrée permettant de compter des impulsions (ex. capteur de débit)

Après il faut juste décider combien de de port il faut proposer.

Sur l'architecture Beaglebone+Cape ou Beaglebone+arduino , les deux me plaisent bien.
L'avantage d'une Cape c'est qu'effectivement on accède directement aux ports d'E/S et on fait tourner sur la même carte la partie logicielle y compris une IHM de type Web (à base d'AngularJS par exemple) accessible effectivement depuis n'importe quel appareil connecté au même réseau que le BBB. Ci-dessous un schéma correspondant à cette architecture.
[thumbnail=center]download/file.php?mode=view&id=3490&sid ... 0b26137609[/thumbnail]
Avec la solution Arduino, l'avantage c'est qu'on est pas lié au BBB. On peut en utiliser un, par exemple couplé avec un écran LCD (celui-ci par exemple ...) pour afficher l'IHM directement sur le tableau de commande, mais pas obligé. On pourrait le brancher à un RPi, un PC portable ou une UC fixe... la connexion "PC"<->Arduino passerait par USB je pense. La carte pourrait même tourner en autonome.

[NicoJ]

Voilà ce que ça pourrait donner en passant par un Arduino (ou une autre carte micro-controleur d'ailleurs).