Se mettre au simracing alors qu’on se dé-confine, mais quelle idée à la con. Jusqu’à preuve du contraire je fais bien ce que je veux. Il y aura plusieurs articles pour éviter de faire un trop gros pavé.
Pas mal de monde s’y est mis pendant le confinement, et moi-même maintenant qu’on peut remettre le nez dehors ça me donne envie (ne pas chercher la cohérence). Bien entendu, il est inconcevable de ne pas chercher des solution ouvertes pour ça. Allons-y donc.
3615MAVIE : Je joue pas mal à DiRT, et c’est vrai qu’un volant à retour de force ça serait sympa. J’avais même acheté un Occulus Quest 2 pour tester la VR. Problème : mon PC est largement sous-dimensionné pour ça (GTX960). Ajouter à cela le setup ultra-relou (câbles, poids, inscription Facebook-only, WIFI obligatoire) et le fait que mon oreille interne n’apprécie pas trop trop … mauvaise expérience. Ça aurait été une bonne occasion d’upgrade mon PC, mais c’est un barebone en mini-ITX donc je suis limité sur le choix des CG, vu la pénurie MASSIVE, impossible de trouver une CG entre 100€ et 1000€, donc je passe mon tour. Et je repasserai quand on aura voté une loi qui permet de sectionner la ligne électrique des ~~parasites~~ gens qui minent des putains de cryptomonnaies.
En tous cas, c’est bien une des rares fois où j’ai renvoyé un produit …
Bref, le volant par contre j’ai bien envie. En “entrée de gamme” ya le kit Logitech à 300€ et quelques, ça pourrait être pas mal pour commencer. Mais bof, je n’ai pas envie d’avoir un truc “cheap”, donc j’ai commencé à regarder Thrustmaster, qui est notablement plus cher, mais a meilleure réputation. Et encore au-dessus - et sans rentrer dans les setups custom / pro absurdes - le plus connu étant Fanatec.
Comment je vois les choses:
- Logitech : jouet, mais kit tout-compris pas trop cher
- Thrustmaster : cher pour ce que c’est, mais mieux, beaucoup d’éléments séparés à acheter (roues, pédaliers, leviers …)
- Fanatec : beaucoup trop cher, et totalement indisponible
État de l’art - le “marché” du simracing
Au niveau de volants, la distinction se fait sur le type de moteur utilisé et le type de transmission du volant. Pour simplifier: - Moteur DC : cheap, dans les bases “grand public” Logitech et Thrustmaster - Moteur brushless : haut-de gamme, plus de couple, meilleur contrôle - Transmission engrenages plastique : cheap, Logitech - Transmission courroie / belt-driven : mieux, Thrustmaster et Fanatec - Transmission directe / le volant est sur l’axe du moteur / Direct drive : haut-de gamme, meilleur couple, meilleur rendu.
D’une façon générale, le direct drive à moteur brushless est le saint-graal dans le simracing : ça coûte une blinde, les moteurs sont monstrueux (1kW et plus) et donc les alims sont monstrueuses aussi, le couple est énorme à arracher un bras (20 N.m et plus), donc c’est uniquement pour les setups haut-de-gamme. D’ailleurs Fanatec propose depuis quelques temps une base direct-drive.
Au niveau des pédales, ça se simplifie à “métal ou plastique”, axe des pédales en-dessous (prend moins de place / moins cher) ou au-dessus (plus réaliste), et pédale de frein “standard” à ressort ou load cell. La différence du load cell c’est que la capture de la force de freinage est faite via la pression exercée par le pied, plutôt que la course de la pédale, ce qui rend le contrôle beaucoup plus réaliste et reproductible, et facilite l’acquisition de la mémoire musculaire sur le freinage.
Je ne parle pas des châssis, c’est encore autre chose. Moi je n’ai pas l’intention de me coltiner un truc aussi encombrant, et de toutes façons je n’ai pas la place, et de très très loin. Et je n’ai aucunement l’intention d’investir autant dans un loisir.
Et donc, un setup qui me plairait serait une sorte de “compromis” à base de Thrustmaster. Base + roue “type rally”, pédalier avec load cell, levier de vitesse, frein à main, j’en ai pour plus de 1000€ quand-même.
En soi ça ne me dérange pas tant que ça, mais niveau fiabilité à long-terme … bof. Ok, un moteur DC ça se remplace facilement, mais tout de même. Et 1000€+ quoi … Pour un truc fermé … Donc je me suis demandé s’il n’était pas pertinent de fabriquer moi-même. Comme ça : maintenabilité et évolutivité maximum, et avec de la chance j’apprendrai des trucs.
J’ai donc regardé s’il existait des projets de volant simracing open-source. Évidemment que ça existe mais … Comment dire ? … C’est spécial.
Open-source simracing force feedback wheel - Quelques projets open-source que j’ai trouvé
D’une façon générale il y a plein de vidéos tutube de setup custom, avec des équipements DIY, mais peu, mal, voire pas du tout documenté (après tout, rien n’oblige quelqu’un à donner les sources). Ce qui fait qu’il y a plein d’idées intéressantes qui circulent, de designa intéressants, mais peu de documentation. Quelques spécimens sortent du lot.
Open Sim Wheel : http://opensimwheel.wikidot.com/
Sur ce “projet” la plupart des composants sont propriétaires (cartes, servos …), l’élément le plus important, le contrôleur de Force Feedback n’est pas open-source, c’est un allemand qui l’a bricolé dans un coin, et pour récupérer le binaire il faut avoir un compte sur le forum Virtualracing. Comment dire …
Ce contrôleur est un truc qu’on retrouve souvent, qui s’appelle MMos.
https://granitedevices.com/wiki/MMos
https://forum.virtualracing.org/threads/diy-usb-force-feedback-controller.92420/
“Open-source” mon cul !
Sinon il y a Granite. Positionnement un peu bancal là encore : le firmware est open-source, mais pas le HW. Regardons le code source alors.
https://github.com/SimuCUBE
Hum hum … Pas de commits, uniquement des .md dans le repo ? WTF ?
Dans release il y a un truc qui s’appelle “source code”, je télécharge, dedans il y a un zip qui contient des .dll et quelques trucs avec marqué “QT” dedans, mais rien qui ressemble à du code source. C’est quoi cette arnaque ?
“Open-source” mon cul !
Par contre sur d’autres produits qu’ils vendent là on trouve vraiment les sources, mais surtout du SW.
https://github.com/GraniteDevices
C’est fumeux je trouve.
J’ai vraiment l’impression que la conception de l’open-source dans ce milieu s’arrête à la méca. Ce qui n’est pas très surprenant pour des “car enthusiasts”, c’est le domaine avec lequel ils ont potentiellement le plus d’affinités. Mais à un moment il faut arrêter de se mentir. Parce que là on est totalement dans le mensonge : ces projets sont tout sauf open-source. Et d’ailleurs, un projet “DIY” dans lequel tu achètes des composants propriétaires que tu assembles, bof bof.
Ça me fait penser à beaucoup de projets qui clament être open-source, alors qu’en fait rien du tout.
“Je fournis le schéma de ma carte en PDF, c’est open-source” Non, tu fournis un morceau du manuel de maintenance, ce n’est pas la même chose.
“Je fournis les plans mécaniques de l’enceinte, donc c’est open-source” Non, ça c’est le manuel de montage, ce n’est pas des sources.
Après il y a aussi pas mal de projets qui sont développés avec des outils closed-source et donc les source ne sont utilisables qu’en ayant une licence ad-hoc. Grmpf … Autant des fois ya pas trop le choix (les outils équivalents open source étant soit trop peu performants, soit juste inexistants), autant des fois ça me gêne pas mal. Typiquement les fichiers CAO au format Eagle ça m’emmerde beaucoup. Après, moi je fournis bien des fichiers projet de STM32CubeIDE alors …
… Mais au moins cet outil-là il est pas bridé :p
Le mieux que j’ai trouvé (mais je n’ai pas forcément cherché assez large) c’est ça:
https://hackaday.io/project/163904-open-ffboard
https://github.com/Ultrawipf/OpenFFBoard
C’est vraiment open-source (CAO sous Eagle visiblement … Beurk … Mais bon) et ça a l’air plutôt pas mal (et puis les convertisseurs Eagle vers Kicad ça existe).
Le routage est relativement crado, mais j’ai vu pire, et il y a un effort notable de documentation. Par contre, je trouve dommage qu’il n’y ait aucune mention explicite des outils utilisés pour le développement. Par exemple, le fait que la CAO soit Eagle je l’ai déduit des extensions des fichiers et du format du schéma, mais nulle part il n’est indiqué que c’est Eagle qui est utilisé. Pas très rigoureux tout ça (pourtant on arrête pas de nous dire plein de trucs sur les allemands … :P )
Ce qui m’intéresse surtout c’est le firmware, et comme c’est du STM32 c’est plutôt bien pour moi vu que je connais la cible :) Et en plus c’est du STM32CubeIDE, que demander de plus ? Par contre ya du FreeRTOS et c’est en C++, donc je ne vais pas forcément être à l’aise :( Je tâcherai d’y survivre.
Personnellement, il y a deux éléments principaux qui m’intéressent dans ce code : le contrôle en couple de moteur pas-à-pas et le parsing des commandes HID de force feedback, mais on va y revenir.
Choix du moteur
Si je vais me faire chier à construire le volant FFB moi-même, je vais y mettre quelque chose d’un peu sérieux, sinon autant acheter un truc du commerce. Mais d’un autre côté, je ne veux pas y investir des sommes délirantes, donc je veux trouver un compromis. Et en première approche, le compromis c’est le stepper / moteur pas-à-pas. C’est pas trop cher, pas trop dur à approvisionner en Europe (parce que les brushless … comment dire …) et ça a quand-même un contrôle meilleur qu’un DC à balais. A priori, les défauts principaux par rapport à un brushless c’est le manque de couple et le fait que les pas peuvent se ressentir. Je vais tâcher d’assumer ces défauts.
Autre “défaut” : les drivers de steppers ne sont généralement pas trop prévus pour faire de l’asservissement en couple, donc soit il faut bricoler avec les limitations en courant, soit il faut un contrôleur “custom”.
A priori OpenFFBoard gère ça, ce qui m’arrange bien, d’ailleurs c’est aussi bien pour ça que je voulais partir là-dessus.
Donc, chez Stepperonline, un stepper en NEMA34 qui sort 12N.m en kit avec alim, driver et câbles c’est dans les 150€. Après, à ce prix-là le contrôleur est rudimentaire, et de toutes façons l’encodeur n’est pas très précis, mais j’en prendrais bien un tout de même pour avoir un backup et un moyen de comparaison si ça ne se passe pas bien. Yaka prendre un encodeur un peu mieux genre ça. Sur FFBoard l’auteur propose une liste d’encodeurs dispo sur Digikey. Peut-être l’occasion de faire un compte chez eux ? Dans un premier temps je ne vais pas être plus royaliste que le roi et me contenter de l’encodeur intégré.
On va donc partir sur du stepper en 60V / 5A.
Autres projets
J’ai trouvé d’autres projets intéressants dans le même genre, qui peuvent donner des pistes sur certains aspects, mais qui sont pour des applications plus généralistes.
Arduino SimpleFOCShield
Full open-source, HW et SW, c’est un shield pour Arduino, avec sa lib Arduino associée pour faire du FOC en soft, le shield ne fait que de l’interface de puissance. Il est construit autour d’un circuit intégré ST L6234, qui est un driver de puissance pour moteur 3 phases, donc adapté pour du brushless, mais pas pour du stepper. Il encaisse jusqu’à 52V et 5A, mais la doc du shield limite à 24V, donc environ 130W max. Au cas où l’on se poserait la question : niveau stock c’est pas la fête, au moment de l’écriture de ce post il y en a 34 chez Mouser, 410 chez RS, rien chez Farnell ni Digikey, pas bon signe.
Aparté : Si on regarde chez ST ce qui est proposé d’autre comme driver spécifique pour steppers, on a pas des puissances monstrueuses en général, sauf exception avec le powerSTEP01, qui monte à 10Arms, mais avec un boîtier QFN bien relou. Carte d’évaluation ? Aucun stock, cela va de soi.
Si on regarde les contrôleurs sans MOSFETs intégrés, on trouve les L6480, L6482 et L6506. Le troisième a l’air très old-school, mais il a surtout l’air d’être spécifiquement adapté pour le contrôle en courant, avec deux entrées pour mesures shunt, ce qui est déjà intégré dans les deux autres. Les stocks ? Faméliques.
Ça vaut tout de même le coup de regarder le design, et surtout le SW. Et tiens, au bas de leur page de doc il y a une comparaison qualitative avec d’autres équivalents, dont le “système Trinamic”, qu’ils sont bien urbains de déclarer qu’il ne coûte “que” 100€ … En tous cas aucun des quatre présentés ne supporte les steppers (donc pour le kit Trinamic je suppose qu’ils considèrent une version BLDC-only).
Si on creuse les autres repository autour, on découvre qu’ils ont développé une version “medium power” qui monte jusqu’à 30A et que la lib est supposée être compatible avec les steppers, et avec les CTM32 et les Nucleo, il y a donc définitivement des choses à y apprendre. Ce shield est basé autour de demi-ponts Infineon BTN8982, du même genre que j’ai déjà utilisé sur ma carte de contrôle de vielle à roue motorisée. Tiens tiens …
Il y a un exemple avec un stepper, utilisant une carte Nucleo, ce qui est très intéressant, et confirme que même si la carte “de puissance” est conçue pour du brushless uniquement, la librairie, elle, est compatible steppers, et STM32, même si c’est de la lib Arduino, donc en C++ :( Tout pour plaire donc. J’ai bien envie de faire une sorte de mix entre FFBoard et SimpleFOCShield. En tous cas, à minima, ça me semble une bonne plateforme de test pour de la commande en direct.
ODrive
Un “vieux” projet que je vois passer depuis longtemps. Orienté CNC, donc avec contrôle de deux moteurs BLDC, full open-source HW et SW. La cartes est construite autour d’un contrôleur TI DRV8301, qui est l’équivalent des L64xx de chez ST vus plus haut, avec des MOSFETs externes en boîtiers relous. Ce contrôleur intègre les interfaces et amplis pour les shunts de mesure de courant, comme les ST, et quelques fonctionnalités en plus comme un contrôleur de buck pour pouvoir générer une tension d’alimentation pour un MCU, ce qui évite d’avoir à en ajouter un ailleurs sur le schéma. Le FOC est géré par un STM32F405 directement intégré sur la carte, et il y a un demi-pont séparé pour générer une sortie “DC_BUS” qui doit permettre de commander un actuateur supplémentaire, genre une spindle, je pense. D’ailleurs ce demi-pont est drivé par le même driver que FBBoard (LM5109BSD). Rien de spécial sinon.
De même : c’est surtout le SW qui pourrait nous apprendre des choses.
Infineon shield TLE9879
Il s’agit simplement d’une carte d’évaluation sous forme de shield Arduino pour le contrôleur TLE9879. Rien de spécial à dire, il y a des MOSFETs externes, ça sort 150W max, et il y a de la doc fournie par Infineon, mais sûrement plutôt orientée vers l’utilisation de leurs microcontrôleurs à eux.
Cartes et modules off-the-shelf
Après avoir regardé tout cela et commencé à mettre le nez dans le re-design de FFBoard, je sens venir un écueil classique : c’est trop compliqué, et tout est paré pour que j’abandonne le projet en cours de route par lassitude. Je vais donc me résoudre (résigner ?) à me préparer un setup de manip intermédiaire à base de modules déjà faits, de façon à pouvoir avoir un truc qui marche sans attendre d’avoir un hardware fonctionnel, qui a toutes les chances de ne pas voir le jour. Pour rappel, le but c’est aussi que je m’amuse un peu. Regardons donc cela.
Car au final, il n’y a pas grand chose de spécifique requis pour faire tourner ce moteur, au niveau hardware. Il faut une interface de puissance, et une commande avec potentiellement du FOC hardware en intermédiaire. pour la commande, j’ai déjà des Nucleo qui feront tout à fait l’affaire, et je peux prototyper les interfaces analogiques manquantes, genre pour des capteur ou autres. Ce qu’il me manque vraiment c’est l’interface de puissance, c’est bien pour ça que je suis parti à refaire une carte custom. Mais peut-on trouver des interfaces de puissance déjà toutes faites adaptées à cette application ?
J’ai donc cherché, comme d’habitude, dans les cartes d’évaluation sur Farnell / Mouser. Pour de la commande de steppers, la plupart des cartes que l’on trouve sont soit adaptées pour des petits steppers (genre 2-3A max) soit conçues pour se commander en step / dir, sans possibilité de commander les enroulements en direct, et donc en faisant confiance à un composant déjà tout fait. Bon, avec le CI Trinamic c’est un peu ce vers quoi je me dirige, mais j’ai bien envie de tester la lib FOC software, et pour cela il faut que j’accède directement aux commandes des grilles des MOS. Il me faut une carte qui encaisse du 60V, 10A, et qui dispose de 4 demi-ponts. je précise parce que beaucoup de solutions existent pour du brushless, donc avec 3 demi-ponts.
Après débroussaillage, j’obtiens la sélection suivante: - Chez ST pas mal de cartes pas en stock, genre EVAL6482H, EVAL6480H, EVLPOWERSTEP01, qui conviendrait bien et ne sont pas si chères que ça (\~80€). Et une petite carte vraiment pas chère à 8€ la X-NUCLEO-IHM03A1 : avec connecteurs Arduino / Nucleo, encaisse 85V / 10A, coûte une misère (8€), mais disponible nulle-part. Mouser promet un réapprovisionnement d’ici la fin du mois. - Chez Performance Motion Devices des cartes plutôt bien dimensionnées mais un peu plus chères (plutôt 150€), genre DK78113, DK74113, mais qui ont l’air compliquées à mettre en œuvre, et sur lesquelles on subit un circuit intégré de commande. - Chez Texas Instruments, une petite carte à 30€, dispo, 54V / 4.5A, qui a l’air vraiment pas mal : BOOST-DRV8711. Ça a l’air de parfaitement faire l’affaire, même si j’ai un doute sur la tenue en puissance (les MOS sont petits quand-même, et il n’y a pas de mesure de courant. Sinon plus costaud - mais aussi plus cher : DRV8432EVM, 52V, 7A, 170€, avec du filtrage et un circuit intégré un peu plus complexe, mais toujours de la commande directe, mais pas de mesure de courant. Et 54V c’est limite. - Chez Trinamic, plein de cartes d’évaluation de leurs composants FOC plus ou moins évolués, qui se commandent donc en step / dir et en SPI, et pas d’accès direct aux commandes vu que la plupart de ces composants intègrent les drivers des MOS. La plus intéressante serait la TMC5160-EVAL, 60V, 4.7A. Par contre, ils proposent aussi une carte “Universal Power Stage” : TMC-UPS-10A70V-EVAL. 70V, 10A, commandes directes et mesures de courant, elle a tout pour plaire, même si il n’y en a pas beaucoup en stock et qu’elle n’est pas donnée (170€).
Je pense que je vais tâcher de chopper la carte “universal power stage” de Trinamic, qui est pile ce dont j’ai besoin, plus la petite carte TI à 30€. Pour la commande je vais utiliser une Nucleo compatible avec SimpleFOCShield. pour faire des manips basiques ça devrait suffire.
Pédalier
Pour le pédalier j’ai bien l’intention de l’acheter, mais j’ai quand-même regardé ce que je trouvais en projets open-source, et il n’y a pas grand-chose. D’une façon générale l’électronique est beaucoup plus simple, car se limitant à soit un capteur angulaire basique pour la position des pédales “standard”, et un capteur type jauge de contrainte pour les load-cell. Justement, je me suis un peu intéressé à ce type de capteur.
Basiquement, il s’agit de mesurer la pression exercée “directement” avec un capteur ad-hoc, plutôt qu’indirectement en créant une réaction mécanique (avec un ressort et / ou un piston) et en mesurant la position angulaire, ce qui est moins “crédible” et intuitif. Cela n’enlève pas qu’il faut créer une résistance mécanique, mais la fonction de transfert est plus “réaliste”, parce qu’on est pas obligé d’avoir un déplacement de la pédale pour avoir de nouvelles valeurs, l’augmentation de la pression étant mesurée, ce qui est le comportement physique d’une pédale de frein (par exemple). Pour cela, on utilise des capteur de force ou de déformation type jauge de contrainte, et on y intègre dans un mécanisme avec une pédale de façon à pouvoir mesurer la pression exercée par le pied sur la pédale. Un bon exemple qui permet de se rendre compte est ce projet sur Instructables, qui va avec ce projet sur Github. La reproduction de la résistance mécanique de la pédale et obtenue avec un amortisseur / piston / ressort / combinaison de tout ça, on mesure la pression “derrière” le système de résistance mécanique.
Les jauges de contraintes sont soit des composants tout faits qui intègrent une électronique de conditionnement de signal et fournissent un signal analogique proportionnel à la pression (voire un signal numérique genre I²C), soit sont passifs. Le capteur en lui-même est résistif, et on mesure avec un pont de Weathstone et de l’amplification analogique. un circuit assez répandu visiblement pour ça est le HX711 de chez Sparkfun. Après on fait une fonction de transfert pour corriger, et le tour est joué. Globalement il y a très peu d’électronique, et un petit peu de SW, mais surtout de la méca.
Levier de vitesse et frein à main
Pour ça, j’ai par contre bien envie de fabriquer, ce qui est proposé à la vente n’est vraiment pas très affriolant, je trouve. A minima c’est beaucoup trop cher, et en plus j’ai un doute concernant la possibilité de fixer sur mon bureau, dont l’épaisseur très importante (un peu plus de 5cm) peu poser souci, vu que c’est l’épaisseur maximale annoncée “standard”. Je n’ai pas envie de me retrouver comme un con avec un levier de vitesse ultra-cher qui ne se fixe pas sur mon bureau et devoir le modifier, ça me ferait un peu chier. Et surtout, je n’en ai pas besoin pour jouer dans un premier temps, vu que je peux jouer en auto, ou avec des boutons, donc ce n’est pas bloquant, donc ça peut être un projet secondaire.
Au niveau capteurs, c’est beaucoup plus simple que les précédents, car globalement on ne fait que détection un jeu de positions (6 ou 8 pour un levier de vitesse, 2 pour du séquentiel et frein), donc des fin de course peuvent suffire, même si des solutions à base de mesure analogique marchent aussi (le levier de vitesse Logitech marche comme ça, le Logitech aussi grâce à un capteur Hall). Autre avantage : si on se limite à une boîte séquentielle, en vrai on peut avoir la même méca pour le levier de vitesse et pour le frein à main. C’est d’ailleurs ce que propose Logitech avec le handbrake Sparco, qui peut aussi être utilisé comme levier de boîte séquentielle.
Mécaniquement, il faut reproduire une sorte de gros levier, comme sur les interrupteurs momentanés, mais en plus gros. Donc un levier avec deux ressorts de retour, des fins de course de chaque côté, idéalement un bouton / switch en plus pour un éventuel mode supplémentaire (genre marche arrière). Pour être plus “réaliste”, il faut aussi faire des “crans” mécaniques, et le top du top est d’avoir un système qui bloque le changement de vitesse quand l’embrayage n’est pas enclenché.
Pour les crans, un truc qui marche bien c’est de faire des épaulements dans un axe et mettre un tensionneur qui s’enclenche dedans et se passe à force. Pour le blocage de l’embrayage, un solénoïde fera l’affaire. A voir si on peut le gérer via des infos USB, mais sinon relire directement l’état de la pédale d’embrayage peut suffire, bien que ça soit un peu bourrin.
D’une façon générale, il y a 95% de design mécanique sur cet accessoire. le reste c’est du détail. D’ailleurs le design d’origine du FFBoard permet de faire rentrer des entrées switch ou ADC pour gérer / centraliser ce genre d’accessoire. Perso je vais partir sur le même genre de design que le handbrake Thrustmaster / Sparco : un levier “plat” vertical, comme sur les vraies :p J’ai pris de la barre en alu de 3mm avec des trous, je vais en coller deux épaisseurs l’une coutre l’autre, et les trous me serviront à visser l’axe et le mécanisme.
Épilogue
J’étais parti bille en tête à refaire complétement le design des cartes FFBoard, et en creusant je me suis rendu compte qu’il y avait sans doute moyen de m’épargner du taf, et qu’il existait des solutions intermédiaires pas trop débiles. Ceci-dit, avant de faire ce constat j’ai déjà passé pas mal de temps à travailler sur du dimensionnement et du re-design, et je n’ai pas l’intention d’y mettre à la poubelle. De plus, il y a des choses très intéressantes à en ressortir, donc je vais tout de même compulser tout ça, mais dans un autre article.
Au final je pense commencer par jouer la sécurité, en achetant des modules déjà tout faits, de façon à ne pas avoir à attendre d’avoir le hard qui tourne pour faire des choses, sinon il n’y a aucune chance que j’aboutisse à quoi que ce soit. Ce n’est pas tellement satisfaisant, autant au niveau financier qu’écologique, mais bon … Je ne sais pas, je trouve que c’est toujours mieux que d’acheter un truc tout fait que je ne saurais pas maintenir.
A suivre …