Foedora2 : Différence entre versions

Version actuelle en date du 18 juin 2014 à 16:40

Descriptif du projet, tel qu'il a été imaginé

A partir de recherches artistiques et plastiques sur le milieu routier et le paysage en mouvement vu d'un véhicule, j'ai imaginé une sorte de "machine à mirages" dans laquelle le spectateur peut se perdre. Pour le spectateur, cette installation est composée d'une projection où l'on voit des bâtiments sur un horizon, comme une sorte d'extrait de ville. Selon l'endroit où se déplace le visiteur, les éléments de cette ville bouge d'avant en arrière, de gauche à droite, comme si elle voulait se rapprocher du visiteur lorsqu'il est loin mais s'en éloigner à son approche. Il y a une idée de ville en fuite qui veut entraîner le visiteur avec elle.

Cette ville se déplace de manière particulière : à première vue, elle bouge d'une côté à l'autre sans grande logique, même si un bruit de moteur semble indiquer l'existence d'un système automatisé. En toute logique, il est possible de contrôler vers quelle endroit vont aller les éléments de cette ville, mais il est impossible de créer la même composition de ville dès qu'il y a déplacement. Pour faire plus simple, il est possible de deviner l'existence d'une machine derrière la création de l'image projetée, mais il est difficile d'en comprendre le fonctionnement. Et c'est précisément ce qui m'intéresse.

La machine en question peut être visible par le visiteur dans un deuxième temps : il s'agit d'une sorte de monolithe où trône un petit théâtre qui fait glisser une ville miniature de manière infinie et indéterminée.

Pour illustrer l'origine du titre, je post en même temps l'extrait des Villes Invisibles d'Italo Calvino :

Les villes et le désir

Au centre de Foedora, métropole de pierre grise, il y a un palais de métal avec une boule de verre dans chaque salle. Si l’on regarde dans ces boules, on y voit chaque fois une ville bleue qui est la maquette d’une autre Foedora. Ce sont les formes que la ville aurait pu prendre si, pour une raison ou une autre, elle n’était devenue telle qu’aujourd’hui nous la voyons. A chaque époque il y eut quelqu’un pour, regardant Foedora comme elle était alors, imaginer comment en faire la ville idéale ; mais alors même qu’il en construisait en miniature la maquette, déjà Foedora n’était plus ce qu’elle était au début, et ce qui avait été, jusqu’à la vielle, l’un de ses avenirs possibles, n’était plus désormais qu’un jouet dans une boule de verre.

Foedora, à présent, avec ce palais des boules de verre possède son musée : tous ses habitants le visitent, chacun y choisit la ville qui répond à ses désirs, il la contemple et imagine qu’il se mire dans l’étang des méduses qui aurait dû recueillir les eaux du canal (s’il n’avait été asséché), qu’il parcourt perché dans un baldaquin l’allée réservée aux éléphants (à présent interdits dans la ville), qu’il glisse le long de la spirale du minaret en colimaçon (qui ne trouva plus le terrain d’où il devait surgir).

Sur la carte de ton empire, ô Grand Khan, doivent trouver place aussi bien la grande Foedora de pierre et les petites Foedora dans leurs boules de verre. Non parce qu’elles sont toutes également réelles, mais parce que toutes ne sont que présumées. L’une rassemble ce qui est accepté comme nécessaire alors qu’il ne l’est pas encore ; les autres ce qui est imaginé comme possible et l’instant d’après ne l’est plus."

Italo Calvino, Les villes invisibles, II - Les villes et le désir. 4.

Historique du projet

La première version de ce projet a été travaillé en 2010-2011 alors que j'étais encore en école d'art. En fin de cycle, cette installation était composée d'une surface de captation en volume composé d'une planche sous laquelle se trouvaient des capteurs de pression. Les informations des capteurs transitaient par Arduino, puis Processing, et selon le résultat obtenu, retransitaient par Arduino vers deux moteurs pas-à-pas. L'ensemble des échanges d'informations rendaient l'interactivité lente (entre 10 et 30 secondes de réaction) et l'ensemble de l'installation instable. Ce qui m'amène fatalement à repenser ce dispositif.

