Raspberry Pi : fabriquons des trucs!

[al_bebert]

Bon j'ai pas lu tous les posts donc désolé par avance :)

j'ai une petite question car ma recherche google na pas trouver de réponse;

voila j'ai trouver comment commander un moteur PAP avec un Pi :)

donc je me dit je vais bien trouver des gens qui ont fait une fraiseuse à commande numérique en utilisant le Pi il y a pas de raison.

et bien NON rien quedal nada :(

alors voila je cherche des infos, j'ai déjà les moteurs PAP (merci les vielles imprimantes matricielles) le Pi ne devrait plus tarder...

voila si tu as des idées sur ce point... :)

et encore merci pour ton travail ce post est une vrai mine :)

edit : bon après une recherche en anglais j'ai trouver plus de choses mais pas encore quelque chose de bien concret (hormis des vidéo YT mais bloquer au boulot..)

[sky99]

Bon j'ai pas lu tous les posts donc désolé par avance :)

j'ai une petite question car ma recherche google na pas trouver de réponse;

voila j'ai trouver comment commander un moteur PAP avec un Pi :)

donc je me dit je vais bien trouver des gens qui ont fait une fraiseuse à commande numérique en utilisant le Pi il y a pas de raison.

et bien NON rien quedal nada :(

alors voila je cherche des infos, j'ai déjà les moteurs PAP (merci les vielles imprimantes matricielles) le Pi ne devrait plus tarder...

voila si tu as des idées sur ce point... :)

et encore merci pour ton travail ce post est une vrai mine :)

edit : bon après une recherche en anglais j'ai trouver plus de choses mais pas encore quelque chose de bien concret (hormis des vidéo YT mais bloquer au boulot..)

Déjà, avec tes moteurs PAP, il faut transformer le mouvement rotatif en mouvement linéaire, et sur deux axes. Soit avec une grande tige filetée, soit avec

des bandes souples avec des dents, comme dans un mécanisme de scanner. Il faudra sans doute également un système pour abaisser la fraise, mais là,

à part un troisième axe, je ne sais pas trop.

Une fois ceci fait, il faudra mettre des contacteurs pour le retour de position de la partie mobile, probablement au moins

un contacteur en début ou fin de chaque axe (ou les deux), qui permettra de déterminer le 0,0.

à partir de lè, il devient possible de programmer l'ensemble; il faudra définir le mouvement minimal que peut entraîner un "pas" du moteur pas à pas sur chaque axe,

ça correspondra à la résolution du déplacement. Du coup si on sait qu'un pas du moteur correspond à un déplacement de par exemple un demi millimètre, alors

il est possible d'établir une carte de déplacement, ou chaque "pixel" correspondrait à une zone accessible. Ou ça peut simplement être une suite de coordonnées entières(ce qui revient au même).

Maintenant, je dirais que le plus simple est de commencer "petit", par exemple avec un crayon, ou quelque chose du genre. Car avec une fraiseuse, le problème,

ce sera non seulement le poids de la fraiseuse à installer sur les axes mobiles, mais également le couple, la puissance, et les vibrations générées par l'appareil.

Tous ces paramètres feront bouger la fraiseuse, et si elle est contrainte sur un support, soit toute la machine bougera, soit la fraiseuse se déplacera sur les axes.

Du coup il faut un bon couple de tenue des moteurs pas à pas!

Parceque si jamais la fraiseuse en attaquant le matériau à usiner provoque une force en retour trop importante, elle pourrait forcer le moteur pas à pas à tourner dans le sens inverse du mouvement,

ou le bloquer dans sa rotation. Or du coup, la commande numérique serait faussée,puisque dans le programme on serait à une position précise, alors qu'en pratique on serait ailleurs.

A mon sens il faudra donc également rajouter un Feedback sur la rotation des axes, avec une roue codeuse ou quelque chose du genre, pour savoir si l'axe tourne et dans quel sens!

En tous cas si tu concrétises le projet, fais nous savoir tout ça, car c'est aussi une des choses que j'aimerais réaliser :) (mais j'avais pensé commencer par une petite graveuse laser)

[al_bebert]

Bon j'ai pas lu tous les posts donc désolé par avance :)

j'ai une petite question car ma recherche google na pas trouver de réponse;

voila j'ai trouver comment commander un moteur PAP avec un Pi :)

donc je me dit je vais bien trouver des gens qui ont fait une fraiseuse à commande numérique en utilisant le Pi il y a pas de raison.

et bien NON rien quedal nada :(

alors voila je cherche des infos, j'ai déjà les moteurs PAP (merci les vielles imprimantes matricielles) le Pi ne devrait plus tarder...

voila si tu as des idées sur ce point... :)

et encore merci pour ton travail ce post est une vrai mine :)

edit : bon après une recherche en anglais j'ai trouver plus de choses mais pas encore quelque chose de bien concret (hormis des vidéo YT mais bloquer au boulot..)

Déjà, avec tes moteurs PAP, il faut transformer le mouvement rotatif en mouvement linéaire, et sur deux axes. Soit avec une grande tige filetée, soit avec

des bandes souples avec des dents, comme dans un mécanisme de scanner. Il faudra sans doute également un système pour abaisser la fraise, mais là,

à part un troisième axe, je ne sais pas trop.

Une fois ceci fait, il faudra mettre des contacteurs pour le retour de position de la partie mobile, probablement au moins

un contacteur en début ou fin de chaque axe (ou les deux), qui permettra de déterminer le 0,0.

à partir de lè, il devient possible de programmer l'ensemble; il faudra définir le mouvement minimal que peut entraîner un "pas" du moteur pas à pas sur chaque axe,

ça correspondra à la résolution du déplacement. Du coup si on sait qu'un pas du moteur correspond à un déplacement de par exemple un demi millimètre, alors

il est possible d'établir une carte de déplacement, ou chaque "pixel" correspondrait à une zone accessible. Ou ça peut simplement être une suite de coordonnées entières(ce qui revient au même).

Maintenant, je dirais que le plus simple est de commencer "petit", par exemple avec un crayon, ou quelque chose du genre. Car avec une fraiseuse, le problème,

ce sera non seulement le poids de la fraiseuse à installer sur les axes mobiles, mais également le couple, la puissance, et les vibrations générées par l'appareil.

Tous ces paramètres feront bouger la fraiseuse, et si elle est contrainte sur un support, soit toute la machine bougera, soit la fraiseuse se déplacera sur les axes.

Du coup il faut un bon couple de tenue des moteurs pas à pas!

Parceque si jamais la fraiseuse en attaquant le matériau à usiner provoque une force en retour trop importante, elle pourrait forcer le moteur pas à pas à tourner dans le sens inverse du mouvement,

ou le bloquer dans sa rotation. Or du coup, la commande numérique serait faussée,puisque dans le programme on serait à une position précise, alors qu'en pratique on serait ailleurs.

A mon sens il faudra donc également rajouter un Feedback sur la rotation des axes, avec une roue codeuse ou quelque chose du genre, pour savoir si l'axe tourne et dans quel sens!

En tous cas si tu concrétises le projet, fais nous savoir tout ça, car c'est aussi une des choses que j'aimerais réaliser :) (mais j'avais pensé commencer par une petite graveuse laser)

toute la partie mécanique ça je m'en occupe ce n'est pas un soucis :) je compte bien gérer 3 axes. avec 3 capteurs de début de courses pour initialiser le point 0 puis 3 capteurs de fin de courses mutalisés si possible qui stop juste le programe (il est anormal de taper dans les capteurs de fin de courses)

pour le couple le but est d'utiliser un dremel je me fait pas trop de soucis pour toute la partie mécanique au pire il suffit de réduire le pas d'avance de la fraise (réduction mécanique) pour éviter de forcer etc etc.

il y a déjà de nombreux projet avec des cartes spécialisées et ça marche vraiment bien, la le but c'est d'utiliser un raspberry en fait.

