Raspberry Pi : fabriquons des trucs!

[sky99]

En fait... Je pensais à un truc vachement plus simple : avoir un petit tag sur un bracelet (montre, bijou...), et des lecteurs NFC à la place (ou à côté) des interrupteurs : le RPi récupère le tag NFC du bracelet, identifie de quelle pièce cela provient, et effectue les actions correspondantes.

Dans ce cas la, c'est tout à fait possible, et même à priori plutôt simple.

C'est précisement l'objectif du RFID, d'ailleurs, de différencier des objets ainsi.

Pour cela, il faudrait pouvoir gérer les différents tags et surtout les différentes provenances... Et ensuite avoir assez d'E/S pour pouvoir gérer toute la maison

Mais je pense que ça pourrait être tip top

En effet, ce serait un grand projet, et ça ferait une super maison intelligente :)

Pour les entrées sorties, ce n'est pas réellement un problème. j'ai dans les tuyeaux un tutoriel sur une puce permettant d'ajouter 16 entrées-sorties, et on peut utiliser jusqu'à 7 de ces puces sur un raspberry pi, soit 112 E-S. la puce vaut 3$, donc ce n'est pas ruineux non plus.

gérer différents tags, c'est très simple, c'est la base du RFID/NFC. Sur chaque tag, tu écris un identifiant unique, donc lorsqu'il est lu par le lecteur RFID, tu sais précisement quel tag est présent. Pour ce qui est de la position, si tu te places toujours dans le contexte "je pose mon bidule sur la surface prévue pour" (ça peut être un bol, une plaque, ou simplement une zone sur un meuble -tu as environ 10cm de portée avec un lecteur RFID de base-), ça ne pose AUCUN problème.

Si je prends un Pi, et que je lui ajoute trois lecteurs RFID, il suffit de regarder sur quel lecteur tu as détecté le tag RFID. j'avais compris dans ton précédent post, que tu souhaitais localiser un objet dans une pièce à partir de son tag RFID, d'ou ma digression sur les antennes...

par contre, tu parles de multiplier les antennes dans la maison. Ce sera nécéssaire certes, mais le problème sera de connecter les antennes au pi qui gère tout ça. Il faudrait faire passer des câbles ou utiliser un protocole de transmission sans fil.

Le plus simple, à mon avis,c'est de partir sur l'idée "une piece, un raspberry et un -ou éventuellement plusieurs- lecteurs".

Le lecteur RFID coute environ 30$. Un raspberry c'est environ 35$. si tu rajoutes une SD, une alim electrique, et une clé wifi, tu as un "pack" pour environ une centaine d'euros, pour une pièce. ça te permet déja de détecter qui est dans la pièce si il pose son tag dans la zone de l'antenne.

Maintenant pour le reste des applications, il faudra d'autres composants : par exemple un relais pour allumer telle ou telle lumière, un système pour pouvoir commander la chaine hifi, une façon de communiquer avec le chauffage/clim...

Pour la chaine hifi, une solution peut être d'avoir une sortie son sur le raspberry connectée à la chaine hifi, et le pi balance le signal sonore de ton choix.

Pour le chauffage/clim, j'ai un projet en cours sur le controle d'une clim, en déchiffrant le protocole de la télécomande IR. le récepteur IR permettant de lire la télécomande coute environ 2$, et une LED IR pour emettre le signal souhaité (allumer la clim, baisser la température, etc) coute moins d'un euro.

Au passage, si tu as un pi dans chaque pièce, tu as un ordinateur avec un CPU ARM. Tu peux donc faire de la reconnaissance vocale, et plutôt que de placer un tag RFID, tu pourrais aussi bien avoir un mot cléf "ambiance 4" dans telle ou telle salle, et ça t"éviterait d'avoir à mettre des capteurs RFID partout.

[JeanChristophe]

Juste un grand bravo, et merci pour l'initiative qui malgré mon manque de temps me donne envie de m'y mettre.

[nemesis93_75]

Quand je lis ton dernier post, sky, j'ai le kiki tout dur

[Yaug]

Salut à toi Sky99.

Je me suis inscrit sur le site rien que pour pouvoir te féliciter.

M'étant lancé dans l'aventure raspberry pi depuis décembre, je suis ravi de voir tes tutos qui sont d'une grande qualité.

Car si la communauté est vaste, il est souvent difficile de trouver des bons tutos (quand on utilise un capteur un poil différent par exemple ).

Donc surtout continue !

De mon coté, coté projet, je suis parti sur un serveur de domotique maison piloté par la voix couplé avec une station météo faite main.

Comme idées de projets, les robots me tente ENORMEMENT, mais pour le moment, je ne me suis pas encore lancé.

J'avais aussi envie de reproduire l'expérience Pi in the Sky de Dave Akerman.

Mais bon.. la domotique me permet déjà dans un premier temps d'apprendre à me servir du raspberry et de mettre à jour mes connaissances bien rouillées en électronique.

Bref, félicitation, et merci !

[ngcubeur]

En fait... Je pensais à un truc vachement plus simple : avoir un petit tag sur un bracelet (montre, bijou...), et des lecteurs NFC à la place (ou à côté) des interrupteurs : le RPi récupère le tag NFC du bracelet, identifie de quelle pièce cela provient, et effectue les actions correspondantes.

Dans ce cas la, c'est tout à fait possible, et même à priori plutôt simple.

C'est précisement l'objectif du RFID, d'ailleurs, de différencier des objets ainsi.

Oui ça je sais

Pour cela, il faudrait pouvoir gérer les différents tags et surtout les différentes provenances... Et ensuite avoir assez d'E/S pour pouvoir gérer toute la maison

Mais je pense que ça pourrait être tip top

En effet, ce serait un grand projet, et ça ferait une super maison intelligente :)

Pour les entrées sorties, ce n'est pas réellement un problème. j'ai dans les tuyeaux un tutoriel sur une puce permettant d'ajouter 16 entrées-sorties, et on peut utiliser jusqu'à 7 de ces puces sur un raspberry pi, soit 112 E-S. la puce vaut 3$, donc ce n'est pas ruineux non plus.

gérer différents tags, c'est très simple, c'est la base du RFID/NFC. Sur chaque tag, tu écris un identifiant unique, donc lorsqu'il est lu par le lecteur RFID, tu sais précisement quel tag est présent. Pour ce qui est de la position, si tu te places toujours dans le contexte "je pose mon bidule sur la surface prévue pour" (ça peut être un bol, une plaque, ou simplement une zone sur un meuble -tu as environ 10cm de portée avec un lecteur RFID de base-), ça ne pose AUCUN problème.

Si je prends un Pi, et que je lui ajoute trois lecteurs RFID, il suffit de regarder sur quel lecteur tu as détecté le tag RFID. j'avais compris dans ton précédent post, que tu souhaitais localiser un objet dans une pièce à partir de son tag RFID, d'ou ma digression sur les antennes...

Pour les E/S c'est une bonne nouvelle !

Pour gérer les tags, oui je savais aussi

Par contre, au prix du lecteur... Ca revient vite cher je trouve. Y'a pas moyen d'ajouter un petit calculateur entre chaque antenne et le lecteur pour qu'il puisse avoir un signal unique venant de chaque antenne ?

par contre, tu parles de multiplier les antennes dans la maison. Ce sera nécéssaire certes, mais le problème sera de connecter les antennes au pi qui gère tout ça. Il faudrait faire passer des câbles ou utiliser un protocole de transmission sans fil.

Le plus simple, à mon avis,c'est de partir sur l'idée "une piece, un raspberry et un -ou éventuellement plusieurs- lecteurs".

Le lecteur RFID coute environ 30$. Un raspberry c'est environ 35$. si tu rajoutes une SD, une alim electrique, et une clé wifi, tu as un "pack" pour environ une centaine d'euros, pour une pièce. ça te permet déja de détecter qui est dans la pièce si il pose son tag dans la zone de l'antenne.

Pour les câbles etc... Si je me lance là-dedans, ça sera quand je serai propriétaire, donc tout pourra passer dans les murs Et ça permettra de pas mettre 100€/pièce pour du "gadget"... Et ça permettra de mieux centraliser

Maintenant pour le reste des applications, il faudra d'autres composants : par exemple un relais pour allumer telle ou telle lumière, un système pour pouvoir commander la chaine hifi, une façon de communiquer avec le chauffage/clim...

Pour la chaine hifi, une solution peut être d'avoir une sortie son sur le raspberry connectée à la chaine hifi, et le pi balance le signal sonore de ton choix.

Pour le chauffage/clim, j'ai un projet en cours sur le controle d'une clim, en déchiffrant le protocole de la télécomande IR. le récepteur IR permettant de lire la télécomande coute environ 2$, et une LED IR pour emettre le signal souhaité (allumer la clim, baisser la température, etc) coute moins d'un euro.

Oui, je sais qu'il faudra autre chose... Dans l'idéal, pour le son, je voyais la sortie son du RPi sur un ampli numérique (les DIY), avec un système de relais pour orienter la sortie vers les bons HP. Le tout serait compact, peu consommateur... Intégrable partout

Au passage, si tu as un pi dans chaque pièce, tu as un ordinateur avec un CPU ARM. Tu peux donc faire de la reconnaissance vocale, et plutôt que de placer un tag RFID, tu pourrais aussi bien avoir un mot cléf "ambiance 4" dans telle ou telle salle, et ça t"éviterait d'avoir à mettre des capteurs RFID partout.

Oui, ça serait le top d'avoir un RPi par pièce... Et un "central", pour pouvoir avoir une gestion d'ensemble + une gestion personnalisée de chaque pièce (jouer 4 musiques différentes dans 4 pièces par exemple). Mais ça fait potentiellement augmenter les coûts par 7-8

En tout cas, tu es très intéressant

[HyD_z]

Bonjour,

Premier post sur le forum PCi. J'utilise aussi le raspberry, étant électronicien de formation je galère plus avec la partie info, j'ai l'impression d'utiliser que 1% des possibilités de la bête, j'en ai un usage qui se rapproche plus de celui d'un arduino. Je poste pour vous conseiller une distribution, elle est basée sur Raspbian, c'est Occidentalis vous pouvez la trouver sur Adafruit. Le plus c'est qu'on peut l'utiliser directement en ssh dès la première utilisation avec génération de mot de passe, donc pas besoin d'écran. En ce moment j'ai comme projet de faire communiquer le raspberry avec des arduino et des PIC's en sans fil avec un petit composant pas cher le NRF24L01+. je vous tiendrai au courant.

[sinosoft]

Bravo pour ce tuto, je sens que je vais bientot craquer et en acheter un, avec le pack motorisé

[sky99]

...

...

Merci beaucoup, ça me motive pour continuer :)

Salut à toi Sky99.

Je me suis inscrit sur le site rien que pour pouvoir te féliciter.