Ce qui est inchangé

La version sur laquelle je travaille en ce moment conserve l'organisation des moteurs à l'intérieur de la boîte motorisée : grosso modo une carte Arduino + 2 contrôleurs de moteurs + deux moteurs pas-à-pas. Sur l'axe des moteurs se trouve une bobine en acier type canette de machine à coudre qui va embobiner un fil attaché à la partie "théâtre". Le "monolithe" en lui-même ne changer pas non plus, ni même l'éclairage intérieur, organisé en rangées de leds. Le modèle de webcam est le même.

Ce qui est amélioré

Le plus grand changement réside tout d'abord dans le système de captation en lui-même : exit la planche de capteurs, remplacé désormais par une caméra Kinect© qui va éviter les allers-retours d'informations dans Arduino et permettre une captation plus discrète et plus "souple". La caméra peut être à l'avant, derrière le visiteur ou sur les côtés, selon la configuration de l'espace.

Un autre changement majeur concerne directement les sketches Processing et Arduino puisque le changement du système de captation entraîne le changement du code. D'autres changements sont survenus à cause des moteurs utilisés. En bref, l'intégralité du code a changé.

L'alimentation des éléments électroniques a été également repensé puisque les moteurs et les rangées de leds fonctionne grâce à une alimentation de PC. Seule la carte Arduino peut nécessiter une alimentation externe avec un voltage précis.

Ce qui est à l'étude

Les éléments de ville, d'abord réalisé en papier pour rester dans l'idée d'une "ville-croquis" risquent d'être remplacés par des éléments imprimés en 3D avec un habillage miroitant. On passerait de la ville-croquis à la ville-image. Je reviendrais plus tard sur ce changement qui est encore à l'étude.

L'alimentation de la webcam et la restitution de son visuel risque aussi de se faire "en-dehors de l'ordinateur" : la caméra ne sera plus alimentée par un ordinateur portable via un port USB, mais par une Raspberry Pi. Cette solution m'a été proposée après avoir constaté que le modèle n'était pas compatible avec mon ordinateur.

note du 23 janvier : J'ai testé l'alimentation et la restitution vidéo de la webcam via Raspberry et ce n'est pas une bonne idée quand on veut projeter l'image vidéo en grand : soit c'est trop lent, soit c'est trop pixellisé. Mais une autre solution fait son chemin...

Journal

Avant d'arriver à la Plateforme C

grosso modo :

- janvier - avril 2013 : Je récupère le monolithe et progressivement du matériel pour travailler et reconstruire le dispositif électronique.

- mai - juin 2013 : je réfléchis au nouveau système d'alimentation. A ce stade, la motorisation fonctionne "en pilote automatique" (sans interactivité).

- août - septembre 2013 : je récupère sur caméra Kinect© pour travailler sur l'interactivité de l'installation.

- début novembre 2013 : l'interactivité est fonctionnelle, mais j'ai désormais besoin de tester la mise en espace de l'installation et faire des réglages. L'installation est interactive mais le système de webcam n'est pas installée puisque le matériel est incompatible avec l'ordinateur. J'entends parler de Ping et de la Plateforme C, nouvellement inaugurée.

- janvier 2014 : J'arrive à la Plateforme C pour y travailler, échanger sur le projet et rencontrer des personnes avec qui je vais pouvoir discuter.

Période du 7 au 10 janvier

Je fais connaissance avec les lieux et les personnes qui s'en occupent. On parle du fonctionnement de la Plateforme C, du projet sur lequel je travaille, de ce que je peux tester, améliorer. Rapidement, il est question :

- d'augmenter la réactivité de la machine.

- d'étudier l'éclairage.

- de résoudre le problème que j'ai rencontré avec la webcam utilisé grâce à RPI.

