Point projet, questions, et choix !

Dès le début de la phase de prototypage, le but était de m'assurer que j'allais être capable de contrôler des relais avec un Raspberry Pi.
Cela s'est avéré plutôt simple. La communauté a beaucoup travaillé, les libraires sont nombreuses et les cartes électroniques sont peu onéreuses.

Maintenant il temps de prendre un peu de recul et repenser le projet dans son ensemble : choix du Raspberry Pi pour le tir, montage des relais pour les multiplier, mise au point d'un système de vérification de la continuité des lignes, commande de l'ensemble.

Prenons les points un par un...

Choix du Raspberry Pi

La framboise est-elle un bon choix pour ce montage ?

Après ces quelques tests et jours de réflexion ... je ne crois pas.

Les raisons en sont les suivantes :

1. C'est un OS complet. Donc il peut planter (même si c'est Linux), il peut y avoir des comportements étranges (les relais qui se connectent au boot) et puis ... 
2. ... il est trop complet pour ce que je veux faire ! Lan, HDMI, USB, Stockage ... j'ai juste besoin d'une boîte qui commande des PINs !
3. Il n'a pas d'entrée analogique (voir plus loin sur le test des lignes, cela va poser problème). Certes on peut lui adjoindre une carte pour faire de l'analogique, mais on en revient au point 2, c'est compliqué tout ça !
4. Le temps de boot est long. Certes je pourrais le réduire avec une autre distribution, mais on voit bien que le projet n'est pas fait pour ça.

Bref, je remets en cause le choix du Raspberry comme moteur de tir, même si je ne l'exclue pas du projet, j'y reviens plus tard.

Multiplication des relais

Ah, les relais. J'ai fait mes tests avec 8 relais, c'est cool. Mais je vais en avoir besoin d'au moins 30 !

Donc de 30 GPIOs. 

C'est faisable, mais au prix d'une carte d'extension de GPIO en port I2C. Soit, mais il y a plus simple : je vais utiliser des multiplexeurs, donc faire des série de 74HC595.
De même, je vais avoir besoin pour mes tests de ligne d'entrées analogiques (peut-être pas autant c'est un point à creuser), donc il faut envisager des dé-multiplexeurs analogiques.

Bref, en tout cas le choix est fait parmi les divers solutions et je vais partir sur des multiplexeurs au moins en sortie.

Vérification de la continuité des lignes

C'est un point que je n'ai pas encore étudié en détail, mais le principe sera le suivant : faire passer un courant très faible dans chacune des sorties pour récupérer un voltage qui me permettra :