bon par contre le projet va mettre beaucoup de temps à être réaliser... pas de temps à consacrer à mes loisirs en ce moment :(

[sky99]

pour le couple le but est d'utiliser un dremel je me fait pas trop de soucis pour toute la partie mécanique au pire il suffit de réduire le pas d'avance de la fraise (réduction mécanique) pour éviter de forcer etc etc.

il y a déjà de nombreux projet avec des cartes spécialisées et ça marche vraiment bien, la le but c'est d'utiliser un raspberry en fait.

bon par contre le projet va mettre beaucoup de temps à être réaliser... pas de temps à consacrer à mes loisirs en ce moment :(

Dans ce cas, si la partie mécanique ne pose pas de problème, ça devrait être TRES simple!

Il suffit de prendre un driver, comme le L293D (pour des moteurs de moins de 600mA), ou le L298 pour des moteurs

plus puissants. A partir de là, il suffit d'envoyer des signaux sur un certain nombre de GPIO pour activer le moteur souhaité comme voulu.

Éventuellement, une solution intermédiaire pourrait être d'utiliser trois drivers (un pour chaque moteur PAP), et interfacer ces composants

à un µC (genre ATMega, ou picaxe, mais moi je ne connais que les ATMega ou ATtiny). Ensuite, il ne restera plus qu'à programmer le µC

pour répondre à certaines commandes (par exemple, moveTo(X,Y) et toutes les fonctions du même genre.). A ce moment, on peut interfacer

le µC au Pi (par exemple par l'interface série, SPI, ou I2C). Du coup le Pi recevrait des données de haut niveau (un patron de la pièce à usiner)

et enverrait les données de bas niveau au µC, qui assurerait un travail précis avec des commandes en temps réel.

En plus le point sympa, c'est que du coup, ça ferait une sorte de "périphérique" au pi :)

[Geekomanie]

Pour infos, je viens de voir que les caméra board sont de nouveau disponibles sur le site kubii.fr !

[yeror]

Bonjour,

tout neuf dans le monde de Raspberry PI et de la robotique, je me demande à partir de quels éléments construire un robot capable de se déplacer d'un point A vers un point B.

Donc l'idée, une fois qu'on a fabriqué un robot capable de se déplacer et d'éviter les obstacles (grâce aux excellents tutoriels trouvés sur ce site) c'est que le robot soit capable d'aller sur demande de la pièce de l'appartement dans lequel il se trouve vers une autre pièce du même appartement.

Par exemple, le robot est dans le salon. On lui "dit" d'aller dans la cuisine.

Pour l'instant, ma réflexion n'est pas de savoir comment on lui "dit" mais de quels éléments matériels et logiciels on a besoin pour que le robot :

1 - reconnaisse l'endroit ou il se trouve,

2 - détermine la route pour aller vers sa destination,

3 - sache qu'il est arrivé à destination.

Je me disais que pour répondre aux 1 et aux 3 on pourrait utiliser :

- des puces RFID dans les différentes pièces de l'appartement.

- mettre une webcam sur le robot qui recherche un repère précis dans chaque pièce.

...

Mais comment gérer la route ?

Je m'excuse si le sujet a déjà été traité. J'ai essayé de chercher avant de poser mes questions.

N'hésitez pas toutes les idées sont bonnes à prendre.

Merci

Y.

[sky99]

Bonjour,

tout neuf dans le monde de Raspberry PI et de la robotique, je me demande à partir de quels éléments construire un robot capable de se déplacer d'un point A vers un point B.

Donc l'idée, une fois qu'on a fabriqué un robot capable de se déplacer et d'éviter les obstacles (grâce aux excellents tutoriels trouvés sur ce site) c'est que le robot soit capable d'aller sur demande de la pièce de l'appartement dans lequel il se trouve vers une autre pièce du même appartement.

Par exemple, le robot est dans le salon. On lui "dit" d'aller dans la cuisine.

Pour l'instant, ma réflexion n'est pas de savoir comment on lui "dit" mais de quels éléments matériels et logiciels on a besoin pour que le robot :

1 - reconnaisse l'endroit ou il se trouve,

2 - détermine la route pour aller vers sa destination,

3 - sache qu'il est arrivé à destination.

Je me disais que pour répondre aux 1 et aux 3 on pourrait utiliser :

- des puces RFID dans les différentes pièces de l'appartement.

- mettre une webcam sur le robot qui recherche un repère précis dans chaque pièce.

...

Mais comment gérer la route ?

Je m'excuse si le sujet a déjà été traité. J'ai essayé de chercher avant de poser mes questions.

N'hésitez pas toutes les idées sont bonnes à prendre.

Merci

Y.

Hello!

J'ai pas beaucoup mis à jour le sujet ces temps ci, mais je suis en fin de thèse, donc un peu booké :)

Sur le sujet, toutefois, après avoir fait R.Cerda, j'ai commencé la version 2.0, avec un nouveau châssis, un Raspberry Pi modèle A, une meilleure batterie (lithium), et de nouveaux capteurs, dont certains doivent arriver bientôt.

Et justement, cette nouvelle version devrait me permettre de répondre à tes problématiques.

L'approche RFID pourrait être tentée, mais j'y vois quand même de gros soucis : le RFID est à courte portée (10cm au mieux, hors matériel très cher). Du coup ça oblige à avoir des tags partout ou alors de froler les capteurs de repérage. ça pourrait toutefois être une solution, en combinaison avec un guidage optique (le pi va se coller sur une cible, lit le tag, et sait ou il est).

Bref, pour ma part, je conseillerais plutôt soit l'approche optique (caméra et traitement des images pour reconnaître des éléments précis), soit d'utiliser des balises, soit radio, soit infrarouge. Avec les balises IR, le robot aurait juste à les trouver et déterminer de quelle balise il s'agit, pour savoir ou il est d'après des informations qu'il a en mémoire. Avec des balises radio, il s'agirait de trianguler le signal d'au moins 3 balises fixes pour déterminer la position relative du robot. C'est à mon sens l'une des solutions les plus puissantes, mais il reste à parvenir à le faire. Dans quelle mesure peut on déterminer sa position par rapport à 3 balises proches de quelques metres avec un équipement radio standard? c'est à voir.

Du coup, pour ma part, je tenterai l'approche video. Sur R.Cerda, j'ai mis une webcam, et je peux streamer le flux vidéo par wifi. Donc dans un premier temps j'ai pu regarder ce que fait le robot en "vue première personne", mais du coup je vais maintenant pouvoir utiliser opencv ou autre pour faire certains traitements automatiques.

Une piste simple, c'est d'imprimer des balises visuelles spécifiques, que le robot à en mémoire. En analysant le flux vidéo, celui ci sera capable ou non de repérer la balise. SI chaque balise est différente, ça lui fait déjà un moyen de savoir ou il est. S'il sait ou il est, on peut commencer à cartographier la maison à partir des balises.

Par exemple : "balise 1" détectée, je veux aller à "balise 2". Pour cela, je sais que je dois tourner de tant de degrés vers la gauche, avancer de X, tourner comme ci, comme ça, puis je serai en vue de la balise. A partir de là, navigation "à vue".

Il faut savoir qu'avec les algos de visions par ordinateur, on peut également déterminer la distance à la balise, ainsi que l'angle avec la balise, etc.

Du coup, le robot, en voyant la balise, peut se faire une idée précise de sa position : je suis à X cm de la balise, avec un angle de Y° par rapport à la normale à la surface de la balise. Du coup on peut faire pas mal de choses.

Cependant, il y a des points à régler avant tout cela (pas nécessairement, mais ça aidera grandement de le faire), à savoir la connaissance et le contrôle des déplacements éffectués par le robot. A l'heure actuelle, mon robot avance à une vitesse que j'ai estimée approximativement, mais elle varie selon la charge de la batterie. Du coup d'éventuels calculs sont vite faussés. D'autre part, il tourne sur la gauche très légèrement quand il est censé avancer tout droit.

Il faut donc ajouter un système permettant de mesurer la rotation de chaque roue (c'est prévu, avec des capteurs à 2-3€, quand j'aurai les 2 je ferai un tuto).

Si on connait la vitesse de rotation de chaque roue, on peut déjà ajuster la vitesse pour qu'elle soit similaire entre les deux roues, ou au moins corriger la trajectoire pour compenser une dérive d'un coté ou de l'autre.

En connaissant cette donnée, on peut également convertir cela en distance parcourue, et ainsi commencer à cartographier, le robot sachant à peu près ou il se trouve par rapport à son point de départ.

On peut également calculer l'angle des rotations effectuées. Tout cela permettra de stocker des trajets, pour éventuellement les refaire. Cela permettra également de cartographier une zone.

Je vais donc pour ma part appliquer cette solution, mais également utiliser un accéléromètre pour voir si par ce biais on peut avoir des données fiables. Je vous tiendrai au courant.

Bref, je dirais globalement :

-Etape 1 : faire un robot qui roule

-Etape 2 : lui permettre d'utiliser ses organes sensoriels pour avoir un minimum d'autonomie et ainsi de pouvoir éviter les obstacles

-Etape 3 : ajouter/utiliser des organes sensoriels lui permettant de savoir ce qu'il fait (avoir des déplacements précis, et un feedback dessus)

-Etape 4 : utiliser tous ces systèmes et éventuellement d'autres pour permettre au robot de "comprendre/reconnaître" son environnement, et ainsi se situer dans l'espace, établir des relations de distance entre divers points, voire cartographier certains obstacles

-Etape 5 : on peut commencer à faire du pathfinding et ainsi définir des routines pour "aller du point A au point B"

A partir de là on aura mis en place toutes les briques de bas niveau qui permettront de penser à des tâches de haut niveau, comme "transporter un objet d'un endroit à un autre", ou "patrouiller entre N points", "vérifier un élément dans la maison, prendre une photo, et l'envoyer sur un serveur", ou des combinaisons de ces tâches...

Je trouve que c'est un objectif très intéréssant, et je pense que je m'y attarderai quand je pourrai. Pour mon robot, les prochaines étapes sont l'étape 3 et l'étape 4.

Je pense que ça permettra aussi au robot d'avoir la capacité de se rendre sur une borne de recharge si nécéssaire!

Du coup avec un nombre suffisant de robots, on peut s'assurer d'en avoir toujours un de chargé, en train de faire la tâche souhaitée...

[yeror]

Bonjour et merci pour cette réponse complète.

j'ai eu une autre idée mais complètement théorique donc peut-être complètement irréalisable. Bref, je me suis souvenu avoir dans un coin un GPS de randonnée pédestre (Garmin) avec un port série. Je me demande donc si ce n'est pas un moyen possible. Les questions sont donc :

- peut on récupérer les données du GPS (puis les traiter).

- le GPS sera t-il assez précis dans un appartement. Pour cela je n'ai qu'à le rretrouver/rallumer et me ballader chez moi :-)

Qu'en pensez-vous ?

[sky99]

Bonjour et merci pour cette réponse complète.

j'ai eu une autre idée mais complètement théorique donc peut-être complètement irréalisable. Bref, je me suis souvenu avoir dans un coin un GPS de randonnée pédestre (Garmin) avec un port série. Je me demande donc si ce n'est pas un moyen possible. Les questions sont donc :

- peut on récupérer les données du GPS (puis les traiter).

- le GPS sera t-il assez précis dans un appartement. Pour cela je n'ai qu'à le rretrouver/rallumer et me ballader chez moi :-)

Qu'en pensez-vous ?

Salut!

On peut en effet récupérer les données d'un GPS. Il existe pour cela des modules faits pour l'utilisation par un microcontrôleur, un raspberry pi, ou n'importe quel système d'électronique programmable, le Adafruit ultimate GPS Breakout. Il n'est pas très cher, et est censé être très efficace.

Pour ce qui est de récupérer les données du GPS garmin, c'est peut être possible, mais il faudra trouver ou lire les données, à moins qu'il y aie un port/protocole de communication documenté. Mais ça doit être possible.

Cependant, dans tous les cas, la précision des GPS civils tourne entre 1 et 10m, donc pas sur que ça soit assez précis pour un usage robotique dans une petite surface...

De plus en intérieur, les signaux GPS sont souvent bloqués, donc on risque de ne pas capter les signaux des satellites.

Je sais qu'il existe des balises GPS qu'on peut mettre à des points précis pour creer des points de référence, mais c'est plutôt réservé aux gros chantiers, et j'imagine que même si on arrivait à les trouver, ça coûterait sans doute des centaine sou des milliers d'euros.

Bref, je ne pense pas que ce soit une solution réellement applicable pour un positionnement de robot en intérieur, mais le même principe est surement applicable avec des balises IR ou radio :)

