Category Archives: Raspberry Pi

[RaspberryPi] Premiers pas vers l’astrophoto …

by Matthieu

Il y a peu, j’ai récupéré un télescope. Pas de toute première jeunesse, il avait été offert à mon grand-père pour ses … pour son anniversaire d’il y a longtemps, vers la fin des années 80. Je n’étais à peine plus haut que trois pommes et deux beignets avec mes 6 ou 7 ans, mais j’avais été admiratif devant l’objet d’astronomie.

Plus de 25 ans plus tard, suite au départ de ma grand-mère partie rejoindre son amour disparu 20 ans avant (mon grand-père, donc), j’ai mis la main un peu par hasard sur le télescope lors du partage des affaires de mes aïeux.

  • Premier constat : il est vieux.
  • Deuxième constat : j’y connais QUE DALLE en astronomie. Bien que l’espace m’intéresse, je connais que pouic aux télescopes, leur fonctionnement, leurs vocabulaires, et ce qu’on peut en faire.

C’est un Merak fait par Perl, avec un diamètre de 115mm et une distance focale de 900mm, avec un oculaire de 6mm et un de 20mm et un doubleur de focal. D’après ce que j’ai compris, pour commencer, c’est déjà pas mal. Je vous passe la partie mise en place : lecture d’une doc avec une superbe photo bichrome du télescope, bienvenue dans le passé, alignement du chercheur avec l’axe du télescope, et utilisation des deux oculaires.

Voilà, c’est en place, et je fais mes réglages sur la flèche de la cathédrale de Rouen (la plus haute de France à 151m, pour l’anecdote), que j’immortalise avec mon appareil photo un peu à l’arrache, à l’aide du 20mm Panasonic qui a le bon goût d’avoir une lentille frontal pas trop grosse et donc de s’aligner facilement avec l’oculaire du télescope.

Bon, venons en à la partie « geek » du bouzin : l’avantage de faire des réalisations régulières avec un Raspberry Pi, c’est qu’il arrive un moment où on se rend compte qu’on a du stock en rab à la maison. Je récupère donc :

  • l’ancien R-Pi de mon robot, un B+
  • une Camera Pi
  • un dongle Wi-Fi USB
  • la batterie externe de mon robot (que j’ai du aller rechercher dans le sac de maternité de madame, heureux évènement devant arrivé dans les semaines prochaines, promis chérie je le remets chargé dès que j’ai fini)
  • un bout de carton
  • du petit scotch d’électricien

Coût total neuf, surement moins de 100 euros, coût en récup’ : 0€.

L’idée est donc de mettre la caméra devant l’oculaire à la place de mon oeil, et de faire des photos. Evidement, tout cela se fait de jour, parce que c’est plus facile ! Pour faire des photos, j’utilise bêtement la commande raspistill via ssh. Mais il est nettement plus facile de régler l’alignement optique avec une visu en temps réel de la camera.

J’ai donc utilisé MJPG-streamer, qui permet de balancer des captures avec un format préréglé à l’avance via le réseau, soit sur une page web, soit sur VLC. Pour se faire, j’ai suivi le tuto disponible sur le merveilleux site http://www.instructables.com. Attention cependant, pour pouvoir utiliser la Camera Pi avec MJPG-streamer, il faut au préalable charger le module de compatibilité V4L2 dans le R-Pi :

sudo modprobe bcm2835-v4l2

Egalement, à l’étape 3 du tuto on vous demande de téléchopper via svn la dernière version du soft, mais l’adresse est obsolète. Il faut donc récupérer le soft via :

svn checkout svn://svn.code.sf.net/p/mjpg-streamer/code/ mjpg-streamer-code

Une fois que c’est fait, vous pouvez nuancer la fin du tuto d’instructables.com avec quelques options (format de l’image, port de streaming, etc) via la doc faite à l’arrache par le dev de Mjpg-streamer sur son blog.