- et faire quelques tests d'impression 3D, pour les éléments miniatures notamment.

- et enfin, de penser à s'habiller d'une couche supplémentaire quand on travaille dans l'atelier l'hiver.

Période du 14 au 17 janvier

Il sera surtout question de faire des tests d'impression 3D sur les machines Asimov et de découvrir Openscad.

Les résultats sont assez mauvais au départ, puis, s'approchent de ce que j'avais imaginé imprimer.

Etant donné que j'avais dessiné des formes géométriques simples (immeubles, maisons miniatures), que j'ai extrudé sur Openscad avec une forme telle qu'il y avait une épaisseur d'un ou deux mm, l'imprimante s'est mise à "baver" sur l'impression, comme si la tête extrudeuse (la "plume" de votre "stylo 3D") frottait la forme dessinée et appuyait dessus. Ce qui fait des angles épais et courbes. Ce qui est fâcheux...

Une solution m'a été proposée par Laurent, et dans mon cas, elle fonctionne : la forme "intérieure" qui va "creuser" la forme extérieure donne un meilleur rendu si elle est différente. Pour le dire plus précisément, j'ai creusé mon pavé avec un cylindre, ce qui fait que la machine a dû remplir les 'pleins" laissés par le cylindre en question. Et donc, fini les bavures. Je mets les résultats en image pour que ce soit plus explicite.

Une fois ce problème résolu, je réfléchis à une manière de "lisser" la forme imprimée. Comme vous l'avez vu sur l'image, la dernière réalisation est habillée d'un adhésif type "miroir sans tain". Or le moindre relief se voir sous l'adhésif. Lorsque vous imprimez une forme en trois dimensions, vous avez donc un extrudeur qui pose une matière plastique (je n'ai plus le nom exact en tête...) comme un stylo qui pose un fil plastique dans l'espace, ce qui entraîne des stries, mêmes petites. Selon l'usage que l'on a de la pièce après, les stries peuvent tout à fait ne pas gêner, mais en ce qui me concerne, j'ai besoin d'une surface très lisse. Voici en image le résultat de formes imprimés dès la sortie de l'imprimante :

J'ai testé rapidement le ponçage au papier de verre et l'acétone : l'acétone déforme l'impression et la blanchit, le ponçage blanchit la forme et la réduit légèrement.

A tester plus tard : l'ajout d'une couche de résine Epoxy que l'on travaille après.

Période du 21 au 24 janvier

Rasperry Pi et webcam

Comme indiqué un peu plus haut, je souhaite cette semaine découvrir et tester la Raspberry Pi pour récupérer en temps réel ce que "voit" une webcam, ce qui me permettrais de m'affranchir d'un ordinateur pour cette partie de l'installation. Le matériel en résumé :

Une carte SD (minimum 8 Go pour être à tranquille)

Un câble Ethernet

Un câble micro-USB vers USB

Un clavier et une souris USB standard

Un hub USB avec alimentation séparée (si vous souhaitez brancher d’autres périphériques, genre disque dur auto-alimenté)

Un cable HDMI (Si vous souhaitez le brancher à un écran

source : http://www.libellules.ch/phpBB2/debuter-avec-le-raspberry-pi-t40775.html

Après m'être fait prêté une grande partie du matériel (merci Baptiste!), je découvre l'environnement Linux avec la Raspberry Pi. Mettre le clavier en AZERTY peut vous demander une demi-heure, si, comme moi, vous n'êtes pas familier avec l'écriture dans le terminal. Mais on y arrive.

Pour lire le modèle de webcam que j'avais, j'ai installé les logiciels uvc, et guvcview. On a tenté des choses avec le logiciel cheese, sans succès dans mon cas.

En ce qui concerne le résultat, je suis arrivé là où je souhaitais arriver : récupérer les images d'une webcam pour les projeter sur un écran, ou un vidéoprojecteur. Si la surface de projection est petite, ce procédé est parfait pour s'affranchir d'un ordinateur. En revanche, si vous attendez de la qualité d'image et de la réactivité, Raspberry Pi ne sera malheureusement pas la solution qu'il vous faut : j'ai obtenu soit une image mal définie, soit une image lente. Or je sais que la webcam en question peut faire mieux.

J'arrête donc pour le moment mes explorations sur RPI, mais je dois reconnaître que les possibilités sont alléchantes.

On songe actuellement à une solution via Linux avec une ancienne tour.

Un lien interresant si vous souhaitez découvrir l'univers Raspberry Pi :

https://sites.google.com/site/blainoperso/debuter-avec-raspberry-pi/petit-lexique-linux

Période du 28 au 30 janvier

Je récupère les impressions des "façades" chez un graphiste de Rezé : le résultat est juste au-delà de mes espérances!

Je pense donc partir sur ce type d'éléments de maquette, miroitantes avec un tracé blanc.

Finalement, le limage des pièces s'est fait "à la main" : lime pour dégrossir, puis papiers de verre avec un grain très fin pour finir. Après je vérifie que tout soit bien limé au toucher : on doit avoir l'impression d'avoir un savon entre les doigts!

Sinon pour résoudre le problème qui vient de la webcam, j'ai mis la Raspberry Pi de côté, pour les raisons évoquées plus haut. Olivier avait laissé un ordinateur désossé à la Plateforme C. On y a jeté un oeil, mais impossible de l'allumer, bien que nous ayons ajouté les pièces manquantes de l'ordinateur (RAM et disque dur). On a testé plusieurs types de disques durs, mais sans succès...

Le 7 février

Je fais un bref passage à la Plateforme C dans la matinée : un autre ordinateur serait disponible (type notebook), avec juste l'écran cassé. Cedric tente actuellement de mettre Linux sur une carte SD pour faire fonctionner la bête. Affaire à suivre...

Au mois de mars

Après quelques passages sur Nantes où j'ai pu apprécier le nouveau sol de la fablab, je peux confirmer que la webcam fonctionne désormais grâce à un notebook sous Linux! Le problème de la webcam est donc réglé! Toutefois, quelques frayeurs : au moment de faire une démonstration, j'ai le message suivant :

"A fatal error has been detected by the Java Runtime Environment:

SIGILL (0x4) at pc=0x0000000157fe00b4, pid=472, tid=50203

JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)

Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 compressed oops)

