[DevBlog] Starberrypi, le télescope de feignasse

by Matthieu

Bon, il est temps de dépoussiérer un l’endroit pour parler d’un truc que j’ai commencé il y a maintenant … un peu plus d’un an. L’idée, c’est d’écrire dessus pour :

  • Partager un peu le sujet, des fois que ça serve
  • Formaliser un peu de doc sur les différents choix techniques

Starberrypi c’est quoi ? A la base c’est une idée inspirée par la récupération in extremis d’une antiquité, le minimover 5, remis à neuf, du moins au niveau des moteurs. Pour vous donner une idée de l’âge du truc, le numéro de téléphone du distributeur français indiqué sur le bras comporte 6 chiffres. L’étiquette était peut-être déjà vieille quand elle a été posé, mais quand même, ça sent le milieu des années 80.

Donc l’idée, c’est de prendre ce bras électromécanique respirant la poussière pour en faire un support de caméra mobile afin de pointer directement devant un machin à prendre en photo, de préférence dans le ciel. Prendre des photos et piloter des moteurs pas-à-pas c’est évidement tout à fait dans les cordes, à première vue, pour un Raspberry Pi.

Techniquement niveau matériel, c’est que du déjà-vu ou presque. Une Picam pour l’image, des moteurs pas à pas, seul 2 sur les 6 du minimover suffisent, un peu d’électronique pour les moteurs et basta.

Le détail qui change un peu, c’est l’optique de la caméra. On pourrait faire de l’astrophoto avec la Picam de base, mais… si on monte un objectif de reflex qui zoom un peu, avec la taille du capteur rikiki on obtient un bon gros zoom de porc pour pas cher. Sur le papier, c’est bien, mais ça va avoir quelques conséquences sur l’image (si tu viens de penser à la taille des photosites et au bruit numérique, c’est dans l’idée). Ceci va donc nécessiter un peu de CAO, et d’abus de bien social pour imprimer un adaptateur d’objectif <que j’ai, de préférence> vers la Picam.

Nouveauté pour moi également, trouver un capteur « quivabien » pour me permettre d’aligner le télescope de façon automatique. En gros, la base en astro, c’est l’altitude (hauteur par rapport à l’horizon) et l’azimut (orientation par rapport au nord). Pour l’un, il faut un accéléromètre, pour l’autre il faut une boussole.

Histoire de penser à tout détailler plus tard, voici une liste de tout ce qui m’est passé par les mains pour ce projet :

  • Un télescope Newton 115mm-900mm
  • Un Raspberry Pi 3
  • Des moteurs pas à pas en pagaille
  • Un ULN2803
  • Un DC+Stepper Motor HAT de chez Adafruit
  • Des drivers de moteur pas à pas A4988, de chez Pololu
  • Un capteur d’orientation BNO055
  • Une boussole CMPS11
  • Une boussole CMPS03
  • Un Sense Hat de chez Raspberry Pi
  • Des meccano
  • Des alims externes diverses (5 et 19V notamment)
  • Une imprimante 3D Ultimaker 3

Tout n’a pas servi, mais disons que l’expérience gagné sur chaque truc m’a fait progresser pour la réalisation. Je n’ai pas encore parler de soft parce qu’on verra plus tard. Mais spoiler, ça va surtout se passer en python.