Vous finissez donc avec un télescope qui prend des photos, et qui peut même faire du streaming sur l’internet mondial (rep à ça Philae et Hubble !).



Alors vous me direz « mais elle est flou ton image ! ». Oui, en effet, j’ai une impression de netteté bien supérieur en vidéo ou en visu direct dans l’oculaire. Deux explications :

  1. J’ai peut être mal réglé la partie optique
  2. J’ai l’impression que cela pourrait être du à des turbulences entre les couches d’air chaud et froid traversées par les rayons arrivant au télescope.

Mais cela dit, dans la notice c’est écrit que ce n’est pas un instrument d’observation terrestre, et je pense que face à un astre le problème devrait être moindre.

Il reste également d’autre point à régler, comme la latence du streaming. Il existe il me semble des solutions bien mieux adapté pour visualiser ce que voit la caméra en alternative à MJPG-streamer, où la réactivité est meilleur. Dernier point, si le mode automatique de raspistill se débrouille pas trop mal de jour, il faudra probablement mieux paramétrer la prise de vue lors de photo de nuit. Ensuite peut-être viendra le temps de l’utilisation de technique plus avancer comme l’empilement d’image pour l’observation plus profonde, ou bien l’utilisation d’une camera sans filtre infra-rouge.

Bref, to be continued comme on dit au pays de la NSA.


[R-Pi – Video] RPi-kee – le robot qui suit des lignes

by Matthieu

On avait donc parlé ici, puis par ici de comment on fait un robot (vite fait, hein).

J’ai fini par arrivé à un résultat convaincant, que je vous présente via une petite vidéo. C’est de l’accélérer x3 car il faut le reconnaitre, si les moteurs pas à pas me fournisse une grande précision, c’est quand même pas avec ça que je vais battre Schumacher… quoi que on me dit dans l’oreillette que sur une piste de ski c’est jouable.

Bref, voilà la vidéo, et si vous activez les sous-titres vous aurez quelques explications supplémentaire.

Image de prévisualisation YouTube

Il reste bien évidemment des ajustements à faire. J’ai notamment acheté des moteurs CC et le drive qui va derrière pour améliorer la vitesse du robot. Comme j’avais déjà 2 moteurs pas à pas 5V, ainsi que 2 moteurs 12V (ceux de la vidéos), je vais pouvoir motorisé la caméra également. Et/ou faire une tourelle avec un laser-destruktor-de-la-mor, mais j’ai un soucis de batterie à gérer pour ça.


[R-Pi] RPi-kee – Partie 2 :Electronique

by Matthieu

L’ensemble des composants, sans la partie méca, dans la petite boite de transport

Cet article fait suite à celui là : RPi-kee – Partie 1 :Généralité et Mécanique.

Electronique

Voilà une partie un peu plus « sensible ». Faire un montage en Meccanos et le rater, ce n’est pas grave. On démonte et on recommence. En élec, c’est un peu plus touchy. Soit, un mauvais montage peut juste ne pas fonctionner, mais peut aussi cramer des composants, voir le Raspberry Pi lui-même. Je n’ai qu’un seul modèle B+, et je n’ai pas envie d’en racheter un… tout de suite.
Tiens, à propos de composants, voyons voir de quoi a-t-on besoin, par fonction :

– Premier besoin impératif dont je n’avais pas encore parlé : pouvoir tester avec des fils…

=> Oui, dit comme ça c’est pas clair. On le sait tous, le Wifi (de surcroit en USB), c’est de la merde, et les batteries ça se décharge. J’ai donc deux interfaces réseaux sur le Raspberry Pi : une clé wifi et le port Ethernet. Concernant l’alimentation, j’ai la possibilité d’alimenter le Pi soit par son port micro USB avec un chargeur de téléphone portable (pas forcément très généreux en milli Ampère), soit par les GPIO. L’avantage de l’alimentation via les GPIO c’est que l’on peut brancher une grosse source de courant sur l’ensemble des composants, dont le Pi.
Si l’alimentation passe au travers du Pi pour alimenter le reste, le pauvre risque d’avoir chaud. Bref, pour toute la partie mise en place et premier essai, il est plus prudent d’avoir une alimentation externe.

