Tentative exploratoire de filage de soie d’asclépiade

Frederik Projet Asclépiade

J’ai fait une première tentative de filage de l’asclépiade en plaçant du médium glacis clair dans un pot en plastique, suivi par des soies. C’était davantage un test exploratoire pour débroussailler la suite des choses.

J’ai tout d’abord essayé de mélanger le tout à l’aide d’un bâton, puis l’idée m’est venue d’enrouler le début de l’accumulation de soie autour, afin d’avoir une base solide. En rajoutant progressivement des soies au mélange et en tournant le fil imbibé d’adhésif dans le pot, j’ai obtenu une manière de filer les soies en un fil potentiellement infini, tant que les paramètres sont bien contrôlés.

Tout porte à croire qu’en contrôlant le flux de soie et d’adhésif, un fil très fin pourrait être produit.
Le bout opposé au bâton, lorsqu’il ne restait plus de médium glacis clair dans le pot.
Le fil dans toute sa longueur, est un peu rigide par endroits à cause de son épaisseur
Les fibres sont bien maintenues ensembles.

En enroulant la fibre autour du bâton, j’ai pu continuer presque indéfiniment, n’étant limité que par la quantité de médium dans le pot. Ensuite, je l’ai déroulé au complet et accroché pour laisser sécher. Toutes ces étapes devront être bien contrôlées dans un prototype éventuel.

Piano midi avec fluidsynth

Frederik midi

J’ai installé Ubuntu Studio sur une tour pour faire un piano midi qui s’ouvre automatiquement.

Voici le script bash que j’ai adapté d’ici : https://superuser.com/questions/1291367/bash-condition-not-met-when-executed-by-crontab

#!/bin/bash
sleep 60
echo "Starting"
/usr/bin/fluidsynth -is -a jack -j -m alsa_seq /home/fred/Nice-Keys-Ultimate-V2.3.sf2 &
echo "Fluidsynth started"
while true; do /usr/bin/aconnect -o; if [[ $(/usr/bin/aconnect -o ) = FLUID ]]; then break; fi; sleep 2; done
/usr/bin/aconnect 20:0 128:0
echo "Connected"

