bleugafoto

Des photos, et des restes. le blog de ecaheti.

Archive pour la catégorie ‘code’

« Articles plus anciens

Et on continue avec la suite de ceci.

Informatique

La partie logicielle est à mes yeux la plus large des trois. En effet, il y a mille et une manière de faire tout et n’importe quoi, et dans l’ensemble on peut faire et défaire tout comme on le souhaite. Entre les OS, les langages, les librairies, les algorithmes, les compétences et les préférences du développeur… Il y a autant de réponse à une question donnée qu’il y a de question !

Le système d’exploitation

Déjà, quel OS pour le Raspberry ? La question est vite réglé, malgré les diverses versions de GNU/Linux disponible : le choix est Raspbian, la version de Debian spécialement adapté au Pi. C’est la version la plus utilisée, et donc celle sur laquelle on a le plus de support. Ensuite, l’avantage de l’OS, c’est le fait de pouvoir lancer des process, rentre certaines taches automatiques simplement, la partie communication avec l’extérieur est simple (par exemple sauvegarder un fichier de log en local puis le synchroniser sur un répertoire partagé sur le réseau, c’est bête comme chou).

Langage de Programmation

Le Pi est, principalement, dédié à être utilisé avec des scripts en python. On trouve à ce titre des dizaines de trucs fait en python pour tout et n’importe quoi : piloter des GPIO, la caméra, faire des sauvegardes ou bien faire une interface console pour l’utilisateur. Mais parce qu’on a un OS Linux, on a aussi moyen d’utiliser n’importe quel langage. Et quand je parlais des préférences du développeur, c’est là que ça joue. Moi, le python… c’est pas trop ma tasse de thé, alors que le C, ça me branche vachement plus. Et je me débrouille mieux avec. Dans la mesure du possible donc, je tente de faire un maximum de chose en C, et d’utiliser d’autres options (script python tout prêt, Shell scripts, …) uniquement quand je n’ai pas le choix. Garder une certaine homogénéité me parait important pour pouvoir maintenir plus facilement l’ensemble du projet.

Accéder aux fonctions “spéciales” du Raspberry Pi

Sans rien autour de lui, le RPi est un ordinateur sous Linux, ni plus ni moins. Mais il dispose d’interface avec le monde extérieur qui nécessite un peu de boulot pour être exploités. La question se pose donc, dois-je développer moi-même mes propres fonctions pour y accéder ou existe-t-il des bibliothèques toutes faites pour me faciliter la vie ? Et ces bibliothèques valent-elles vraiment le coup ?

- GPIO

=> La fondation Raspberry a eu une bonne et une mauvaise idée. La bonne c’est de rapidement mettre à disposition des utilisateurs une librairie pour facilement utiliser toutes les fonctions des GPIO, que ça soit l’utilisation en mode brut (entrée/sortie numérique), ou bien l’utilisation des bus de communication disponible (I2C et SPI). La mauvaise, c’est que c’est en python. C’est là qu’intervient WiringPi, une librairie pour la gestion de GPIO en C. Pile poil ce que je voulais. Son auteur a le bon goût d’avoir rendu sa lib compatible avec le RPi B+ très rapidement.
J’ai procédé rapidement à quelques tests unitaires, pas de problème pour piloter les moteurs (utilisation des GPIOs), ni pour faire récupérer des données sur l’ADC (utilisation du bus SPI).

- Camera

=> Ici les choses se compliquent un peu. Je n’ai pas trouvé de librairies pour piloter la caméra directement. Ma principale expérience pour le moment est la réalisation d’un système de détection de mouvement, avec la caméra montée sur un moteur. Pour faire une simple capture, il faut taper une commande dans la console sous linux, dans laquelle on indique la résolution de sortie, le format, si on pivote l’image, si on applique un filtre, l’ISO, etc. C’est facile, mais la caméra met alors plus seconde pour faire une capture (indépendamment de la vitesse d’obturation). Pas terrible pour faire du suivi rapide d’objet en déplacement. L’astuce est alors lancé la capture en mode daemon (en lui précisant la taille, le format, etc.) et de lui envoyer par la suite un signal pour faire une capture. A ce moment, le cliché est instantané. Bref, c’est presque parfait, sauf que c’est en ligne de commande, et donc ça sent le Shell script. Première entorse à ma sacro-sainte homogénéité.
Capturer une image c’est bien, en faire quelque chose c’est mieux. Quand on parle traitement d’image sous Linux, il y a une bibliothèque qui vient rapidement à l’esprit, c’est OpenCV (Open Computer Vision). Elle dispose d’une myriade d’outils de traitement tout prêt pour faire tout et n’importe quoi avec vos images. Mais pour être honnête, c’est un mastodonte. Quand j’ai commencé mon détecteur de mouvement, j’ai eu envie de faire le traitement moi-même, histoire d’en apprendre un peu plus sur le traitement d’images. Au départ je voulais simplement comparer des images, mais de fils en aiguilles j’ai aussi implémenté la possibilité d’appliquer des filtres matriciels sur les images, calculer et afficher des histogrammes, ainsi que d’autre fonction simple comme de n’afficher que la luminance, ou bien une seul couleur en particulier. Bref, quand j’ai commencé à m’aventurer par-là, j’ai transformé mon soft de détection de mouvement en un sous-produit d’une librairie que j’ai appelé LLIPS (pour Light Library for Image ProcesS). Ça vaudrait un article à elle toute seule, mais je n’ai pas vraiment fini de la faire jolie avec les commentaires et la documentation qui va bien.
Pourquoi s’emmerder à faire une librairie qui existe déjà ? Simplement parce que je n’ai pas besoin de tout, et aussi parce que pour le coup, je peux adapter l’outil très rapidement. Pendant que je travaille sur le code RPi-kee, il m’arrive régulièrement de fignoler Llips, et de commiter à part les modifications.

- Généralité