– Piloter l’ensemble, communiquer, contrôler, commander

=> Le Raspberry Pi, bien évidement. Un modèle B+ pour être précis. J’aurai très bien plus prendre un B (voir un A, qui est un B sans port Ethernet, avec un seul port USB et 256 Mo de RAM), mais la quantité de truc que je cherche à interfacer m’a fait dire qu’un B+ et ses multiples GPIO et sa liaison SPI (bus de communication série très utilisé pour l’interfaçage de composants) en rab m’ont fait dire que ça serait plus confortable. Et puis le B+ et le B coute le même prix. Pourquoi se priver ? Et pour les trois fanboys du fond qui me demande pourquoi je ne suis pas partie sur une Beagleboard, un Arduino ou le dernier PC embarqué d’Intel, je répondrais que c’est la communauté et le support autour du Raspberry Pi qui fait la différence. En cas de pépin, c’est sympa de trouver des topic [RESOLU] et [SOLVED] sur les forums adéquat. Pour aller avec, bien évidemment, une blinde de développement logiciel.

– La possibilité de suivre une ligne au sol

=> La Camera Pi. Le RPi possède un port permettant de connecter une caméra de 5mpixel, fabriqué par la fondation Raspberry Pi. Elle est donc parfaitement compatible, de pas mal de doc, et j’ai déjà un peu d’expérience avec.

– Détecter les obstacles à proximité

Bidouille diverses

=> On aurait pu croire que la camera aurait pu servir à cet endroit-ci, mais en fait, bof. En effet, le traitement d’image c’est quand même un peu lourd, et surtout, c’est assez moyen pour la mesure de profondeur. J’ai donc choisi 2 capteurs infra-rouge de mesure de distance. Un permettant la mesure de 20cm à 120cm (GP2Y0A02YK, de Sharp), un autre de 100cm à 550cm (GP2Y0A710K0F, Sharp aussi). Ils seront donc mis sur la face avant du robot pour avoir une info sur ce qui se trouve en face. Il sera probablement possible de faire un scan de l’environnement en faisant tourner le robot sur lui-même. Voir de monter le couple de capteur sur une tourelle. Pour les plus curieux de la technique, je précise que j’ai pris deux capteurs et non pas un de 0cm à 550cm, parce que ça n’existe pas ! En effet, la portée de la mesure dépend de l’écart entre l’émetteur IR et le récepteur. J’ai dimensionné la portée maximale de la mesure par rapport à … ben, la largeur des pièces de mon appartement. Raison simple, non ? A part ça, ce sont des capteurs qui s’alimentent en 5V et qui renvoi une tension inversement proportionnel à la distance, et de surcroit, en fait, de façon pas linéaire du tout. Le Raspberry Pi ne disposant pas d’outils de mesure de tension, j’ai donc également pris un ADC (Analog to Digital Converter, Convertisseur Analogique Numérique en français, soit CAN, mais ce terme est pourri dans le monde de l’embarqué parce que ça confusionne avec le bus CAN de Bosch qu’on trouve dans toutes les bagnoles entre autres). L’ADC est un MCP3008 de chez Microchip, qui s’interface sur un bus SPI, dont dispose le RPi ça tombe trèèès bien.

Le banc de caarctérisation des capteurs IR

– Se balader de façon autonome (même si aléatoire)

=> Le Raspberry Pi intervient dans le pilotage, et pour le côté sans fil, j’ai une clé wifi et une batterie externe de téléphone mobile assez costaude de 12000mAh, capable de délivrer 2A. D’après mon 6ème sens (ouais, un truc de techos, tu peux pas test) ça devrait tenir plusieurs dizaines de minutes sans aucun problème, voir beaucoup plus. Une fois que j’aurai fini le montage complet full option, je ferais un benchmark.