M'étant lancé dans l'aventure raspberry pi depuis décembre, je suis ravi de voir tes tutos qui sont d'une grande qualité.

Car si la communauté est vaste, il est souvent difficile de trouver des bons tutos (quand on utilise un capteur un poil différent par exemple ).

Donc surtout continue !

De mon coté, coté projet, je suis parti sur un serveur de domotique maison piloté par la voix couplé avec une station météo faite main.

Comme idées de projets, les robots me tente ENORMEMENT, mais pour le moment, je ne me suis pas encore lancé.

J'avais aussi envie de reproduire l'expérience Pi in the Sky de Dave Akerman.

Mais bon.. la domotique me permet déjà dans un premier temps d'apprendre à me servir du raspberry et de mettre à jour mes connaissances bien rouillées en électronique.

Bref, félicitation, et merci !

Merci également :)

Pour le serveur domotique, n'hésite pas à nous faire des retours, idem pour la station météo "faite main" :)

Ce sont deux sujets qui intéressent beaucoup de monde. J'ai également quelques idées de capteurs environnementaux, dont je posterai plus tard les concepts, et peut être la réalisation également. Je dispose d'une station météo, et l'un de mes objectifs initiaux etait de m'en servir pour calibrer des capteurs que j'aurais fabriqué moi même :)

Pour les robots, si ça te fait envie, je te dirai lance toi, parce que j'ai attendu 5 ans avant d'essayer, et quand je m'y suis mis, je me suis rendu compte que ce n'est ni très cher, ni si complexe que cela.

pour moins de 100€ et une demi journée, on peut avoir un robot qui évite des obstacles.

Et si la base est un raspberry pi, on peut toujours ajouter une webcam, et tenter des choses plus ambitieuses sans grand surcoût...

Au passage, les robots sont pas mal pour commencer également :)

Par contre, au prix du lecteur... Ca revient vite cher je trouve. Y'a pas moyen d'ajouter un petit calculateur entre chaque antenne et le lecteur pour qu'il puisse avoir un signal unique venant de chaque antenne ?

Je pense qu'il y a bien moyen. mais à ce niveau là, il faudra faire un peu plus d'électronique de bas niveau. En pratique, fabriquer une antenne RFID, ça consiste juste à enrouler du fil. Je suppose qu'en désolidarisant l'antenne, il doit être possible de mettre par exemple 4 antennes, et de lire l'une après l'autre en utilisant le même circuit. Cependant il faut être prêt à mettre les mains dans le cambouis :)

Pour les câbles etc... Si je me lance là-dedans, ça sera quand je serai propriétaire, donc tout pourra passer dans les murs Et ça permettra de pas mettre 100€/pièce pour du "gadget"... Et ça permettra de mieux centraliser

Je comprends. Toutefois, le truc, c'est que faire passer du câble dans les murs, c'est pas anodin comme coût. ça peut couter moins cher justement de multiplier les raspberry. Les goulottes pour cables, pour faire passer du fil le long d'un mur, sans creuser de tranchée, ça coute déjà 2-3€ la goulotte de 2m. Selon la distance/disposition, il t'en faudra plusieurs pour chaque pièce. De plus, il faudra faire passer du câble (du RJ11 devrait faire l'affaire, ou pourquoi pas du RJ45?), câble qui a un coût. Si tu veux creuser des tranchées dans les murs, c'est super cher; par contre si tu prévois de construire, la le surcoût d'un câblage supplémentaire est sans doute négligeable.

Pour ce qui est du câblage, il faut aussi penser à l'affaiblissement du signal. Il faudrait tester quelle longueur de fil peut véhiculer un signal analogique si on parle de connecter une antenne déportée, ou numérique si on parle de connecter le lecteur RFID à un PI déporté.

Donc ce n'est pas forcément plus cher de multiplier les PI, avec du wifi...

Il faut s'attendre à ce que ça coute un peu cher, de toutes façons. Le mieux à mon avis, c'est de commencer par petits bouts, avec un pi, et un lecteur RFID, et à partir de la, de tester des ajouts, des longueurs de câbles, etc :)

Oui, ça serait le top d'avoir un RPi par pièce... Et un "central", pour pouvoir avoir une gestion d'ensemble + une gestion personnalisée de chaque pièce (jouer 4 musiques différentes dans 4 pièces par exemple). Mais ça fait potentiellement augmenter les coûts par 7-8

Encore une fois, je pense que pour ton projet il y aura certains coûts anexes (câblage, installations électriques systèmes de commande des appareils) qui risquent de coûter plus cher.

De plus tu peux aussi faire ça progressivement, en ajoutant les pièces prioritaires en premier :)Je pense que c'est un projet ambitieux, qui devrait prendre un peu de temps, et également un peu de sous pour toute la maison :)

Maintenant si tu trouves des solutions pour baisser les coûts, n'hésite pas à les partager, un tel projet intéressera sans doute beaucoup de monde!

En tout cas, tu es très intéressant

Encore merci :)

Mais le plus chouette, c'est de voir que pas mal de monde se met à tripatouiller des raspbery, et du coup on pourra former une petite communauté, et échanger là dessus...

Pour moi tout ça, c'est comme un bon repas, c'est plus sympa à partager à plusieurs :)

[Yaug]

Merci également :)

Pour le serveur domotique, n'hésite pas à nous faire des retours, idem pour la station météo "faite main" :)

Ce sont deux sujets qui intéressent beaucoup de monde. J'ai également quelques idées de capteurs environnementaux, dont je posterai plus tard les concepts, et peut être la réalisation également. Je dispose d'une station météo, et l'un de mes objectifs initiaux etait de m'en servir pour calibrer des capteurs que j'aurais fabriqué moi même :)

J'ai des tutos en cours sur mon blog, mais il me manque du matos pour finir :'(

Notamment des cables mâles / mâles pour ma breadboard. J'ai passé une commande chez adafruit y'a un mois, elle n'est pas encore arrivée... Du coup j'ai racheté des cables et des résistances via ebay. Au final, une fois que j'ai une référence, je regarde sur ebay, car il y a souvent des trucs pas chers et en bonnes quantités. (et c'est pratique vu que je n'ai pas trouvé encore de magasin d'éléctronique dans mon coin).

Je te préviendrais quand j'aurais mis mes premiers tutos, surtout que j'ai 3 sondes différentes à tester.

Pour les robots, si ça te fait envie, je te dirai lance toi, parce que j'ai attendu 5 ans avant d'essayer, et quand je m'y suis mis, je me suis rendu compte que ce n'est ni très cher, ni si complexe que cela.

pour moins de 100€ et une demi journée, on peut avoir un robot qui évite des obstacles.

Et si la base est un raspberry pi, on peut toujours ajouter une webcam, et tenter des choses plus ambitieuses sans grand surcoût...

Au passage, les robots sont pas mal pour commencer également :)

Pour le moment c'est surtout que je préfère éviter de m'éparpiller de trop. Je me fais déjà la domotique / station météo, et ensuite j'élargirais.

Sinon, je me connais, ça va partir en live. D'autant plus que si je me lance dans un projet de rover, je voudrais créer un truc bien costaud, donc je préfère avoir déjà des connaissances pour me faire ça.

Sinon, une petite question au passage.

Pour éviter d'avoir des fils de partout (et à 5v, on a vite fait de perdre pas mal), j'étais parti pas mal dans l'idée de me créer un raspberrypi master, qui communique via du 433Mhz avec des dépendances du genre arduino light + capteur (temperature, pression, effet de hall) ou arduino + relai.

Qu'en penses - tu ? c'est faisable ?

Merci :)

[sky99]

J'ai des tutos en cours sur mon blog, mais il me manque du matos pour finir :'(

Notamment des cables mâles / mâles pour ma breadboard. J'ai passé une commande chez adafruit y'a un mois, elle n'est pas encore arrivée... Du coup j'ai racheté des cables et des résistances via ebay. Au final, une fois que j'ai une référence, je regarde sur ebay, car il y a souvent des trucs pas chers et en bonnes quantités. (et c'est pratique vu que je n'ai pas trouvé encore de magasin d'éléctronique dans mon coin).

Je te préviendrais quand j'aurais mis mes premiers tutos, surtout que j'ai 3 sondes différentes à tester.

Pour Adafruit, c'est bizarre, ils sont rapides d'habitude... peut être un problème de transporteur? moi je prends UPS express Saver, ils prennent quelques jours pour partir des USA à paris, puis de paris à la Guadeloupe :)

Pour le moment c'est surtout que je préfère éviter de m'éparpiller de trop. Je me fais déjà la domotique / station météo, et ensuite j'élargirais.

Sinon, je me connais, ça va partir en live. D'autant plus que si je me lance dans un projet de rover, je voudrais créer un truc bien costaud, donc je préfère avoir déjà des connaissances pour me faire ça.

Je comprends parfaitement, j'ai 15 projets en cours en parallèle, et en vrai, aucun n'avance significativement ces temps ci ^^ d'un autre coté les tutos m'ont pris du temps. Apres le point intéressant c'est que les composants peuvent servir à l'un comme à l'autre :) Mais pour faire un gros robot, c'est plus tout à fait les mêmes composants, il est vrai. Les miens sont légers, et d'intérieur ^^

Sinon, une petite question au passage.

Pour éviter d'avoir des fils de partout (et à 5v, on a vite fait de perdre pas mal), j'étais parti pas mal dans l'idée de me créer un raspberrypi master, qui communique via du 433Mhz avec des dépendances du genre arduino light + capteur (temperature, pression, effet de hall) ou arduino + relai.

Qu'en penses - tu ? c'est faisable ?

Merci :)

ça me semble tout à fait faisable, et même pas trop compliqué. Tu peux passer en 433Mhz via des cartes dédiées, dans ce cas, il faudra un encodeur/décodeur pour éviter les interférances, ou alors carrément prendre du zigbee, ou même un shield wifi pour les arduino...

Dans tous les cas, le arduino à un/des ports série, et le Raspberry aussi. Beaucoup de composants sans fil que j'ai vus permettent en gros de faire communiquer deux éléments distants comme si on était en connection série directe (donc Tx et Rx).

Je ne l'ai pas fait, mais le principe est assez standard, et on trouve pas mal d'équipements pas chers. Par exemple des transmetteurs 433Mhz a 4$ (mais sans encodeur en revanche, donc adapté à une seule paire communicante, et pas de bruit trop important sur la fréquence)

Et selon le budget on doit même pouvoir trouver des trucs tout faits, à brancher et à utiliser avec un code fourni :)

[Vanilys]

Hello tout le monde !

Déjà, un immense bravo et merci à Sky99 pour ces tutos très très bien écrits et pédagogiques.

C'est important pour moi d'y aller étape par étape, car hélas je n'ai aucune formation en électronique (par contre je suis développeur, donc ce côté là me fait moins peur).

Et là, le Raspberry Pi me fait de l'oeil depuis belle lurette. Cependant, je n'avais pas trop envie d'installer des solutions toutes faites - même si elles sont très bien, bien sûr - comme un RaspBMC etc ...