J'ai le module GPS d'Adafruit, il faudrait aussi que je fasse des tests sur sa précision (et un tuto d'ailleurs)

[Nitro-TecK]

Sky j'attends avec iNpatience ton tuto sur le GPS car je risque d'en avoir rapidement besoin

Sinon je me permet de poster mon petit projet en cours sur lequel il y a déjà apparement pas mal de choses déja faites.

Comme je suis un peu fan de voiture, je souhaite pouvoir facilement obtenir toutes les infos sur la voiture via la prise ODB.

Je viens donc de me commander une boitier type ELM327 et via CRON lancé au démarrage JDASH qui permet ensuite de récupérer toutes les informations.

Pour l'instant tout va bien, disons que çà reste du Linux/Java. mais pour voir quelque chose de "transportable" et avoir un écran pour voir toutes les informations, j'ai eu l'idée d'utiliser l'ecran d'un vieu EEEPC qui traine chez moi et la je seche. Avez vous une idée sur comment pouvoir récupérer l'ecran pour mon RPi ?

Pour en revenir au GPS, je me dis qu'il serait aussi interessant quite à avoir un ecran, d'avoir un GPS. Mais par contre sur Nunux pas grand chose, donc si vous connaissez un systeme de navigation ? (Etant sur android, j'ai pu tester la version de google map pour les itinéraire et c'est pas trop mal, un moyen d'exporter le tout ?)

Merci d'avance.

EDIT : Bon j'ai déémonter mon EEE PC plus rapidement que prévu, donc j'ai une connectique de type Mini LVDS. Mais un convertisseur n'existe pas ... nice :(

[flotix]

Hello tous le monde,

Je voulais savoir si il est possible de brancher plusieurs montages sur un gpio?

Ou bien sa va partir en sucette niveau data...

Merci.

[Yaug]

Bonjour,

pourquoi ne pas brancher sur plusieurs GPIO ?

Et sinon, en général, on passe par un MCP3008 ou un MCP23017 pour multiplier les GPIOs et donc les montages connectés dessus, ce qui ne pose aucun problème particulier.

[sky99]

Sky j'attends avec iNpatience ton tuto sur le GPS car je risque d'en avoir rapidement besoin

Sinon je me permet de poster mon petit projet en cours sur lequel il y a déjà apparement pas mal de choses déja faites.

Comme je suis un peu fan de voiture, je souhaite pouvoir facilement obtenir toutes les infos sur la voiture via la prise ODB.

Je viens donc de me commander une boitier type ELM327 et via CRON lancé au démarrage JDASH qui permet ensuite de récupérer toutes les informations.

Pour l'instant tout va bien, disons que çà reste du Linux/Java. mais pour voir quelque chose de "transportable" et avoir un écran pour voir toutes les informations, j'ai eu l'idée d'utiliser l'ecran d'un vieu EEEPC qui traine chez moi et la je seche. Avez vous une idée sur comment pouvoir récupérer l'ecran pour mon RPi ?

Pour en revenir au GPS, je me dis qu'il serait aussi interessant quite à avoir un ecran, d'avoir un GPS. Mais par contre sur Nunux pas grand chose, donc si vous connaissez un systeme de navigation ? (Etant sur android, j'ai pu tester la version de google map pour les itinéraire et c'est pas trop mal, un moyen d'exporter le tout ?)

Merci d'avance.

EDIT : Bon j'ai déémonter mon EEE PC plus rapidement que prévu, donc j'ai une connectique de type Mini LVDS. Mais un convertisseur n'existe pas ... nice :(

Salut!

Je suis très intéressé par tes résultats sur le ODB, donc n'hésites pas à nous en faire part :)

Pour le EEEPC, malheureusement, comme tu t'en es rendu compte, c'est du LVDS, est c'est souvent galère à récupérer. Tu peux peut-être récupérer un adaptateur vers un format "normal", mais je ne sais pas si ce sera forcément rentable. En effet, tu peux trouver des petits LCD 4-6 pouces aux alentours de 50$ ou même beaucoup moins avec certaines bonnes affaires. En HDMI c'est plus "future-proof" et réutilisable, mais la sortie s-vidéo du pi fonctionne très bien (la sortie jaune, j'ai pu vérifier le bon fonctionnement, il faut juste ne brancher que ça au boot, car si le HDMI est aussi branché, il prend le pas, et pas de sortie sur le svideo)

Pour le GPS, ça dépend de si tu es en ligne/hors ligne. En ligne, ça sera assez facile de récupérer via l'api google maps un affichage, en passant les coordonnées détectées par le GPS.

Peut être qu'il y a des versions "hors ligne" ou un truc du genre?

Sinon il y a openstreetmaps, et du coup la on peut TOUT faire.

Mais même avec google maps, je pense qu'il y a moyen d'avoir une version en cache/hors ligne ou un truc du genre(je parle pas d'une appli externe, juste de la version browser web).

Je vais essayer de me magner pour le GPS :) Mais dans tous les cas, il y a le tuto d'Adafruit, en anglais... En gros ce que je ferai, ce sera de tester ce qu'ils disent, et écrire un tuto dérivé en FR ^^

Voici déjà les liens d'Adafruit:

http://learn.adafruit.com/adafruit-ultimate-gps-on-the-raspberry-pi ->tuto d'utilisation du module GPS sur le pi

http://learn.adafruit.com/adafruit-ultimate-gps ->description du module GPS, qui est vraiment petit, consomme peu, et plein de fonctionnalités intéressantes (par exemple, il peut logger les données GPS tout seul, même sans que le pi soit actif, pendant plusieurs heures, avant de les retransmettre)

https://github.com/adafruit/Adafruit-GPS-Library -> leur bibliothèque pour s'en servir avec le pi

Au passage, on le trouve en France chez snootlab, qui a des frais de ports très modérés pour la France continentale.

Hello tous le monde,

Je voulais savoir si il est possible de brancher plusieurs montages sur un gpio?

Ou bien sa va partir en sucette niveau data...

Merci.

Comme le dit Yaug, si tu branches deux leds sur un GPIO par exemple, quand tu vas mettre le GPIO à 1, les deux LED vont s'allumer. Donc tu peux mettre autant de dispositifs contrôlés par le même GPIO, mais ils fonctionneront tous de la même façon, cad tous allumés, ou tous éteints (ou des combinaisons, si tu as un bidule qui s'allume quand il reçoit un 1, et un autre qui s'allume en recevant un 0).

Pour multiplier les GPIO le plus simple, c'est comme le dit encore Yaug, d'utiliser un MCP23017/23008, ça rajoute 16 ou 8GPIO par puce selon le modèle choisi, et tu peux en avoir jusqu'à 7.

Maintenant, si tu interfaces des composants un peu "intelligents", il y a moyen d'en mettre plusieurs sur un GPIO, si tu en utilise un deuxième pour dire à quel composant tu parles. Par exemple, sur le premier GPIO, tu envoie des données, et sur le second GPIO, tu envoie 0 pour la première puce, et 1 pour la seconde puce. Pour parler à 3 puces, il faudra donc logiquement 3GPIO, pour avoir une adresse sur 2 bits. Du coup on ne gagne rien. Sauf qu'avec 2 bits, on code 4 adresses, donc tu peux potentiellement communiquer avec 4 puces différentes... Et en passant à 3 bits d'adresse (donc 4 GPIO au total), tu peux communiquer avec 8 puces.

Maintenant, il faudra que ce soient des puces programmables pour pouvoir définir ce comportement. Du coup, comme des protocoles comme l'I2C existent, et gèrent justement tout ça, c'est bien plus intéréssant de s'en servir. En fin de compte, avec un MCP23017 par exemple, tu branches deux fils sur les broches I2C du Raspberry pi, un fil sur le +3.3v, et un fil sur la masse, et tu as rajouté 16GPIO exploitables!

[francois1812]

Bonjour,

Sky99: Un énorme merci pour cette mine d'or d'information ! C'est franchement excellent ! Bravo mille fois !

J'ai une petite question, quel logiciel utilises-tu pour faire les schémas de tes tutoriaux (par exemple celui pour allumer une LED) ?

merci (un de plus) d'avance!

[Nitro-TecK]

Merci Sky pour ton retour, donc oui LVDS et convertisseur = une blinde

Pour ce qui est du GPS c'est également ce qu'il me semblais, API Google Maps mais je ne crois pas que le hors ligne soit efficace, tant pis je vais rester avec mon Nexus4 pour me guider.

Donc j'aurai uniquement une valise OBD 2 pour le rPi.

Pour faire simple (j'attends un écran et mon cable OBD pour tester) :

- Rpi avec java d'installer (sudo apt-get install openjdk-7-jdk)

- Télécharger/Décompresser JDASH (http://linux.softpedia.com/get/Utilities/JDash-34315.shtml)

- Décompresser JDASH

- Acheter une prise OBD/USB avec une puce ELM327 (ebay.co.uk de mon coté, payé 12€ livrée)

- Brancher le sur l'USB et reperer le port (normalement /dev/ttyUSB0)

- Configurer JDASH via "java -jar JDashConfig.jar" et regler les paramètres (y compris le port si il change)

- Lancer JDASH via "java -jar JDash.jar

Il est préférable d'utiliser le port video jaune avec une résolution "faiblarde" en HDMI j'ai l'impression que c'est pas très réactif et ont à de la latence.

Je pense que pour le coup JAVA est surement un peu trop gourmand, donc à voir pour optimiser la chose.

Vous devriez avoir normalement les infos RPM/KPM de votre voiture. Pour le moment j'ai pas encore trop mis le nez dedans pour afficher d'autres éléments mais je reviendrai poster la suite après.

(Désolé jamais été très balaises pour les tutos)

[sky99]

Bonjour,

Sky99: Un énorme merci pour cette mine d'or d'information ! C'est franchement excellent ! Bravo mille fois !

J'ai une petite question, quel logiciel utilises-tu pour faire les schémas de tes tutoriaux (par exemple celui pour allumer une LED) ?

merci (un de plus) d'avance!

Salut!

A l'époque, je faisais ces schémas avec un editeur d'image simple, en utilisant des calques (gimp ou autre). J'ai trouvé sur le net des templates de base, et je les modifiais si besoin est. Les fils sont en fait des traits, les connections de petits carrés remplis. C'est très fastidieux,

aussi je te recommande ce que j'utilise actuellement : Fritzing, qui est open source, et multi plateforme (je crois même qu'on n'est pas obligé de l'installer, juste de le décompresser).

La différence, c'est que ce logiciel permet d'amener des composants dans la zone de dessin, et on les relie avec des fils virtuels, mais qui symbolisent réellement une connexion. Si on bouge les composants, les fils suivent, et il y a tout plein d'options. De plus les modèles de nombreux composants sont présents, et , cerise sur le gâteau, il peut sortir un schema électronique du montage qu'on a construit.

Il y a en plus la possibilité d'ajouter les composants manquants en les faisant soi même (je n'ai pas réussi à le faire rapidement, et donc j'ai pris une autre solution plutôt que de chercher les tutos, mais je pense que ça doit pouvoir se faire sans trop de difficultés si on prend le temps d'apprendre), ou en téléchargeant des packs de composants...

Merci Sky pour ton retour, donc oui LVDS et convertisseur = une blinde

Pour ce qui est du GPS c'est également ce qu'il me semblais, API Google Maps mais je ne crois pas que le hors ligne soit efficace, tant pis je vais rester avec mon Nexus4 pour me guider.

Donc j'aurai uniquement une valise OBD 2 pour le rPi.

Pour faire simple (j'attends un écran et mon cable OBD pour tester) :

- Rpi avec java d'installer (sudo apt-get install openjdk-7-jdk)

- Télécharger/Décompresser JDASH (http://linux.softpedia.com/get/Utilities/JDash-34315.shtml)

- Décompresser JDASH

- Acheter une prise OBD/USB avec une puce ELM327 (ebay.co.uk de mon coté, payé 12€ livrée)

- Brancher le sur l'USB et reperer le port (normalement /dev/ttyUSB0)

- Configurer JDASH via "java -jar JDashConfig.jar" et regler les paramètres (y compris le port si il change)

- Lancer JDASH via "java -jar JDash.jar

Il est préférable d'utiliser le port video jaune avec une résolution "faiblarde" en HDMI j'ai l'impression que c'est pas très réactif et ont à de la latence.

Je pense que pour le coup JAVA est surement un peu trop gourmand, donc à voir pour optimiser la chose.

Vous devriez avoir normalement les infos RPM/KPM de votre voiture. Pour le moment j'ai pas encore trop mis le nez dedans pour afficher d'autres éléments mais je reviendrai poster la suite après.

(Désolé jamais été très balaises pour les tutos)

Merci pour ces infos, le jour ou j'ai le connecteur, je testerai (faudrait que je vérifie toutefois que j'ai bien ce connecteur dans ma vielle punto de 2001 ^^)

Pour java, je ne sais pas si ça a changé à l'époque, mais je me rappelle qu'il y avait un truc qui faisait que le java était un peu lent (et d'ailleurs il y avait une version de raspbian avec support de java et une autre sans, parceque je ne sais plus trop quoi).

Ceci dit, tu peux essayer avec raspi-config de changer la quantité de ram disponible pour le système (par exemple en ne laissant que 16mo pour la vidéo, si tu ne fais pas d'affichage 3D ou autres!), voire d'overclocker, c'est assez facile et à peu près sans risque.

Normalement, S-video pi hdmi, ça ne devrait pas faire une grande différence sur la vitesse de l'affichage, puisque c'est le circuit video qui gère tout ça.

Une solution pour accelerer l'affichage serait de choisir un WM ultra léger, et de virer tout ce qui n'est pas nécéssaire... Après il y a la solution de se passer du serveur X, et d'afficher dans le framebuffer comme font certains media centers, mais là je ne sais pas trop comment ça se passe, ni ce qu'il faut faire pour ça.

Une chose est sure, mon Pi décode de la full HD 1080p sans problème, avec une sortie sur ma télé HDMI. Donc il ne devrait pas avoir de problème pour afficher les infos du GPS sur un écran!

Par contre une solution ça pourrait être d'avoir un affichage sur un petit LCD texte des données lues... Et par la suite il est toujours possible d'ajouter un LCD graphique pour afficher ce qui est nécessaire.

Autre possibilité sinon, si le pi s'avère trop lent, il existe d'autres cartes du même type, ou même des sortes de "clés USB" android. Donc pour pas trop cher, il est possible d'avoir par exemple ce dispositif Android, qui utiliserait google maps, mais qui recevrait les données lues par le Pi par un moyen quelconque (USB, wifi, bluetooth...). EN gros le pi servirait d'interface OBD2 pour le bidule Android. Voire même pourquoi pas, utiliser un smartphone connecté en wifi au pi... Et comme certains ont une sortie HDMI, il doit être possible d'afficher le smarphone sur un ecran plus grand.

Pour moi l'intérêt de cette approche, c'est de pouvoir disposer de l'API android pour ces tâches, car par exemple la synthèse vocale, reco vocale, etc, c'est galère à faire soi même en utilisant des librairies sous linux. Avec android, les stagiaires de mon labo y sont parvenus assez vite!

[christophefrontignan]

Bonjour à tous et félicitations pour votre travail.

Je me permets de faire appel à vous car j'ai un projet DIY pour lequel je suis bloqué. De plus cela pourrait bien être une nouvelle idée de réalisation.....

Je ne sais pas si mon choix est judicieux mais vous aller me dire ce que vous en penser.

Je souhaite construire mon propre NAS avec comme OS soit Freenas (ou Nas4Free) soit OpenMediaVault. Pour cette partie je me débrouille.

Là ou j'ai besoin d'un p'tit coup de pouce c'est pour la gestion de divers paramétres "annexes". Le volume de stockage dont j'ai besoin d'une part et le système de fichier d'autre part vont me conduire à prévoir environ une petite dizaine de baies de stockage. Je n'ai pas encore arreté définitivement le nombre.

Je souhaite intégrer à ce NAS maison, un système de surveillance que certains appelle aussi monitoring, devant remplir les fonctions suivantes :

-> Affichage sur chaque afficheur (1 par baie) du numéro d'identification du disque au sein du NAS (ou un nom de baptème donné par l'administrateur de manière en cas de défaillance d'un disque signalé par le système de pouvoir le retrouver facilement et de le remplacer à chaud) OU tout simplement afficher un message d'erreur, de sa température, de son taux d'occupation, de la présence ou non d'un disque dans la baie et enfin si le disque est en cours de réparation ( reconstitution d'une grappe RAID suite à un crash)

-> Affichage sur un afficheur général de la consomation électrique globale du NAS, l'état de fonctionnement du NAS (ok tout va bien, mode dégradé engendré par la réparation d'un disque en cours ou NAS injoignable par utilisation d'une fonction watchdog), débit émission et reception, adresse IP attribué.

-> En fonction des températures relevés piloter les ventilateurs et/ou agir sur la climatisation, activer des informations lumineuses de type feu tricolore.

Ne sachant pas le faire directement sur la carte mère, je pensais confier ce monitoring à la framboise. Qu'en pensez-vous ?

De plus cela permettrait d'enregistrer les informations des capteurs dans une base de données de type MySQL, d'envoyer des alertes par Email ou par SMS......

Si tous les tutos que vous avez longuement expliqués me permettraient de commencer, je suis bloquer par la partie informatique relative aux disques, leur fonctionnement, détecter une erreur, taux occupation, signaler l'erreur, détection de leur mode de fonctionnement (erreur, reconstruction en cours...) De plus, est ce que le nombre d'afficheurs peut poser un problème à la framboise ?

Voilà en quelques lignes mon projet.

Merci @ tous pour votre aide et vos lumières.

Bonnes vacances

Christophe

[Nitro-TecK]

Bonjour, je reviens suite à la réception de mes différents composants.

J'ai reçu mon écran (25€ via amazon, parfait), il se connecte sur le +12V et ne s'allume qu'uniquement si il recoit un signal donc pas de prise de tête pour gerer l'allumage avec le RPI.

Pour le RPi justement, j'ai câbler le pin J6 pour le démarrer et relier le GPIO pour l’éteindre mais pas prévu de résistance pour l'interrupteur, je pensais que mettre le pin a la masse pouvais suffire mais non

Par contre la ou je suis pas sur de moi c'est concernant le code pour qu'il soit exécuter au démarrage.

Et autre question toute bete.

J'ai mon programme en JAVA qui sera "seul" à tourner, il y a t'il un moyen de lancer JAVA sans la partie graphique de Raspbian au démarrage ?

Merci.

[sky99]

Bonjour à tous et félicitations pour votre travail.

Je me permets de faire appel à vous car j'ai un projet DIY pour lequel je suis bloqué. De plus cela pourrait bien être une nouvelle idée de réalisation.....

Je ne sais pas si mon choix est judicieux mais vous aller me dire ce que vous en penser.

Je souhaite construire mon propre NAS avec comme OS soit Freenas (ou Nas4Free) soit OpenMediaVault. Pour cette partie je me débrouille.

Là ou j'ai besoin d'un p'tit coup de pouce c'est pour la gestion de divers paramétres "annexes". Le volume de stockage dont j'ai besoin d'une part et le système de fichier d'autre part vont me conduire à prévoir environ une petite dizaine de baies de stockage. Je n'ai pas encore arreté définitivement le nombre.

Je souhaite intégrer à ce NAS maison, un système de surveillance que certains appelle aussi monitoring, devant remplir les fonctions suivantes :

-> Affichage sur chaque afficheur (1 par baie) du numéro d'identification du disque au sein du NAS (ou un nom de baptème donné par l'administrateur de manière en cas de défaillance d'un disque signalé par le système de pouvoir le retrouver facilement et de le remplacer à chaud) OU tout simplement afficher un message d'erreur, de sa température, de son taux d'occupation, de la présence ou non d'un disque dans la baie et enfin si le disque est en cours de réparation ( reconstitution d'une grappe RAID suite à un crash)

-> Affichage sur un afficheur général de la consomation électrique globale du NAS, l'état de fonctionnement du NAS (ok tout va bien, mode dégradé engendré par la réparation d'un disque en cours ou NAS injoignable par utilisation d'une fonction watchdog), débit émission et reception, adresse IP attribué.

-> En fonction des températures relevés piloter les ventilateurs et/ou agir sur la climatisation, activer des informations lumineuses de type feu tricolore.

Ne sachant pas le faire directement sur la carte mère, je pensais confier ce monitoring à la framboise. Qu'en pensez-vous ?

De plus cela permettrait d'enregistrer les informations des capteurs dans une base de données de type MySQL, d'envoyer des alertes par Email ou par SMS......

Si tous les tutos que vous avez longuement expliqués me permettraient de commencer, je suis bloquer par la partie informatique relative aux disques, leur fonctionnement, détecter une erreur, taux occupation, signaler l'erreur, détection de leur mode de fonctionnement (erreur, reconstruction en cours...) De plus, est ce que le nombre d'afficheurs peut poser un problème à la framboise ?

Voilà en quelques lignes mon projet.

Merci @ tous pour votre aide et vos lumières.

Bonnes vacances

Christophe

Salut! Si je comprends bien, chaque baie du nas aurait son LCD attitré. C'est, théoriquement possible, mais très honêtement, ce sera long, couteux, et très pénible a débugger en cas de fil débranché. 10 LCD basiques, ça fait dejà près de 100€, sans compter les fils, les quelques puces qui seront forcément nécéssaires. De plus un LCD parallèle, c'est au moins 6 ou 6 fils, ce qui voudrait dire 60 fils pour les LCD, et ce sera probablement un sacré bordel à gérer!

Du coup, je te propose une autre idée : si au lieu de plein de petits LCD simples, tu prenais un LCD graphique un peu plus évolué, tu pourrais afficher les infos de tous les disques, leur présence, et même des petites icones pour signaler ceci ou celà.

Et pour conserver un affichage propre à chaque baie, une solution serait de mettre une led RGB sur chaque baie. Avec une led RGB, tu peux afficher facilement 7 couleurs, voire bien plus en gérant l'affichage en PWM. Mais partons sur 7 couleurs, ça fait déjà 7 messages possibles. Ensuite, on peut moduler, avec la led allumée en continu, un clignottement lent, ou un clignottement rapide. ça fait à ce moment 21 messages possibles!

Du coup il y a de quoi avoir un affichage 'volume absent', 'surchauffe du disque', 'erreur smart', 'tout va bien', etc... et ce pour chaque disque. Mais en plus, le LCD peut aussi afficher ces informations de manière textuelle. Un LCD graphique, ça vaut 20-25€, avec rétro-éclairage RGB. On peut du coup avoir un affichage sur fond vert en temps normal, ou rouge quand une erreur demande l'attention de l'utilisateur, jaune quand il y a juste un warning...

Pour l'aspect technique : le pi (ou même un Arduino, c'est aussi possible, et ça permettrait de faire une simple connexion en USB entre le NAS et le module d'affichage!) pourra parfaitement monitorer les températures, gerer l'alimentation électrique (avec un relais, on peut allumer/eteindre physiquement l'alim, et par exemple relancer un serveur planté et inaccessible), contrôler des ventilos de façon indépendante du NAS (donc ventiler même après l'arrêt du NAS si nécéssaire par ex). En revanche, les données sur le NAS lui même, qui proviennent des infos SMART du nas, le taux d'utilisation CPU et toutes les variables gérées par l'OS du NAS, ça ce n'est pas dirrectement possible, ou pas de façon simple. La solution, ce sera d'avoir le NAS qui envoie des informations (ou le module de monitoring qui les demande à un service sur le NAS) qui seront alors affichées, stockées, monitorées.

Entre Arduino et Raspberry pi, ici, le Arduino sera chouette pour l'aspect USB. EN se débrouillant bien, on peut programmer un gros module arduino gérant le LCD, les sondes et tout ce qui est nécéssaire, et se connectant en USB au NAS. Sur le NAS on développe un programme qui communique avec le module Arduino par USB pour envoyer ou recevoir des données quand/si nécéssaire. Du coup il faudrait juste installer le programme sur le NAS, brancher le bidule de monitoring, et hop, ce serait un peu comme un périphérique USB normal quoi.

Avec le raspberry pi, la communication sera un peu moins "simple", puisque ça ne sera pas de l'USB, mais par le réseau. Du coup,le module de monitoring ne serait pas un périphérique du NAS, mais une machine indépendante sur le réseau. Cela a certaines conséquences : les communications seront donc par réseau, du coup pas de réseau pas d'affichage des données smart (mais la température, etc, si), mais en revanche, la programmation des communications peut être plus simple par le réseau si on maitrise cet aspect. Le second gros avantage, c'est que le pi pourrait être une sorte de master node du nas, et donc commander son allumage/extinction, lui envoyer des commandes, et continuer à fonctionner même quand le NAS serait offline. Donc par exemple si le nas est eteint pour une raison quelconque, il serait possible de le rallumer par le réseau, sans avoir du wake on lan. De même, on pourrait envisager un nas en cluster, sur 2 machines. Avec le pi, le monitoring ne serait pas plus compliqué avec 10 machines qu'avec une seule. Bref, ça ouvre d'autres possibilités.

Maintenant, je dois dire que c'est un assez gros projet, il faut être conscient que ça prendra un certain temps ^^

ça m'intéresse beaucoup, car j'ai un projet proche (j'ai un NAS home made, avec un rhéobus dedans qui affiche la température des disques, et je me disais que j'aurais pu faire mieux avec un LCD), mais je n'ai pas du tout le temps de travailler dessus ces temps ci. Le mien serait plus petit (mon nas est en mini ITX, dans un boitier home made, avec maxi 7 emplacements de disques dans mon boitier, mais 6 sur la carte). Dans tous les cas, nos problématiques sont proches, car je voulais afficher d'abord les températures, la ventilation, et les trucs de base du même ordre, mais aussi l'occupation CPU, l'espace sur les disques, et des données SMART. Par contre je n'ai pas fait de Raid sur mon nas, donc je n'ai rien prévu là dessus :)

Dernier point : une idée sympa, c'est de rajouter des boutons en façade, et de permettre d'assigner des commandes à ces boutons. Dans mon cas, l'idée, c'était d'avoir un bouton sur le nas (j'ai trouvé de magnifiques boutons poussoirs en inox, avec une led intégrée) qui lancerait un rsync de mes fichiers de thèse entre mon laptop de boulot et le NAS, et la led du bouton qui s'allumerait tant que la sync ne serait pas finie :)

Mais en pratique, je pense que je finirai ma thèse avant de finir ce projet!

PS : désolé du délai de réponse, mais c'est justement du à la rédaction de ma thèse qui me prend un peu tout mon temps!

Bonjour, je reviens suite à la réception de mes différents composants.

J'ai reçu mon écran (25€ via amazon, parfait), il se connecte sur le +12V et ne s'allume qu'uniquement si il recoit un signal donc pas de prise de tête pour gerer l'allumage avec le RPI.

Pour le RPi justement, j'ai câbler le pin J6 pour le démarrer et relier le GPIO pour l’éteindre mais pas prévu de résistance pour l'interrupteur, je pensais que mettre le pin a la masse pouvais suffire mais non

Par contre la ou je suis pas sur de moi c'est concernant le code pour qu'il soit exécuter au démarrage.

Et autre question toute bete.

J'ai mon programme en JAVA qui sera "seul" à tourner, il y a t'il un moyen de lancer JAVA sans la partie graphique de Raspbian au démarrage ?

Merci.

Pour l'écran, tu peux quand même contrôler son alimentation via le pi, en utilisant un relais ou un transistor. ça évitera que le LCD ne consomme du courant pour rien quand le véhicule est éteint!

Pour le java, ça ne posera pas de problème, puisque tu peux parfaitement faire du java en command line. Du coup, tu peux avoir java sur ta machine sans serveur graphique. Et du coup il suffira de faire un script pour lancer le programme java au démarrage :)

Sinon, désolé mais je n'ai pas encore eu le temps de faire le tuto GPS!

Je crains malheureusement que ça risque d'être pour septembre au mieux!

[christophefrontignan]

Bonsoir Sky99,

Merci pour ta réponse. Je vois effectivement que nous avons un projet aux caractéristiques trés proches.

Je trouve ton idée d'un écran unique associé à des led excellente.

Pour ce qui est de l'aspect technique, c'est la solution autonome que je souhaiterais prévilégier. De cette manière, même le NAS éteint, je continue à avoir des infos, déclencher des actions et faire effectivement du Wake on Land. Bref le monitoring par un système distinct ouvre des possibilités très interressantes. Mais en contre partie, complique énormément, la collecte des informations techniques de type para-informatique (CPU, RAID, SMART.....).

Du coup peut être est il possible d'associer les 2 interfaces.

Je m'explique : utiliser pour le dialogue avec le NAS et la collecte des informations para-informatique une liaison USB et conserver une connection réseau avec la carte de monitoring. De cette manière, permet la mise ON ou OFF du NAS à distance ainsi que lors de son fonctionnement la collecte des infos hardware et fonction Watch dog, et lors des périodes d'extinction du NAS permets de continuer à collecter des infos comme températures des disques ou autre (et bien évidemment commander sa mise en marche à distance de type Wake on Land).

Je trouve également ton idée d'attribuer des tâches à des boutons en façade excellente.

Du coup, plus je réffléchie à mon/notre projets plus je me dis qu'il serait sympas de prévoir telle ou telle fonction. Et je me rends compte qu'en fait je vais avoir besoin d'un véritable ordinateur (mini-ordinateur ! ) pour monitorer un .... ordinateur !! Mais là ou tu as parfaitement raison c'est qu'effectivement une fois le système de monitoring réalisé, il devrait être capable de prendre en charge des systèmes NAS et autre serveur en cluster.

Mon gros problème c'est que si le montage, l'installation et le parametrage d'un NAS ne me pose absolument aucun soucis, le dialogue entre le NAS et la carte de monitoring me parait insurmontable. En d'autre terme, récupérer et exploiter les infos hardware du NAS ainsi qu'attribuer des tâches informatiques à des boutons en façades, je ne sais pas faire et je ne vois pas comment m'y prendre ! je n'ai aucune connaissance en programmation, mais je suis volontaire pour apprendre.

Si une ou des personnes pouvaient me donner des pistes de travaille et autres tuyaux dans ce domaine je lui en serait extrémement reconnaissant.

Pour ce projet j'ai pensé au PI et à l'arduinos. Mais je regarde aussi du côté de cubieboard qui m'a l'air d'être aussi prometteur. Naturellement et comme toujours, il va falloir au bout d'un moment faire un choix......

PS : pour l'écran pourquoi pas un mini écran tactile ? (ça va pas arranger mes affaires de programmation.... )

Merci @ tous.

[sky99]

Bonsoir Sky99,

Merci pour ta réponse. Je vois effectivement que nous avons un projet aux caractéristiques trés proches.

Je trouve ton idée d'un écran unique associé à des led excellente.

Pour ce qui est de l'aspect technique, c'est la solution autonome que je souhaiterais prévilégier. De cette manière, même le NAS éteint, je continue à avoir des infos, déclencher des actions et faire effectivement du Wake on Land. Bref le monitoring par un système distinct ouvre des possibilités très interressantes. Mais en contre partie, complique énormément, la collecte des informations techniques de type para-informatique (CPU, RAID, SMART.....).

Du coup peut être est il possible d'associer les 2 interfaces.

Je m'explique : utiliser pour le dialogue avec le NAS et la collecte des informations para-informatique une liaison USB et conserver une connection réseau avec la carte de monitoring. De cette manière, permet la mise ON ou OFF du NAS à distance ainsi que lors de son fonctionnement la collecte des infos hardware et fonction Watch dog, et lors des périodes d'extinction du NAS permets de continuer à collecter des infos comme températures des disques ou autre (et bien évidemment commander sa mise en marche à distance de type Wake on Land).

Je trouve également ton idée d'attribuer des tâches à des boutons en façade excellente.

Du coup, plus je réffléchie à mon/notre projets plus je me dis qu'il serait sympas de prévoir telle ou telle fonction. Et je me rends compte qu'en fait je vais avoir besoin d'un véritable ordinateur (mini-ordinateur ! ) pour monitorer un .... ordinateur !! Mais là ou tu as parfaitement raison c'est qu'effectivement une fois le système de monitoring réalisé, il devrait être capable de prendre en charge des systèmes NAS et autre serveur en cluster.

Mon gros problème c'est que si le montage, l'installation et le parametrage d'un NAS ne me pose absolument aucun soucis, le dialogue entre le NAS et la carte de monitoring me parait insurmontable. En d'autre terme, récupérer et exploiter les infos hardware du NAS ainsi qu'attribuer des tâches informatiques à des boutons en façades, je ne sais pas faire et je ne vois pas comment m'y prendre ! je n'ai aucune connaissance en programmation, mais je suis volontaire pour apprendre.

Si une ou des personnes pouvaient me donner des pistes de travaille et autres tuyaux dans ce domaine je lui en serait extrémement reconnaissant.

Pour ce projet j'ai pensé au PI et à l'arduinos. Mais je regarde aussi du côté de cubieboard qui m'a l'air d'être aussi prometteur. Naturellement et comme toujours, il va falloir au bout d'un moment faire un choix......

PS : pour l'écran pourquoi pas un mini écran tactile ? (ça va pas arranger mes affaires de programmation.... )

Merci @ tous.

Salut!

Bien entendu, si tu es prêt à investir en temps et sous, (après ça ne sera pas non plus hyper cher, par rapport au coût du NAS, mais bon peut être 60 a 100€),

tu peux en effet avoir la combinaison des deux, comme ça ça serait la combinaison de toutes les fonctionnalités sympa. Dans ce cas, une possibilité, ce serait d'avoir un petit module basé sur le pi, qui commande l'allumage des prises électriques si c'est une fonctionnalité souhaitée, et qui gère l'ensemble sur le réseau -mais ça peut en fait être n'importe quel ordinateur, et si la machine n'a pas de GPIO, ce n'est pas compliqué : un Arduino en USB permet de lui en ajouter!- , et un module type arduino ou autre, en USB sur chaque ordinateur à monitorer -donc chaque noeud du nas si plusieurs NAS, mais du coup c'est extensible aux autres pc à monitorer-, avec un LCD commandé par ce module, qui afficherait les infos locales du NAS/PC, tout en sachant que ces infos sont également centralisées/recueuillies par le pi/pc "master node".

Je dirais même qu'à la limite, ça permettrait de scinder le développement en module ce qui permettrait de faire morceau par morceau :)

Pour les fonctionnalités qu'il est possible de développer, en gros, je dirais qu'il n'y a pratiquement pas de limite. La seule chose, c'est que plus il y en a, plus ça prendra de temps. Donc mon conseil, ce serait de commencer simple, et de faire un développement "incrémental". En clair, au début par exemple, ça peut être de commencer

par mettre un Arduino avec un LCD quelconque dans le NAS (les 2*16 caractères coûtent 10€ environ, et 20€ pour les 4*20 avec rétro-éclairage RGB).

On rajoute quelques sondes de température, deux trois transistors, et hop, on peut déjà monitorer et afficher la température du NAS, et contrôler l'allumage/la vitesse

des ventilos.

Partant de là, il est possible d'afficher la vitesse de rotation des ventilos et les températures, mais également une alerte en cas de surchauffe. Et un écran LCD à rétro-éclairage RGB permet de contrôler précisément l'intensité de chaque couleur parmi le rouge, vert et le bleu, donc 255*255*255 couleurs en fin de compte. Avec ça, on

peut faire des signaux, par exemple le LCD est en vert quand tout va bien, en jaune quand il y a un warning affiché, en rouge quand il y a un problème, et clignotte rouge-jaune quand c'est un problème critique, genre plantage du NAS.

Ce petit projet, il est assez simple, en ayant des tutos, c'est l'affaire d'environ 1 après midi. Et c'est une bonne façon de commencer effectivement le projet :)

L'étape suivante, ça sera de faire un peu de programmation sur le NAS, pour faire des scripts qui récupèrent des données système. Ne serait ce que l'IP, l'occupation CPU, la ram libre, l'espace libre sur les disques. Partant de ces données, on peut faire un programme qui se charge de les collecter à intervalle régulier (réglable), avec un cron ou autre pour s'assurer qu'il soit toujours lancé sur le NAS, et qui envoie ces données par USB au Arduino. A ce moment, on revient à de la prog Arduino, et il s'agira de récupérer les données reçues par l'USB (c'est en fait une communication série, c'est très bien documenté sur le net, et cette communication est

bi-directionnelle, donc on peut aussi envoyer dans l'autre sens), et de gérer leur affichage sur le LCD. Et là il y a un petit travail à faire, car sur un 4x20, on a donc 4 lignes pour un certain nombre d'infos , et donc il faut réfléchir à ce qui doit être affiché, si on met un affichage changeant (c'est ce que j'ai fait sur mon pi, ou sur ma station météo Arduino), avec par exemple sur la ligne 1 les valeurs des sondes de température en alternance avec la vitesse des ventilos, sur la ligne 2 le taux d'occupation CPU en alternance avec la ram libre, sur la ligne 3 l'IP et le nombre d'users, et sur la ligne 4l'espace libre sur chaque disque qui défile.

Du coup ça fait déjà une première version de l'outil de monitoring. On peut alors l'améliorer, en ajoutant des boutons, et une petite interface permettant de configurer ce qu'on veut (affichage, couleur du LCD, vitesse de changement des infos, affichage de telle info en permanence sur une ligne, etc), et en développant d'autres scripts sur le NAS qui récupèrent l'état SMART de chaque disque, avec des infos du genre nombre se secteurs défectueux (en espérant voir 0 à chaque fois ^^), la durée d'activité, la température de la sonde interne du disque, etc. Mais également les infos sur le volume RAID pour pouvoir afficher "raid ok", ou "volume en reconstruction", etc.

A ce moment, on peut faire entrer en jeu le Raspberry Pi, et comme toutes ces données ont été collectées par les scripts, et sont envoyées au arduino-lcd, il est également assez simple de les envoyer par le réseau. Une solution hyper simple : un simple post http, avec un traitement des données par php. le post http

est ultra facile en python, et la récupération en php des données d'un post est tout aussi simple. Dans la version 2.0 de R.Cerda, mon robot Raspberry pi, on peut le commander par des simples post http, traités par le PHP, qui appelle les scripts "avancer, tourner, reculer". Et c'est l'affaire de 10 minutes à coder :)

A priori, sur le pi, le seul matériel, en dehors d'un afficheur pour afficher ce qu'on veut, ce serait des relais, si on veut pouvoir contrôler l'alimentation éléctrique 220V du NAS (et pourquoi pas, d'autres composants, par exemple un ventilateur de maison, braqué vers le NAS, qu'on peut allumer ou éteindre à volonté par le pi, ou automatiquement, ou n'importe quoi d'autre du même genre, par exemple, une fonction "couper l'alimentation du routeur, attendre 5s, puis remettre le courant du routeur", qui permettrait de faire un reset du routeur. Bien sur, on peut aussi ajouter tout plein de boutons, pour faire une interface et envoyer des commande au NAS, et pourquoi pas des LED pour afficher en un instant l'état des disques sur le pi également (rien n’empêche de le faire sur le pi ET sur le NAS, avec par exemple une option pour éteindre les LED et autres sur le pi, pour ne pas faire de lumière la nuit si il est dans une chambre. Petit truc possible aussi, on peut mesurer la conso électrique d'un appareil, avec un petit module a 10-20€, et obtenir cette valeur par une sortie analogique. Du coup on pourrait aussi monitorer la conso en ampères du NAS, et comme on connait la tension d'alim (230V), on calcule la puissance consommée facilement (P=U*I), et on peut faire toutes sortes d'applications avec ces données.

Bref, pour le pi, du développement réseau, gestion de l'affichage, centralisation et stockage des données, envoi des commandes et contrôle de quelques modules/capteurs si souhaité.

A noter toutefois que comme on a la collecte des données faite en script sur le NAS, on peut aussi bien décider de se passer du Arduino, et envoyer directement les données par le réseau au pi, et faire les affichages dessus. On peut également commencer par le développement du module raspberry pi puis laisser le Arduino pour après.

Mais du coup 3 phases :

-développent des scripts sur le NAS (du shell et du python, par exemple très facile avec python et hyper puissant. En C, ce sera nettement plus chiant, du fait qu'il faudra trouver comment accéder à diverses variable du système, utiliser une lib pour faire des requetes HTTP, et divers trucs du genre, alors qu'en python, on a en 10 lignes un bidule pour envoyer du http post et d'autres fonctions du genre)

-développement du module d'affichage Arduino, avec LCD, leds, et pourquoi pas boutons pour faire une interface

-développement du module central Raspberry pi.

Le point intéréssant c'est qu'en fait on peut faire les 3 phases un peu dans l'ordre qu'on veut (forcément, si le code sur le NAS n'est pas fait, il n'y aura pas des tonnes de données à afficher, mais on peut déja programmer l'interface et tout)

Sinon, pour l'écran tactile, c'est également une solution, et ça se trouve pour pas trop cher. Je n'ai pas encore essayé, car je n'en ai pas eu besoin jusqu'ici, mais c'est sur que ça augmente la complexité de programmation sur certains aspects, car il faudra du coup définir une GUI pour que l'on sache qu'un appui ici correspond à tel ou tel bouton. Mais c'est une idée :) Mon conseil toutefois, ça aurait été de commencer avec un LCD simple, genre LCD a caractères, quitte à upgrader après, et un LCD texte, c'est jamais perdu, ça pourra toujours servir à divers projets, sans être un investissement trop énorme :)

Pour ce qui est de comment faire du point de vue pratique, comme je le disais plus haut, une étape sera de collecter les données du système.

J'ai des scripts que j'ai faits pour récupérer l'IP de eth0, wlan0, l'uptime, et des trucs du genre. Une fois que tu as ces données, l'échange dépend de ce que tu veux faire : envoyer à un Arduino, ou envoyer à un raspberry pi.

Pour envoyer au pi, la solution que je préconise c'est le post HTTP. Encore une fois, j'ai du code fonctionnel, et qui plus est ça ne marche pas qu'avec le pi, mais n'importe quelle machine qui a un serveur HTTP et php d'installé (ou ASP, ou autre, de ton choix). La encore, j'ai des bouts de code.

Pour envoyer a l'Arduino, il faut utiliser les fonctions Serial. C'est bien documenté, et ça devrait être assez simple. Je le fais souvent dans le sens Arduino-PC, mais je ne l'ai jamais fait dans le sens PC->Arduino. Toutefois, normalement au lieu d'utiliser Serial.print("...................."); tu utilises Serial.read(); donc pas plus compliqué que ça.

Du coté du PC, j'ai fait un programme qui récupère les données d'une station météo commerciale, et ça passe par le port série. Donc en pratique exactement la même chose. Le programme est en C, donc j'utilise une lib pour gérer le protocole de communication de ma station météo, mais comme là tu développes le tout, c'est toi qui décides du protocole. Du coup ça simplifie grandement, tu enverra/recevra du texte, donc tu peux formater en XML, ou mettre des sortes de balises spécifiques. Je suis un grand fana du XML, mais sur la station météo que je construis sur une base Arduino, je communique par ondes radio 433Mhz, et je suis limité à 30 caractères par envoi. Du coup j'ai fait un petit protocole simple : "xy:valeur", ou x et y sont deux nombres/lettres qui identifient la donnée envoyee, et après les : on trouve la valeur associée. Donc comme tu n'es pas limité en taille, ça pourrait être plus détaillé genre donnée/commande:valeur/instructions, donc tu indique si tu envoie une variable, ou une commande, et ensuite la valeur de la variable, ou les paramètres de l'instruction.

Bref, ça se fait, et pour Arduino on trouve ENORMEMENT de doc, avec des bouts de code.

Pour les autres platformes de développent, en effet, il y a cubieboard, beaglebone, teensy et plein d'autres. Maintenant, je sais pourquoi je pourrais vouloir un teensy dans certains cas, plutot que telle ou telle autre solution, etc. Mais en gros, à moins d'en avoir besoin, je reste avec Arduino, car c'est quand même assez puissant, et surtout, c'est la plus populaire, donc on trouve des quantités astronomiques de ressources,d'exemples, de librairies, etc... C'est la meilleure solution pour débuter à mon sens, car on trouvera de l'aide facilement, des tas d'infos, hacks, etc. Il est de plus possible de fabriquer son Arduino facilement (j'en ai 2 "vrais" -Arduino UNO R3- et au moins une dizaine que j'ai fabriqués moi même avec une breadboard, la puce et quelques composants. Et j'ai deux adaptateurs USB-serie pour programmer ces arduinos que je fabrique :)

Pour le Raspberry pi, c'est un peu la même chose. En board programmable de dev linux, avec des GPIO, il y a mieux, mais plus cher, et moins connu. Pour le pi, il y a quantité de ressources disponibles, et si tu as un souci avec une pandaboard, je sais déja que je ne peux pas t'aider car je n'en ai pas :) Maintenant le Pi a certains défauts : en utilisation embarquée, il consomme trop à mon gout pour certaines applications (700mA, soit 3.5W pour le B, et 400mA soit 2W pour le A. ça peut parraitre peu, mais pour mes projets embarqués, avec Arduino j'arrive à avoir des consommations de l'ordre de quelques mA au plus, mettons 20mA en pleine charge, et je peux aller jusqu'à des µA avec la veille et autres. Donc pour une batterie donnée, je peux avoir une autonomie en mois, voir en années, contre quelques heures pour le pi),et dans certains cas, il manque de puissance, par exemple pour faire des calculs lourds (traitement d'image/vidéo en ne passant pas par le GPU).

Maintenant, dans ton cas, je pense que ça ne posera pas de problème, 2-3W par rapport à la conso du NAS, c'est moins qu'un disque dur, et la puissance est bien suffisante pour faire toutes sortes de monitoring :)

Dernier point, qui peut s'avérer intéréssant : tu peux intégrer des équipements réseau dans l'histoire. En achetant certains routeurs, tu peux virer le firmware proprio pour mettre dd-wrt, open-wrt,tomato, ou un autre firmware de routeur libre basé sur linux. Et bien souvent on peut accéder au port série du routeur. ça veut dire qu'il devient possible d'interfacer le routeur avec un Arduino/raspberry pi, pour pouvoir rajouter encore des fonctionnalités à volonté... Mais même sans passer par le port série, avec ces firmwares, tu as un linux sur lequel tu as l'accès root, donc tu peux programmer ce que tu veux. Du coup par ex, on peut imaginer un démon qui monitore le débit qui passe par chaque port du réseau pour pouvoir mesurer le trafic entrant/sortant sur le NAS, qui serait envoyé automatiquement au pi, par exemple. Ou alors, pouvoir, à distance, changer l'adresse LAN du NAS par une interface WEB, faire du VPN, bref, tout un tas de fonctionnalités amusantes :) Et pourquoi pas, du load balancing ! Bref, ça permet d'envisager une autre couche de fonctionnalités :) Et dans tous les cas, j'ai mis un firmware libre sur mon routeur (DIR-300 je crois, un simple 100mbits, mais il ne sert qu'à router le net. Mon NAS et mes machines sont sur un switch gigabit), et niveau admin, réservation d'adresse, statistiques et autres, c'est carrément mieux :) J'ai commandé un mini routeur/point d'accès sans fil compatible, pour pouvoir expérimenter dessus quand j'aurai le temps :)

Ah et aussi un truc : avec le pi, si y'a un serveur web, on peut facilement imaginer une interface web pour smartphone/tablette pour faire le monitoring/envoyer des commandes :) Et voire même une appli Android, c'est pas si dur à faire -mais bon c'est quand même du boulot, une appli Android, faut apprendre l'API, du coup une simple interface web, ou une appli qui charge du contenu web, c'est plus simple et plus rapide-!

En résumé, je te conseillerais de récupérer un Arduino, un LCD, quelques composants (des résistances, des boutons, et les capteurs de ton choix - tiens par exemple un capteur d'humidité pour vérifier les conditions de fonctionnement du NAS!-), et de te lancer. Commence par le plus simple, et tu verra que c'est bien plus facile que ça n'y parait. AU début c'est un peu intimidant, mais on apprend vite. En pratique, moi j'ai commencé tout ça en décembre 2012, donc il y a 8 mois. Maintenant j'ai fait plusieurs robots, des modules de mesure ultra basse conso, communications radio 433Mhz, monitoring de mon aquarium, contrôle d’éléments 220V, etc etc... Et je suis parti de 0. Je pense qu'en plus si tu as un objectif bien précis, tu progressera rapidement, contrairement à moi, car j'avais envie de tester tout plein de trucs dans tous les sens (robots, sans fil, capteurs, station météo, trucs solaires autonomes, etc).

L'idée c'est que si tu commences progressivement, tu apprendra à faire tel ou tel truc, ce qui te donnera des idées pour la suite. Et sur tout ton projet, je ne vois pas d'aspects qui me paraissent bloquants, ou je me dis "ça, je ne vois pas comment faire". Donc commence, et si tu as des problèmes, n'hésite pas a solliciter de l'aide ici ou par PM :) Et sur certains aspects je peux même te fournir des bouts de code.

Le plus dur, c'est de se lancer. Une fois les appréhensions passées, quand on a le matos en main, on teste, on cherche un peu, et ça avance tout seul :)

A bientôt :)

[christophefrontignan]

Bonsoir Sky99,

Merci pour toutes tes observations et conseils.

Je pense qu'effectivement il est temps de commencer. Mais j'avoue que n'ayant aucune connaissance en programmation et ce, dans quelque langage que ce soit, cela me fait peur....

Cependant, je vais me laisser encore quelques semaines histoire de poser et hiérarchiser les étapes ainsi que de faire le trie sur les fonctionnalités souhaitées.

Je pense que je devrais commencer les premiers essais fin septembre en fonction de mon apprentissage/découverte....

Je ne manquerai de partager mon aventure avec toi et avec vous tous.

Au fait j'aime beaucoup ton site/blog sur lequel on peu retrouver la plupart des constructions qui ont été abordées ici.

@ très bientot et bon courage pour ta thèse.

[mickey7]

Bonjour,

Tout d'abord merci pour les nombreux tutos: c'est vraiment enrichissant :)

Voilà, à mon tour je souhaiterais utiliser mon raspberry comme télécommande IR mais je n'ai aucune connaissance en électronique.

J'ai suivi le tuto et je suis arrivé à ce résultat (ne pas faire attention à la valeur de la résistance):

Pour info, le schéma du TSOP utilisé:

Quelqu'un pourrait-il me confirmer qu'il n'y a pas d'erreur?

Merci beaucoup :)

[xillibit]

Bonjour,

J'aurais voulu utiliser un ULN2803a pour contrôler un ruban LED RVB, sur la broche commune en entrée de l'ULN2803a je ne trouve nul part combien d’ampères maximum il peut supporter.

Le souci avec un ULN2803a c'est qu'on ne peut pas utiliser toutes les sorties en même temps à 500mA car sinon il a trop de chaleur à dissiper et il supporterait pas. Pour un ruban LED RVB d'un mètre ça va mais au-dessus, ce n'est pas possible.

[sky99]

Bonjour à tous! Je sais que j'ai déjà dit ça plusieurs fois, mais je reviens bientôt :)

Normalement ma soutenance de thèse est prévue pour le 9 décembre, donc après, je vais pouvoir recommencer à faire des trucs \o/

J'ai deux grosses boites en plastique de matériel à utiliser, et du coup plein de tutoriels à faire !

Alors à bientôt, et dans l'intervalle n'hésitez pas à poster vos trouvailles!

Salut à toute la communauté, et à bientôt!