=> Quand j’ai réalisé les premiers softs sur avec la caméra et le moteur, le cœur principal de mon programme était en Shell script (abordé un peu ici : ). Ce qui est bien avec les scripts c’est de pouvoir lancer des trucs en tache de fond. C’est très pratique car je peux lancer un mouvement moteur et faire autre chose pendant que ça tourne. De même, avec les traitements d’images, que ça soit des redimensionnements (que je faisais avec mogrify, vachement bien), des comparaisons, etc. Par contre j’ai un peu galéré pour la communication entre les différentes tâches. Ne serait-ce que pour lancer un chronomètre, je suis passé par un compteur écrit dans un fichier texte, qu’un programme écrit et qu’un autre relit. Bref, pas terrible.
Pour RPi-kee, j’ai rapidement compris que cette solution ne serait pas terrible, voir carrément à chier. De plus, si je m’amusais à coder un process pour faire des acquisitions, un autre pour les traiter, un autre pour faire du TCP et les transmettre, le coup des fichiers textes pour communiquer serait vraiment pourri. Il me restait donc deux solutions :
- La mémoire partagé entre les process, comme je l’avais fait il y a biiiieeeeeen longtemps à l’IUT
- Plusieurs tâches au sein d’un même process.
La deuxième solution m’attirait beaucoup plus, surtout que j’ai l’habitude d’utiliser un OS temps réel au boulot, et que je suis donc assez familier du sujet. J’ai donc déniché dans un coin la bibliothèque pthread !
Elle est disponible sous Linux nativement, et dispose également d’un port sous Windows, avec quelques restrictions mais qui n’impacte pas les fonctions de base. Ce port me permet donc de bosser également sous Windows. Pthread permet de définir fonction sous forme de thread tourne donc joyeusement en parallèle (dans la mesure du parallélisme tel qu’il existe dans un processeur de PC). Ce n’est pas une émulation ou une astuce du genre, quand on lance plusieurs threads on voit bien dans un gestionnaire de tâches le nombre de threads qu’on a lancé. Cela convient donc très bien à mes fonctions de pilotage moteur qui sont en fait une séquence ordonnée sur 4 GPIOs avec un délai entre chaque pas. Appeler la fonction “avancer” bloque donc ainsi l’exécution du programme. Avec un thread dédié par moteur, je peux donc lancer mes boucles en parallèle et faire autre chose en même temps. La possibilité de faire des threads change d’ailleurs grandement la façon d’implémenter une fonction. Si on prend l’exemple des acquisitions sur l’ADC; avec un seul thread, vous devez d’abord faire votre acquisition, qui vous prendra un temps T1, puis mettre en forme les données reçues, avec par exemple l’utiliser de look-up-table pour transformer la tension des capteurs IR en cm, traitement long d’une durée T2. Votre fonction prendra donc un temps T1+T2. Si vous travaillez maintenant avec des threads, vous synchronisez le début de la tâche “Calcul” avec la fin de votre première tâche “Acquisition”. Ainsi, lorsque la première acquisition sera finie, vous commencerez immédiatement la deuxième acquisition pendant que vous traiterez la première. Si T1 est plus grand que T2, votre fonction d’acquisition ne prendra plus qu’un temps T1. Si c’est T2 qui est plus grand, c’est le contraire (à quelques cas particuliers près qui se gèrent sans trop de difficulté).
S’il y en a deux qui suive au fond, ils n’auront pas manqué de noter que j’ai dit que je travaillais également sur l’OS de Microsoft. Et oui, c’est bien le cas.
Si j’ai réalisé plusieurs tests unitaires directement en développant sur le Raspberry Pi, à grand coup de putty et de WinSCP, quand j’ai commencé à créer le projet, j’ai préféré travailler avec un IDE. De plus, comme je développe ça sur mes heures perdues (dans le train, dans le salon sur mon portable, sur mon PC fixe, parfois même au boulot entre midi et deux), j’ai mis en place une compilation conditionnée à l’OS utilisé. Je fais donc la partie driver/bas niveau sur le Pi en SSH, et tout le haut niveau sur PC Windows. Evidemment je ne récupère pas toutes les valeurs analogiques et je ne peux pas utiliser WiringPi, mais cela me permet de faire les threads, le traitement d’image, la communication TCP et le contrôle commande de façon indépendante. Pour avoir les schémas électriques, les images de test et la doc technique, Google Drive est mon ami, et pour le code j’utilise un dépôt SVN … sous Github. Je leur dois au passage une reconnaissance éternelle d’avoir mis en place l’accès SVN à leurs dépôts ! En effet, je n’aime pas Git.

A l’heure actuelle, je n’ai pas encore terminé. La partie logicielle va être assez tordu à faire, avec toutes les tâches que j’ai prévu de faire, mais ça devrait m’occuper un bon moment. Il me reste également quelques soucis mécaniques à résoudre, et puis valider que les moteurs 12V peuvent faire leur boulot correctement. Au final, je suis quand même assez près de mon but, et j’espère pouvoir finir par avoir quelques choses de vraiment chouette. Dans les tâches annexes qu’il me reste à côté, j’aimerai également pouvoir utiliser un écran qui se plug directement sur le Raspberry Pi, histoire par exemple d’afficher en temps réel des infos sur le robot. Le problème étant surtout que l’écran utilise la même liaison SPI que l’ADC et qu’il y a de bonne chance qu’ils s’entre perturbent. Dans les à côté également, j’aimerai finir proprement Llips, histoire par exemple de le rendre multithread. Cela me permettrait surement de gagner encore un peu de temps de process, le cœur ARM11 du RPi n’étant un modèle de rapidité. Si j’avais VRAIMENT que ça à faire, il serait même probablement possible d’utiliser le GPU pour faire le boulot. Mais, du temps, c’est pas forcement ce dont je dispose le plus !

Et histoire d’illustrer un peu l’article parce que les images c’est cool, voilà le genre de traitement. On part d’une image avec une ligne (c’est un tapis ikea du meilleur goût), on cherche les zones de contraste, et on définit un certain nombre de point et de segment appartenant à cette zone de contrate.

On se servira ensuite des angles et positions pour définir la trajectoire du robot. Simple, non ?

Mon Raspberry Pi, c’est mon petit passe-temps quand j’en ai marre de bosser. Mais tout de même, je me rassure en me disant que quand je fais du développement sur le Pi, ça me fait découvrir des trucs divers et variés.
Pour le coup, je suis encore sur ma détection / suivi de mouvement utilisant la Camera Board. L’algorithme général est pas bien compliqué :

  1. Acquérir l’image n-2 et la convertir
  2. Acquérir l’image n-1 et la convertir
  3. Acquérir l’image n et la convertir
  4. Comparer les images n-2 et n-1
  5. Comparer les images n-1 et n
  6. Déduire des deux étapes précédentes s’il y a eu un mouvement
  7. Centrer la caméra vers le mouvement
  8. Sauvegarder les images pertinentes sur le réseau
  9. Renommer n-1 en n-2 et n en n-1
  10. Boucler à l’étape 3

L’étape 7 est faite avec un script en python, les étapes 4, 5 et 6 faites avec un soft en C, le reste, c’est du bash script. Le script générant des fichiers régulièrement, je le fais tourner dans un ramdisk histoire de ne pas pourrir ma flash.
L’idée, c’est d’optimiser un peu le concept. Première piste que j’ai suivi, c’est de lancer en arrière-plan les différentes copies et renommage de fichier lorsque que ça pouvait être fait (genre l’étape 8, mais pas la neuf). En bash c’est pas bien compliqué, suffit de rajouter un « & » à la fin de la ligne. De même, le lancement du script python pour faire pivoter la caméra, je me fous pas mal d’attendre que le mouvement ce termine.

Puis, je me suis mis en tête de mesurer le temps d’exécution du soft en C, qui pour rappel prends 3 images en entrée, et me sort 3 images en sortie (diff entre n-2 et n-1, diff entre n-2 et le mouvement résultant). J’ai pris le timestamp au démarrage du soft et à la fin, une différence entre les 2, un printf, un boucle réalisant 100 fois l’opération histoire de faire un peu de stat’.