Non, mon envie première, c'est d'aller plus loin en utilisant des composants électroniques pour tenter de créer des robots, ou de me mettre à la domotique en général.

Mais j'avais un peu peur, j'avoue : je ne savais vraiment pas comment m'y prendre, même si je n'ai pas encore beaucoup cherché il est vrai, car d'entrée tout cela me paraissait terriblement confus et difficile pour un novice, car ce qu'on peut trouver sur le net est très souvent accessible à des personnes confirmées, ou qui ne sont pas complètement débutantes.

Tout ça pour dire que tu m'as redonné confiance et reboosté mon envie de m'y mettre !

J'ai lu très attentivement tous les tutos que tu as déjà postés sur ce thread, ainsi que quelques tutos un peu plus détaillées sur ton blog.

Quand c'est bien expliqué comme cela, ça n'a pas l'air si compliqué pour commencer à jouer avec, et créer des choses basiques, brique après brique :)

Donc merci, 1000x merci, je pense fortement maintenant passer commande pour un RPI, puis pour quelques composants électroniques ... et après, "y'a plus qu'à" :-)

Continue à nous proposer des articles, vraiment tu feras le bonheur de beaucoup de personnes, y compris moi.

A bientôt !

[LowG33k]

Bonsoir Sky99,

un peu comme Yaug, je me suis inscrit juste pour te félicité des tutos que tu as écrits.

C'est vrai qu'à la base je l'avais prix pour faire de la domotique, mais mes souvenirs d’électronique sont un peu rouillé ^^ . Grâce à tes tutos sa devrais revenir. J'ai vu également ton blog, il a l'air intéressant.

Alors continue comme sa, c'est génial

[Yaug]

ça me semble tout à fait faisable, et même pas trop compliqué. Tu peux passer en 433Mhz via des cartes dédiées, dans ce cas, il faudra un encodeur/décodeur pour éviter les interférances, ou alors carrément prendre du zigbee, ou même un shield wifi pour les arduino...

Dans tous les cas, le arduino à un/des ports série, et le Raspberry aussi. Beaucoup de composants sans fil que j'ai vus permettent en gros de faire communiquer deux éléments distants comme si on était en connection série directe (donc Tx et Rx).

Je ne l'ai pas fait, mais le principe est assez standard, et on trouve pas mal d'équipements pas chers. Par exemple des transmetteurs 433Mhz a 4$ (mais sans encodeur en revanche, donc adapté à une seule paire communicante, et pas de bruit trop important sur la fréquence)

Et selon le budget on doit même pouvoir trouver des trucs tout faits, à brancher et à utiliser avec un code fourni :)

C'était en gros la logique vers laquelle je voulais tendre

j'ai déjà un émetteur récepteur 433 Mhz (non testé encore), que je voulais tester avec le support du blog d'idleman (gros tutos aussi pour la domotique, très bien fait !)

Donc j'aurais mis sur le master : émetteur / récepteur, et sur chaque slave 1 émetteur et 1 récepteur, le tout en commençant avec un premier, puis en ajoutant un second etc... Quitte à utiliser un code radio fait maison pour sécuriser au maximum les échanges. C'est un peu l'idée que j'avais, mais sans trop savoir si c'est réellement faisable et surtout si c'est réellement stable à long terme.

Merci pour tes retours en tout cas !

[sky99]

Merci à tous pour les encouragements, ça me motive complètement :)

Mon PC vient de planter, donc je viens de perdre le début du précédent tuto, mais du coup je suis motivé pour le refaire :)

Cette fois ci, je posterai des versions non finies, comme ça je n'aurai pas tout à recommencer !

A bientôt pour un autre tutoriel : comment ajouter jusqu'à 128GPIO au Raspberry Pi!

[sky99]

Ajouter des GPIO au Raspberry pi en utilisant une puce MCP23017 ou MCP23008

Si le nombre de GPIO disponibles sur le Raspberry Pi ne vous convient pas, pas d'inquiétude, il est possible d'en rajouter. La puce MCP23017 permet

d'ajouter 16 GPIO , et la puce MCP23008 permet d'en rajouter 8. Dans les deux cas, ces puces se connectent au Raspberry Pi sur des GPIO "spéciaux",

dédiés au protocole I²C. Ce qui est formidable, c'est que même ainsi, vos broches I²C restent disponibles, grâce à un système d'adressage.

Il est ainsi possible de connecter d'autres puces sur les broches I²C en chaînant celles ci avec notre MCP23017 ou MCP23008. Pour cela,

on utilisera un système d'adressage que nous verrons plus tard.