[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.


[Raspberry Pi] Un afficheur pour mon thermostat

by Matthieu

Résumé du projet :

  • Récupérer certaines infos sur Internet
  • Récupérer des infos locales
  • Créer une image avec ses infos
  • Afficher l’image

Vous vous souvenez du thermostat pour mon radiateur électrique ? Bien. Ce Raspberry Pi avait donc 2 rôles : faire des acquisitions de températures pour les envoyer à un serveur qui log ces données pour la postérité et, en fonction d’un fichier de consigne, piloter un radiateur pour choisir quelle commande de chauffage il doit utiliser, en fonction de la température ambiante et de l’heure (chauffer pendant la journée en semaine, c’est pas cool avec Dame Nature).
Bref, c’est un Raspberry Pi qui se tourne un peu les pouces. Et c’est là qu’intervient le recyclage d’un écran Adafruit (2.8′, tactile, avec des boutons en dessous, non utilisé dans mon cas … pour le moment) qui dormait dans une boite parce que je n’avais pas pu l’utiliser sur mon robot comme prévu.

Un boitier adapté (Adafruit également) et un peu de code plus tard, voilà tout plein d’info pertinente afficher sur l’écran !

On y voit donc :

  • La date
  • L’heure
  • La température interne
  • L’état de la commande de chauffage
  • La température extérieure, le taux d’humidité relative, la vitesse du vent, et la date d’acquisition de ses trois infos.

Cette dernière ligne est en fait issue d’un site qui recense plein de donnée météo, le National Oceanic and Atmospheric Administration. Il existe sous Debian l’outil weather-util permettant de récupérer ces infos en utilisant le nom de la station météo, son code d’immatriculation, ou bien des coordonnées dans votre petit terminal. Vous trouverez des détails sur son utilisation ici. Cela dit, je me suis rendu compte qu’en tapant http://weather.noaa.gov/pub/data/observations/metar/decoded/XXXX.TXT dans votre navigateur internet on peut récupérer les mêmes infos, il suffit de remplacer XXXX par le code de la station, trouvable via le site weather.nooa.gov. Avec un simple wget on récupère un TXT, il ne reste plus qu’à le traiter.

Concernant le traitement des données, j’ai fait un bout de code en C qui récupère le .TXT, le décode pour récupérer les données (température/humidité/vent/horodatage), récupère les infos de la sonde locale (réutilisation du code du thermostat), et on passe tous ces paramètres dans la commande « convert » venant du package debian « imagemagick » qui va afficher tout plein de texte sur un fond noir (Détails ici).

Pour utiliser l’écran, il faut avoir installé les petits package prévu par Adafruit (le tuto ici) et lancer la commande permettant d’envoyer l’image. Avec un cron toutes les minutes, ça permet d’afficher un résumé météo rapide.

Et voilà le travail ! Il faudrait encore modifié la plaquette d’essai histoire de rendre ça encore plus joli. Voir même afficher sur l’image de fond un graph de la température, changer l’afficher avec les boutons, ou que sais-je encore !


[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.

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.


[Raspberry Pi] Thermostat pour radiateur Pass Program

by Matthieu

J’ai laissé un peu de côté mon p’tit robot RPi-kee pour m’atteler à un autre projet, un peu plus terre à terre, et nettement plus utile pour l’humanité. Sous cette introduction un peu pompeuse, se cache sauvegarde de la planète, économie d’énergie et tout le bullshit marketing qui va avec.

Depuis maintenant plus d’un an, j’ai l’honneur d’avoir dans mon salon un Raspberry Pi avec une sonde DS18xxx et un système logiciel pour récupérer cette température et la coller dans une base de données. Si vous me demandez quelle était la température le 4 juin 2014 à 11h dans mon appartement, je suis capable de vous répondre ! C’est beau la technologie. Mais pas très utile.

Avec l’hiver qui vient (TM de la famille Stark), nous avons remis en route un radiateur sur les 5 disponibles chez nous. J’ai beau avec un appartement neuf (refait en 2008), il a été construit avec des jolis convecteurs peuvent être un gouffre financier. Nous avons donc pris l’habitude de le mettre en route le matin au réveil, de le couper en partant, de le relancer le soir en rentrant et finalement de l’éteindre au coucher.

Et si on automatisait tout ça ?

J’ai donc commencé par regarder de plus près mes radiateurs. Il s’agit de modèle F18 de chez Atlantic (mais si, la pub radio avec Charlotte de Turkeim…), qui ne sont pas vraiment haut de gamme, bien au contraire. Néanmoins, ils ont l’avantage d’être « programmable ». Ils disposent de base de 2 thermostats (un « jour » et un « nuit ») ainsi qu’un mode hors gel, et off. On peut donc avec un curseur passé de jour à nuit, à off et à hors gel. Mais alors, programmable, ça veut dire quoi ?
Ça veut dire qu’ils sont connectés à mon réseau électrique par 3 fils : Phase (fil marron, 220V alternatif), Neutre (fil bleu), et le p’tit dernier, le Pilote (fil noir). J’ai donc enquêté un peu, et j’ai regardé comment était câblé tout ça en démontant le cache dans le mur où vont (les putes, TM Tywin Lannister) les fils du radiateur. Comme je le disais plus haut, mon appartement est à peu près neuf, et donc l’électricité est bien faite. Je suis descendu voir mon tableau électrique, et que vois-je : 5 fils noirs qui ne sont connectés à rien, et un fil marron. J’ai pris l’initiative de penser que tout ça est un pré câblage pour un boitier de contrôle.

En regardant la documentation du radiateur, j’ai appris que le fil pilote permet de mettre le radiateur dans des modes de fonctionnement particuliers en fonction du signal envoyé sur le fil pilote. Les différents signaux sont les suivants :

  • Rien : mode jour
  • 220V double alternance : mode nuit
  • 220V alternance positive : mode arrêt délestage
  • 220V alternance négative : mode hors gel
  • 220V double alternance un peu déphasée: mode jour -1°C
  • 220V double alternance un peu plus déphasée: mode jour -2°C

Au final, chaque mode est une transformation du signal 220V plus ou moins compliqué. Quand on regarde la doc toujours, on voit qu’il est possible d’installer (ou de faire installer) un boitier dans le tableau électrique pour réaliser ses opérations. Après, il existe plusieurs options genre thermostat sans fil à placer dans le salon, programmateur plus ou moins complexe, et tout ça, pour faire des sous ! Pour vous donner une idée, le programmateur simple pour UN radiateur coûte entre 50 et 100 euros, et je ne vous parle même pas du thermostat central, et j’évite le sujet du prix de l’intervention de l’installateur agréé.

Le truc quand même bien fait, c’est que le pilotage entre le mode jour et le mode nuit est super simple : soit on déconnecte le fil pilote, soit on y colle 220V.

Voilà, l’objectif est défini, faire un interrupteur commandé par une électronique, le Raspberry Pi en l’occurrence. Et coup de bol, celui qui trône dans mon salon est à 2m du radiateur (caché derrière un meuble, parce que le côté esthétique est important aussi).

Hardware requis :

Le mot clé, c’est « relai ». Un relai en électronique, c’est un interrupteur commandé. On met une tension à la borne du relai, il se ferme. On met 0V, il s’ouvre. De l’autre côté du relai, on branche le 220V et le fil pilote, et zou, terminé.
Evidemment, en pratique, il faut rajouter quelques fioritures pour avoir quelques choses d’utilisable. Et par chance (ou bien alors parce que c’est un besoin pas si exceptionnel) j’ai trouvé sur le site mchobby.be un joli pack « Relai 220V« , avec la doc de montage adéquat.

Ce kit est composé d’un relai pilotable en 5V, d’une diode de roue libre (l’entrée d’un relai est une bobine dans lequel le courant est stocké, la diode de roue libre permet au relai de se vider proprement quand vous le déconnecter), d’un couple transistor/résistance pour piloter le relai (en gros, ça fait la conversion entre une GPIO 3,3V du RPi ou du 5V d’un Arduino pour avoir suffisamment de patate pour attaquer le relai), et pour la rigolade d’une LED pour voir quand le relai est fermé (d’ailleurs elle est monté à l’envers sur le schéma de mchobby, pensez à la retourner si vous l’utilisez). Comme support le site conseil une carte permaproto, ce qui est un très bon conseil. Avoir un support solide quand on joue avec le secteur, c’est plutôt sécurisant.
Coût total : moins de 20€ (hors Raspberry Pi que j’avais déjà).

J’ai rajouté un câble pour relier le triplet 5V/Gnd/GPIO au RPi, un câble pour relier le 220V et le fil pilote (pour le coup, je me suis branché directement au domino reliant le radiateur au réseau câblé dans le mur), et voilà pour le hardware.

Côté Soft :

J’utilise la même librairie de pilotage de GPIO que pour RPi-kee, qui dispose pour le test d’un petit utilitaire pour switcher les GPIO à partir du shell de Debian, très pratique pour les premiers tests, permettant de vérifier le concept.
Ensuite, j’ai préparé un petit tableau Excel avec quelques infos pertinentes, comme une température de consigne, et également des plages horaires pendant lesquelles le radiateur doit être en mode jour. Une fois le tableau sauvegardé au format CSV, reste à faire une bout de code en C pour lire le fichier, trouvé la température de consigne, et déterminer si le radiateur doit être en mode jour ou en mode nuit. Condition supplémentaire, si la température de la pièce est supérieure à la consigne, alors on passe forcément en mode nuit.
La seule opération qui reste à faire sur le radiateur est donc de configurer correctement les deux roulettes de puissance. Celle du mode nuit le plus bas possible, est celle du mode jour assez haute pour chauffer la pièce normalement.
Le plus « difficile » pour ce programme, c’est surtout le décodage du fichier texte contenant les données de la sonde de température, et le décodage du fichier de consigne. Oui, piloter une GPIO avec WiringPi, c’est juste tout con.

Le soft final est lancé avec une tâche planifiée (crontab) tous les quarts d’heure, et roulez jeunesse. Ensuite on peut faire un peu tout et n’importe quoi pour rendre le truc plus facile d’accès, comme une interface web pour la configuration du fichier de consigne ou la lecture en live de la sonde de température, histoire que d’autres personnes du foyer puisse modifier le chauffage sans avoir à modifier le CSV via SSH.

Au final j’ai donc un radiateur qui s’allume le matin avant que je me lève, et qui se coupe tout seul quand il fait bon. Mission accomplie, et si je veux utiliser mes autres radiateurs, je n’ai plus qu’à relier les fils pilotes dans mon tableau électrique.

Note de bas de page : quand on touche au 220V, on met le circuit hors tension avec le disjoncteur AVANT ! Si vous mourrez en faisant de la merde dans votre tableau électrique, spa dma faute !


[R-Pi] RPi-kee – Partie 3 : Informatique

by Matthieu

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 ?


[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] Log de température, communication IP et Camera Board

by Matthieu

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 :

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


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