Ayant développé l’appli sur un PC, j’ai donc eu comme première mesure moyenne 99ms pour réaliser l’opération (sur un Core i7 3520M @ 2,9GHz), que j’ai ensuite refait sur le Pi à partir de la flash, et j’ai eu 597ms de moyenne (sur un Raspberry Pi 256Mo @ 700MHz). Alors oui… ça fait beaucoup. Puis test en ramdisk, et j’ai eu la surprise de voir que le temps moyen, 624ms est plus élevé qu’en flash ! Je n’ai pas encore compris pourquoi, il faudra que je vois s’il n’y pas une merde dans ma config de ramdisk.

En étant bête et con, j’ai ensuite overclocké le Pi avec l’outil de config fourni avec (raspi-config) à 1GHz. Résultat en flash : 477ms, et en ramdisk 478ms. Conclusion partielle, avec un overclock de 43%, je gagne 23% de perf. Bon, c’est toujours ça de pris.

Enfin, un peu plus malin, j’ai testé de compiler mon soft avec l’option d’optimisation de GCC (gcc -Ox source.c -o mon_exe), qui propose 5 niveaux de vitesse et une optimisation en taille. J’ai gardé l’overclock par flemme de redémarrer le R-Pi, et j’ai fait tourner l’appli en flash. Les résultats oscillent entre 354ms et 328ms, respectivement pour l’optimisation en taille et l’optimisation de niveau trois (-O3).

Avec un overclock et une option en plus dans GCC, je suis donc passé de 597 à 328ms 45% de temps en moins. L’air de rien, c’est pas si mal et ne m’a demandé aucun effort intellectuel d’optimisation de code.

Résumé des différents essais :

Au final, j’ai surtout tenté d’améliorer le temps d’exécution de la comparaison d’image. Mais il y a d’autres points qui pourraient être abordé :

  • Pouvoir lancer des commandes en fond dans le shell script en étant sur que leurs résultats seront prêts quand j’en aurai besoin
  • La comparaison d’image se fait en comparant les images pixels par pixels et couleur par couleurs (une boucle « for » avec 3 comparaisons dedans). Bien que le Rpi soit mono-coeur, peut être qu’on pourrait tenter de paralléliser ces comparaisons, ou bien de ne faire qu’une seule couleur
  • Vérifier que la partie « conversion d’image » est optimal. Pour le moment, je fais une capture en JPG, convertie ensuite et redimensionner en bmp (avec un rapport x16 entre les deux, permettant de créer la miniature bmp en sous échantillonnant les pixels de l’image capturé)

Et pour terminer, vérifier régulièrement que le truc marche encore après toutes ces bidouilles !

Hop la, le retour du blog ! Dans les épisodes précédents, j’avais expliqué comment mettre en place un serveur de téléchargement. Depuis j’ai un peu changer/améliorer l’installation, d’abord d’un point de vue hardware :

  • Changement du système de fichier du disque “NAS” (ça a l’air de rien, mais ça a ses petites conséquences) sur le Raspberry Pi (que l’on appellera RpiWeb, qui contient les fonctions évoquer dans l’article précédent, à savoir serveur Web, NAS, Seedbox)
  • Installation d’un deuxième Raspberry Pi (que l’on appellera RpiAcq) contenant notamment deux sondes de températures DS18B20 et une Camera Board)
  • Suite à mon récent déménagement j’ai également changé de box Internet, et l’air de rien ça a des conséquences également.
  • Également sur RpiAcq, j’ai installé tout récemment un moteur pas-à-pas (stepper motor outre-manche)

Travaux sur la box

Bon, l’air de rien, ça fait pas mal de choses nouvelles à gérer. Déjà, la box internet. Avant, je routais sagement le port 80 du Rpi sur le port 80 de la Freebox. Mais ça, c’était avant. Maintenant j’ai une BBox (pas Sensation, mais alors pas du tout) que c’est un peu de la merde, pour 2 choses un peu essentiel. Déjà, quand je route le 80 du Pi vers le 80 de la box, ça m’affiche … le port 80 de la box. Ok, je me retrouve donc avec l’interface de config de la box accessible par le monde entier, super safe, et pas vachement pratique pour auto-héberger son p’tit site. Mais bon, j’ai changé le port externe et j’arrive à accéder à mon site sur un autre port, mais ça fait con, et en plus y a que le port 80 qui passe au boulot. Autre incommodité, impossible de se connecter “de l’intérieur” sur le site via l’adresse externe. Problème que je n’avais pas avec la Freebox. Contournement, un favori “RpiWeb interne” et un “RpiWeb externe”. Typiquement le genre de tracasserie qui en soit n’est pas grave mais qui put l’amateurisme. Mais bon, c’est le prix d’un Youtube réactif….

Travaux sur RpiWeb

Bref, concernant le RpiWeb, j’ai également changé le disque du NAS, par un modèle plus gros de récup et formater en ext au lieu de NTFS. L’installation a grandement gagné en stabilité, et si j’avais parfois le disque NTFS qui se déconnectait/démontait tout seul, plus aucun soucis maintenant… à part qu’il a faut maintenant que je gère précisément les droits d’accès, ce qui est parfois un peu pénible, gérer mon utilisateur moi-même, mon guest pour le partage réseau, et le serveur Web qui écrit des choses à droite à gauche.

J’avais également des déconnexions réseaux/wifi, et j’ai donc dégagé le dongle USB par un boitier CPL, le Netgear XAVT5602, qui a le bon gout d’être vendu par 3, et de disposer de 2 port Ethernet sur chaque boitier. Ceci me permet de simplifier la config Internet du Rpi, et de faire un p’tit hub Ethernet local.
J’ai rajouté pas mal de script shell pour automatiser pas mal de tâche propre à ce serveur, genre :

  • Faire un backup régulier du répertoire home et web
  • Scanner tout le sous réseau local pour afficher ensuite les machines présentes, et loguer les heures de présence
  • En fonction du script précédent, détecter certaines machines particulières (mon téléphone est-il connecté ? Le RpiAcq ?)
  • Vérifier l’adresse externe de la box et uploader sur un site une redirection vers cette adresse (pour ne pas avoir à me souvenir de l’IP externe de la box quand je me connecte à partir d’une machine qui n’est pas à moi). J’avais expliqué dans mon article précédent pourquoi je faisais ça et pourquoi je ne voulais pas passer par noip ou dyndns

Dernier point, depuis le passage en ext, mon script perl permettant de faire du téléchargement direct fonctionne de façon erratique. Je l’ai donc remplacé par une page en PHP de mon cru. Soit, je perds certaines fonctionnalités genre le téléchargement de plusieurs fichiers en parallèle, mais pour ce que je m’en sers ça colle très bien à mon usage.

Capteur de température sur RpiAcq

Bon, on va être honnête, c’est clairement ce qui m’a le plus amusé. Ayant déménagé d’une maison avec une chaudière à gaz avec thermostat à un appartement chauffé au grille-pain électrique, je me suis dit que faire le thermostat moi-même pourrait être chouette. Direction learn.adafruit.com, le site de la bidouille par excellence, bien documenté, avec des liens vers les différents composants dans leur boutique pour que ton côté geek compulsif puisse s’exprimer dans une réalisation électronique facile mais au combien gratifiante. Le site n’est pas le moins cher, mais il est bien foutu, et on trouve tout, tout de suite. J’ai donc acheté une plaquette d’essai, des câbles, un déport de connexion pour le port d’extension du Rpi, et une sonde DS18B20.