Ces deux puces coûtent 2$ pour le MCP23008, et 3$ pour le MCP23017. A moins d'avoir des contraintes d'espace (le MCP23008 se présente sous

forme d'une puce à 16 broches, en 2*8, alors que la MCP23017 est une puce à 28 broches, en 2*14) sur votre montage, autant prendre des MCP23017. :)

Pour être complet, voici les spécifications des puces :

• Datasheet du MCP23017;
  
• Datasheet du MCP23008.
  

A noter que la lecture des spécifications n'est pas du tout nécessaire pour l'utilisation de cette puce, je mettrai tout le nécessaire dans ce tutoriel. Toutefois, il

peut être utile d'avoir ces fichiers sous la main, par exemple pour les schémas de la disposition des broches de la puce, ou pour y dénicher plus d'informations...

Le câblage des deux puces ne sera pas identique, mais il est assez facile de passer de l'un à l'autre. Pour la suite, je montrerai le câblage des MCP23017

dans un premier temps, et des MCP23008 dans une mise à jour ultérieure. En revanche, le code et tout le reste seront similaires.

Un point intéressant à noter est que ces puces ont de nombreuses fonctionnalités, comme des résistances "pull-up", qui nous simplifieront la vie pour lire des boutons

poussoir, par exemple! En outre, chaque GPIO de la puce peut fournir 25mA, contre 16mA pour les GPIO du Raspberry, ce qui ne suffit pas pour alimenter

pleinement une DEL par exemple (20mA pour les DEL standard), sans compter que le Raspberry ne peut fournir plus de 50mA sur le total des GPIO!

Ici, nous pourrons donc alimenter pleinement 16 LED sans problème. Enfin, un dernier point intéressant, c'est que ces puces sont solides. Je ne vous garantis

pas qu'elles sont protégées contre les mauvaises manipulations, je n'ai pas fouillé dans les spécifications pour vérifier. Mais en pratique, sur les miennes,

j'ai fait plein de bêtises, en ayant câblé des choses à l'envers, mis le +3.3V d'alimentation sur une mauvaise broche, au point d'avoir eu deux puces brûlantes.

Eh bien une fois le bon câblage fait, les puces se sont mises à fonctionner comme si de rien n'était...

Utiliser ces puces peut s'avérer intéressant même si vous n'avez pas besoin de plus de GPIO, ne serait-ce que pour protéger le Raspberry pi, car les GPIO "natifs"

sont eux très fragiles, et n'ont aucune protection. On peut facilement griller des GPIO ou même un Pi entier en faisant de mauvais branchements...

Dans tous les cas, en cas de mauvaise manipulation au pire, vous grillez une puce qui coûte 3$, et qu'il suffit de changer pour continuer à utiliser votre système...

Le câblage

Passons maintenant à la pratique. Dans un premier temps, je tiens à signaler que je n'ai pas fait ce tutoriel en partant du néant, j'ai utilisé le tutoriel d'Adafruit sur

l'utilisation du MCP23017 pour câbler ma première puce. Maintenant j'écris ce tutoriel en essayant d'ajouter ce qui m'a manqué dans celui d'Adafruit.

Voici le schéma du câblage :

Le MCP23017 est alimenté par du 3.3V, qui se connecte à la 6ème broche en partant du bas, à gauche. La masse du

Raspberry sera connecté à la 5ème broche en partant du bas, à gauche.

Le GPIO SDA (second en en partant du haut, colonne de gauche sur le Pi) se connecte à la seconde broche en partant du bas,

à gauche, du MCP23017. Enfin,le GPIO SCL (troisième broche en partant du haut, colonne de gauche sur le Pi) se connecte à

la 3ème broche en partant du bas, à gauche sur le MCP23017.

Sur la colonne de droite du MCP23017, vous constaterez que la 4eme broche en partant du bas est connectée au +3.3V. Cette broche

est la broche NON-Reset. Elle est à 3.3V, soit un 1 logique, ce qui veut dire que reset est à 0. Si vous souhaitez faire un reset du

MCP23017, vous pouvez toujours connecter cette broche à un GPIO, mais pensez à définir la valeur à 1 pour le fonctionnement normal.

Les trois broches du bas, dans la colonne de droite du MCP23017 servent à coder l'adresse de la puce, sur 3 bits, donc 8 adresses possibles.

Si la broche donnée est sur le +3.3V, alors le bit concerné est à 1. Si la broche est sur le 0V, alors le bit concerné est à 0. Ici, l'adresse

est donc 000. Le premier bit de l'adresse est celui tout en bas à droite, le second est le deuxième en partant du bas, à droite, et le troisième

bit d'adresse est le troisième en partant du bas, à droite.

Si vous branchez une autre puce I2C, il faudra qu'elle aie une autre adresse. Si ce n'est pas possible pour l'autre puce (adresse soudée par exemple)

il est toujours possible de changer celle du MCP23017 ou du MCP23008. Si vous utilisez plusieurs MCP23017 ou MCP23008, il faudra s'assurer

d'avoir des adresses différentes pour chaque puce.

Maintenant, vous disposez d'une puce utilisable, et les 8 broches du haut, à gauche comme à droite, sont les GPIO.

On peut voir sur ces schémas l'ordre des GPIO, et ou se trouve le premier :

A gauche le MCP23017, à droite le MCP23008.

Sur le MCP23017, la broche 0 est donc la 7ème en partant du bas. Les numéros de GPIO vont croissant jusqu'au haut de la puce, (en haut à droite c'est la broche 7), et décroissent sur les 8 premières broches de la colonne de gauche (tout en haut à gauche, c'est le GPIO 8, et la 8eme broche en partant du haut sur la colonne de gauche est le GPIO 15).

Configuration de Raspbian

Configurons maintenant Raspbian pour gérer le protocole I²C.

Si vous utilisez Occidentalis, la distrib est déjà prête de base, et vous n'avez rien à faire de plus. En revanche, avec Raspbian, il faudra faire quelques petites opérations, plus détaillées sur le tutoriel d'Adafruit sur la configuration I²C de Raspbian.

Voyons rapidement ce qu'il faut faire :

d'abord, nous allons éditer le fichier /etc/modules pour y ajouter les modules noyeau nécéssaires à l'utilisation du protocole I²C.

Pour cela, il suffira d'éditer en root ce fichier :

sudo nano /etc/modules

Ajoutez à la fin du fichier les deux lignes suivantes :

i2c-bcm2708i2c-dev

Pour que les modifications prennent effet, il faudra redemarrer, et les pilotes seront chargés au démarrage.

Une autre solution est d'utiliser modprobe :

sudo modprobe i2c-bcm2708sudo modprobe i2c-dev

Cela aura pour effet de charger immédiatement les modules, sans avoir à redémarrer. Si jamais toutefois cela ne fonctionne pas, essayez de redémarrer:

sudo reboot now

Si jamais vous avez des problèmes, essayez de mettre à jour Raspbian avant de ré-essayer:

sudo apt-get upgradesudo apt-get update

Sur ma version de raspbian, je n'ai pas eu de problèmes, mais le tuto d'Adafruit précise que vous pouvez avoir un fichier /etc/modprobe.d/raspi_blacklist.conf.

Si c'est le cas, éditez ce fichier :

sudo nano /etc/modprobe.d/raspi_blacklist.conf

et cherchez les lignes suivantes :

blacklist spi-bcm2708blacklist i2c-bcm2708

Modifiez les lignes en ajoutant # devant :

#blacklist spi-bcm2708#blacklist i2c-bcm2708

Dans tous les cas, avec nano, pour sauvegarder, tapez CTRL+x, et ensuite o ou y pour confirmer la sauvegarde.

Nous allons maintenant installer des outils pour tester/vérifier les périphériques I2C:

sudo apt-get install python-smbussudo apt-get install i2c-tools

à ce moment, vous pouvez utiliser i2cdetect pour voir si la puce est détectée. Si vous avez les anciens Raspberry (versions 256Mo, principalement), il faudra taper :

sudo i2cdetect -y 0

Avec les versions récentes (révision 2 et +, qui ont 512Mo de ram , pour un modèle B) il faudra taper :

sudo i2cdetect -y 1

La raison est que le bus I²C utilisé sur les GPIO est devenu le bus 1 au lieu du bus 0 depuis les rev2. Il doit y avoir un autre sous système du Pi qui utilise le bus 0 quelque part sur la carte.

Si tout à fonctionné , vous verrez quelquechose de ce genre :

Sauf que si vous avez câblé avec les 3 bits d'adresse à 0, vous verrez 20 dans la matrice, et pas 40 ou 70.

Si vous ne voyez rien, c'est qu'il y a un problème de câblage, vérifiez les broches d'adresse, la broche "non-reset" qui doit être connectée au 3.3V et non à la masse, le +3.3v et la masse de la puce, et enfin les prises SDA et SCL, qu'on inverse parfois (ça m'est arrivé plusieurs fois)

Le code

Passons maintenant à une application pratique, avec du code. Nous allons faire clignoter une LED en utilisant un GPIO du MCP23017. Pour cela, nous n'allons pas implémenter le protocole I2C, mais utiliser le code d'Adafruit.

Rendez vous sur le github de Adafruit, pour télécharger deux fichiers :

• Adafruit_I2C.py
  
• Adafruit_MCP230xx.py
  

Le premier est la classe qui permet d'utiliser le protocole I2C. Le second est une classe permettant d'utiliser le MCP23017 pour "faire des trucs".

En pratique, le code d'exemple donné permet de lire la valeur d'un bouton, et également de faire clignoter une DEL.

Il y a quelques petites modifications à apporter pour adapter le code à vos besoins, je vais les détailler ci dessous :

#!/usr/bin/pythonfrom Adafruit_I2C import Adafruit_I2Cimport smbusimport timeMCP23017_IODIRA = 0x00MCP23017_IODIRB = 0x01MCP23017_GPIOA  = 0x12MCP23017_GPIOB  = 0x13MCP23017_GPPUA  = 0x0CMCP23017_GPPUB  = 0x0DMCP23017_OLATA  = 0x14MCP23017_OLATB  = 0x15MCP23008_GPIOA  = 0x09MCP23008_GPPUA  = 0x06MCP23008_OLATA  = 0x0Aclass Adafruit_MCP230XX(object):OUTPUT = 0INPUT = 1def __init__(self, address, num_gpios, busnum = 0):	assert num_gpios >= 0 and num_gpios <= 16, "Number of GPIOs must be between 0 and 16"	self.i2c = Adafruit_I2C(address=address, bus=smbus.SMBus(busnum))		self.address = address	self.num_gpios = num_gpios	# set defaults	if num_gpios <= 8:		self.i2c.write8(MCP23017_IODIRA, 0xFF)  # all inputs on port A		self.direction = self.i2c.readU8(MCP23017_IODIRA)		self.i2c.write8(MCP23008_GPPUA, 0x00)	elif num_gpios > 8 and num_gpios <= 16:		self.i2c.write8(MCP23017_IODIRA, 0xFF)  # all inputs on port A		self.i2c.write8(MCP23017_IODIRB, 0xFF)  # all inputs on port B		self.direction = self.i2c.readU8(MCP23017_IODIRA)		self.direction |= self.i2c.readU8(MCP23017_IODIRB) << 8		self.i2c.write8(MCP23017_GPPUA, 0x00)		self.i2c.write8(MCP23017_GPPUB, 0x00)def _changebit(self, bitmap, bit, value):	assert value == 1 or value == 0, "Value is %s must be 1 or 0" % value	if value == 0:		return bitmap & ~(1 << bit)	elif value == 1:		return bitmap | (1 << bit)def _readandchangepin(self, port, pin, value, currvalue = None):	assert pin >= 0 and pin < self.num_gpios, "Pin number %s is invalid, only 0-%s are valid" % (pin, self.num_gpios)	#assert self.direction & (1 << pin) == 0, "Pin %s not set to output" % pin	if not currvalue:		 currvalue = self.i2c.readU8(port)	newvalue = self._changebit(currvalue, pin, value)	self.i2c.write8(port, newvalue)	return newvaluedef pullup(self, pin, value):	if self.num_gpios <= 8:		return self._readandchangepin(MCP23008_GPPUA, pin, value)	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>:			return self._readandchangepin(MCP23017_GPPUA, pin, value)		else:			return self._readandchangepin(MCP23017_GPPUB, pin-8, value)# Set pin to either input or output modedef config(self, pin, mode):	  	if self.num_gpios <= 8:		self.direction = self._readandchangepin(MCP23017_IODIRA, pin, mode)	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>:			self.direction = self._readandchangepin(MCP23017_IODIRA, pin, mode)		else:			self.direction = self._readandchangepin(MCP23017_IODIRB, pin-8, mode)	return self.directiondef output(self, pin, value):	# assert self.direction & (1 << pin) == 0, "Pin %s not set to output" % pin	if self.num_gpios <= 8:		self.outputvalue = self._readandchangepin(MCP23008_GPIOA, pin, value, self.i2c.readU8(MCP23008_OLATA))	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>:			self.outputvalue = self._readandchangepin(MCP23017_GPIOA, pin, value, self.i2c.readU8(MCP23017_OLATA))		else:			self.outputvalue = self._readandchangepin(MCP23017_GPIOB, pin-8, value, self.i2c.readU8(MCP23017_OLATB))	return self.outputvalue	self.outputvalue = self._readandchangepin(MCP23017_IODIRA, pin, value, self.outputvalue)	return self.outputvaluedef input(self, pin):	assert pin >= 0 and pin < self.num_gpios, "Pin number %s is invalid, only 0-%s are valid" % (pin, self.num_gpios)	assert self.direction & (1 << pin) != 0, "Pin %s not set to input" % pin	if self.num_gpios <= 8:		value = self.i2c.readU8(MCP23008_GPIOA)	elif self.num_gpios > 8 and self.num_gpios <= 16:		value = self.i2c.readU16(MCP23017_GPIOA)		temp = value >> 8		value <<= 8		value |= temp	return value & (1 << pin)def readU8(self): result = self.i2c.readU8(MCP23008_OLATA) return(result)def readS8(self): result = self.i2c.readU8(MCP23008_OLATA) if (result > 127): result -= 256 return resultdef readU16(self): assert self.num_gpios >= 16, "16bits required" lo = self.i2c.readU8(MCP23017_OLATA) hi = self.i2c.readU8(MCP23017_OLATB) return((hi << 8)/>/>/>/> | lo)def readS16(self): assert self.num_gpios >= 16, "16bits required" lo = self.i2c.readU8(MCP23017_OLATA) hi = self.i2c.readU8(MCP23017_OLATB) if (hi > 127): hi -= 256 return((hi << 8)/>/>/>/> | lo)def write8(self, value): self.i2c.write8(MCP23008_OLATA, value)def write16(self, value): assert self.num_gpios >= 16, "16bits required" self.i2c.write8(MCP23017_OLATA, value & 0xFF) self.i2c.write8(MCP23017_OLATB, (value >> 8)/>/>/>/> & 0xFF)	  # RPi.GPIO compatible interface for MCP23017 and MCP23008class MCP230XX_GPIO(object):OUT = 0IN = 1BCM = 0BOARD = 0def __init__(self, busnum, address, num_gpios):	self.chip = Adafruit_MCP230XX(busnum, address, num_gpios)def setmode(self, mode):	# do nothing	passdef setup(self, pin, mode):	self.chip.config(pin, mode)def input(self, pin):	return self.chip.input(pin)def output(self, pin, value):	self.chip.output(pin, value)def pullup(self, pin, value):	self.chip.pullup(pin, value)if __name__ == '__main__':#definissez la variable adress comme étant ce que vous avez réglé avec les broches adresse, selon la valeur retournée par i2cdetect !!#définissez num_gpios à 16 pour le MCP23017, et à 8 pour le MCP23008 !!#définissez busnum à 0 pour les anciens raspberry pi, et busnum à 1 pour les nouveaux !!mcp = Adafruit_MCP230XX(address = 0x20, num_gpios = 16, busnum = 1)# ***************************************************# Set num_gpios to 8 for MCP23008 or 16 for MCP23017!# If you have a new Pi you may also need to add:# busnum = 1# ***************************************************# définition des broches 0, 1 et 2 en sortie (on peut définir les broches 0 à 15 de cette façon)mcp.config(0, mcp.OUTPUT)mcp.config(1, mcp.OUTPUT)mcp.config(2, mcp.OUTPUT)# On définit la broche 3 en entrée avec la résistance pull-up intégrée d'activéemcp.pullup(3, 1)# on affiche le résultat de la lecture. mcp.input(3) lit la broche 3.print "%d: %x" % (3, mcp.input(3) >> 3)while (True):  mcp.output(0, 1)  # broche 0 à high  time.sleep(0.5)  mcp.output(0, 0)  # broche 0 à low  time.sleep(0.5)

Le passage important à vérifier est :

mcp = Adafruit_MCP230XX(address = 0x20, num_gpios = 16, busnum = 1)

busnum doit être à 1 pour les Raspberry de 512mo et toutes les versions 2 et +, sinon, pour les anciens pi (256mo pour un modèle B), la valeur de busnum doit être à 0.

l'adresse doit correspondre à ce que i2cdetect retourne, avec 0x devant.

Enfin, si vous avez un MCP23008, il faudra mettre num_gpios=8 au lieu de num_gpios=16.

Pour le reste, j'ai remplacé les commentaires du main par des commentaires en français, ça devrait être assez explicite.

Il ne reste plus qu'à lancer :

sudo python Adafruit_MCP230xx.py

Voici le schéma du montage correspondant :

Ps: désolé si j'ai pris pas mal de temps pour ce tuto (et il reste quelques petites améliorations à faire), mais pendant son écriture,

mon watercooling a coulé (heureusement, c'est du liquide de refroidissement auto, pas trop conducteur à priori), et mon pc à planté

plusieurs fois, j'ai donc du recommencer certains passages. Si ça parait un peu décousu, c'est sans doute parce que ça a été repris

plusieurs fois. Je mettrai à jour, mais plus tard...

[alyex]

Bonjour,

Voilà plus d'une dizaine d'année que j'aimerai me lancer dans la robotique sans jamais oser même après avoir acheté plusieurs livres pour débutant et fait des centaines de recherches sur le net.

Depuis quelques semaines la tentation est grande mais à chaque fois quelque chose m'en empêche; la peur de me planter en beauté car pas assez guidé...

Hier encore j'étais en train de lire des articles sur les Raspberry Pi et Arduino, et voilà qu'aujourd'hui je tombe sur vos tuto simples, avec des liens, des prix, et en Français !

Et là je me sens d'un coup plus en confiance, grâce à vous j'ai l'impression d'avoir tout ce qu'il faut pour me lancer.

Alors je vous remercie pour cette excellente initiative et pour tout le travail effectué !

Reste plus qu'à me jeter à l'eau ;o)

[jeanyv78]

Bien le bonjour et félicitations pour ce post Sky.

En tant que "viel" électronicien (Bac F2 de 1981) je suis resté aux bons vieux composants avec lesquels je suis encore capable de faire des choses sympas... Mais cette découverte du Rasberry PI va me faciliter la tâche...

J'ai automatisé mon portail d'entrée de "ma propriété" et comme une buse, j'ai flingué le bus de données (court jus sur la ligne). Le portail manoeuvre toujours mais si je connecte mes cellules de détection infrarouge, que dalle... Une bagnole entre les 2 vantaux et je suis bbon pour de la tôlerie...

Ceci est la première des chose que je dois résoudre. J'ai pas envie de faire marcher la garantie de la motorisation, ça me saôule rien que de penser à tout démonter...

2 ème problème à résoudre quand le portail manoeuvre, je n'ai pas d'éclairage. J'ai une allée de 66 mètres dans laquelle j'ai des réverbères, je veux connecter la boiboite sur la lumière, qui ne s'allumera qu'à la nuit tombée.

3 ème problème, je vais mettre au milieu de mon allée une BIR (barrière IR) qui quand un véhicule sortira, déclenchera l'ouverture automatique du portail.

Les solutions à ces problèmes seront apportées par la petite platine rasberry PI.

Voici ma contribution.

@ +.

Jean-Yves.

[achabance]

Bravo pour ton tuto sky99. Ca donne vraiment envie de resortir la boîte d'électronique...

L'année dernière je me suis amusé avec un PicAxe, mais le Raspberry et infiniment plus puissant et facile à mettre en oeuvre.

[sky99]

Hello :) En effet, je pense qu'il y a de quoi s'amuser :)

