antistress : Un nouveau podcast dédié aux logiciels libres. Le sommaire du 1er numéro laisse apercevoir un contenu dense : tant mieux ! Je ne l'ai pas encore écouté faute de temps, mais ça ne saurait tarder ;)
antistress : "Disponible depuis fin juin sur diverses plateformes de vidéo à la demande mais aussi sur BitTorrent en toute légalité, le documentaire sur la vie d'Aaron Swartz, un activiste américain qui a trouvé la mort au début de l'année 2013".
antistress : "À Toulouse, le personnel de la ville a procédé à la migration de nombreux postes de travail afin de remplacer la suite bureautique propriétaire Microsoft Office par une solution libre. Cette bascule vers LibreOffice a permis de faire économiser à la ville pas moins d'un millions d'euros en trois ans."
« La numérisation se focalise sur le texte et néglige souvent les images. »
Nous nous en faisons régulièrement l'écho pour nous en féliciter : de plus en plus de livres du domaine public sont numérisés et, à ce titre, Internet Archive constitue sans conteste l'un des plus gros dépôts au monde.
Cette numérisation gagne chaque année en intelligence, avec notamment le renseignement des métadonnées et les possibilités de la recherche plein texte qui facilitent leur consultation. Mais il n'en va pas toujours de même pour les nombreuses illustrations (croquis, dessins, cartes, photographies...) qui accompagnent ces ouvrages. Elles sont en effet trop souvent liées aux livres qui les contiennent, peuvent ne pas avoir de légende et échappent aux finesses de l'OCR.
D'où l'idée brillante de l'universitaire Kalev Leetaru de développer une application pour aller chercher les images des quelque 600 millions de pages des livres de la bibliothèque numérique d'Internet Archive pour les extraire et les indexer séparément dans un espace dédié, en l'occurrence la plateforme Flickr. Le projet prévoit d'en télécharger 14 millions et nous en sommes déjà à 2,6 millions !
Un soin tout particulier a été apporté aux éléments connexes à l'image permettant de l'identifier et de la trouver plus facilement. Sur cet exemple, révélant par ailleurs que les chatons ont existé avant Internet, on peut ainsi constater la présence de nombreuses informations en bas du document.
Titre, auteur, date, éditeur, catégories, tags, texte du livre parent apparaissant juste avant et juste après l'image... sont autant de données utiles à son référencement. Sans oublier bien sûr des liens permettant de consulter intégralement, sur Internet Archive, le livre numérique d'où est extraite l'illustration.
Du coup si vous voulez d'autres illustrations du même livre c'est ici ou, plus généralement, de livres édités en 1907, c'est là. Quant aux chats de tout Internet Archive, il suffit de suivre ce lien ;)
Elles sont à disposition de tous sous la mention « Aucune restriction de droits d'auteur connue », ce qui signifie qu'elles appartiennent toutes au domaine public [1].
Je suis parti en vacances (en Bretagne !) pendant toute une semaine et figurez-vous que ça m'a empêché de "flasher" mon téléphone, mon Flame sous Firefox OS 2.0. Lorsqu'un bidouilleur comme moi se retrouve avec un téléphone bidouillable, il bidouille. Une semaine sans rien toucher, ça n’était pas arrivé depuis la livraison du téléphone.
Une semaine, donc, c'est la période pendant laquelle j'ai pu tester la version 2.0 du système d'exploitation de la fondation Mozilla. L'interface, les nouveautés, les améliorations depuis la version 1.3 livrée avec le téléphone, tout ceci est passé entre mes mains. Résultat : c'est génial, ou presque.
L'interface de la 2.0 est très agréable. Je ne me vois plus retourner en 1.3 ou 1.4. Je suis franchement satisfait. C'est une vraie réussite par rapport à l'ancienne version que je trouvais quand même austère.
L'appareil photo est bien plus utilisable : l'auto-focus est de la partie et c’était tout ce qu'il manquait à ce téléphone. Les applications Calendrier et E-Mail sont une franche réussite. Ce sont celles que j'utilise le plus et je suis ravi de l'attention portée à leur design.
Du côté des soucis, je suis quand même tombé sur des redémarrages sauvages. Je ne sais pas pourquoi ni comment. Soit le téléphone plantait soit les poches étaient trop étroites et j'appuyais sur les boutons sans m'en rendre compte. L'appareil photo plantait aussi de temps en temps, un redémarrage était obligatoire pour le récupérer. Pour le reste, pas de souci.
En revenant, j'ai tout de suite flashé mon téléphone et c'est l'autonomie qui s'est révélée être au rendez-vous. Plus besoin de recharger son téléphone pour lui faire passer la nuit, enfin !
Je garde mon ZTE Open C que j'ai confié à mon tendre père histoire d'avoir son avis de novice et un téléphone de référence. Je ne me vois plus l'utiliser en l’état : son interface 1.3 me rebute presque. De son cote, il découvre les smartphones via ce téléphone et il s'amuse comme un petit fou.
Je suis aussi parti pour une week-end à la Capitale en train : la belle occasion ! Dans le train, entre l'envoie de SMS pour m'orienter en prévision du débarquement Gare de l'Est, l'utilisation de FreshRSS, l’écoute de musique mais aussi quelque parties de Age of Barbarians et 2 appels : rien a signaler. Le téléphone n'a pas disjoncté.
J'y reviendrais plus tard mais il me parait évident que si Mozilla veut faire le malin avec son OS, il devrait commencer par des téléphones performants livrés avec la version 2.0 de son Firefox OS. Maintenant qu'il est bien placé en low-cost avec son téléphone à 1999 roupies, il va falloir avancer vers le moyen/haut de gamme.
Je termine par dire que je pars sur une petite ile française pendant encore une semaine et que, of course, je prendrais mon téléphone pour lui faire faire tout et n'importe quoi ! La vie est si dure... ;-)
Il y a presque un an je finissais Discovery, mon premier robot autonome. Le passage au hackathon Nao 2013 de la Cité des Sciences a considérablement changé ma vision de la robotique domestique : connexion à Internet, interaction avec son environnement et l’Humain. Construire mon nouveau robot m’a appris plein de choses
J’avais gagné un Arduino-compatible grâce à un concours DFRobot, gracieusement expédié par un revendeur français. Peu après Guillaume m’avait offert un Raspberry Pi B ainsi qu’un boîtier qu’il avait imprimé en 3D avec le matériel de sa boite. Il ne m’a pas fallu très longtemps pour savoir quoi en faire : lisez la suite pour le découvrir !
Définir les grandes lignes d’un projet est le moment le plus excitant : tout est possible. Faire un brainstorming avec soit même prend des semaines, c’est un moment de la vie où les idées fusent et se croisent à tout moment de la journée, surtout quand on n’a rien pour noter. Certains environnements sont plus adaptés que d’autres au développement de l’imagination et l’important est de vous y sentir détendu.
Concept initial
En terme d’objectif, je me suis inspiré de mon expérience sur Nao. À ce jour, j’aimerais beaucoup découvrir le framework libre de Darwin-OP que l’on devrait retrouver sur un dérivé nommé Jimmy. En attendant voici ce que j’ai dégagé pour mon proof of concept :
pilotage par le réseau à l’aide du protocole HTTP
interface web de contrôle à l’aide de joysticks virtuels tactiles
bouton de connexion permettant à un seul utilisateur à la fois de piloter
retour vidéo d’une webcam embarquée sur une page publique pour tous le monde
Et plus tard :
une page de statistiques (graphs de températures, uptime, load average, load en fonction du temps, …)
reconnaissance vidéo à l’aide d’OpenCV (suivi d’objets, de visages, …)
IA de pilotage automatique par reconnaissance vidéo
reconnaissance d’empreintes sonores à la Shazaam pour avoir des commandes en jouant des sons depuis un téléphone
text to speech pour signaler son état (IP, position, objets reconnus)
speech to text pour avoir des commandes vocales
amélioration de l’IA pour être capable d’apprentissage
Le code a été pensé dès le départ avec ces impératifs et découpé en modules indépendants exécutés dans des threads. Ce planning est prévisionnel et a encore le temps d’évoluer d’ici que je trouve le temps d’y arriver.
Pour y parvenir, j’ai choisi de placer toute l’intelligence du robot dans un programme exécuté sur le micro ordinateur embarqué. L’Arduino a pour rôle de faire ce qu’on lui dit et reçoit ses ordres du programme via son port USB. Le Raspberry Pi peut ainsi servir pour exécuter bien d’autres fonctionnalités : serveur Web, streaming de webcam, base de données et pourquoi pas une centrale domotique !
Liste de courses
Il faut tout d’abord se construire un châssis avec une plateforme roulante de votre choix. Moi j’ai réutilisé des Meccano de mon enfance mais j’ai aidé des amis à se servir de vieilles voitures radiocommandées. Si vous n’avez rien de tout ça chez vous, pas de panique : soyez inventif, allez sur un site de petites annonces et cherchez des occasions type robot aspirateur. Voici les composants dont je me suis servi :
Une variante de l’Arduino Leonardo appelée DFRobot Romeo v2. Elle a l’avantage de proposer une multitude d’interfaces pour connecter des servomoteurs, deux borniers moteurs ainsi que deux borniers d’alimentation externe pour moteurs et servos
une batterie de modélisme à connecter dessus
un servo moteur pour orienter une webcam
Un micro-ordinateur type Raspberry Pi B, assez puissant pour faire de l’encodage vidéo (matériellement en H264)
une batterie de rechargement USB possédant au moins deux ports USB, dont un de 1A et l’autre de 2A, par exemple une RAVPower 14000mAh
un hub à alimentation externe, par exemple un D-Link DUB H4, pour alimenter les périphériques connectés au Pi
un cordon USB A mâle vers DC 5.5×2.1mm pour alimenter le hub D-Link avec la batterie sur le port USB 2A
deux cordons USB vers Micro USB pour relier l’Arduino au Hub et le Raspberry au port 1A de la batterie
une webcam
Il est important de séparer l’alimentation du circuit informatique de celle du circuit « de puissance » car les moteurs provoqueront des appels de courant, et par conséquent des chutes de tension pouvant amener le circuit de commande à redémarrer aléatoirement. Voici de bons vieux schémas :
Commencer par le début
J’aime beaucoup avancer par petites itérations. Installer le Raspberry Pi et écrire un programme Arduino basique sont les deux premières choses que j’ai faites. Cela m’a permis de tester le bon fonctionnement de mon matériel, batteries et moteurs. Paramétrer le Raspberry Pi en Wifi m’a demandé quelques recherches supplémentaires pour profiter des avantages du roaming et ainsi ne plus avoir à jongler entre mes différents points d’accès.
Puis j’ai commencé à faire des choix techniques. Ayant choisi de faire mon programme en Python, j’ai d’abord planché sur un moyen de piloter la carte Arduino. Cela se fait très simplement via la bibliothèque Nanpy, livrée avec un firmware à téléverser sur l’Arduino. J’ai fait un article séparé pour la présenter et la comparer avec les solutions alternatives utilisant le firmware Firmata.
J’ai ensuite réfléchi à la manière dont piloter la carte Raspberry Pi (qui pilote à son tour l’Arduino, vous suivez ? :D). Ce problème revient à se demander comment transmettre de l’information entre deux ordinateurs modernes, ce qui est relativement trivial. J’avais déjà bien assez de pain sur la planche pour me lancer dans la rédaction de mon propre protocole (même basique) qui aurait impliqué un client spécifique pour communiquer.
Au lieu de ça, j’ai choisi le bon vieux protocole HTTP pour mille raisons : implémentations à foison sur tout type de terminaux, support dans tous les langages, livré avec un langage de balisage et un langage de script qui permettent de créer très rapidement des interfaces, etc.
J’avais besoin d’une bibliothèque légère, très basique, simple à utiliser. J’ai choisi Bottle pour cette tâche. Là encore, j’ai rédigé un article séparé pour comparer les autres solutions trouvées.
Il m’a fallu trouver une base de données, car Bottle ne gère pas le stockage de session. La contrainte de travailler sur un système installé sur une carte SD sont les accès en écriture : ils usent le support et ralentissent le système. J’ai pris Redis principalement pour son stockage volatil en Ram : les écritures se font sur demande ou à la fermeture de la base. Le risque de perdre des données existe mais un robot ne manipule aucune donnée critique. C’est une base NoSQL de type clé/valeur, on y stocke donc des variables (hash compris) et c’est tout !
Pour finir, il me fallait pouvoir contrôler l’API que j’avais l’intention de créer (une simple URL retournant une page vide dont les paramètres transmettent la direction des moteurs à faire appliquer par le serveur) sur tout terminal supportant HTML5, tactile compris. Je me suis orienté vers virtualjoystick.js, une superbe petite bibliothèque de joysticks virtuels qui fonctionne parfaitement sur mon téléphone Firefox OS ainsi que sur PC à l’aide d’une souris. Comme à mon habitude, j’aime prendre le temps de comparer les alternatives, c’est chose faite.
La gestion du streaming vidéo de la webcam a été tranchée trop tardivement pour pouvoir être mise en place dans les temps. Il me fallait quelque chose d’intégrable dans une page web, transportable par HTTP. Peu de formats vidéo répondent à cet impératif. Voici le dilemme : vous avez une application qui s’ouvre dans n’importe quel navigateur, mais aucun standard n’impose le format vidéo:
OGV, libre mais inefficace en qualité et en poids ?
WEBM, touché par des brevets, Open Source mais plus gourmand ?
MP4, criblé de brevets mais souvent supporté matériellement ?
Pour avoir expérimenté avec un flux vidéo en 280p, l’encodage est quelque chose de très consommateur pour un processeur ARM11. Le Raspberry Pi n’en est tout simplement pas capable. En revanche il dispose d’une puce dédiée à ce travail, capable d’encoder/décoder du 1080p en MP4. Reste à trouver une application permettant de le réaliser, pour l’heure à ma connaissance seul le logiciel gstreamer sait le faire (API OpenMax). Hors c’est une telle usine à gaz qu’il m’a été impossible d’en comprendre le principe.
J’ai contourné le problème et me suis rabattu sur le format le plus universel à ce jour : le Motion JPEG (ou mjpeg), un flux d’images jpg indépendantes qui se remplacent les unes les autres dans la balise HTML img. Oui, c’est moche. VLC sait faire cela via son utilitaire en lignes de commande cvlc. L’inconvénient : il me semble que les images sont écrites sur le support de stockage au lieu d’être acheminées directement de la caméra sur le réseau. J’ai rédigé un billet entrant un peu plus loin dans le débat des formats vidéo pour HTML5.
Lancer des programmes externes et communiquer avec eux via un pipe se fait très bien avec le module subprocess de Python. À terme, OpenCV devrait venir s’intercaler entre la source vidéo et le flux streamé pour déterminer comment diriger le robot, comme l’illustre le schéma ci-dessous :
Des tests au déploiement
On se retrouve vite à vouloir faire exécuter son programme par le Raspberry Pi plutôt que par l’ordinateur qui sert au développement. Plusieurs méthodes pour cela :
coder directement sur les fichiers présents sur le Raspberry Pi au travers d’SSHFS (leeeent)
coder depuis un ordinateur, pusher sur GIT, ouvrir un terminal et puller les révisions sur le Raspberry Pi
coder depuis un ordinateur et utiliser un script « hook » post-push pour déclencher un pull sur le Raspberry Pi
J’ai jusque là exclusivement utilisé la seconde option, la troisième serait bien plus commode mais je ne vois pas comment la mettre en place sachant que l’IP du robot change selon les points d’accès Wifi.
Une fois en place, il ne reste qu’à gérer l’envoi d’un mail contenant l’URL de l’interface web pour faire d’une pierre deux coups : connaître l’IP de la machine et pouvoir tester l’interface web. Python le fait nativement en moins de dix lignes.
Dernière chose à ne pas oublier : automatiser le lancement du programme. Deux écoles : crontab et /etc/init.d/ j’ai choisi le crontab @reboot qui se lance à chaque démarrage du système d’exploitation.
Choix d’une licence
C’est la première fois que je distribue un Logiciel Libre. Libre de droit, libre de mon droit d’auteur. Proposer les sources ouvertes de ce projet est une démarche pédagogique, les proposer avec une licence permet à quiconque de les modifier, de les partager, de les vendre au travers d’une page dans un magazine, d’un blog contenant de la publicité. La licence que j’ai choisi pose quelques conditions à cela dont l’une est de conserver la paternité.
Poser un cadre légal pour quelques lignes de code n’est pas utile à proprement parler. Ce que j’ai créé existe en partie parce que toutes les briques que j’ai utilisé sont libres. Par contre j’aime beaucoup l’idée qu’une communauté puisse se former autour d’un projet, c’est pour cela que je tiens à diffuser la paternité du code : retrouver l’auteur originel pour discuter avec lui n’est possible que si tout le monde joue le jeu en passant le flambeau.
Choisir une licence est quelque chose de difficile, on peut remercier les auteurs de choosealicense et de Veni Vivi Libri. Je voulais quelque chose de permissif et simple à comprendre. La Simplified BSD License, datant d’avant la reconnaissance des brevets logiciels aux US, est une licence non copyleft en opposition à la GPL. J’aimais bien l’idéologie, mais je m’attendais à quelque chose moins brut de décoffrage, de plus sympa.
Je me suis attelé à mettre en place la CeCILL-B en anglais, la FAQ explique cela très bien. C’est une transposition de la philosophie de la Simplified BSD License en droit français, avec une préoccupation plus prononcée pour le respect de la paternité ainsi qu’un engagement du créateur qu’en cas de litige, 30j de délais seront accordés avant résiliation du contrat. Les licences CeCILL proposent aussi une version de la GPL et LGPL en droit français.
La première étape est de vérifier qu’aucune bibliothèque utilisée n’est publiée sous une licence incompatible (ex: une copyleft, qui interdit de sous licencier du code). Bottle, Redis-py et virtualjoystick.js sont sous MIT, une licence quasi identique à la Simplified BSD License. Il faudrait ensuite s’assurer la paternité et l’antériorité de l’œuvre en la protégeant de diverse façon décrites sur cette page. Merci aux auteurs de cette mine d’infos.
Bien que tout soit public sur Internet, ce que nous produisons peut être défendu par la juridiction française dans la mesure où le site causant l’infraction est accessible depuis la France et hébergé dans l’un des États membres de l’UE. En dehors, il appartiendra au pays du site fautif de reconnaître la juridiction française (indiquée par la licence CeCILL). Utiliser une licence garanti donc avant tout que vous concédez la libre exploitation de vos œuvres. Expliciter ses intentions est même une condition sine qua non à toute nouvelle production de Logiciel Libre : les entreprises ont besoin de sécurité.
Présentation des résultats
Voici finalement la raison d’être de cet article : le code source ! (on me souffle dans l’oreillette que le site est lent, n’en voulez pas à ma Freebox)
Guide d’installation : sur le lien ci-dessus vous trouverez un bouton « Download zip », dézippez, ouvrez une console, tapez « ./main.py », et voilà Visitez http://127.0.0.1:8080 et admirez. N’ayez pas peur de regarder le code, le Python se lit facilement.
J’ai réalisé trois vidéos durant le développement :
Ce n’était pas facile de filmer et de faire la démo en même temps, d’autre part je n’ai retrouvé chez moi que d’antiques batteries de modélisme qui n’avaient pas été entretenues pendant plus de sept ans. Le résultat n’est pas super réactif j’en conviens !
Pour aller plus loin
Je ne me suis pas tout de suite attelé à la gestion audio du port Jack en Python, mais il serait cool de pouvoir parler dans un micro qui soit émis dans des enceintes branchées sur le robot. J’ai listé en début d’article ce que je pourrais faire par la suite, il faudra patienter un peu.
Il me reste un tas d’applications à essayer, j’attends surtout vos réactions et vos sentiments sur ce projet pour glaner de nouvelles idées. À bientôt !
Ce samedi, des bénévoles de la communauté Mozilla française sont présents dans des magasins Leclerc qui distribuent le smartphone ZTE Open C sous Firefox OS, dont nous vous avions parlé cet été.
Tous les magasins de cette chaîne ne sont pas concernés, loin de là, mais dans ceux qui ont bien voulu accueillir les démonstrateurs de Firefox OS, les réactions semblent positives. Selon un message envoyé sur la liste de diffusion MozFr, les clients sont avant tout attirés par le petit prix de ce smartphone.
« Encore un de vendu ! »
Espérons que cette initiative sympathique permettra aux clients potentiels de réaliser qu’il ne s’agit pas que d’une affaire de prix, mais également que Firefox OS est un système de smartphone plus ouvert.
Merci aux bénévoles et bon courage à eux (« que le réseau soit avec vous ! »)
Visitez 