Pour info, cette sonde n’est pas un “bête” capteur de température, mais une sonde “intelligente” qui intègre un contrôleur OneWire, un protocole utilisé en domotique pour récupérer facilement les informations des capteurs/actionneurs d’une installation. Ce protocole n’est pas géré en tant que tel sur le Rpi, mais le noyau Linux permet de faire du bit banging imitant le codage/décodage du OneWire. Bon, en gros, une fois le câblage fini, c’est super fastoche à utiliser. Vous chargez 2 modules dans le noyau de l’OS (ça fait style je m’y connais, de dire ça, mais si vous préférez, c’est 2 commandes à recopier dans un terminal), vous faites un cat d’un certain fichier et zou c’est plié, la température du capteur s’affiche en millidegré.

Soyons honnête de suite, d’un point de vue hardware je me suis arrêté là. J’ai acheté 2 capteurs pisse que j’habite un 2 pièces, mais pour le moment ils sont montés l’un à côté de l’autre. Je voulais aussi pouvoir piloter mes radiateurs, mais ils sont alimentés directement par un câble qui sort du mur, donc comme je n’ai pas envie de tenter de détériorer l’installation, je me suis arrêté là… niveau hardware. Parce que pour le soft, c’est autre chose !
Oui, je me suis dit que j’avais un site web sur un Rpi, un relevé de température sur l’autre, il ne me manquait pas grand-chose pour lier les deux. D’un point de vue générale je me suis fixé la contrainte suivante : ne rien stocker sur RpiAcq. J’ai donc développé un bout de soft pour :

  • Faire une requête de température
  • Aller chercher les températures (les deux sondes ainsi que la température du CPU du RpiAcq
  • Stocker la température

Je suis parti sur un modèle UDP avec socket non bloquante afin d’éviter qu’une mesure de température qui part en couille ne bloque le système. Au départ je stockais le résultat dans un fichier texte toutes les heures, mais après quelques centaines de relevés, je me suis orienté vers une base de données sqlite3 pour pouvoir traiter plus facilement l’affichage des données sur le site web. Au final ça marche bien, et c’est cool, même si un peu inutile (enfin si, j’ai pu me rendre compte qu’en coupant complètement le chauffage par grand froid en mon absence, mon appart descendait sous les 12°C).
A faire : J’ai les deux sondes dans mon salon, faudrait que j’en place une dans la chambre histoire que ça serve un peu plus. En théorie en tirant un seul câble c’est jouable, le OneWire étant fait pour. Et aussi tenter de piloter les radiateurs, je ne sais pas trop comment.

CameraPi sur RpiAcq

Quel achat compulsif cette caméra ! C’est fourni comme le Raspberry, un pauvre PCB, et puis c’est tout. J’ai donc acheté en plus de la camera un petit support en plastique permettant en outre de placer la caméra sur un pied photo. L’avantage de la CameraPi, c’est qu’étant la webcam officielle de la fondation Raspberry Pi, son utilisation est super facile et documentée clairement. Le plus “dur” c’est de la brancher, et c’est pas bien compliqué. Moi mon challenge, c’est comme pour les sondes de températures, c’est de récupérer l’image sur RpiWeb !
Qu’à cela ne tienne, je me suis attelé au développement d’un outil pour transférer l’image de RpiAcq vers RpiWeb. Alors vous me direz… mais pourquoi faire un outil quand il existe déjà des trucs pour faire le taf (Samba, FTP, NFS, voir même ssh ou http). Et bien parce que je voulais un truc TRES simple d’utilisation. Et pour la beauté du dev, aussi. Hop, c’est reparti pour un client/server, mais en TCP cette fois. Principe identique à la température, avec en plus de la gestion de fichier :

  • Faire une requête de transfert de fichier
  • Faire une requête de capture d’image
  • Répondre en envoyant la taille de l’image
  • Transférer l’image p’tit bout par p’tit bout (rappel : un trame TCP c’est 1,5ko max…)
  • Reconstruire le fichier côté RpiWeb

Votre vif esprit aura remarqué que je fais d’abord une requête de transfert de fichier, puis d’image. Le client/serveur que j’ai développé permet en plus de prendre une photo de transférer n’importe quel fichier, histoire que je puisse le réutiliser pour récupérer d’autres trucs. Ça peut être utile…
Une fois l’image récupérée, elle est archivé sur le NAS. Via les crontab, la capture se fait tous les quarts d’heures. Et là vous me direz, mais… il finira par passer à poil devant la caméra ! Et bien non, car si mon téléphone est présent sur le réseau, l’archivage est automatiquement désactivé. J’ai donc une liste d’adresse MAC qui, si elles sont détectées sur le réseau, désactive la prise automatique de photos. Niveau utilité, j’ai donc pu constater que les ouvriers qui devaient venir pendant mon absence n’ont pas trop fait de la merde, et je peux prendre des photos du chat qui glande sur le canapé.

Moteur pas-à-pas sur RpiAcq

Dernier raffinement, rendre la camera orientable. Retour sur Adafruit.com pour trouver de quoi faire. J’ai trouvé des exemples de moteur CC, de servo moteur, et donc de pas-à-pas. J’ai choisi ce dernier pour une raison simple, son utilisation reste dans l’enveloppe énergétique du Rpi. En gros, l’alimentation 5v suffit. Comme d’habitude, le tutoriel sur Adafruit est simple comme tout. J’ai acheté le moteur et une plaquette de test plus grand pour pouvoir bosser proprement et garder mes sondes de températures. Au passage j’ai pris un boitier de protection.

Mon seul regret ici, c’est que je n’ai pas réussi à piloter le moteur avec un soft en C. Ah oui, j’oubliais de le dire, dans les contraintes que je me fixe, j’essaie de ne pas m’éparpiller niveau langage de développement. J’évite donc soigneusement le python parce que je n’aime pas ça, et pour le moment, je fais du C, du shell script, du html/PHP et un poil de SQL. Mais ici j’étais si près de finir que j’ai eu la flemme de chercher pourquoi mon soft en C ne fonctionnait pas. Les fonctions de base pour piloter le moteur sont donc en python.

Pour pouvoir piloter le moteur via RpiWeb, j’ai mis à jour le client TCP du transfert d’image pour qu’il soit possible de demander soit un fichier à transférer, soit la prise de photo, soit un mouvement à gauche/droite.
Dernier raffinement, un petit montage avec des Meccano pour fixer la caméra sur l’arbre. Pour que ça soit tip top moumoute faudra rajouter un axe de rotation verticale avec un deuxième moteur, un pointeur laser, une coque blanche ovoïdale et un haut-parleur qui balancerait des “Where are you ?”, “Are you still there ?” et autre “I don’t hate you” de façon aléatoire.

Et pour le fun, une petite vidéo :
YouTube Preview Image

Si un sujet vous intéresse, n’hésitez pas à poser des questions, je suis ouvert !

Plusieurs semaines après avoir reçu mon Raspberry Pi, je lui ai enfin trouvé une fonction intéressante, qui marche, et qui s’est bien adapté à mon installation informatique domestique (en gros, je n’ai rien pourri, du moins pas à ma connaissance).

Le but

L’objectif vite fait que je m’étais fixé, c’est un serveur de téléchargement. L’idée c’était de pouvoir lancer des torrents à distance pour récupérer d’obscure distribution linux ou bien encore faire bénéficier la terre entière d’une source supplémentaire pour Warsow 1.0. Oui, je suis un geek altruiste. Également à mon cahier des charges, pouvoir lancer des téléchargements directs, en passant par une interface web. En effet, si un coup de ssh + wget fait l’affaire, d’un point de vue commodité d’utilisation ce n’est pas top, surtout quand les ports différents du 80 sont bloqués au boulot. Et par dessus le marché, se débrouiller pour que cela soit accessible un peu tout le temps malgré l’IP dynamique de ma box.

Préambule

Je ne sortirais pas un pack de binaire pour faire le taf, car j’ai utilisé plein de brique différente pour remplir chaque tâche fixée, entre ce qui se télécharge, ce qui se configure sur la box, les bouts de code php, les configs de serveur web et les scripts linux, il y a un peu trop de bazars pour “faire un pack”. Certains passages peuvent être délicat, surtout si on connait que pouic à Linux et à Debian. De plus, je considère certain point comme acquis de base, genre l’installation de l’OS sur le R-Pi.

Tout ce qui est décrit est surtout inhérent à Debian et à Linux plutôt qu’au R-Pi lui-même, si vous avez un PC qui traine dans un coin et que vous voulez faire la même utilisation c’est très possible. Sauf qu’il y aura des moyens probablement plus simples, voir meilleurs. Typiquement, j’aurai pu installer Java puis JDownloader, et en terme de fonctionnalité j’avais déjà presque tout le boulot de fait. Sauf que JDownloader c’est vachement trop lourd pour le Raspberry, et surtout c’est pas terrible pour la partie ligne de commande (certaines fonctions ont refusé de se lancer parce qu’aucun serveur X ne tournait). Et sur un ARM11@700MHz avec 256Mo, le serveur X est utilisable, mais si on peut se passer de le faire tourner c’est pas plus mal, surtout sans écran…

Matériel

  • Un Raspberry Pi, évidement
  • Un chargeur 5V/850mA de téléphone avec son câble micro-USB
  • Un carte SD de 4go (classe 4 à la limite, classe 6 ou plus préférée)
  • Un disque dur USB (fabriqué avec un boitier Antec fanless et un disque sata dedans)
  • Un dongle USB Wifi - DLink DWA131, reconnue sans problème par l’OS.

Pourquoi me galérer avec du Wifi puisque j’ai de l’Ethernet à bord ? Et bien parce que ma box est dans mon salon, et que pour des besoins d’esthétique de ce dernier j’ai décidé de ne pas y coller mon serveur en kit. Etant donné que le R-Pi est proche de mon PC, j’ai donc câblé l’Ethernet entre les deux. Comme ça, j’ai une connexion directe au serveur en cas de besoin…

A noter au passage que j’ai également intercalé un hub USB avec alimentation externe afin d’éviter que la clé Wifi ne tire trop de courant du Raspberry. Je vous passe les détails électriques, mais ce n’est pas forcément une bonne idée de faire consommer de l’élec sur un si petit appareil.

Au final, j’ai quand même 3 prises de courant d’utilisée… C’est sur qu’on est moins sur un modèle de discrétion qu’un Raspberry tout seul, mais bon, au pire je fabriquerais une alim unique en partant de celle du disque dur externe, mais on verra plus tard.

Logiciels

Comme je le disais, c’est un amas de brique disponible sur le net, de fonction de l’OS, et deux trois configurations et scripts maison. Voilà dans l’ordre ou je l’ai fait les grandes étapes de réalisation. Tiens au passage, j’en profite pour citer un outil Windows sympa: HDDRawCopy 1.02. Je m’en sers pour faire des copy brut de la carte SD avant de tenter des trucs à la con pour pouvoir revenir à un état précédant en cas de besoin.

Bon, zou, on y va.

Installer l’OS

Soyons honnête, celui-là, vous le faites tous seul. D’ailleurs on peut voir ça comme un test d’admission. Si vous n’y arrivez pas, vendez vendre Raspberry Pi sur internet, vous en tirerez plus de satisfaction. Sinon, vous avez le Beginners Guide sur elinux.org, et surtout quand même dans la version Wheezy, la commande raspi-config qui permet de tout bien faire joli sans se fatiguer, et qui de surcroit se lance automatique au premier démarrage de l’OS. Profitez en pour utiliser la fonction qui permet d’assigner un maximum de RAM au CPU au détriment du GPU, complètement inutile dans notre application. Et tant qu’à faire changez le mot de passe de l’utilisateur de base… (protip hacking : le login/mdp par défaut, c’est pi/raspberry. Si vous tentez de vous connecter malicieusement au R-Pi de quelqu’un, commencez par testez ça.)

Configurer la partie réseau

Phase assez importante puisqu’une fois réalisé, votre Pi va enfin pouvoir devenir indépendant de son écran. Commencez par vérifier que votre dongle Wifi est reconnu (ne le cherchez pas si vous n’en avez pas…) avec un lsusb :

moi@tarte ~ $ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 005: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge
Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 007: ID 07d1:3303 D-Link System DWA-131 802.11n Wireless N Nano Adapter(rev.A1) [Realtek RTL8192SU]

On voit dans le bordel un machin D-Link, c’est que ça doit être bon. Vérifiez maintenant que vos deux interfaces réseaux apparaissent quand vous taper ifconfig. Vous devriez voir lo, eth0 et wlan0. Si vous n’utilisez qu’une connexion Ethernet et que vous avez connecté votre R-Pi à votre box, sa config réseau doit être bonne et un ping www.google.fr vous confirmera que votre Pi est connecté au monde. Sinon, un petit
moi@tarte ~ $ sudo nano /etc/network/interfaces
vous donnera accès au fichier de config des interfaces réseaux. Voici la mienne, avec la partie wifi avec clé wep en DHCP, et la partie Ethernet en IP fixe.
auto lo
iface lo inet loopback
auto wlan0
iface wlan0 inet dhcp
wireless-mode managed
wireless-essid mon_reseau
wireless-key ###CLE_WEP###
iface eth0 inet static
address 192.168.137.85
netmask 255.255.255.0

Le contenu du fichier tel que je l’utilise vous permet d’avoir une connexion wifi en DHCP sur votre réseau ultra protégé par clé Wep (je vous laisse l’ami Google pour les autres types de clé de chiffrement bien plus sécurisée) pour la partie Web, ainsi qu’une connexion “de backup” directement branché en ethernet sur votre PC. Il conviendra bien évidement d’utiliser une adresse IP sur le même sous-réseau sur le PC.

Connexion d’un disque dur USB

Je ne l’ai pas précisé, mais un boitier disposant de sa propre source d’alimentation est préférable, voir indispensable. Je vous parlais de l’alim du dongle wifi qui était limite, c’est encore plus critique avec un disque dur, nettement plus gourmand. Pour connecter un disque dur sous Linux, il faut le “monter” dans l’arborescence. En gros dire à l’OS “Quand tu détectes tel périphérique, affiche son contenu à tel endroit, de tel façon, avec tel droit”. Quand vous êtes sur la ligne de commande uniquement, il faudra taper la commande adequat une fois le disque dur connecté. Si vous avez lancé l’interface graphique LXDE, il se montera tout seul avec des paramètres génériques plutôt pas mal. J’ai donc profité de ce montage automatique pour recopier les paramètres et les mettre dans le fichier /etc/fstab afin d’avoir un montage automatique du disque dès le démarrage de l’OS.
Je récapitule :

  • Allez dans LXDE avec un startx.
  • Branchez le disque.
  • Récupérez les paramètres actuellement utilisé en tapant mount
  • Débranchez le disque
  • Créez le répertoire de montage la où bon vous semble (chez moi mkdir /media/disque_ext)
  • Editez le fichier fstab pour rajouter la ligne

/dev/sda1 /media/disque_ext auto rw,nosuid,nodev,allow_other,default_permissions 0 0

  • Dans la ligne de commande, tapez sudo mount -a pour monter tout ce qui est décrit dans fstab.

Voilà, vous avez normalement à présent un système qui monte son disque tout seul au démarrage et qui se connecte à l’Internet mondial. Et dès fois que votre box explose, vous gardez un accès via Ethernet.

Partager le contenu du disque

Bon, je ne vous le cache pas, c’est une partie qui m’a un peu fait chier. Si l’installation de base de samba (l’outil Linux qui permet de partager des fichiers “façon partage de fichiers Windows”) est très simple comme n’importe quelle installation sous linux, sa configuration est toujours un peu hasardeuse à mon gout. Mais au moins, on contrôle TRES finement le moindre droit d’accès.
Premier truc, installer samba :
sudo apt-get install samba
Ensuite viens la partie la plus marrante, celle où on va remercie Google d’exister, l’édition du fichier de configuration. Mon but à moi était d’avoir un repertoire publique, accessible par n’importe quel utilisateur de mon réseau, sans login ni mot de passe. Les plus “power user” d’entre vous voudront peut être également des répertoires par utilisateur, mais dans mon cas, le seul répertoire qui m’intéresse est celui dans lequel vont attérir tout les téléchargements lancés via torrent ou via direct download.
Le fichier de configuration de samba est le suivant : /etc/samba/smb.conf. Avant de tout pourrir parce que vous risquez de faire quelques essais à taton avant d’obtenir la bonne solution, faites une petite copie du fichier.
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.original
Ensuite, pour l’éditer :
sudo nano /etc/samba/smb.conf
Dans mon fichier, j’ai modifié le droit d’accès général (section ####### Authentication #######), qui est passé de
#security = user
à
security = share
J’ai également rajouter
map to guest = bad user
guest account = nobody

Et enfin j’ai inséré à la fin le bloc
[Partage]
comment = Public Storage
path = /media/disque_ext/
read only = no
public = yes
browseable = yes
guest ok = Yes
create mode = 777
directory mode = 777

pour désigner mon répertoire de partage. J’ai également changé les droits d’accès, de façon un peu brutale il est vrai, à mon disque externe. En effet, vous avez beau avoir le droit de passer l’étage d’authentification samba avec votre PC, ça n’octroit pas forcement le droit d’accéder à tout les répertoires du serveur. Un chmod sur le repertoire /media/disque_ext devrait faire l’affaire.
Dernière étape, à faire à chaque modification de /etc/samba/smb.conf, relancez le serveur samba :
sudo /etc/init.d/samba restart
Félicitation, si tout marche bien, vous avez un NAS. A noter au passage que votre R-Pi devrait apparaitre dans l’explorateur de réseau de Windows, mais la règle qui décide par quelle interface réseau vous y accédez m’est complètement inconnue. En effet, vous pouvez utilisez soit votre carte Wifi, qui étant connecté au même réseau que le serveur permet de s’y connecter, soit votre carte Ethernet. Le meilleur moyen que j’ai trouvé pour forcer Windows à utiliser une carte ou l’autre est d’entrer directement l’adresse IP correspondant à l’interface voulue dans la barre d’adresse de l’explorateur (ou via le menu “Executer”). Ainsi, en passant par \\192.168.137.85, vous utilisez l’IP que vous avez configurée pour Ethernet, et donc vous bénéficierez d’un débit nettement meilleur pour lire et écrire sur votre serveur. Tant qu’à automatiser les choses, j’ai créé dans Windows un disque réseau lié directement à mon repertoire de partage, m’évitant donc de me poser la question quand je veux récupérer mon DVD d’install de Ubuntu de 6Go.

Installer Transmission

Transmission est un client torrent un peu connu, à tel point que c’est celui fourni avec les distributions Ubuntu et leurs dérivées (LinuxMint, par exemple). Pour l’installation, comme d’hab c’est assez simple, il faut juste savoir que c’est le paquet transmission-remote et pas transmission tout court qui vous intéresse. Transmission-remote contient juste ce qu’il faut pour utiliser le client avec une interface web ou bien la ligne de commande. C’est le premier cas qui nous intéresse.
Ensuite vient la config de transmission, et cela se fait par le fichier /var/lib/transmission-daemon/info/settings.json
Il convient de modifier plusieurs choses, du genre :
accès par l’importe à partir de n’importe quelle adresse source : "rpc-whitelist": "127.0.0.1,*.*.*.*",
Nom de l’utilisateur : "rpc-username": "moi",
Mot de passe : "rpc-password": "les-fps-c-lol",
NB: cette ligne sera crypté au prochain restart du service
Port de connexion : "rpc-port": 1234,
Emplacement de téléchargement : "download-dir": "/media/disque_ext/",
Dernière étape, on redémarre le service pour prendre en compte les modifs
sudo service transmission-daemon start

Voilà, vous pourrez donc vous connectez à votre interface en allant sur http://server_ip:1234, en utilisant soit l’adresse du Wifi, soit celle de l’Ethernet.

L’interface web permet déjà quelques réglages sans avoir à toucher à settings.json, mais au besoin vous pourrez paramétrer un peu plus finement votre serveur en tapant dans le fichier.

Installer Lighttpd et PHP pour la suite

Alors non, mon but n’était pas d’hebergé un serveur web avec mon CV et mon blog, parce que 1) je ne cherche pas de taf, et j’ai déjà un blog que vous êtes dessus. Mais pour gérer les téléchargements directs, je n’ai trouvé que wget4web, qui est un ensemble de scripts CGI en Perl qui fonctionnent donc à partir d’une page web. Et pour le PHP, c’est que j’avais besoin d’information pour certain lien que seul PHP pouvait me fournir. Mais on verra cela dans les parties suivantes.

L’installation de Lighttpd est relativement conne, et c’est encore une fois la config qui s’avère plus délicate.
Pour l’installer, one more again :
sudo apt-get install lighttpd
Puis les extensions PHP
sudo apt-get install php5-common php5-cgi php5
Activation de l’extension PHP
sudo lighty-enable-mod fastcgi-php
Activation de l’extension CGI
sudo lighty-enable-mod cgi

L’activation de CGI va créer un fichier /etc/lighttpd/conf-enabled/10-cgi.conf, que vous modifierez de la façon suivante

$HTTP["url"] =~ “^/cgi-bin/” {
cgi.assign = (
“.cgi” => “/usr/bin/perl”,
)
}

pour spécifier à votre serveur quels binaires il devra utiliser lors d’un accès à un fichier .cgi .

On termine par dire serveur web de prendre en compte la nouvelle config
sudo service lighttpd force-reload

D’un point de vue facilité d’utilisation, il est pratique d’autoriser votre utilisateur linux du R-Pi à utiliser facilement le dossier /var/www/ dans lequel se trouve vos pages (genre éviter de faire des sudo à foison pour mettre des fichiers dans le repertoire).

Changez le propriétaire du dossier pour assigner le groupe www-data
sudo chown www-data:www-data /var/www
Donnez le droit d’écriture au groupe
sudo chmod 775 /var/www
Ajoutez votre utilisateur (”moi”) au groupe
sudo usermod -a -G www-data moi

Vous avez maintenant un serveur web capable d’executer des scripts en Perl et du PHP, et vous pouvez donc monter un site web 1.0 accessible à http://server_ip, en mettant vos pages dans /var/www/ .

Installer et configurer wget4web

On arrive à un point qui n’est plus très compliqué. Télécharger à la main (oui, des fois ça arrive!) l’archive contenant wget4web dans votre /var/www, en créant un répertoire cgi-bin au préalable.

cd /var/www
mkdir cgi-bin
cd cgi-bin
wget http://exir.ru/wget4web/wget4web-1.0.tar.gz

Et décompresser là directement dedans
tar xzf wget4web-1.0.tar.gz

Il vous faudra ensuite modifier /var/www/cgi-bin/wget4web/data/info.cgi dans lequel se trouve les emplacements de téléchargements ainsi que certaines autres infos intéressantes :

# Directory for Wget logs
$logsdir = "/media/disque_ext/logs";
# Directory for tasks for wget
$tasksdir = "/media/disque_ext/tasks";
# There save downloading files
$filesdir = "/media/disque_ext/p";

N’oubliez pas d’aller créer les répertoires logs et tasks à la racine de votre disque externe…

Puis, dans le fichier /var/www/cgi-bin/wget4web/data/users.cgi, ajouter les utilisateurs qui auront droit d’utiliser le service. La syntaxe est simple, chaque ligne contient un utilisateur, son mot de passe, et la mention admin pour accéder à quelques options de niveaux supérieurs :
moi|mo2pass|admin
lui|lololol

Vous avez maintenant accès à :
http://server_ip/cgi-bin/wget4web/add.cgi - Permet d’ajouter un téléchargement
http://server_ip/cgi-bin/wget4web/progress.cgi - Permet de voir les DL en cours
http://server_ip/cgi-bin/wget4web/admincenter.cgi - Permet de voir certaines statistiques et permettre la supression des téléchargement en cours.

Quand on lui demande télécharger un truc, ça fait le boulot. Le soucis c’est que les pages de stats ne fonctionnent pas bien. C’est un peu pénible, mais bon, on peut faire avec. J’ai vu un type proposer une version modifié, mais uniquement sous forme de binaire pour des Mybook de WD. Les binaires… chouette…

Voilà, vous disposez maintenant d’un serveur qui fait tourner des services de téléchargement divers, pour peu que vous connaissiez les adresses de chaque pas. C’est la où c’est super classe d’avoir un serveur http déjà prêt, vous allez pouvoir faire une page de résumer de tout les liens disponibles sur votre Raspberry.

Configuration de la box pour gérer tout ça de loin

Bon, c’est super cool, mais si vous pouviez manager tout ça de loin, genre avec votre smartphone pendant que vous êtes au pestacle de fin d’année de votre moutard, ça serait mieux. Dans l’idée, vous avez 3 ports à rerouter sur votre box. Le port 80 pour le serveur web, le port 1234 pour Transmission, et éventuellement, le port 22 pour vous connecter discretement en ssh (qu’évidement vous changerez, au moins sur la box, par mesure de sécurité).
Pour cela, utilisez Google qui vous dira comment facilement router les ports de votre box vers les ports TCP du Raspberry Pi.

Comment se debrouiller avec son IP dynamique

Je fais partie de cette frange de la population dont la box change régulièrement d’IP pour une raison qui m’échappe encore. Enfin, ce que je ne comprends pas, c’est pourquoi certains changent, et pas d’autre. Bref, peu importe, j’ai trouvé un truc. Vous pouvez tenter de vous debrouillez en vous inscrivant sur un site genre no-ip ou bien dyndns, ce que je n’avais pas envi de faire parce que 1) la dernière fois que j’ai essayé de faire un truc comme ça, j’ai pas réussi 2) j’ai mon propre site et j’avais envie de pouvoir m’en servir. La classe ultime aurait été de pouvoir créer un sous domaine qui m’amène directement sur le R-Pi. Mais cela n’est visiblement pas possible avec mon hébergeur. Pour remédier à ça, j’ai donc créé un script (merci au gens qui m’ont aidés à le faire!) qui se lance tout les 5min a l’aide des cron table de linux, qui va regarder mon adresse IP publique, et la compare avec la précédante (stockée dans un fichier texte).
Si l’adresse est identique, on ne fait rien, et si elle est différente, j’upload sur mon site un page web contenant une bête redirection vers la nouvelle adresse IP.
Pour récuper l’IP, je choppe la page de garde de icanhazip.com.