Pour les PicAxe, je pense qu'il ne faut pas opposer les deux, mais qu'au contraire la combinaison des de divers microcontroleurs avec le pi

peut rendre le tout encore plus efficace... Le pi n'a qu'une seule sortie PWM, et par rapport à un microcontroleur, il y a un OS classique

qui tourne. Donc on a pas du temps réel sur l'exécution des commandes, et pas de garantie sur la précision des timings... Du coup

pour contrôler certains dispositifs, utiliser le pi pour envoyer des commandes à un microcontrôleur, qui lui ensuite se charge de faire

certaines tâches me semble un must dans certains cas! De plus, si on imagine un microcontrôleur qui s'occupe de faire des timings

PWM précis, d'ajuster ceci ou cela en fonction de divers paramètres, cela fait qu'on a une tâche qui tourne de façon indépendante

tant que le contrôleur central qu'est le pi n'ordonne pas un autre changement... Et pendant ce temps le pi peut faire des tâches plus complexes

(analyse d'images , de son, etc)...

L'analogie que je ferai serait celle du cerveau. Quand vous codez un programme, vous utilisez votre cerveau pour atteindre des objectifs précis,

et il y a des chances que si il fallait faire autre chose en même temps, ce soit l'un ou l'autre, ou alors les deux, mais pas forcément bien faits.

Cependant, la respiration, les battements du coeur et d'autres fonctions (ne serait-ce que l'équilibre, la coordination, la focalisation des yeux) qui

sont plus ou moins complexes sont exécutées en arrière plan par des portions dédiées du cerveau... A tout moment on peut prendre la main

sur certaines (fermer les yeux, arrêter de respirer), mais pas sur d'autres. Dans notre analogie le pi serait le cerveau conscient, qui fait

les tâches de haut niveau, et le microcontrôleur serait les parties du cerveau qui gèrent les tâches de bas niveau...

Justement pour un robot, ça peut être une architecture formidable :

On aurait un robot à microcontrôleur, qui a un algorithme d'évitement d'obstacle de bas niveau, CAD que quand il détecte un obstacle, il s'arrête, quand il détecte

un vide il s'arrête, et qu'il gère les organes du robot automatiquement (par exemple le balayage avant par une tourelle infrarouge). Par dessus, on aurait

un Raspberry qui lui donnerait des ordres de haut niveau (avance, tourne, ralentis à telle vitesse, tourne en avançant), mais sans savoir réellement

comment gérer les roues, sans connaitre les détails de la PWM derrière chaque roue, ou sans se demander comment savoir à quelle distance sont les objets

devant : il demande au microcontrôleur, qui lui fait en permanence le balayage et retourne la valeur filtrée de la distance des objets devant, un peu sur le coté,

etc...

Du coup, on peut facilement imaginer que notre Raspberry est occupé plutôt à analyser le flux d'une webcam, et/ou à faire tourner des algorithmes d'IA comme

un réseau de neurones pour comprendre son environnement, ou encore des algorithmes évolutionnaires pour adapter son comportement à l'environnement,

ou à la réalisation d'une tâche demandée...

Pour ma part, ça fait partie des objectifs que j'aimerais atteindre à terme, J'ai utilisé un Arduino, et découvert qu'on peut se contenter de la puce seule, et fabriquer son arduino

pour une bouchée de pain. Donc j’espère bien interfacer un raspberry à la puce du Arduino (Atmel Atmega328 dans mon cas) pour combiner les forces des deux et éliminer

les faiblesses de chaque :)

[sky99]

Utilisation de DEL RGB : un peu de couleur!

Les DEL RGB sont des DEL contenant en fait 3 DEL : une rouge ®, une verte (G), et une bleue (B). Le format est celui d'une DEL classique, sauf qu'il y a 4 pattes.

On peut allumer l'une des 3 couleurs, pour avoir du rouge, du vert ou du bleu, mais on peut également allumer des combinaisons de deux couleurs (Rouge + Vert = jaune, par ex),

ou même les trois couleurs en même temps pour faire du blanc. Enfin, si vous contrôlez le niveau de chaque led avec de la PWM, vous pouvez faire varier l'intensité de chaque

couleur. Imaginons que vous puissiez faire varier en pwm chaque patte de la led de 0 à 255 : en pratique, vous obtenez des nuances de couleurs comme dans un logiciel

d'image, avec 256 nuances de chaque couleur de base, et une combinaison de 256*256*256 = environ 16 millions de couleurs! Aujourd'hui, nous ne nous occuperons

pas de PWM, car le PI ne dispose que d'une broche PWM. On se contentera d'allumer chaque couleur, et de combiner les couleurs de façon simple.

En premier lieu, vous trouverez divers types de LED RGB.

Il y en aura des "clear", dont le boitier epoxy est transparant. La luminosité de celles ci est maximale devant la LED, mais plus faible sur le coté. Elles sont souvent éblouissantes vues de face.

Il y aura aussi les "diffused", dont le boitier est translucide, vous ne verrez pas l'intérieur clairement. Celles ci diffusent davantage la lumière, et sont mieux visibles dans tous les sens.

L'autre point important, c'est la distinction entre les common cathode et les common anode.

Les premières, les common cathode ont une patte pour le + de chaque couleur, et une patte commune pour le - de toutes les couleurs. Pour les common anode, c'est le contraire, la patte

commune est l'anode, donc on a une patte comune pour le + (l'anode), et une patte pour le - de chaque couleur. Cela signifie que le câblage ne sera pas le même, et la logique

de contrôle sera également différente. Si vous avez le choix, les common cathode sont plus simples, bien que les common anode ne soient pas particulièrement complexes.

Dans les deux cas, voici la disposition des pattes de la LED :

En pratique, voici ce que peut donner une LED RGB:

[media]

[/media]

Chez moi la vidéo ne s’intègre pas à la page, donc je mets le lien :

Les DEL RGB Common cathode (à cathode commune)

Ici, c'est donc le - qui est commun.

Le câblage est donc très simple : vous branchez la cathode (patte 2), qui est la plus grande patte, sur le -, vous reliez les pattes 1 et 4 à des GPIO, et la patte 3 à une résistance qui va dans un GPIO. Il suffit alors de définir le GPIO à high pour allumer une couleur, et à low pour l'eteindre.

Idéalement, la résistance en série pour la patte 3 (rouge) devrait faire 65 Ohms.

Voici un schéma de câblage pour Arduino, avant de passer à la version Raspberry Pi :)

Le schéma de câblage sera donc le suivant, en utilisant un MCP23017 pour profiter de ses GPIO :

-très bientôt-

Quand au code, il est relativement simple :