– Avancer

– Reculer

– Tourner

=> Et oui, c’est important ça ! Des moteurs ! Au départ j’ai pris 2 moteurs pas-à-pas unipolaire de 5V. Pourquoi ? Parce que j’avais trouvé un tutoriel pour les connecter au Raspberry. Il faut les connecter au travers d’un ULN2803A qui est un composant se plaçant entre les moteurs et le Raspberry. Un moteur, ça consomme bien plus que ce que Pi est capable de cracher. Après mes premiers essais avec la structure complète, j’ai réalisé qu’ils étaient trop faibles pour la déplacer. J’ai donc investis dans des moteurs équivalents en 12V, unipolaire donc. L’avantage c’est que c’est compatible directement avec le câblage existant (à la tension d’alimentation près), et que ça apporte 66% de couple en plus (pour 140% de tension… mouais, ce n’est pas aussi efficace mais j’m’en fous pour le moment). Tout mon petit bazar étant prévu pour fonctionner avec la batterie 5V. Et là, astuce, le rehausseur de tension U3V50ALV capable de transformer 3V minimum vers 4 à 12V me sauve la mise ! En revanche, ça fait passer la motorisation du robot à la première place potentielle du composant qui suce le plus. Ici encore, il faudra avancer précautionneusement. Quand j’ai testé les moteurs 5V, j’ai alimenté le montage via le RPi. Il bien tenu le coup, mais il faudra sûrement que je ne branche pas la batterie directement sur lui pour le faire fonctionner en continu avec les moteurs 12V.

– Monitorer certaines grandeurs physiques propres (tension d’alimentation, température)

Atelier soudure et instrumentation…

=> Ici également, c’est l’ADC qui fait le taf. A noter que l’ADC ne fait pas une mesure de tension absolu; en fait, il compare un signal par rapport à une entrée de référence (Vref). Donc si vous lui mettez en entrée la tension de la batterie, et que vous mettez en Vref la tension de la batterie … et bien l’ADC vous dirait que l’entrée est en permanence à 100% de Vref. Sauf que votre batterie elle aura son niveau réel qui va gentiment passer de 5V à plus rien, sans que votre ADC le voit. Pour info, le fonctionnement d’une batterie, c’est que ça reste longtemps à 5V, puis en fin de course ça descend d’abord doucement vers 4,9V puis 4,8 , 4,7 et paf, il ne reste plus assez pour votre électronique qui se met à fonctionner bizarrement, jusqu’à ce que votre système s’éteigne peu après. Là encore, il va falloir faire des mesures pour voir comment la batterie se comporte et ainsi pouvoir monitorer efficacement sa tension.

Ah d’accord, mais ça ne résout pas le souci de Vref ! En fait ce n’est pas si compliqué, j’ai résolu la question avec un régulateur de tension, un L7805CV. Un composant qui à la brillante idée de sortir 5V constant pourvu qu’on lui rentre plus que 5V… et moi j’ai du 12V qui traine. L’inconvénient du truc, c’est que ça fait encore une nouvelle source de consommation, mais que même si le 12V subit des variations, le 5V sera constant. Parfait pour mon Vref.

Pas de bol, je ne suis pas sur de garder l’écran…

Au passage, pourquoi ne pas monitorer le 12V également ? Avec 2 résistances on fait un petit montage qui fournira 2/3 de 12V, et qui variera de façon linéaire avec lui. Oui, c’est un pont diviseur de tension, montage que les électroniciens apprennent la plupart du temps avant même de savoir lire.
Les températures mesurables sur le système sont la température du processeur du Pi, et j’ai également dans mon stock une sonde 1-Wire DS18B20. C’est une sonde « numérique » qui se branche sur une GPIO du Raspberry Pi. Le noyau linux de l’OS Raspbian permet de discuter sans soucis avec ce type de sonde. On peut même placer plusieurs sondes sur le même fil et ainsi monitorer plusieurs emplacement. Pourquoi ne pas, donc, mettre une sonde plaquée sur chaque moteur, sur le rehausseur de tension, une autre suffisamment éloigné pour mesurer la température ambiante, et j’en passe. Dans mon cas, c’est du nice to have, et je m’en occuperais plus tard.