#!/bin/sh
FILE='redir.html'
rm $FILE
wget -O ip.txt http://icanhazip.com
cmp -s ip.txt ip_old.txt
if [ $? -eq 0 ]; then
echo “Same IP has previous, no need to change”
else
echo “IP different, will upload IP redirection”
echo “<html>” >> $FILE
echo “<head>” >> $FILE
echo -n “<title>Ma redirection</title>” >> $FILE
echo “<meta http-equiv=\”content-type\” content=\”text/html; charset=utf-8\” />” >> $FILE
echo -n “<meta http-equiv=\”refresh\” content=\”2; URL=http://” >> $FILE
sed -n ‘1p’ ip.txt >> $FILE
echo  “\”>” >> $FILE
echo “</head>” >> $FILE
echo “<body>” >> $FILE
echo “</body>” >> $FILE
echo “</html>” >> $FILE
./envoi_fichier_ftp
fi
mv ip.txt ip_old.txt
exit 0

Ce script en appelle un deuxième pour l’upload du fichier, le script envoi_fichier_ftp (Je reconnais m’être honteusement très inspiré de l’internet pour faire ce script):

#!/bin/sh
HOST='ftp.monsite.fr'
USER='moi'
PASSWD='***'
FILE='index.html'
ftp -n $HOST << END_SCRIPT
quote USER $USER
quote PASS $PASSWD
put $FILE fb/$FILE
quit
END_SCRIPT
exit 0