#!/usr/bin/pythonfrom Adafruit_I2C import Adafruit_I2Cimport smbusimport timeMCP23017_IODIRA = 0x00MCP23017_IODIRB = 0x01MCP23017_GPIOA  = 0x12MCP23017_GPIOB  = 0x13MCP23017_GPPUA  = 0x0CMCP23017_GPPUB  = 0x0DMCP23017_OLATA  = 0x14MCP23017_OLATB  = 0x15MCP23008_GPIOA  = 0x09MCP23008_GPPUA  = 0x06MCP23008_OLATA  = 0x0Aclass Adafruit_MCP230XX(object):OUTPUT = 0INPUT = 1def __init__(self, address, num_gpios, busnum = 0):	assert num_gpios >= 0 and num_gpios <= 16, "Number of GPIOs must be between 0 and 16"	self.i2c = Adafruit_I2C(address=address, bus=smbus.SMBus(busnum))		self.address = address	self.num_gpios = num_gpios	# set defaults	if num_gpios <= 8:		self.i2c.write8(MCP23017_IODIRA, 0xFF)  # all inputs on port A		self.direction = self.i2c.readU8(MCP23017_IODIRA)		self.i2c.write8(MCP23008_GPPUA, 0x00)	elif num_gpios > 8 and num_gpios <= 16:		self.i2c.write8(MCP23017_IODIRA, 0xFF)  # all inputs on port A		self.i2c.write8(MCP23017_IODIRB, 0xFF)  # all inputs on port B		self.direction = self.i2c.readU8(MCP23017_IODIRA)		self.direction |= self.i2c.readU8(MCP23017_IODIRB) << 8		self.i2c.write8(MCP23017_GPPUA, 0x00)		self.i2c.write8(MCP23017_GPPUB, 0x00)def _changebit(self, bitmap, bit, value):	assert value == 1 or value == 0, "Value is %s must be 1 or 0" % value	if value == 0:		return bitmap & ~(1 << bit)	elif value == 1:		return bitmap | (1 << bit)def _readandchangepin(self, port, pin, value, currvalue = None):	assert pin >= 0 and pin < self.num_gpios, "Pin number %s is invalid, only 0-%s are valid" % (pin, self.num_gpios)	#assert self.direction & (1 << pin) == 0, "Pin %s not set to output" % pin	if not currvalue:		 currvalue = self.i2c.readU8(port)	newvalue = self._changebit(currvalue, pin, value)	self.i2c.write8(port, newvalue)	return newvaluedef pullup(self, pin, value):	if self.num_gpios <= 8:		return self._readandchangepin(MCP23008_GPPUA, pin, value)	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>/>/>:			return self._readandchangepin(MCP23017_GPPUA, pin, value)		else:			return self._readandchangepin(MCP23017_GPPUB, pin-8, value)# Set pin to either input or output modedef config(self, pin, mode):	  	if self.num_gpios <= 8:		self.direction = self._readandchangepin(MCP23017_IODIRA, pin, mode)	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>/>/>:			self.direction = self._readandchangepin(MCP23017_IODIRA, pin, mode)		else:			self.direction = self._readandchangepin(MCP23017_IODIRB, pin-8, mode)	return self.directiondef output(self, pin, value):	# assert self.direction & (1 << pin) == 0, "Pin %s not set to output" % pin	if self.num_gpios <= 8:		self.outputvalue = self._readandchangepin(MCP23008_GPIOA, pin, value, self.i2c.readU8(MCP23008_OLATA))	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>/>/>:			self.outputvalue = self._readandchangepin(MCP23017_GPIOA, pin, value, self.i2c.readU8(MCP23017_OLATA))		else:			self.outputvalue = self._readandchangepin(MCP23017_GPIOB, pin-8, value, self.i2c.readU8(MCP23017_OLATB))	return self.outputvalue	self.outputvalue = self._readandchangepin(MCP23017_IODIRA, pin, value, self.outputvalue)	return self.outputvaluedef input(self, pin):	assert pin >= 0 and pin < self.num_gpios, "Pin number %s is invalid, only 0-%s are valid" % (pin, self.num_gpios)	assert self.direction & (1 << pin) != 0, "Pin %s not set to input" % pin	if self.num_gpios <= 8:		value = self.i2c.readU8(MCP23008_GPIOA)	elif self.num_gpios > 8 and self.num_gpios <= 16:		value = self.i2c.readU16(MCP23017_GPIOA)		temp = value >> 8		value <<= 8		value |= temp	return value & (1 << pin)def readU8(self): result = self.i2c.readU8(MCP23008_OLATA) return(result)def readS8(self): result = self.i2c.readU8(MCP23008_OLATA) if (result > 127): result -= 256 return resultdef readU16(self): assert self.num_gpios >= 16, "16bits required" lo = self.i2c.readU8(MCP23017_OLATA) hi = self.i2c.readU8(MCP23017_OLATB) return((hi << 8)/>/>/>/>/>/> | lo)def readS16(self): assert self.num_gpios >= 16, "16bits required" lo = self.i2c.readU8(MCP23017_OLATA) hi = self.i2c.readU8(MCP23017_OLATB) if (hi > 127): hi -= 256 return((hi << 8)/>/>/>/>/>/> | lo)def write8(self, value): self.i2c.write8(MCP23008_OLATA, value)def write16(self, value): assert self.num_gpios >= 16, "16bits required" self.i2c.write8(MCP23017_OLATA, value & 0xFF) self.i2c.write8(MCP23017_OLATB, (value >> 8)/>/>/>/>/>/> & 0xFF)	  # RPi.GPIO compatible interface for MCP23017 and MCP23008class MCP230XX_GPIO(object):OUT = 0IN = 1BCM = 0BOARD = 0def __init__(self, busnum, address, num_gpios):	self.chip = Adafruit_MCP230XX(busnum, address, num_gpios)def setmode(self, mode):	# do nothing	passdef setup(self, pin, mode):	self.chip.config(pin, mode)def input(self, pin):	return self.chip.input(pin)def output(self, pin, value):	self.chip.output(pin, value)def pullup(self, pin, value):	self.chip.pullup(pin, value)def lightRGBLed(rState,gState,bState,rPin,gPin,bPin):mcp.output(rPin, rState)mcp.output(gPin, gState)mcp.output(bPin, bState)def lightRGBLed2(color,rPin,gPin,bPin):if color == 'red':	lightRGBLed(1,0,0,rPin,gPin,bPin)elif color == 'green':	lightRGBLed(0,1,0,rPin,gPin,bPin)elif color == 'blue':	lightRGBLed(0,0,1,rPin,gPin,bPin)elif color == 'yellow':	lightRGBLed(1,1,0,rPin,gPin,bPin)elif color == 'magenta':	lightRGBLed(1,0,1,rPin,gPin,bPin)elif color == 'cyan':	lightRGBLed(0,1,1,rPin,gPin,bPin)elif color == 'white':	lightRGBLed(1,1,1,rPin,gPin,bPin)if __name__ == '__main__':mcp = Adafruit_MCP230XX(busnum = 1, address = 0x20, num_gpios = 16)r1=10g1=8b1=9mcp.config(b1, mcp.OUTPUT)mcp.config(g1, mcp.OUTPUT)mcp.config(r1, mcp.OUTPUT)while (True):  print "off"  lightRGBLed(0,0,0,r1,g1,b1)  time.sleep(1)  print "rouge"  lightRGBLed(1,0,0,r1,g1,b1)  time.sleep(1)  print "vert"    lightRGBLed(0,1,0,r1,g1,b1)  time.sleep(1)  print "bleu"  lightRGBLed(0,0,1,r1,g1,b1)  time.sleep(1)  print "vert+bleu"    lightRGBLed(0,1,1,r1,g1,b1)  time.sleep(1)  print "rouge+bleu"    lightRGBLed(1,0,1,r1,g1,b1)  time.sleep(1)  print "rouge+vert"    lightRGBLed(1,1,0,r1,g1,b1)  time.sleep(1)  print "rouge+vert+bleu"    lightRGBLed(1,1,1,r1,g1,b1)  time.sleep(1)

La suite tout de suite

Les DEL RGB Common Anode (à anode commune)

Ici, c'est donc le + qui est commun.

Le câblage sera donc différent : on connecte toujours chaque couleur à un GPIO, et toujours une résistance en série pour le rouge.

En revanche, la broche commune, l'anode, sera branchée sur le +3.3v.

La différence c'est qu'ici, pour allumer une couleur, il faudra mettre le GPIO correspondant à 0.

Si le GPIO est à 0, il est à 0V. Donc, le courant entre par l'anode a +3.3V, cela fait une tension de 3.3V au bornes de la DEL.

En revanche, si on met le GPIO à 1, il sera à 3.3V. Ce qui fait qu'a chaque borne de la DEL, on a du +3.3V. du coup la tension

aux bornes de celle ci est de 0V, et elle reste éteinte!

Le code est donc inversé, puisqu'il faut passer le GPIO à 0 pour allumer, et à 1 pour éteindre:

#!/usr/bin/pythonfrom Adafruit_I2C import Adafruit_I2Cimport smbusimport timeMCP23017_IODIRA = 0x00MCP23017_IODIRB = 0x01MCP23017_GPIOA  = 0x12MCP23017_GPIOB  = 0x13MCP23017_GPPUA  = 0x0CMCP23017_GPPUB  = 0x0DMCP23017_OLATA  = 0x14MCP23017_OLATB  = 0x15MCP23008_GPIOA  = 0x09MCP23008_GPPUA  = 0x06MCP23008_OLATA  = 0x0Aclass Adafruit_MCP230XX(object):OUTPUT = 0INPUT = 1def __init__(self, address, num_gpios, busnum = 0):	assert num_gpios >= 0 and num_gpios <= 16, "Number of GPIOs must be between 0 and 16"	self.i2c = Adafruit_I2C(address=address, bus=smbus.SMBus(busnum))		self.address = address	self.num_gpios = num_gpios	# set defaults	if num_gpios <= 8:		self.i2c.write8(MCP23017_IODIRA, 0xFF)  # all inputs on port A		self.direction = self.i2c.readU8(MCP23017_IODIRA)		self.i2c.write8(MCP23008_GPPUA, 0x00)	elif num_gpios > 8 and num_gpios <= 16:		self.i2c.write8(MCP23017_IODIRA, 0xFF)  # all inputs on port A		self.i2c.write8(MCP23017_IODIRB, 0xFF)  # all inputs on port B		self.direction = self.i2c.readU8(MCP23017_IODIRA)		self.direction |= self.i2c.readU8(MCP23017_IODIRB) << 8		self.i2c.write8(MCP23017_GPPUA, 0x00)		self.i2c.write8(MCP23017_GPPUB, 0x00)def _changebit(self, bitmap, bit, value):	assert value == 1 or value == 0, "Value is %s must be 1 or 0" % value	if value == 0:		return bitmap & ~(1 << bit)	elif value == 1:		return bitmap | (1 << bit)def _readandchangepin(self, port, pin, value, currvalue = None):	assert pin >= 0 and pin < self.num_gpios, "Pin number %s is invalid, only 0-%s are valid" % (pin, self.num_gpios)	#assert self.direction & (1 << pin) == 0, "Pin %s not set to output" % pin	if not currvalue:		 currvalue = self.i2c.readU8(port)	newvalue = self._changebit(currvalue, pin, value)	self.i2c.write8(port, newvalue)	return newvaluedef pullup(self, pin, value):	if self.num_gpios <= 8:		return self._readandchangepin(MCP23008_GPPUA, pin, value)	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>/>/>:			return self._readandchangepin(MCP23017_GPPUA, pin, value)		else:			return self._readandchangepin(MCP23017_GPPUB, pin-8, value)# Set pin to either input or output modedef config(self, pin, mode):	  	if self.num_gpios <= 8:		self.direction = self._readandchangepin(MCP23017_IODIRA, pin, mode)	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>/>/>:			self.direction = self._readandchangepin(MCP23017_IODIRA, pin, mode)		else:			self.direction = self._readandchangepin(MCP23017_IODIRB, pin-8, mode)	return self.directiondef output(self, pin, value):	# assert self.direction & (1 << pin) == 0, "Pin %s not set to output" % pin	if self.num_gpios <= 8:		self.outputvalue = self._readandchangepin(MCP23008_GPIOA, pin, value, self.i2c.readU8(MCP23008_OLATA))	if self.num_gpios <= 16:		if (pin < 8)/>/>/>/>/>/>:			self.outputvalue = self._readandchangepin(MCP23017_GPIOA, pin, value, self.i2c.readU8(MCP23017_OLATA))		else:			self.outputvalue = self._readandchangepin(MCP23017_GPIOB, pin-8, value, self.i2c.readU8(MCP23017_OLATB))	return self.outputvalue	self.outputvalue = self._readandchangepin(MCP23017_IODIRA, pin, value, self.outputvalue)	return self.outputvaluedef input(self, pin):	assert pin >= 0 and pin < self.num_gpios, "Pin number %s is invalid, only 0-%s are valid" % (pin, self.num_gpios)	assert self.direction & (1 << pin) != 0, "Pin %s not set to input" % pin	if self.num_gpios <= 8:		value = self.i2c.readU8(MCP23008_GPIOA)	elif self.num_gpios > 8 and self.num_gpios <= 16:		value = self.i2c.readU16(MCP23017_GPIOA)		temp = value >> 8		value <<= 8		value |= temp	return value & (1 << pin)def readU8(self): result = self.i2c.readU8(MCP23008_OLATA) return(result)def readS8(self): result = self.i2c.readU8(MCP23008_OLATA) if (result > 127): result -= 256 return resultdef readU16(self): assert self.num_gpios >= 16, "16bits required" lo = self.i2c.readU8(MCP23017_OLATA) hi = self.i2c.readU8(MCP23017_OLATB) return((hi << 8)/>/>/>/>/>/> | lo)def readS16(self): assert self.num_gpios >= 16, "16bits required" lo = self.i2c.readU8(MCP23017_OLATA) hi = self.i2c.readU8(MCP23017_OLATB) if (hi > 127): hi -= 256 return((hi << 8)/>/>/>/>/>/> | lo)def write8(self, value): self.i2c.write8(MCP23008_OLATA, value)def write16(self, value): assert self.num_gpios >= 16, "16bits required" self.i2c.write8(MCP23017_OLATA, value & 0xFF) self.i2c.write8(MCP23017_OLATB, (value >> 8)/>/>/>/>/>/> & 0xFF)	  # RPi.GPIO compatible interface for MCP23017 and MCP23008class MCP230XX_GPIO(object):OUT = 0IN = 1BCM = 0BOARD = 0def __init__(self, busnum, address, num_gpios):	self.chip = Adafruit_MCP230XX(busnum, address, num_gpios)def setmode(self, mode):	# do nothing	passdef setup(self, pin, mode):	self.chip.config(pin, mode)def input(self, pin):	return self.chip.input(pin)def output(self, pin, value):	self.chip.output(pin, value)def pullup(self, pin, value):	self.chip.pullup(pin, value)def lightRGBLed(rState,gState,bState,rPin,gPin,bPin):mcp.output(rPin, rState)mcp.output(gPin, gState)mcp.output(bPin, bState)def lightRGBLed2(color,rPin,gPin,bPin):if color == 'red':	lightRGBLed(0,1,1,rPin,gPin,bPin)elif color == 'green':	lightRGBLed(1,0,1,rPin,gPin,bPin)elif color == 'blue':	lightRGBLed(1,1,0,rPin,gPin,bPin)elif color == 'yellow':	lightRGBLed(0,0,1,rPin,gPin,bPin)elif color == 'magenta':	lightRGBLed(0,1,0,rPin,gPin,bPin)elif color == 'cyan':	lightRGBLed(1,0,0,rPin,gPin,bPin)elif color == 'white':	lightRGBLed(0,0,0,rPin,gPin,bPin)if __name__ == '__main__':mcp = Adafruit_MCP230XX(busnum = 1, address = 0x20, num_gpios = 16)r1=10g1=8b1=9mcp.config(b1, mcp.OUTPUT)mcp.config(g1, mcp.OUTPUT)mcp.config(r1, mcp.OUTPUT)while (True):  print "off"  lightRGBLed(1,1,1,r1,g1,b1)  time.sleep(1)  print "rouge"  lightRGBLed(0,1,1,r1,g1,b1)  time.sleep(1)  print "vert"    lightRGBLed(1,0,1,r1,g1,b1)  time.sleep(1)  print "bleu"  lightRGBLed(1,1,0,r1,g1,b1)  time.sleep(1)  print "vert+bleu"    lightRGBLed(1,0,0,r1,g1,b1)  time.sleep(1)  print "rouge+bleu"    lightRGBLed(0,1,0,r1,g1,b1)  time.sleep(1)  print "rouge+vert"    lightRGBLed(0,0,1,r1,g1,b1)  time.sleep(1)  print "rouge+vert+bleu"    lightRGBLed(0,0,0,r1,g1,b1)  time.sleep(1)

[chrissimon]

Un post d'encouragement de plus ! Je me suis commandé un RPI à des fins plus informatiques qu'électroniques (héberger chez moi site / emails / accès à distance et config réseau) et ce post donne plus qu'envie d'acheter quelques composants pour se mettre à l'électronique :)

[sky99]

Capturer et diffuser des images et/ou un flux vidéo depuis une Webcam

Ce petit tutoriel n'est pas électronique, mais peut servir à toutes sortes d'applications. Il nous faut un Raspberry Pi, et une webcam USB. Nous allons voir comment prendre des captures en jpg de la webcam, mais aussi capturer des flux vidéo, que nous pourrons également diffuser par un serveur web.

En premier lieu, je me base sur ce tutoriel sur l'utilisation de mjpg-streamer avec un RaspberryPi, que je traduis, et auquel j'ajoute quelques petites touches.

En premier lieu, vérifiez que votre webcam est bien supportée. Pour cela, branchez la sur un port USB quelconque, puis lancez un terminal, et tapez la commande lsusb:

pi@pi3 ~$ lsusbBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. 4-Port HUBBus 001 Device 005: ID 0566:3020 Monterey International Corp.Bus 001 Device 006: ID 1a40:0101 Terminus Technology Inc. 4-Port HUBBus 001 Device 007: ID 046d:c05b Logitech, Inc. M-U0004 810-001317 [b110 Optical USB Mouse]Bus 001 Device 008: ID 0566:8899 Monterey International Corp.Bus 001 Device 009: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11nBus 001 Device 010: ID 046d:080a Logitech, Inc. Portable Webcam C905

Dans mon cas, je vois le device 010 comme étant ma webcam, donc tout va bien.

Installons quelques paquets dont nous aurons besoin :

sudo apt-get install subversion libv4l-dev libjpeg8-dev imagemagick fswebcam

Pour vérifier si votre webcam supporte le MJPEG, vous pouvez utiliser cette commande :

pi@pi3 ~ $ sudo fswebcam --verbose--- Opening /dev/video0...Trying source module v4l2.../dev/video0 opened.<SNIP>src_v4l2_set_pix_format,541: Device offers the following V4L2 pixel formats:src_v4l2_set_pix_format,554: 0: [0x56595559] 'YUYV' (YUV 4:2:2 (YUYV))src_v4l2_set_pix_format,554: 1: [0x47504A4D] 'MJPG' (MJPEG)Using palette MJPEG<SNIP>

Si le support du MJPEG n’apparaît pas, il faudra trouver une solution pour convertir le flux vidéo. Pour moi ça fonctionnait, donc je n'ai pas cherché davantage. Ceci dit au moins, les images seront accessibles.

Maintenant, nous pouvons télécharger, compiler, et installer mjpeg-streamer :

svn co https://mjpg-streamer.svn.sourceforge.net/svnroot/mjpg-streamermjpg-streamercd mjpg-streamer/mjpg-streamermake USE_LIBV4L2=true clean allsudo make DESTDIR=/usr installcd ../.. ; rm -rf mjpg-streamer

Si la compilation a réussi, vous devriez pouvoir lancer le flux de webcam:

mjpg_streamer -i "/usr/lib/input_uvc.so -d /dev/video0" -o "/usr/lib/output_http.so -p 8001 -w /var/www/mjpg_streamer -n"

Pour pouvoir vérifier, lancez un navigateur sur n'importe quelle machine connectée au même réseau que le pi, et tapez l'adresse

http://IP_RASPBERRYPI:PORT/?action=stream

si vous n'avez pas changé le nom d'hote du Raspberry Pi, l'adresse suivante fonctionnera (en local) :

http://raspberrypi:8001/?action=stream .

SI vous voyez un flux vidéo, c'est que tout fonctionne correctement.

Il est possible de parametrer la résolution, ainsi que le nombre d'images capturées par seconde, en utilisant les parametres -r, suivi d'une résolution (par ex 640x480), ou de l'une des chaines suivantes : QSIF QCIF CGA QVGA CIF VGA SVGA XGA SXGA, et le paramètre -f suivi du nombre de FPS souhaité, dans la ligne de commande. Attention, ces paramètres ne sont pas des paramètes de mjpeg, mais du plugin d'entrée, ce qui signifie en pratique que la commande sera la suivante :

sudo mjpg_streamer -i "/usr/lib/input_uvc.so -d /dev/video0 -f 5 -r XGA" -o "/usr/lib/output_http.so -p 8001 -w /var/www/mjpg_streamer -n"

Le paramètre -p permet au passage de spécifier le port sur lequel on pourra voir le flux vidéo. Dans mon cas, j'ai choisi le port 8001, car le port 80 est déjà occupé par apache.

Pour arrêter le stream, il suffira de faire CTRL+C.

Pour intégrer ce flux dans une page hébergée sur le serveur apache du même Raspberry pi, il suffira d'inclure l'adresse http://localhost:8001/?action=stream dans une page quelconque sur votre serveur apache du pi... Bien sur c'est également possible par le réseau local, ou même par le net si vous configurez votre routeur et le NAT correctement...

Au passage, il est possible d'ouvrir le flux video depuis VLC, et ainsi le visionner, voire l'enregistrer depuis n'importe quel autre poste connecté...

Au passage, mjpeg-streamer utilise la compression intégrée aux webcam. De ce fait la compression vidéo est rapide, et la consommation CPU est minime : moins de 2% chez moi au maximum. On peut donc envisager de streamer de multiples webcam sans problèmes!

