Mois : janvier 2018

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.

Conception du détecteur de l’imagerie oxymétrique

Frederik Conception optique, Fibre optique, Impression 3D, Oxymétrie

Pour pouvoir mesurer le signal dans chaque fibre, je devais trouver un moyen de les imager avec ma caméra à haute sensibilité. J’ai tout d’abord réussi à trouver une lentille en ménisque convergent qui a une distance focale de 35 mm, en la collant directement sur l’objectif de la caméra, cela permet de rapprocher l’objet de la distance hyperfocale (approx 30 cm je crois) jusqu’à 35 mm, en diminuant le champ de vue par la même occasion.

J’ai donc imprimé deux pièces s’emboîtant en une boite en prisme cubique. La première est une plaque comportant 49 trous afin de faire passer toutes les fibres et de les aligner sur un même plan. La deuxième a un trou au centre pour y insérer la caméra ainsi qu’un petit remontant cylindrique afin d’y fixer la lentille. Le tout permet de bien maintenir toute l’optique solidement en position et dans l’obscurité, autant les fibres que la lentille et la caméra.

Une fois la boîte refermée, cela donne le détecteur assemblé visible sur les deux photos ci-dessus. D’un côté, il y a la caméra, bien insérée et collée, et de l’autre, le paquet de 49 fibres formant l’image. On peut voir le résultat capté par la caméra ci-dessous. L’espacement entre les fibres est tel qu’il permet à chacune d’être bien résolue et échantillonnée sur un bon nombre de pixels, même lorsque l’intensité lumineuse dans la fibre optique est très élevée. Dans le cas présent, j’avais pointé quelques fibres directement sur une ampoule incandescente. Bien évidemment, comme je n’utilise pas de lentille de champ à la sortie des fibres, celles sur le bord de l’image vont avoir une intensité captée par la caméra beaucoup plus faible que celles au centre, il va donc falloir faire une calibration pour appliquer la correction sur le signal mesuré.

 

Test du LCD sur le télescope LCD

Frederik Télescope LCD

J’ai testé l’écran LCD de mon télescope LCD hier. Après moult essais, je ne suis pas parvenu à afficher quoi que ce soit dessus. Tout semblait pourtant fonctionner, je n’avais pas de message d’erreur dans le logiciel. Je me suis rendu compte en fait que je l’avais brisé en l’insérant dans ma monture, comme en témoigne la photo ci-dessous.

C’est bien plus fragile que je le pensais en fait, les bords supportent peu les stress mécaniques.

Je me suis donc rabattu sur mon autre écran LCD modifié, celui qui est branché sur une carte Nextion que j’avais utilisé comme preuve de concept au tout début du projet. Sa conception mécanique est un peu différente, ce qui fait que j’avais gardé la monture métallique qui fait la bordure du verre, lui donnant tout de même une bonne résistance au stress mécanique lors de l’insertion dans ma monture. En fait, je pense que c’est le poids du raspberry pi qui a joué, fissurant le verre et les connecteurs internes.

Cela donne donc les résultats suivants, ce qui est très satisfaisant, et ça l’est encore plus lorsque l’on place un oeil face à l’oculaire au lieu de l’objectif d’une caméra.

Les lentilles de champ permettent d’avoir une bonne luminosité de l’image malgré l’atténuation du LCD lorsque l’oeil est bien aligné avec l’optique. Le vignettage que l’on peut observer sur les images est dû à l’aperture stop de la caméra, pour l’oeil, on voit surtout des aberrations sur les bords de l’image.

Mais tout fonctionne bien, les images réelles et virtuelles se combinent à merveille dans mon système, et tout est à l’endroit!