Je précise qu’il n’y a aucune nécessité d’avoir un site internet à soit pour faire marcher ce truc, vous pouvez très bien l’utiliser avec un monsite.free.fr.

Les plus attentifs (s’il y en encore, cet article est le plus long que j’ai fait, je crois. Je vais surement mettre des photos de dames pour donner du courage aux plus téméraires lecteurs) auront remarque que la redirection m’amené sur la racine de l’adresse ip externe… où il n’y a rien. En effet les script CGI sont http://server_ip_extern/cgi-bin/wget4web/***.cgi, et le serveur Transmission sur un port différent. Voilà donc l’occasion rêvée de faire une page de garde en PHP !

Si faire une une page avec les liens vers les CGI est plutôt simple, changer le port alors que, je vous le rappelle, l’on ne connait pas l’IP sur laquelle on se trouve est un poil plus compliqué. Enfin, une fois qu’on a la bonne variable PHP (merci au gens qui m’ont aidés à le faire, encore une fois), c’est plus simple. Voilà le petit bout de code qui m’a permis de faire un lien sur l’adresse IP en changeant de port :

<?php $ip = $_SERVER['SERVER_NAME']; ?>
<p><a href=”http://<?php echo $ip;?>:1234″>truc avec des torrents légaux</a>

Cela aura le bon goût de s’appliquer quelque soit votre IP d’accès, externe, interne via Wifi, interne via Ethernet
Le reste du fichier est du html tout ce qu’il y a de plus con, des liens, un titre pour faire joli, une CSS pour faire encore plus joli (ok… ça m’a servi pour éviter une répétition de l’image de fond). Vous pouvez même faire des trucs trop top avec des cadres, des frames, des gifs animés de david bastien, des photos de votre chien, mais rappelez vous une chose, tout cela tourne sur un tout petit serveur avec le petit upload de votre ADSL (les fibrés, vos gueules !), ne lui en demander pas trop !

