bleugafoto

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

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

Thursday 13 February 2014 à 11:19

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 !

[Voyage][Photo][Vidéo] Scanditrip

Friday 24 January 2014 à 10:43

Tiens, en cherchant un truc sur mon ordi, je suis retombé sur des souvenirs de mon p’tit voyage vers le lointain en Mai 2013, que je me permet de partager un peu à l’arrache :

Donc, en résumé, en Norvège on trouve en autre :

Des rennes (surtout en Mai en fait):



Le phare de Slettnes (le plus septentrionale du continent européen) :


Et également des routes avec pas grand chose autour :


Et une vidéo, aussi…

YouTube Preview Image

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

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

Travaux sur la box

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

Travaux sur RpiWeb

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

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

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

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

Capteur de température sur RpiAcq

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

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

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

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

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

CameraPi sur RpiAcq

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

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

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

Moteur pas-à-pas sur RpiAcq

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

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

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

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

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

RIP Brian

Monday 2 December 2013 à 10:27

Je ne pouvais pas ne pas en parler, tant Brian est mon idole.
uppix.net
uppix.net
uppix.net
uppix.net
Oui, j’ai pas cherché très loin les images, mais bon, c’est quand même pas du grand cinéma non plus hein…

NFS Shift 2 - CarPorn

Monday 29 July 2013 à 15:35

Un moment de solitude, une bande originale qui m’inspire, et voilà…

YouTube Preview Image

Décidément, faut que j’arrête de regarder Fast & Furious, ce film causera ma perte.