– Fonctionner dans le noir

=> La Camera Pi de base dispose comme tous les capteurs photos du monde ou presque un filtre infrarouge, permettant de supprimer les longueurs d’onde infrarouge proche. En effet, les capteurs photos sont sensibles par nature à ce type de rayonnement. Pour rappel, on ne parle pas ici de l’infrarouge lointain, celui qui sert aux caméras thermiques. Pour l’observation nocturne, les p’tits gars de la fondation Raspberry ont également sorti la Camera Pi NoIR (et nous, petit frenchy, pouvons profiter de cet adorable jeu de mot), une Camera Pi strictement identique à la première d’un point de vue électronique et informatique, mais dépourvu de filtre infrarouge. Le meilleur moyen dans profiter pleinement est donc de coupler cette caméra à un projecteur infrarouge. Et comment fait-on cela ? Avec des LED infrarouge, tout simplement. Le seul hic dans l’histoire, c’est que la caméra et les capteurs de distance risque de s’entre perturbé. Il conviendra donc de gérer leur fonctionnement de façon à éviter que les capteurs soient éblouis par le projecteur.

Le plan de câblage prévu, réalisé avec FidoCADj

Petit résumé sans tout le blabla justificatif de design :

– Piloter l’ensemble, communiquer, contrôler, commander
=> Un Raspberry Pi B+

– Détecter les obstacles à proximité
=> Un ADC MCP3008 en SPI, un capteur de distance IR 20cm à 120cm (GP2Y0A02YK, de Sharp), un autre de 100cm à 550cm (GP2Y0A710K0F, Sharp aussi).

– Se balader de façon autonome (même si aléatoire)
=> Un dongle Wi-Fi USB, une batterie 12000mAh

– Avancer
– Reculer
– Tourner

=> Un rehausseur de tension U3V50ALV, un ULN2803A, deux moteurs pas-à-pas 12V unipolaire

– Monitorer certaines grandeurs physiques propres (tension d’alimentation, température)
=> Le même ADC MCP3008 en SPI, un régulateur de tension, un L7805CV, 2 ou 3 résistances, sonde 1-Wire DS18B20

– La possibilité de suivre une ligne au sol
– Fonctionner dans le noir
=> Camera Pi NoIR + LED infrarouge

Savoir cablant en suivant son plan…

– Matériel annexe
=> Une breadboard, des fils pour la breadboard mâle-mâle, des femelle-femelle, un fer à souder, de l’étain, des tournevis, etc.

Au final je n’aurai plus qu’à aborder la partie logicielle, histoire d’avoir fait le tour sur le démarrage du projet ! Au final je n’aurai plus qu’à aborder la partie logicielle, histoire d’avoir fait le tour sur le démarrage du projet ! Au passage, je signale que la plupart des concepts d’électronique ne sont pas bien compliqué, et qu’un débutant motivé avec Google peut faire la même chose, voir mieux sans soucis.


[R-Pi] RPi-kee – Partie 1 :Généralité et Mécanique

by Matthieu

J’avais déjà commencé à en parler un peu à droite à gauche, évoquer deux ou trois idées de réalisation, mais voilà, je me suis lancé, j’ai quelque chose qui commence à être montrable, et donc je le montre. L’article faisait une 10 pages, je me permettrais de le publier en 3 fois.

RPi-kee

Un peu d’histoire d’abord, pourquoi RPi-kee ? Il y a bien longtemps, quand j’étais étudiant, j’avais fait mon projet de fin d’étude sur le thème « IHM Innovantes, télé opération d’un robot via un terminal sans-fil ». J’en ai déjà parlé 50 fois ici et , mais pour les retardataires, un bref résumé s’impose.