Bon, ceci clos ce gros paté pour faire de presque A à Z un serveur de téléchargement. J’espère n’avoir rien oublié pour qu’au moins, de base, ça marche. Pour finir, je tiens aussi à préciser que ces travaux sont l’oeuvre d’un passioné un peu touche à tout, et pas vraiment un professionnel du domaine. Certains points sont donc clairement améliorable, et c’est avec une certaine humilité concernant l’ensemble de la réalisation que j’en parle. Je suis conscient qu’il existe peut être des failles ou des imperfections inadmissibles, et si vous aviez quelques conseils à prodiguer, allez y de bon coeur !

Sources
http://elinux.org/RPi_Adding_USB_Drives
http://elinux.org/R-Pi_NAS
http://sorrodje.alter-it.org/index.php?article29/seedbox-sur-micro-vks-avec-transmission”
http://www.penguintutor.com/linux/light-webserver
http://bredsaal.dk/using-shell-scripts-for-cgi-in-lighttpd
http://exir.ru/wget4web/

Raspberry Pi

Thursday 5 July 2012


Aujourd’hui, on va parler un peu de ce petit “ordinateur”. En effet, malgré sa taille et son encombrement plus que réduit, il faut bien reconnaitre qu’on y branche la même chose que sur une UC classique (clavier/souris/écran/alim/”disque dur”), et que ça permet de taper du texte, aller sur l’Internet, envoyer un mail, bref, des trucs qu’on sait déjà tous faire avec un PC classique, une console de jeu ou un smartphone.