J’ai rajouté un sleep 60 pour attendre que l’os ait fini de démarrer comme du monde, sinon il y avait des erreurs bizarres (probablement qu’il faut que la carte de son soit chargée avant d’exécuter le script.

Ensuite, j’ai ajouté ceci dans la crontab :

@reboot bash /home/fred/pianolauncher.sh >> /home/fred/out.log 2>&1

où pianolauncher est mon script ci-haut. Ça fonctionnait lorsque mon écran était connecté, mais sans écran, il y avait un bug. Il faut ajouter la ligne suivante au fichier /etc/environment :

JACK_NO_AUDIO_RESERVATION=1

Eh voilà! Un piano avec une latence très faible grâce au kernel préemptoire d’Ubuntu Studio, qui s’ouvre automatiquement sans besoin d’avoir d’écran, avec une librairie de sons vraiment géniale!

Test de plusieurs adhésifs sur l’asclépiade

Frederik Projet Asclépiade

En mars dernier, je suis passé dans un magasin d’art pour acheter des échantillons de toutes les colles et adhésifs que j’ai pu trouver, afin de les tester sur la fibre d’asclépiade. La seule contrainte était qu’ils devaient être sous forme liquide et pouvoir sécher à l’air libre. Quelques mois ont passé sans que je tente l’expérience, mais cette semaine fut la bonne! Les résultats m’ont grandement surpris.

Premièrement, je vais commencer par expliquer ma méthodologie. J’ai utilisé des grilles en coton, communément appelées tissu à fromage, comme substrat de base pour emprisonner les fibres, qui sont très volatiles rappelons-le. Une fois les fibres bien placées, j’appliquais la colle généreusement, en tâchant de bien la mélanger aux fibres. Dans mon premier essai, des fibres se sont échappées et j’ai tâché de les rassembler pour former un fil, ce qui a très bien fonctionné. Voyons voir les résultats un par un. J’utilise des critères subjectifs de flexibilité, résistance à l’eau, toxicité et confort afin d’effectuer la comparaison.

Colle à bois

Lorsqu’elle n’est pas sèche, la colle à bois (Colle blanche multi-usage Lepage) semble être l’adhésif idéal. Les fibres s’y mélangent parfaitement, leur comportement est surprenant  puisqu’on est habitué qu’elles soient fortement hydrophobes (mais la colle ne contient visiblement pas d’eau). On peut facilement façonner un fil qui tient bien. Cependant, on déchante un peu une fois séché. Le résultat est extrêmement cassant, comme si la colle a trop attaqué chimiquement les fibres.

Flexibilité : 1/5

Résistance à l’eau : Oui

Toxicité : Non

Confort : 2/5

Mod Podge

Le Mod Podge (Mod Podge fini mat) est beaucoup plus liquide à l’application que la colle, et donne l’impression de moins bien tenir sur la fibre, probablement parce qu’il contient de l’eau. Par contre, une fois séché, le résultat est impressionnant : les fibres conservent leur souplesse et leur brillance, tout en ayant plutôt bien fusionné. Seul hic : il se dissout complètement une fois plongé dans l’eau, ce qui empêche son usage dans le textile.

Flexibilité : 3/5

Résistance à l’eau : Non

Toxicité : Non

Confort : 4/5

Medium glacis clair

Le medium glacis clair (Jo Sonja clear glaze medium surface sealer) a une viscosité qui se situe entre celle de la colle et du modpoge, et ressemble à une peinture transparente. On peut facilement façonner un fil à la manière de la colle. Une fois séché, le fil garde sa souplesse et sa brillance, ce qui signifie que la fibre est peu attaquée. Problème : ne se trouve plus au Omer DeSerre.

Flexibilité : 3/5

Résistance à l’eau : Oui

Toxicité :  contient du propylène glycol et de l’hydroxide d’ammonium (aucune idée de la concentration), mais je ne sais pas si c’est toxique, ça semble être correct.

Confort : 4/5

Médium textile

Le médium textile (Ceramcoat médium textile) ressemble beaucoup au médium glacis clair. Cependant, il ne permet pas de façonner aussi bien un fil à l’application. Une fois séché, la fibre conserve ses propriétés. Il ne résiste pas vraiment bien à l’eau, bien que je n’ai pas suivi le protocole de l’étiquette disant qu’il faut attendre 7 jours avant de laver le tissu (trop long, à un moment donné).

Flexibilité : 3/5

Résistance à l’eau : Non

Toxicité : Non

Confort : 4/5

Peinture acrylique pour cuir

La peinture acrylique pour cuir (DecoArt Patent Leather Paint) a été un essai chanceux puisque visiblement, ce produit est fait pour être utilisé sur du cuir, qui a des propriétés bien différentes des fibres de l’asclépiade. Pourtant, un peu comme avec la colle, les fibres semblaient directement se prêter à la fabrication d’un fil dès l’application. Une fois séché, la couleur bleue reste vraiment tenace. Les fibres conservent une flexibilité et semblent même beaucoup moins cassantes qu’à l’origine.

Flexibilité : 3/5

Résistance à l’eau : Oui

Toxicité : Non

Confort : 3/5

Colle caoutchouc

La colle caoutchouc (Elmers) a été choisie plutôt dans une tentative d’être exhaustif et de ne laisser de côté aucune alternative, bien que son caractère poison et inflammable soit rébarbatif. À l’application, une odeur forte se dégage, mais j’avais prévu le coup en plaçant mes tests dans une pièce à part et bien aérée. Cela vient avec un pinceau et je ne l’ai pas autant manipulé que les autres, ce qui laisse la comparaison un peu délicate. Un fois séché, les fibres sont bien collées, bien qu’il ait été difficile de les enrober complètement d’adhésif. Elles conservent parfaitement leur propriété hydrofuge.

Flexibilité : 4/5

Résistance à l’eau : Oui

Toxicité : Oui ++

Confort : 2/5

Conclusion

Pour mon application, qui est d’éventuellement faire un textile d’asclépiade, seuls deux adhésifs ont passé le test : le médium glacis clair et la peinture acrylique pour cuir. Ils ont en commun de fonctionner sur une base d’acrylique, qui semble avoir une bonne compatibilité chimique avec la cellulose de l’asclépiade. Ce sera donc à investiguer davantage, mais je crois avoir bien cerné mes recherches. Le hic, c’est que ce sont deux produits assez chers (4,5$ pour 60ml), mais probablement qu’une très faible quantité est véritablement nécessaire pour bien coller les fibres, dépendamment de la méthode d’application qui reste bien évidemment à optimiser. Le fil résultant sera donc inévitablement un composite synthétique-asclépiade, avec tous les avantages et inconvénients que cela comporte. La capacité d’utiliser des peintures colorées est tout de même très intéressant, et la résistance accrue aux contraintes mécaniques que confère l’adhésif permet de rendre filable une soie extrêmement fragile et lisse, tout en conservant ses propriétés isolantes et hydrofuges.

Synchronisation des DEL avec le signal vidéo

Frederik Électronique, Oxymétrie

Afin de bien pouvoir séparer les signaux de ma caméra oxymétrique, je dois trouver un moyen pour synchroniser les DELs avec l’acquisition des images. L’objectif est d’alterner les prises de vue entre un éclairage avec la DEL rouge et avec la DEL infrarouge, sans que les signaux se chevauchent. Le hic, c’est que la caméra que j’utilise n’a aucun trig externe : toute l’électronique de contrôle est intégrée, laissant seulement le signal vidéo analogique en sortie.

Mon premier essai fut avec une esquisse arduinesque d’une redoutable simplicité :

void loop() {
analogWrite(5,10);
delay(33);
delayMicroseconds(325);
analogWrite(5,0);
analogWrite(6,60);
delay(33);
delayMicroseconds(325);
analogWrite(6,0);
}

La broche enable de chaque régulateur de courant des DELs est reliée aux pin 5 et 6 de l’arduino, qui fait un PWM pour éviter la surchauffe. Essentiellement, le programme allume en alternance les deux DEL, avec une période d’environ 33,333ms, pour correspondre au 30 images par secondes du flux vidéo. Il y a deux problèmes principaux à cette approche : l’horloge de l’arduino n’est synchronisée ni en phase, ni en fréquence avec celle de la caméra, ce qui fait que pendant la durée d’une prise d’image, bien souvent les deux DELs sont allumées séquentiellement, donc on se retrouve avec un signal mélangé. La légère différence en fréquence fait que ce décalage en phase se déplace au fil du temps, produisant un battement lent dans le signal qui rend celui-ci inutilisable périodiquement. Bref, ça marche, mais ce n’est vraiment pas fiable et il y a manière de faire mieux.

J’ai donc relégué l’arduino et me suis décidé à résoudre le problème de manière purement électronique. Le schéma est présenté ci-dessous :

J’ai commencé par observer le signal vidéo analogique à l’oscilloscope. Il ressemble à ceci :

À chaque ligne, il y a un pic vers le bas qui indique une nouvelle ligne. La zone au milieu de la photo survient à la fréquence de 60Hz, puisque la vidéo est interlacée, c’est l’indicateur de nouvelle image. Afin de me synchroniser là-dessus, je me sers de la partie distinctive qui est un plat près de 0V. Je passe donc ce signal dans la borne négative d’un premier comparateur, avec un niveau de voltage assez bas sur la borne positive (224mV), ce qui sort uniquement les pics les plus bas (nouvelle ligne et nouvelle image). La sortie de ce comparateur donne ceci :

Les pics plus importants correspondent au plateau près de zéro que je souhaitais isoler. Je passe ce signal dans un filtre passe-bas, qui va garder seulement la composante à 60Hz et retirer les petites fluctuations :

Je passe ensuite ce signal dans un second comparateur, afin d’obtenir un retour parfait au ground et une forme plus abrupte des pics :

Ça marche bien, sauf que c’est en open collector, donc on ne peut pas l’interfacer directement avec une puce en logique CMOS. Le voltage du niveau haut est à 4,3V environ, ce qui est trop loin du 5V. Après un bon bout de gossage, j’ai réussi à brancher un transistor PNP en configuration d’émetteur commun. Le biasing provoquait des effets bizarres, parce que je mettais une résistance de charge trop élevée, ce qui limitait trop le courant dans le collecteur. En le revirant de bord, (l’émetteur et le collecteur sont inversés), j’ai réussi à le faire marcher par magie. En investiguant un peu, je me suis rendu compte que faire ça diminue le facteur beta, soit le gain en courant du transistor. Autrement dit, la région d’amplification est beaucoup plus faible et il sature très rapidement. En diminuant la résistance de charge, le courant augmente drastiquement et on peut se servir du transistor branché normalement, puisqu’il reproduit bien l’onde carrée. Cela donne un pic inversé qui varie entre 4,9V et 0V :

En envoyant cela dans l’entrée d’horloge d’une bascule T, on crée une onde carrée avec un rapport cyclique de 50%, à la moitié de la fréquence des pulses d’entrée :

Donc après toutes ces étapes, on vient de recréer une horloge qui est synchronisée sur celle de la caméra (avec une phase décalée bien sûr), à 30Hz. Afin de contrôler les DELs, je vais la diviser encore en deux avec une autre bascule T, ce qui va produire deux ondes carrées à 15Hz déphasées de 180 degrés, autrement dit, les deux DELs vont clignoter en alternance à la fréquence de la caméra. Cela donne ceci :

Finalement, je me sers de ce signal pour moduler une autre onde carrée générée par un timer 555 avec un duty cycle faible, qui fait office de PWM pour mes DELs. Le résultat, appliqué sur la broche de contrôle des régulateurs de mes DELs, ressemble à ceci :

Et ça marche tout seul! Lorsqu’on allume le tout, les DELs se mettent à clignoter à la bonne fréquence comme par magie!

Analyse du flux vidéo de la caméra oxymétrique avec Processing

Frederik Oxymétrie, Processing

J’ai déjà montré auparavant (voir l’article ici) la construction de ma caméra, qui permet d’imager la sortie des 49 fibres optiques récoltant le signal lumineux dans les deux longueurs d’onde, sur une surface donnée. À présent, mon objectif était de faire le traitement du flux vidéo en temps réel, afin de sortir un graphique de l’intensité lumineuse recueillie en fonction du temps, et ce, pour tous les canaux.

Mon choix d’environnement de programmation s’est porté sur Processing (https://processing.org/), parce qu’il a été conçu spécialement pour des artistes en art visuel et en multimédia, avec une foule de librairies et une communauté en ligne. Il est open source, le langage ressemble énormément à celui d’arduino, ce qui n’est pas étonnant puisqu’ils partagent la parenté de leurs créateurs. Étant donné que mon projet est assez complexe, passant du traitement d’image à l’implémentation du calcul du SpO2 et finalement la représentation 3D du résultat en temps réel, avoir un environnement de programmation épuré était essentiel. Et finalement, pour obtenir éventuellement (peut-être, un jour) un affichage des données esthétiquement attrayant, chose dans laquelle je suis assez novice, je me suis dit que Processing était la meilleure option, vu la quantité surprenante de tutoriels sous toutes les formes.

J’ai donc téléchargé la dernière version, et j’ai trouvé le tutoriel suivant, qui m’a permis d’afficher la sortie de ma caméra à l’écran de mon ordinateur :

Cette vidéo est très exhaustive, et j’ai réussi aisément à non seulement faire fonctionner ma caméra, mais en plus, à comprendre assez bien la philosophie qui dicte l’architecture de programmation de Processing : l’utilisation de la fonction void draw() et des interrupts de capture déjà implémentés. Le tout est vraiment simple et sympathique d’utilisation.

Pour la partie traçage d’un graphique en temps réel, après quelques recherches, j’ai fini par tomber sur le code disponible ici. Rien de bien compliqué, et cela utilise la libraire Grafica que l’on peut télécharger avec le gestionnaire de librairies inclus dans Processing.

Ma seule contribution provenant des entrailles de mon cerveau fut, pour l’instant, la création d’une fonction convertissant une image de 720×480 pixels en 49 valeurs d’intensité correspondant à chacun de mes canaux. La voici :

float[] getsignal() {
float[] ch = new float[49];
for (int xi = 0; xi <= 6; xi++) {
for (int yi = 0; yi <=6; yi++) {
int xin = 67*xi + 185;
int yin = 72*yi + 25;
int n = xi + 7*yi;
for (int x = xin-dc; x <= xin+dc; x++) {
for (int y = yin-dc; y<= yin+dc; y++) {
int loc = x + y * video.width;
float intensity = brightness(video.pixels[loc]);
if (intensity > 50) ch[n] = ch[n] + intensity;
}
}
}
}
return ch;
}

Il s’agit de 4 boucles for nichées les unes dans les autres. Les deux premières permettent de sauter d’une région d’intérêt à l’autre, selon une formule empirique en pixels donnant la position du centre de chaque fibre sur l’image. Les deux autres passent sur chaque pixel à l’intérieur d’un carré de largeur définie par 2*dc (j’ai mis dc=20 dans le programme, donc la région d’intérêt est un carré de 40×40 pixels centré sur la sortie de chaque fibre). On a vu dans l’article précédant que le signal d’intensité saturait et débordait sur une largeur variable de pixels, j’ai donc dû faire un compromis et définir des zones que j’estimais pouvoir être remplies seulement par la lumière d’une seule fibre. La vitesse d’exécution n’a pas été ma priorité, j’avoue que ce traitement d’image pourrait largement être optimisé, l’important étant simplement d’en faire une preuve de concept, j’utilise un ordi de bureau tout de même, ce qui me donne une bonne puissance de calcul. Donc à l’intérieur du carré, j’extrais, pour chaque pixel, la valeur d’intensité lumineuse à l’aide de la fonction brightness, qui extrait cette composante de la couleur dans l’espace HSB, à partir d’un pixel RGB (oui ma caméra est noir et blanc pour l’infrarouge et les faibles luminosités, mais le convertisseur analogique/digital que j’utilise numérise les pixels en RBG, même si concrètement, toutes les valeurs correspondent simplement à des niveaux de gris). J’ai ensuite rajouté un treshold de 50 sur cette valeur, afin d’éliminer les pixels noirs du calcul d’intensité, et de bien circonscrire le cercle lumineux produit par la fibre. Je fais une somme brute de toutes les valeurs d’intensité de tous les pixels d’intérêt, afin de produire une seule valeur représentative (on l’espère) de l’intensité lumineuse dans la fibre, et donc, de la quantité de lumière diffusée par l’organe qui a été rétroréfléchie.

Comme on peut le voir à la figure suivante, cette approche permet effectivement de tracer le signal lumineux en temps réel, sur le canal de notre choix. L’axe des x est le temps en nombre de points, puisqu’on a 30 images/s, cela fait 30 points/s donc la plage couvre une quinzaine de secondes. L’intensité est une valeur arbitraire, en première approximation linéairement proportionnelle à la quantité de lumière dans la fibre. Je l’ai vérifié rapidement, de manière qualitative, en observant ce que je crois être les pulsations cardiaques! (À vérifier, bien entendu!) Une courte vidéo montre le résultat. Cette partie du travail du projet a été effectué du 26 au 28 avril dernier, mais je n’ai pas pris le temps de le documenter auparavant. D’autres développements ont été faits et je les posterai sous peu!

Découpage laser de l’asclépiade

Frederik Projet Asclépiade

J’ai fait des tests en soumettant la fibre d’asclépiade à différentes puissances de mon laser. Ce que je me suis rendu compte, c’est qu’il ne se passe rien en-dessous de 70mW. À cette valeur, lorsqu’un bout de fibre simple est exactement au focus, il commence à brûler. Lorsque la fibre d’asclépiade brûle, elle agit en quelque sorte comme de l’encens à très haute vitesse, prenant environ 1 seconde pour que le tison la parcourt au complet.

La fibre est tellement lisse qu’elle réfléchit la lumière du laser comme un miroir cylindrique avec très peu de distorsion, c’est fascinant et ça provoque divers effets de lumière et d’optique vraiment intéressants. Il faudrait penser si on pourrait l’intégrer dans de l’optique, comme un diffuseur ayant de bonnes propriétés thermiques et acoustiques, je ne sais pas.

Lorsque le laser commence à interagir avec la fibre, on entend un petit bourdonnement, celui de la fréquence du PWM. Je restais à des fréquences aux alentours de 60Hz. Peut-être que je pourrais expérimenter avec d’autres valeurs, pour voir, mais je ne pense pas que cela soit vraiment différent.

En conclusion, le laser est approprié pour faire de la découpe de la fibre, avec les bons paramètres, c’est possible d’éviter de la faire prendre en feu et de produire une coupure nette et propre au travers de toutes les fibres en même temps. Autrement dit, une fois qu’un tissu d’asclépiade sera conçu, on pourra en faire la découpe facilement avec un faisceau laser. Par contre, pour modifier les propriétés de la fibre et ainsi pouvoir la filer, le laser n’a vraiment pas l’air d’être le bon outil. Soit il passe complètement au travers, soit il la laisse intacte. Il faut continuer à chercher d’autres alternatives!

Automatisation complète de mon extracteur de commentaires YouTube

Frederik Extracteur de commentaires YouTube

Je me suis rendu compte, à force de laisser rouler mon extracteur de commentaires pendant plusieurs heures, voire plusieurs jours, qu’il finit toujours par y avoir une erreur qui le fait crasher, malgré tous les niveaux de robustesse que j’ai tenté de lui inculquer. Je pense que c’est dû en partie à la mémoire vive qui a besoin d’un petit sommeil de quelques instants, le temps de repartir à zéro. En tout cas, je me suis dit qu’un reboot de temps en temps ne doit pas faire de mal à ce pauvre ordi qui subit tous mes scripts plus ou moins legit.

Afin de me débarrasser de la nécessité de brancher un écran pour que firefox fonctionne, j’ai commencé par installer un serveur VNC, en suivant les instructions suivantes. C’est un guide très complet, qui explique également comment faire pour que le serveur VNC se mette en marche tout seul au démarrage. Il est fait pour debian, mais j’ai pu l’adapter sans problème pour Fedora.

Par la suite, j’ai essayé de démarrer mon programme classique d’extracteur de commentaires depuis le bureau virtuel sur lequel je me suis connecté. Ça n’a pas marché, je me suis rendu compte qu’il y avait encore un problème de PATH avec mon geckodriver (je l’avais placé dans ~/bin), il ne le trouvait pas puisque j’étais à l’intérieur du bureau virtuel, pour une raison ou une autre. J’ai donc placé le geckodriver dans /usr/bin, et ça a réglé le problème.

Par la suite, j’ai modifié mon programme pour qu’il se connecte d’abord sur une immense playlist de vidéos YouTube, qu’il enregistre où il est rendu dedans et qu’il commence avec la première vidéo qu’il n’a pas déjà en mémoire, c’est comme un immense générateur de « seed » pour mon crawlbot, ça lui fait des milliers de points de départ différents, tous rassemblés sur une seule page web.

Une fois tout cela testé, j’ai voulu le rendre automatique au démarrage, lorsque l’ordi boote, qu’il lance le crawler une fois que le serveur VNC est parti. C’est là que les problèmes ont commencé. J’ai essayé toutes sortes d’approches, comme d’inclure un appel à mon script python à même le service du VNC… sans grand succès. Ce qui a fini par fonctionner, toutefois, c’est de créer une crontab utilisateur avec ceci à l’intérieur :

@reboot python /home/fred/Documents/python/youtube_com_autoextract.py >> /home/fred/Documents/python/out.log 2>&1

Puisque le serveur VNC se logue directement à l’utilisateur fred de manière automatique, sans qu’il n’y ait besoin d’entrer le mot de passe associé, cela fonctionne, mon script python est lancé. Toutefois, j’obtenais toujours l’erreur récurrente de Selenium qui dit grosso modo que firefox n’a pas d’interface graphique. Je me suis buté à cette erreur un bon bout de temps, puisque lorsque je lançais moi-même exactement le même script depuis le bureau virtuel, tout fonctionnait bien. À force de me promener sur internet, j’ai fini par trouver la réponse ici : il faut spécifier dans le script python quel display on utilise, sinon ça doit sûrement être la valeur par défaut qui embarque, qui est sans doute nulle lorsque le script est lancé automatiquement depuis le crontab. J’ai donc simplement rajouté la ligne :

os.environ[‘DISPLAY’] = ‘:1’

après avoir mis un import os.

Cela fonctionne, puisque mon serveur VNC crée le display virtuel 1, donc la sortie de mon programme python, le browser firefox automatisé, est redirigé sur ce display.

Dernière chose mais non la moindre, je voulais également que mon programme envoie une commande de reboot lorsqu’il crashe. J’ai essayé le os.system(‘sudo shutdown -r now’), tel que trouvé ici, sans succès, l’erreur dit qu’il n’y a ni console ni mot de passe de fourni par l’utilisateur, ce qui est assez vrai.

En fouillant un peu, j’ai trouvé qu’il était possible de désactiver la demande de mot de passe pour n’importe quelle commande avec visudo (j’ai trouvé l’information ici). J’ai essayé avec %user ALL=(ALL) NOPASSWD:/usr/bin/shutdown, ça n’a pas marché. Finalement, je me suis rendu compte que c’était mieux d’utiliser systemd avec la commande systemctl pour lancer la procédure de reboot. J’ai trouvé l’information ici :

user hostname =NOPASSWD: /usr/bin/systemctl reboot

En remplaçant user et hostname par mes valeurs, dans le visudo. En mettant simplement la ligne

os.system(‘sudo systemctl reboot’)

dans un except qui ramasse toutes les erreurs non identifiées de mon script en python, le redémarrage se fait automatiquement lui aussi, sans crasher à cause d’une demande de mot de passe. Tout fonctionne? Je viens de le partir, pour l’infini ou presque on l’espère, ça reste à voir! Mais cette fois-ci, c’est une araignée aux pattes d’acier, je vois mal ce qui va pouvoir la tuer, mis à part une panne de courant.

Vidéo sur mon télescope à réalité augmentée

Frederik Optique, Télescope LCD

J’ai réalisé une vidéo sur mon projet de télescope à réalité augmentée. Je l’ai présenté en long et en large dans les articles précédents. L’ajout dont je n’ai pas parlé est l’arduino et le BMP085 (un capteur de température et de pression), permettant d’afficher sur l’écran LCD les données de température et d’altitude en temps réel. L’arduino envoie une commande par un port série à la carte Nextion, qui actualise les données affichées à l’écran. Le code arduino, basé sur les exemples de Nextion (je n’arrive plus à retrouver le lien) est le suivant :

#include <SoftwareSerial.h>
#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BMP085.h>

SoftwareSerial mySerial(10, 11); /*Even though you can use the hardware serial port in this case I think it is better to
leave the hardware serial open for debugging purposes*/

Adafruit_BMP085 bmp = Adafruit_BMP085(10085);

float temperature;

void setup() {

Serial.begin(57600); //open the hardware serial port
while (!Serial) { // wait for serial port to connect. Needed for native USB port only
;
}
/* Initialise the sensor */
if(!bmp.begin())
{
/* There was a problem detecting the BMP085 … check your connections */
Serial.print(« Ooops, no BMP085 detected … Check your wiring or I2C ADDR! »);
while(1);
}

Serial.println(« Serial On »); //Print this messages when the serial port is connected
mySerial.begin(9600); // set the data rate for the SoftwareSerial port
}

void loop() {
/* Get a new sensor event */
sensors_event_t event;
bmp.getEvent(&event);

/* Display the results (barometric pressure is measure in hPa) */
if (event.pressure)
{
/* Display atmospheric pressue in hPa */
Serial.print(« Pressure: « );
Serial.print(event.pressure);
Serial.println( » hPa »);

/* Calculating altitude with reasonable accuracy requires pressure *
* sea level pressure for your position at the moment the data is *
* converted, as well as the ambient temperature in degress *
* celcius. If you don’t have these values, a ‘generic’ value of *
* 1013.25 hPa can be used (defined as SENSORS_PRESSURE_SEALEVELHPA *
* in sensors.h), but this isn’t ideal and will give variable *
* results from one day to the next. *
* *
* You can usually find the current SLP value by looking at weather *
* websites or from environmental information centers near any major *
* airport. *
* *
* For example, for Paris, France you can check the current mean *
* pressure and sea level at: http://bit.ly/16Au8ol */

/* First we get the current temperature from the BMP085 */
float temperature;
bmp.getTemperature(&temperature);
Serial.print(« Temperature: « );
Serial.print(temperature);
Serial.println( » C »);

/* Then convert the atmospheric pressure, SLP and temp to altitude */
/* Update this next line with the current SLP for better results */
float seaLevelPressure = SENSORS_PRESSURE_SEALEVELHPA;
Serial.print(« Altitude: « );
float alt = bmp.pressureToAltitude(seaLevelPressure,
event.pressure,
temperature);
Serial.print(alt);
Serial.println( » m »);
Serial.println(«  »);
String sendThis = «  »; //Declare and initialise the string we will send

delay(300); //Probably unneccessary, but I give the screen some time to respond
sendThis = « n0.val= »; //Build the part of the string that we know
sendThis.concat(int(temperature)); //Add the variable we want to send
writeString(sendThis); /*Use a function to write the message character by character to the Nextion because
mySerial.write(sendThis) gives you an error due to a datatype mismatch*/
delay(300); //Probably unneccessary, but I give the screen some time to respond
sendThis = « n1.val= »; //Build the part of the string that we know
sendThis.concat(int(alt)); //Add the variable we want to send
writeString(sendThis); /*Use a function to write the message character by character to the Nextion because
mySerial.write(sendThis) gives you an error due to a datatype mismatch*/
}
else
{
Serial.println(« Sensor error »);
}

}

//NOTE: A great big thanks to: RamjetX for writing this function. You can find his/her post here: http://forum.arduino.cc/index.php?topic=89143.0. Please go give him/her some Karma!
void writeString(String stringData) { // Used to serially push out a String with Serial.write()

for (int i = 0; i < stringData.length(); i++)
{
mySerial.write(stringData[i]); // Push each char 1 by 1 on each loop pass
}

mySerial.write(0xff); //We need to write the 3 ending bits to the Nextion as well
mySerial.write(0xff); //it will tell the Nextion that this is the end of what we want to send.
mySerial.write(0xff);

}// end writeString function

Test du laser sur l’asclépiade

Frederik Projet Asclépiade

J’ai fait plusieurs tests avec le laser et la bouteille qui essaie de faire une extrusion continue de la fibre d’asclépiade. C’est vraiment un échec. Premièrement, la fibre reste toute coincée avant d’entrer dans la buse, je ne comprends pas comment répéter les résultats que j’obtenais précédemment. Peut-être que l’asclépiade que j’avais utilisé alors avait des fibres plus courtes, je ne sais pas.

Toute la fibre qui arrive à sortir est simplement brûlée par le laser. Il faudrait trouver une façon de pouvoir contrôler la vitesse de sortie, pour que chaque bout soit exposé au laser de manière contrôlée. Bien sûr, je suis capable d’ajuster la puissance du laser avec un PWM pour obtenir n’importe quelle valeur entre 0 et 3W.

Je vais abandonner l’idée de l’alignement par air comprimé, les résultats ne sont pas concluants. Il va falloir trouver une autre méthode plus fiable et plus reproductible.

Sinon, j’ai fait des tests avec un motton d’asclépiade placé dans le faisceau laser. La fibre étant très petite, elle est aussitôt transformée en fumée. Des bouts brûlés se situent en périphérie du trajet du faisceau. Je les ai regardés au microscope, on peut les voir sur les images ci-dessous. Cela semble donner toutes sortes de formes tordues aux fibres, ce qui est bon signe. Il faudrait voir si elles sont tout aussi isolantes. De plus, je ne sais pas à quel point cela les brise, possiblement qu’elles deviennent encore plus fragiles qu’elles ne le sont déjà, se transformant en poussière encore plus facilement.

En conclusion pour cette petite séance de laboratoire, il faut repenser complètement la méthode d’alignement et expérimenter avec différentes puissances de faisceau, de manière reproductible. L’ajout d’une seconde fibre ou d’un liant quelconque est à investiguer.

Ajout d’une carte fona 3G à mon raspberry pi

Frederik Station raspberry pi portative

J’avais déjà acheté une carte fona 3G l’été passé, j’ai eu bien du plaisir à la faire fonctionner avec un arduino et le code d’exemple fourni par Adafruit. À présent, j’aimerais rendre le tout plus portatif, et la manière la plus simple de le faire est de rajouter la carte à ma station raspberry pi portative. Cela me donnera donc en résultat un « téléphone intelligent » pas mal badass : raspberry pi 3, écran 7 pouces et assez de batterie pour durer 10h.

J’ai connecté l’entrée du 5V de la carte au 5V du raspberry pi, le VIO à 3.3V, le RX de la carte dans le TX du raspberry et vice-versa, et le RTS dans le ground puisque j’ai configuré le fona pour avoir le serial à 7 lignes afin d’avoir une sortie dans la pin de RING.

Après avoir activé l’interface série dans la configuration du raspberry pi (cela ajoute essentiellement la ligne enable_uart=1 à la fin du fichier /boot/config.txt) et avoir redémarré, j’ai ouvert le port série avec

sudo screen /dev/serial0 4800

dans un terminal. Cela marchait à moitié, voire pas du tout. Par exemple, j’écrivais AT et la carte me répondait une seule fois avant de figer. J’ai essayé à peu près tous les baudrate, sans plus de résultat. Après avoir tout essayé, j’ai trouvé comment régler le problème.

Il se trouve que le kernel du raspberry pi utilise lui aussi le port série par défaut comme console pour faire du déboguage, il envoie donc des données à la carte, qui ne sait évidemment pas comment les gérer, ce qui fait tout bugger lorsque l’on essaie d’y accéder avec screen. Pour désactiver cette fonction, il faut aller dans :

/boot/cmdline.txt

et supprimer la partie de la ligne qui dit console=serial0,115200 en gardant le reste de la ligne et en faisant bien attention de ne pas laisser un retour à la ligne dans ce fichier. Cela fait en sorte que le kernel ne se sert plus de cet interface comme console. Une fois le raspberry pi redémarré, tout fonctionne à merveille!

La suite du projet va être de créer une sonnette pour le cellulaire, ensuite de faire un petit boitier pour bien fixer le tout à ma station portative, et éventuellement, de créer ou d’utiliser un petit programme d’interface utilisateur pour commander la carte fona sans passer par les commandes AT qui peuvent vite devenir épuisantes à utiliser.