Le Pekee

Nous sommes en 2006, je viens d’avoir une Nintendo DS Lite, et je souhaite faire un peu plus de chose que poutrer des Aliens dans Metroid et cueillir des noix de coco dans Animal Crossing. Je découvre alors le monde fabuleux des linkers Slot 2 avec leur carte Compact Flash qui déborde de la console, et surtout le développement d’application Homebrews. C’est de là que me vient l’idée d’utiliser la console pour un projet de fin d’étude, et je découvre alors que le département Système Embarqué de mon école dispose d’un « petit » robot, le Pekee. C’est un machin en forme d’aspirateur qui, au moment où je le découvre, possède le fonctionnement suivant : le robot se connecte à un point d’accès wifi, on connecte un PC sous Linux au même réseau et on le pilote avec un petit programme en C++. Je vous passe tout le développement, mais au final on termine avec une DS qui possède six interfaces différentes (boutons physiques, boutons virtuels, cercle de contrôle, accéléromètre, reconnaissance de dessins et reconnaissance vocal low cost) qui dialogue avec le PC, qui transfère les ordres au robot. Ça marche plutôt pas mal, et ça plait, si j’en crois les 270k vues sous YouTube. Pas mal pour l’époque, surtout que toutes les interfaces qu’on propose sont arrivés avant le monde des smartphones (et oui, début 2007, point d’IPhone, si si, rappelez-vous).

Au final si la partie IHM de contrôle est réalisée, toute la partie robot est déjà existante, et surtout, pas à moi. A 6000€ le bestiau, hors de question d’investir mes deniers. A l’époque, je m’étais dit qu’un jour, je ferais le robot qui va avec. Sans trop savoir comment.

Raspberry Time !

Premier montage avec une sonde de température

Après mes études, j’ai continué dans les systèmes embarqués professionnellement parlant. J’ai donc appris plein de chose, découvert des processeurs divers, mais au final ils nécessitent la plupart du temps une carte électronique faite pour et je n’ai pas les moyens ni l’envie de partir dans la réalisation de carte, et pas envie de mettre des sous dans des cartes d’évaluation aux possibilités limitées par des IDE bloqués par des licences hors de prix.

C’est alors que vint le Saint Graal de l’électronique domestique, le Raspberry Pi. Plus versatile et moins complexe à mettre en route que les Arduino, plus puissant, prêt à l’emploi, pas cher, bref, pile poil ce qu’il me fallait. Le nom du projet est donc un mélange de Pekee et Raspberry Pi.

RPi-kee, le cahier des charges

La base que je désirais pour RPi-kee, c’était de faire au moins ce que je faisais faire au Pekee, c’est à dire :

  • Avancer
  • Reculer
  • Tourner
  • Etre compatible d’un point de vue communication avec le « protocole » qu’on utilisait entre la DS et le PC sous linux.

Le truc est un robot mobile, donc tant qu’à faire :

  • Fonctionner sur batterie
  • Etre connecter au réseau en Wi-Fi

Au fur et à mesure que je cherchais comment faire ça, j’ai également découvert pas mal de chose sur le Raspberry Pi, et connaissant ses possibilités, j’ai donc décidé de rajouter quelques fioritures comme :

  • La possibilité de suivre une ligne au sol
  • Détecter les obstacles à proximité
  • Se balader de façon autonome (même si aléatoire)
  • Lancer des frappes nucléaires sur les Etats-Unis
  • Monitorer certaines grandeurs physiques propres (tension d’alimentation, température)
    Fonctionner dans le noir

Organisation du projet