Alors qu’est ce que ça fait d’intéressant ? Et bien en général, on y voit 3 applications majeurs :

  • Officiellement, les concepteurs du RPi le voit comme un support pédagogique low cost pour l’apprentissage du développement. La version de l’OS proposé de base, Debian,  embarque de quoi développer dans pas mal de langage différent (python, C, perl, …), avec des approches graphiques (scratch).
  • Pour les autres, une machine embarquant Linux et bouffant 2/3W qui fait un jolie petit serveur domestique (NAS, LAMP)
  • Et pour les radins, ça peut même faire un média center. En effet, si le processeur principal est clairement un peu out-of-date, il embarque un GPU qui à l’air de prendre en charge du 1080p

Et pour moi ? Et bien je me cherche encore. Ça sera de mauvaise foi de dire que j’ai pas eu le temps, car j’ai commandé la carte chez Farnell le 3 mars, et je l’ai reçu il y a 2 semaines. Ça fait un peu de délai oui. En tout j’en ai eu pour 39 euros, frais de port compris. J’ai bidouillé un peu, fait un NAS vite fait, pourri une fois l’OS, tellement que je l’ai déjà réinstallé, et au final je crois que je vais plutôt faire du dev avec, et ce qui me plairait c’est de faire clignoter des Leds. Ouais, faire clignoter c’est tellement chouette. Bon, en gros, interfacer un peu d’électronique avec pour pouvoir construire Optimus Prime.

Alors si toi aussi tu te sens l’âme d’un bidouilleur de l’extrême et que tu veux tenter de faire des choses avec ton Pi Framboise voilà deux trois liens.

Le site de base, pour avoir des news trop bien genre “Tu peux acheter le boitier en Lego !” : www.raspeberrypi.org

Le wiki “officiel”, dans l’ensemble une bonne mine d’information : elinux.org/R-Pi_Hub

Le jour où vous recevez enfin votre Raspberry Pi, que vous avez installez elinux.org/RPi_Beginners. Vous y trouverez les 2 ou 3 trucs de base à savoir pour avoir une jolie Debian avec un compte à votre nom, configurer votre clavier, la langue du système, enfin bref, tout ce qui ce fait lors d’une installation sur un PC classique.

A partir du wiki j’ai extrais des liens vers des lib que je testerais WiringPi et les drivers de Mike McCauley. Ce sont des librairies en C permettant de jouer avec la partie GPIO. Les broches accessibles permettent également de faire d’autre type de communication, plus ou moins supportées également par ces drivers. Au pire ils ont l’air suffisamment bien documenter pour qu’avec la documentation du CPU du Raspberry Pi on puisse les compléter facilement.

Ah, j’oubliais, si l’achat d’un boitier n’a pas beaucoup d’intérêt, j’ai trouvé autre chose qui fait très joli :  le Starter Kit de SKPang. C’est un support pour le RPi avec une plaquette d’évaluation, ainsi que des leds, des résistances et interrupteurs. Ce qui ont fait un peu d’électricité/électronique au lycée auront une petite remonté de souvenirs émus. Pour commencer à faire du prototypage d’I/O vers le monde extérieur, ça m’a l’air pas mal du tout.