Au passage, si vous avez un appareil photo numérique, certains supportent le standard UVC, et vous pourriez vous en servir de la sorte! Sinon avec gPhoto, il peut être possible de contrôler et commander votre APN depuis le raspberry Pi (ou n'importe quel Linux d'ailleurs) en le branchant en USB.

Vous pouvez voir les options du plugin d'entrée via la commande suivante :

mjpg_streamer -i "input_uvc.so --help"

qui retournera :

MJPG Streamer Version: svn rev: 3:172---------------------------------------------------------------Help for input plugin..: UVC webcam grabber---------------------------------------------------------------The following parameters can be passed to this plugin:[-d | --device ].......: video device to open (your camera)[-r | --resolution ]...: the resolution of the video device,					  can be one of the following strings:					  QSIF QCIF CGA QVGA CIF VGA					  SVGA XGA SXGA					  or a custom value like the following					  example: 640x480[-f | --fps ]..........: frames per second[-y | --yuv ]..........: enable YUYV format and disable MJPEG mode[-q | --quality ]......: JPEG compression quality in percent					  (activates YUYV format, disables MJPEG)[-m | --minimum_size ].: drop frames smaller then this limit, useful					  if the webcam produces small-sized garbage frames					  may happen under low light conditions[-n | --no_dynctrl ]...: do not initalize dynctrls of Linux-UVC driver[-l | --led ]..........: switch the LED "on", "off", let it "blink" or leave					  it up to the driver using the value "auto"---------------------------------------------------------------

de même, la doc du plugin de sortie peut être obtenue par la commande:

mjpg_streamer -o "output_http.so --help"

qui retournera :

MJPG Streamer Version: svn rev: 3:172---------------------------------------------------------------Help for output plugin..: HTTP output plugin---------------------------------------------------------------The following parameters can be passed to this plugin:[-w | --www ]...........: folder that contains webpages in					   flat hierarchy (no subfolders)[-p | --port ]..........: TCP port for this HTTP server[-c | --credentials ]...: ask for "username:password" on connect[-n | --nocommands ]....: disable execution of commands---------------------------------------------------------------

Il est également possible de définir un mot de passe en utilisant l'option -c dans les options du plugin de sortie, ce qui donnera :

sudo mjpg_streamer -i "/usr/lib/input_uvc.so -d /dev/video0 -f 30 -r 640x480" -o "/usr/lib/output_http.so -p 85 -c login:pass -w /var/www/mjpg_streamer -n"

ici j'ai mis login comme nom d'utilisateur, et pass comme mot de passe. A l'ouverture du flux, les identifiants seront demandés., ou alors, il est possible (c'est moins sécurisé) d'ouvrir le flux directement via l'url http://login:pass@raspberrypi:8001/?action=stream.

Si tout fonctionne comme vous le souhaitez, il est possible de faire un service, comme indiqué sur le tutoriel en anglais sur lequel je me suis basé , en créant un fichier /etc/init.d/mjpg_streamer.sh contenant ceci :

#!/bin/sh# /etc/init.d/mjpg_streamer.sh# v0.2 phillips321.co.uk### BEGIN INIT INFO# Provides:		  mjpg_streamer.sh# Required-Start:    $network# Required-Stop:	 $network# Default-Start:	 2 3 4 5# Default-Stop:	  0 1 6# Short-Description: mjpg_streamer for webcam# Description:	   Streams /dev/video0 to http://IP/?action=stream### END INIT INFOf_message(){    echo "[+] $1"}# Carry out specific functions when asked to by the systemcase "$1" in    start)		    f_message "Starting mjpg_streamer"		    mjpg_streamer -b -i "/usr/lib/input_uvc.so -d /dev/video0" -o "/usr/lib/output_http.so -p 80 -w /var/www/mjpg_streamer -n"		    sleep 2		    f_message "mjpg_streamer started"		    ;;    stop)		    f_message "Stopping mjpg_streamer..."		    killall mjpg_streamer		    f_message "mjpg_streamer stopped"		    ;;    restart)		    f_message "Restarting daemon: mjpg_streamer"		    killall mjpg_streamer		    mjpg_streamer -b -i "/usr/lib/input_uvc.so -d /dev/video0" -o "/usr/lib/output_http.so -p 80 -w /var/www/mjpg_streamer -n"		    sleep 2		    f_message "Restarted daemon: mjpg_streamer"		    ;;    status)		    pid=`ps -A | grep mjpg_streamer | grep -v "grep" | grep -v mjpg_streamer. | awk '{print $1}' | head -n 1`		    if [ -n "$pid" ];		    then				    f_message "mjpg_streamer is running with pid ${pid}"				    f_message "mjpg_streamer was started with the following command line"				    cat /proc/${pid}/cmdline ; echo ""		    else				    f_message "Could not find mjpg_streamer running"		    fi		    ;;    *)		    f_message "Usage: $0 {start|stop|status|restart}"		    exit 1		    ;;esacexit 0

Il faudra ensuite taper la commande suivante

sudo update-rc.d mjpg_streamer.sh defaults

Et au prochain redémarrage, le service devrait se lancer automatiquement!

Il deviendra normalement possible d'utiliser les commandes service start, stop, restart et status.

[sky99]

Raspberry Pi : configuration mobile, autonome et sans fil!

Bonjour à tous! Il existe de nombreux moyens d'utiliser un Raspberry Pi sans fil, sur batterie. L'intérêt peut être de l'amener

à un endroit ou il n'y a pas de prise électrique, ou tout simplement de le déplacer pour faire des mesures à divers endroits.

Dans tous les cas, je vais vous décrire une solution que j'ai utilisée pour faire un Pi mobile (sans écran, contrôlé via SSH),

et les résultats obtenus.

En premier lieu, il faut un régulateur de tension. Ce composant sert à prendre une source de courant fournissant une tension

peu précise, ou non adaptée à nos besoins, et à la convertir à une tension qui nous convient. Il existe de nombreux composants,

tel que le LM7805, ou le LM317. Ce composant prend en entrée une tension supérieure à 5V, et abaisse la tension à 5V. Il faut toutefois

que la source initiale de courant fournisse au moins 2V de plus que la tension souhaitée, soit au moins 7V dans notre cas. Il existe d'autres

régulateurs linéaires, dits "low dropout", qui peuvent fonctionner avec 6V pour fournir du 5V par exemple. Dans tous les cas, avec ce genre de

circuits, la différence de tension (par exemple si vous utilisez un LM7805 avec une source à 12V, vous produisez 5V donc la différence

sera de 7V) sera simplement "gasipillée" en chaleur en utilisant le même courant (en mA) que ce que vous voulez alimenter avec.

Si on reprend notre exemple, 12V convertis en 5V, pour alimenter un raspberry pi et quelques dispositifs. Si le Pi et les périphériques

consomment 1A, on dissipera 7W en chaleur. Il faudra donc bien refroidir le régulateur de tension, mais toute cette puissance

sera consommée sur les batteries!

C'est donc une solution, mais pas nécessairement adaptée à la mobilité. Une autre solution est d'utiliser des "swtiching regulators".

Ces composants convertissent une tension vers une autre, et peuvent partir d'une tension plus basse ou plus haute selon le modèle

(ou même les deux parfois) pour générer la tension souhaitée. On en trouve de très efficaces, a 90% ou plus, ce qui signifie

qu'on gaspille moins de 10% de l’énergie. Pour ma part j'ai utilisé ce circuit de chez pololu, qui permet de fournir 5V

en 500mA si la tension d'entrée est inférieure à 5V, ou 1A si la tension d'entrée est supérieure à 5V. Dans mon cas, j'aurai plus

de 5V, donc 1A pour mon système mobile.

J'ai également utilisé une "boite à batteries AA" (je ne sais pas comment appeler ça) :

8xAA Battery holder.

Bien sur, dedans j'ai mis des piles rechargeables AA, 4 de 2700mAh, 2 de 2500mAh, et 2 de 2300mAh.

Le mieux c'est d'avoir des piles rechargeables de même capacité, mais mes autres piles AA de 2700mAh sont

dans un robot que je n'avais pas envie de démonter.

Il faut enfin du câblage :

• Une prise d'alim Jack DC;
  
• Un adaptateur Jack vers USB;
  
• Un câble micro-USB.
  

Il suffit alors de connecter les câble de la boite à batterie au régulateur de tension(+ sur Vin, - sur ground),

puis de faire partir deux câbles de ce même régulateur, vOut sur le + du jack d'alim, et - sur ground.

Le Jack se branche dans l'adaptateur jack-USB, et du coté USB on branche le câble mini USB, qui vient

à son tour se brancher dans le Raspberry pi.

A ce moment, si vous mettez les batteries, le Pi s’allumera.

J'ai complété le tout avec un hub USB, une clef wifi, et une webcam. Comme d'habitude, j'ai une

puce MCP3008 et une MCP23017 pour lire des entrées analogiques, et ajouter des GPIO, respectivement.

Divers petits composants sont branchés dessus, mais le seul qui consomme un peu, c'est une LED RGB, qui

change de couleur de façon cyclique.

L'essentiel de la consommation électrique provient donc du Pi, de la clé Wifi, et de la webcam.

En utilisant le précédent tutoriel sur la capture et le streaming d'un flux vidéo, j'ai diffusé en continu

un flux video jusqu’à ce que les batteries lâchent.

La charge CPU est modérée, en revanche, le wifi fonctionne en continu, et la webcam consomme également.

Dans ces conditions, le Pi a tenu entre 3h et 3h30 sur les 8 piles AA à priori chargées à bloc.

Avec des batteries uniformes (les 2300mAh sont vieilles et usées) et neuves, on doit pouvoir tenir davantage.

Après il est toujours possible de multiplier les packs de batteries...

Une autre solution toutefois, c'est d'utiliser les "batteries portables USB" pour smartphones.

Vérifiez toutefois qu'elles délivrent bien au moins 700mA, ou mieux 1A. Il faut également

regarder la capacité, 1A à 1000mAh, ça fait juste une heure d'autonomie. Selon les usages, ça peut suffire,

mais c'est à vous de voir.

Le montage est détaillé dans cette vidéo :

[pierrot421]

Bravo pour ce que tu fais c'est très intéressant moi qui débute dans la conception de projet avec un ami qui lui pratique depuis plus longtemps je me suis aidé de tes tutos pour débuter sa m'a vachement aidé ! merci

On a un petit projet en vue et j'aurais besoin de toi pour m'expliquer comment par communiquer via un pc c'est a dire recevoir des infos et comment en fonction des infos reçues lui faire piloter un servomoteur de manière simple.

merci d'avance de ton aide :) Continu comme sa pour ce que tu fais en tout cas .

Ps: je débute :)

[Garat]

Félicitation pour tes tutos ! J'ai déjà un raspberry qui sert de mediacenter, je n'ai plus qu'à en acheter un autre pour essayer de découvrir la partie "électronique" et domotique.