Problematic frame:

C [libfreenect.0.1.2.dylib+0x40b4] freenect_camera_init+0x178

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

An error report file with more information is saved as:

/Users/xxxxx/Documents/Processing/libraries/SimpleOpenNI/library/osx/hs_err_pid472.log

If you would like to submit a bug report, please visit:

http://bugreport.sun.com/bugreport/crash.jsp

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug."

Sueurs froides sur le coup...

Je viens de trouve le problème, si jamais cela vous arrive. Je vous invite à jeter un oeil ici : http://forum.processing.org/two/discussion/873/error-when-trying-to-run-sketch-with-simpleopenni/p1

Et plus particulièrement à suivre ce lien là : https://github.com/kronihias/head-pose-estimation/tree/master/mac-libs

où vous trouverez deux éléments à remplacer ("libfreenect.0.1.2.dylib" et "libusb-1.0.0.dylib") dans "Processing/library/SimpleOpenNI/library/osx/OpenNI2/Drivers/" ou quelque chose du genre.

Autre information importante : il y a eu des changements dans la dernière version de SimpleOpenNi!

Du coup, quelques points à changer :

"context.enableScene()" devient "context.enableUser()"

"context.sceneImage()" devient "context.userImage()"

et vous pouvez supprimer la ligne "context.enableUser(SimpleOpenNi.SKEL_PROFILE_NONE);"

A confirmer lors des prochains tests sur place, mais ces manips ont résolu les bugs du moment.

J'espère bientôt pouvoir vous faire partager le code, et peut-être un début de vidéo la prochaine fois.