Bien évidemment, c’est un projet personnel qui s’étend sur plusieurs domaines de compétences, que je maitrise plus ou moins. Les trois grands axes sont :

  • Réalisation mécanique : qui dit robot mobile dit structure, roue, moteur, etc.
  • Réalisation électronique : un Raspberry Pi c’est cool, mais seul, il n’est qu’un micro PC. Il faut donc lui trouver les composants qui réalisent les fonctions du cahier des charges, et qui soit facilement intégrables dans la troisième partie …
  • Réalisation informatique : de là où j’en suis, c’est la partie la plus conséquente. Avoir des capteurs, des actionneurs et des idées pour en faire quelques choses, c’est bien. Mais coordonnées tout ce petit monde, c’est une autre paire de manche. En revanche contrairement aux deux axes précédents, c’est mon boulot, donc j’y suis nettement plus à l’aise.

Mécanique

Des robots mobiles (je précise mobile, car je ne parle pas de ce qui font la cuisine, ou de la soudure sur poste), il en existe des tas de type. Avec des roues, des chenilles, des bipèdes, quadrupèdes, hexa ou octo, mixte roues/bras, des nageoires, des hélices et j’en passe. Moi je veux un truc simple à réaliser, et je choisis donc le type « char ». Non, pas comme un caractère en C/C++/C#/Java, mais comme le Pekee, deux roues qui permettent d’avancer, de reculer et de tourner en fonction du sens de rotation. Pour tourner on fera donc tourner une roue dans un sens, et l’autre dans le sens opposé. Ca a pas mal d’avantage, comme le faite de pouvoir faire demi-tour très facilement, et d’être facile à réaliser. Prenez une voiture par exemple, deux roues qui avancent/reculent, une/deux roues qui permettent la direction. Si les roues motrices sont simples, mécaniquement la direction est très chiante à réaliser.

La homemade roue folle

Évidemment, pour une question d’équilibre, il faut au moins trois points d’appui, et j’ai choisis une roue folle (mettez en deux, ça fait un caddie de supermarché). A l’heure où j’écris, j’ai réalisé moi-même la roue folle, mais j’ai également acheté une roue à bille. Il faudra que je teste et compare les deux.

Ensuite vient la structure. Son but, pouvoir attaché les différents composants (moteurs, Raspberry Pi, montage électronique) de façon stable et solide. N’ayant pas envie d’être contraint par une structure toute faite achetée dans le commerce, j’ai décidé de la fabriqué moi-même. De plus, j’ai fabriqué l’ensemble de façon à pouvoir désolidariser facilement les composants de la structure. Ainsi, le Raspberry Pi, la plaquette de prototypage (breadboard), la batterie et la caméra se démonte facilement. C’est surtout pour des raisons de modularité. Faire des tests de déplacement sans la batterie est plus facile, car je gagne 300g sur la balance.

Ah, j’oubliais : parce que je n’ai pas d’imprimante 3D, et parce que c’est très pratique, l’ensemble de la structure est faite avec … des Meccanos. Parce que ça donne une côté « Short Circuit », et parce que j’ai beau avoir passé fraichement la trentaine, faire des Meccanos le dimanche, c’est super cool. Et surtout, c’est parfaitement adapter à un proto. Bien sûr, je n’ai pas de modèle, j’ai donc tout construit, déconstruit et reconstruit pas mal de truc. Au final j’ai atteint mon but, avoir une structure permettant le montage et démontage rapide des composants. En revanche, le hic, c’est que c’est assez lourd. Je pourrais me tourner vers les Lego (Technics), mais je crains pour la solidité de l’ensemble. La vie est une question de compromis…

Première version du chassis

V2 du chassis

V2 du chassis, vu arrière, sans électronique de contrôle

Avec l'électronique, la batterie, bref, quasi full option

La suite dans quelques jours …


[RaspberryPi][dev] GCC, optimisations et benchmarks…

by Matthieu

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 !


[RaspberryPi] Faire un serveur de téléchargement

by Matthieu

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/


Theme by Ali Han | Copyright 2017 Embarquement ! | Powered by WordPress