1. de tester si la ligne est continue (et donc si les inflammateurs sont bien branchés)
2. d'en déduire une résistance qui me permettra d'évaluer la qualité de la ligne. Si je détecte une résistance trop élevée cela peut signifier un inflammateur défaillant ou un branchement de mauvaise qualité (chose qu'on ne peut pas déterminer avec une simple LED qui indique ON/OFF)

Commande du système

Ma décision est prise, je vais transformer mon boitier en esclave et communiquer avec une "télécommande" par ondes radio. Cela me parait pas le plus simple, mais le plus logique par rapport aux conditions de tir qu'on rencontre sur un feu.

Donc le principe sera le suivant :

• la télécommande aura une batterie à elle, un écran de bonne qualité (probablement tactile) et une interface sans fil pour communiquer avec le boitier de tir
• le boitier aura quant à lui juste un écran minimaliste pour afficher deux ou trois informations, une interface sans fil, et tous les relais à commander ...

Les choix de conception

Tout cela me donne une vision plus précise de mon montage final, et des choix qui s'y rapportent.

Donc afin d'éviter les problèmes liés au Raspberry Pi cités plus haut, je vais m'orienter vers une conception du boitier de tir sur base d'Arduino (probablement un Uno). Cette machine me semble plus adaptée à une utilisation comme commande de tir.

Voici donc vers quoi je m'oriente pour le système de tir :

Le système de tir en version schématique

Quant à la "télécommande", elle aura les composants suivants :

"télécommande" en version schématique

Et là par contre le Raspberry PI prend tout son sens car j'aurais besoin d'un stockage, de pouvoir facilement charger des fichiers via une clé USB, peut-être un jour de jouer du son pour accompagner mon feu ?

Bref tout cela me semble cohérent et va donc me servir de ligne de vie pour la suite du projet.

Le prototypage, partie coeur

Pour commencer la phase de prototypage du cœur, je vais avoir besoin de mes premiers composants.
Rappel des objectifs :

1. Avoir un Raspberry Pi qui commande une carte relais avec ses GPIO
2. Ces relais ont une alimentation séparée en sortie (pour les tests ils vont alimenter des LEDs)

Voila pour une première étape. Dans un second temps nous nous intéresserons à la multiplication des GPIO pour pouvoir gérer assez de relais (minimum 30) en plus du reste ...

Pour réaliser cette première partie de prototypage, voici ma liste de courses réalisée chez Amazon :

• Un Raspberry Pi B+ avec sa carte SD pour l'installation de l'OS (ici)
• Un module relais 8 canaux (ici)
• Une alimentation pour Breadboard (ici)
• Et puis des câbles, des résistances, des leds et une breadboard un peu grande

Objectif : 

• 8 Leds sont alimentées par l'alimentation du Bread Board 
• Le Raspberry Pi contrôle l'allumage de ces Leds par un programme

Voici les tâches à réaliser :

Tâches du cœur du projet

Beaucoup d'informatique, donc, l'électronique restant très simple.

Cette phase est importante à deux titres. Tout d'abord elle va valider le contrôle d'un relais avec le RPI. C'est la base du projet, si je n'y arrive pas c'est fichu. Ensuite elle va poser les bases de ce qui deviendra avec le temps le programme de tir. Les tâches individuelles décrites ci-dessus seront autant de fonctions et d'objets qui par la suite serviront à créer une interface de tir complète.

La suite c'est donc l'installation du Raspberry PI.

Présentation du projet

Maintenant que nous avons fait l'introduction, passons à la phase "organisation du projet".

Je vous propose un petit schémas très synthétique de ce que va être le déroulé des opérations.

Schéma fonctionnel du projet PiFire

Ce n'est pas un document électronique, loin de là, mais un schémas logique.
Le projet se divise en briques.

Les carrés sont des éléments "package", je ne sais pas trop ce que j'y mettrai. Les losanges sont des éléments électroniques, deux alimentations séparées sont des cylindres, les borniers sont représentés par un anneau.

Puis les couleurs :

• Vert : le cœur du projet, sans lesquels le projet est un échec
• Jaune : les éléments optionnels mais qui apporteraient une plus-value
• Gris : l'affichage / contrôle distant. Je ne sais pas quoi faire encore pour cette partie, je la laisse en suspens en attendant.

Voici l'explication du cœur :

• Un contrôleur (pour l'instant un Raspberry Pi) est au centre
• Il est alimenté par une batterie (que l'on va appeler BPI)
• Il contrôle via une carte d'extension GPIO plus ou moins 30 relais
• Ces relais sont reliés à une batterie de tir (BTIR)
• L'ensemble est relié aux borniers qui eux-même sont reliés aux artifices via des inflammateurs.

Voila pour le cœur. C'est très simple et direct (même si ça va représenter du boulot).

Ensuite les options :

• Un convertisseur analogique / numérique est relié au contrôleur et aux borniers. Il servira à mesurer la résistance des lignes, ceci afin d'effectuer un test de continuité. Cette fonction est alimentée par la batterie BPI
• Le contrôleur de batterie, je ne sais pas quelle forme il prendra. Mais il devrait être relié à BPI et BTIR afin de mesurer la charge de ces deux éléments. Rien de plus stressant sur un tir que de s'interroger sur la bonne tenue des batteries !
• Enfin l'interface vers l'humain. Est-ce que ce sera un écran intégré au boitier ? une prise de contrôle à distance ? aujourd'hui je ne peux pas répondre, j'avance en marchant ...

En tout cas, voici le gros parti pris de conception : deux alimentation séparées et aucun moyen de communication entre les deux. C'est le B.A BA d'une table de tir. En aucun cas un bug logiciel ou un dysfonctionnement d'un composant seul ne devra pouvoir déclencher un tir. Naturellement le système de test de continuité va de facto devoir relier les deux, mais il y aura des coupe-circuit et des résistances pour contrôler l'envoi d'électricité dans les bornes et limiter l'ampérage reçu. Nous y reviendrons quand le moment sera venu.

Comme je ne sais pas trop où je vais, là où je rencontrerai des problèmes, je vais commencer par une phase de prototypage. C'est l'objet du prochain billet.

Le projet, définition, inconnues et partis pris

Un projet cela commence avec un cahier des charges.

Système Explo de chez StarLight

Ce projet n'échappe pas à cette règle et voici celui que je me suis fixé :

1. la table de tir devra gérer au minimum 30 lignes 
2. elle devra pouvoir gérer le tir de ces lignes en autonomie en lisant un fichier d'ordres de tir 
3. elle devra permettre de tester la continuité des lignes 
4. le circuit d'alimentation du tir devra être autonome par rapport au circuit d'alimentation du "reste" (test et circuit gérant les ordres) 
5. pouvoir gérer des ordres de tir rapprochés (2ms environ) 
6. l'ensemble devra être : autonome électriquement, posséder des interrupteurs coupe circuit et enfin être disposé dans un boîtier facilement transportable, solide et résistant à des retombées d'artifice

Ceci est la base. Si ce cahier des charges est rempli, le projet sera un succès. Maintenant, il y a les options...

1. pouvoir gérer le feu à distance ...
2. ... si possible en hf
3. gérer numériquement les tests de continuité des lignes 
4. gérer plusieurs modes de tir (pas à pas, manuel, lignes de secours) en plus d'automatique 
5. tester numériquement l'état des batteries 
6. pouvoir gérer plusieurs boîtiers 
7. pouvoir envoyer plusieurs lignes simultanément

Avec les options c'est déjà plus sérieux.

Avant d'aborder la méthode "projet" que je vais utiliser, j'ai fait un choix fondamental pour l'ensemble : choix discutable mais justifié : le système qui commandera l'ensemble sera un Raspberry Pi.
Il y a plein d'autres façons d'y arriver, sûrement des meilleures ou plus efficaces. Mais, il y a plusieurs raisons à cela :

1. vu que le projet est mal défini un système central pouvant faire "plein de choses" (affichage, wifi, hf, usb ...) est un avantage : je ne serai jamais dans un "cul de sac" lié aux choix technologiques
2. je suis à l'aise sous Linux et Python
3. les ressources sur le net sont nombreuses pour ce qui est de programmer un Pi

Par contre je vois déjà des défauts au système :

1. même si c'est un tout petit ordinateur, un Raspberry consomme une quantité non négligeable d'électricité. Pour la partie "mobilité" de l'ensemble cela sera à prendre en compte
2. par rapport à un autre type de "carte" (un Arduino par exemple), le Pi n'a pas en natif de convertisseurs analogiques / numérique. Cela s'ajoute, mais j'en aurais sûrement besoin
3. c'est un linux complet. Donc pour les actions que je vais mener c'est sûrement très lourd, les temps de démarrage seront à ausculter
4. enfin en termes de sécurité, un Raspberry c'est compliqué. Va savoir ce qui va se passer au boot, si il y a un problème sur l'OS ? il ne faut pas que cela puisse déclencher un tir ! Donc il faudra ausculter l'ensemble et mettre des sécurités suffisantes

Mais cela est à relativiser : si je dois changer mon fusil d'épaule je le ferai, le Pi sera de toute façon bien pratique pour la partie maquettage de l'ensemble.

Les bases ayant été posées, je vais pouvoir commencer à parler de la méthodologie du projet.