07
avril
'20

Le Trésor d'Ecco Rona, un escape game pour enfants

Publié le 07 avril 2020

Je suppose que vous n'êtes pas passé à côté de la nouvelle, mais en ce moment c'est confinement. Je me retrouve donc à la maison avec mes deux minis-moi (un de 6 ans, l'autre de 7) que je dois occuper tant bien que mal. Une fois passé le stock de jeux de sociétés dont nous disposons, pourtant bien fourni, je me suis rapidement retrouvé sans munition.

Et c'est là que j'ai aperçu une de mes boîtes de Unlock, un escape game à base de cartes qui nous a fait passer de bonnes soirées, et je me suis dit: "Et pourquoi ne pas inventer un escape game pour enfants en CP/CE1 ?".

Unlock, un jeu d'escape game à base de cartes

Un cadenas, mon Royaume pour un cadenas !

J'ai de suite pensé à utiliser un cadenas pour l'épreuve finale, et en particulier mon cryptex de chez Ugears que j'ai eu à Noël il y a deux ans. Oui mais il y a un hic: je ne me souviens absolument plus du code de ce dernier ! Le code de ce cryptex est défini lors du montage, et est donc fixe. La première étape a donc été de retrouver ce code à 3 chiffres, sans faire de recherche exhaustive car bien trop longue (il faut placer les anneaux de manière à ce qu'ils soient parfaitement alignés sur la combinaison pour que le cryptex s'ouvre) ! J'ai donc opté pour une méthode plus rapide, assez similaire aux techniques employées sur certains cadenas à bagues: le décodage.

La combinaison est définie par la position de l'encoche sur les rotors

Le principe du cryptex est simple: chaque anneau possède une encoche en face du chiffre qui lui est associé dans la combinaison, ce qui n'autorise la partie mobile (l'anse) à ne bouger que lorsque les encoches des anneaux sont alignées avec la barre de verrouillage, autrement dit lorsque la bonne combinaison est choisie. L'objectif quand on cherche à décoder la combinaison est donc de retrouver la position de ces encoches à l'aide d'un outil nommé "décodeur".

Le cryptex de Ugears, ouvert :)

J'ai utilisé une canette vide pour en récupérer la tôle, puis découpé cette dernière de façon à avoir une fine languette de métal. En plaçant cette dernière entre deux anneaux (ou rotors), et en faisant tourner ces derniers, la languette est "attrapée" par l'encoche et entraînée dans la rotation de l'anneau, dévoilant ainsi un chiffre de la combinaison. J'ai ainsi pu retrouver les trois chiffres composant cette combinaison, et ouvrir le cryptex (ouf !).

Réalisation de l'escape game (phase 1)

Je pensais que cela allait être une tâche facile de créer cet escape game, mais non. La particularité des escape games basé sur des cartes, comme Unlock, c'est que la plupart des actions nécessitent de faire des combinaisons. Unlock utilise par ailleurs une application pour Android et iOS afin de proposer des casse-têtes, des puzzles, et même de la réalité augmentée. En ce qui me concerne, je n'avais pas le temps de développer une application aussi complexe, cela va de soi. Il faut donc anticiper un tantinet les numéros que l'on va attribuer aux cartes, afin d'éviter les erreurs et de permettre l'utilisation de valeurs crédibles en fonction des éléments à trouver.

Je me suis donc lancé en début d'après-midi, en partant de recherches sur Google Images pour trouver mes images de base (il ne vous aura pas échappé que je ne suis point graphiste, et heureusement) et Inkscape pour la conception des cartes. Il m'a fallu un peu plus d'une heure pour pondre une histoire et une ébauche de résolution, créer les différentes cartes et intégrer le tout.

J'ai ensuite imprimé l'ensemble des cartes, les ai découpées et assemblées. Je les ai ensuite essayées en y jouant avec mes minis-moi, qui se sont bien pris au jeu !

Test de l'escape game avec les enfants

Réalisation de l'escape game (phase 2)

Cette phase de test a été l'occasion de trouver des erreurs, de penser à des améliorations, en bref de le rendre un poil meilleur ! Car bon, il ne faut pas l'oublier: il s'agit d'un petit escape game conçu en moins de 2 heures avec les moyens du bord.

J'ai aussi publié sur Twitter et Instagram une photo de ce jeu, et plusieurs personnes ont manifesté leur intérêt. Du côté de la famille et des amis, où on avait fait passer quelques photos, c'était la même chose. L'idée a donc germé de le diffuser. Et pour le diffuser, il faut l'améliorer et le rendre utilisable par d'autres (aïe).

La première modification apportée a été de changer le nom. En effet, le nom d'origine était "Le trésor d'Ecco Vid", mais la blagounette n'a pas été directement comprise par les enfants. Dommage. Sur conseil de mon épouse, j'ai changé le nom de Ecco Vid en Ecco Rona, qui sonne mieux et annonce de suite la couleur :). J'ai aussi procédé à plusieurs bugfix suite à la session de test (quelques erreurs sur des numéros, un numéro caché trop visible, etc.), et ai ajouté toute une section concernant les règles (encore trop sommaires à mon goût), l'assemblage et la personnalisation.

Release de la version 1.0 du jeu

Après ces quelques heures supplémentaires à fignoler les cartes et les énigmes, j'ai tout poussé sur Github (fichiers de conception SVG, polices de caractères utilisées et PDF final), et vous pouvez donc vous en resservir. Vous pouvez imprimer le jeu à partir du fichier PDF ou bien le modifier comme il vous chante ce dernier, pour l'adapter à votre situation (cadenas différent, énigmes plus corsées, à vous d'improviser !).

Le tout est diffusé sous licence Creative Commons CC-BY-NC-SA, donc faites vous plaisir !

Télécharger le PDF du Trésor d'Ecco Rona

Accéder au repository Github pour contribuer

19
sept.
'19

Challenge Black Badge leHACK 2019: le vainqueur

Publié le 19 septembre 2019

Lors de la première édition de leHACK qui a eu lieu en juin dernier, tous les participants se sont vu remettre un badge électronique assez minimaliste. Ce badge était constitué d'une LED et de ce qui ressemblait à une antenne. Et quelques petits trucs en plus, sensiblement cachés dans le circuit imprimé.

Premières fausses pistes

Ce n'était pas le premier challenge lié au badge que je réalisais, mais celui-ci a eu tout de même son lot d'erreurs. La plus grosse fut de ne pas mettre directement, comme je l'avais fait il y a deux ans, un indice ou un lien vers le début du challenge. Du coup, tous ceux qui s'y sont collés n'ont pas vraiment su par où commencer, et bon nombre d'entre eux ont repéré l'indice placé sur le badge: "Place me somewhere and be enlightened". Aussi se sont-ils empressés de chercher où placer le badge, harcelant le staff et moi-même pour avoir un indice permettant de localiser l'endroit en question.

Et il y a ceux qui ont cru que l'antenne était une antenne NFC (il y avait de quoi s'y méprendre), et qui ont essayé de "lire" le badge avec différentes applications. Ce qui a eu pour conséquence de faire clignoter la LED, avec un motif propre au fonctionnement du NFC. Certains ont pris cela pour le début du challenge, et ont ainsi cherché à décoder la trame, qui n'était qu'une conséquence de la tentative de communication du téléphone avec le badge. Ce dernier ne répondant bien évidemment pas.

J'ai ainsi rectifié le tir via un tweet indiquant qu'il y avait un indice pour identifier l'endroit où démarrait le challenge, qu'il s'agissait d'une URL, mais que ce n'avait rien à voir avec le texte. On était déjà l'après-midi, la journée était bien entamée.

Finalement, plusieurs participants ont tiqué sur la présence de mon avatar sur le circuit imprimé, et sont allé chercher du côté de ce blog. D'autres ont juste pensé qu'il s'agissait d'une sorte de signature, là encore un manque de clareté de ma part dans la conception de ce challenge.

Les différentes étapes

Quand j'ai pensé à ce challenge black badge, je voulais qu'il y ait différentes techniques et connaissances mises en oeuvre. Pour varier les plaisirs, mais aussi pour amener les participants sur des terrains qu'ils ne connaissent pas forcément, bien qu'il n'y ait rien eu de super exotique en soit. Les étapes étaient donc les suivantes:

  • Une petite épreuve de stéganographie des familles, avec un fichier polyglote très simple (coucou Ange !) et une truc moins sympa pour trouver l'URL de l'épreuve suivante ;
  • Un peu de cryptographie, là encore rien de très difficile si l'on connaît les différents modes d'opération ;
  • De la rétro-ingénierie de firmware, avec du nRF51822 et du Micropython dedans ;
  • Une capture radio d'une émission de données, à analyser avec certains outils dont je parlais (oh surprise) dans mon talk ;
  • Une devinette finale qui imposait de m'envoyer par email tout un ensemble d'informations répondant à celle-ci.

Je ne vais pas entrer dans les détails de la résolution de ces épreuves car différents write-ups ont été écrits et publiés par les participants (liens plus bas), mais je vais élucider certains points techniques et l'origine de certaines étapes.

Tout d'abord, la seconde étape. Je voulais intégrer une épreuve de cryptographie abordable, pas techniquement très complexe mais qui joue avec la manière dont elle est mise en oeuvre plutôt que la robustesse des clés ou des algorithmes. Disons que le bruteforce c'est bien, mais l'objectif était d'amener une vulnérabilité moins triviale qu'une clé de chiffrement facilement devinable (ou factorisable), et des concepts de mathématiques rebutant le débutant. Il m'a semblé intéressant d'explorer les modes d'opération, car tout le monde connaît le mode CBC (on dit un grand "merci" aux attaques par oracles de padding), mais je me suis rendu compte que les autres modes étaient un peu délaissés. j'ai donc opté pour une épreuve basée sur le mode CTR, qui est méconnu de certains bien que très utilisé (notamment dans divers protocoles utilisant de l'AES-GCM ou de l'AES-CCM).

De même, il me semblait inévitable de réaliser une épreuve de rétro-ingénierie de firmware. Le souci, c'est que le RE d'instructions ARM est devenu mainstream et qu'avec la sortie de Ghidra, eh bien c'est devenu beaucoup plus simple. J'ai alors pensé à une fonctionnalité que j'avais découvert quand je bossais sur le développement de Radiobit: les frozen modules. Le système Micropython, que l'on trouve notamment sur le Micro:Bit, permet lors de sa compilation d'intégrer des modules complémentaires développés en Python, mais de façon native. Un outil permet alors de transposer le code python du module en question en code C, et de le compiler et de l'intégrer aux bibliothèques de base. Bien sûr, le code C contient le bytecode du module ainsi que des métadonnées, et donc toutes les informations pour désassembler et interpréter le code du module (méthode pour les furieux). Par ailleurs, le code principal de cette troisième étape en a fait buggé plus d'un: on a bien le code Python du programme principal, mais pas de trace du module crackme ! Plusieurs solutions utilisant différentes techniques ont été trouvées, dont certaines assez originales. Je vous laisse lire les write-ups pour vous faire une idée des différentes méthodes. Cette étape a été la plus difficile à résoudre, beaucoup de participants l'ayant téléchargée mais peu résolue durant l'évènement.

L'étape suivante, la quatrième donc, consistait à aller au stand de digital.security et de demander la "boîte magique", une boîte spécifiquement conçue pour utiliser l'antenne du badge pour transmettre une donnée via un signal lumineux. Seulement voilà, il y avait un hic. Ma super boîte magique n'a pas supporté le voyage, et ne voulait plus faire allumer la LED du badge. J'ai passé quelques heures à debugger le truc, sans succès, puis j'ai indiqué aux personnes du stand de renvoyer ceux qui demanderaient cette boîte vers moi (via Twitter ou e-mail). Bizarrement, personne ne m'a contacté durant l'après-midi ou dans la nuit. Le troisième niveau aura eu raison de la majorité des participants.

J'ai donc, durant les jours suivants, distribué par Twitter et autres médias l'URL de la cinquième étape: un fichier de capture radio effectué via un SDR. L'objectif était clairement d'extraire le contenu de la communication. Là encore, rien de difficile pour qui connaît le domaine, mais c'est loin d'être le cas de la majorité des hackers présents: ces derniers savent utiliser GQRX ou des outils similaires, mais quand il faut enchaîner les blocs GNURadio, c'est une autre histoire. Avec la bonne méthode d'analyse (subtilement abordée dans mon talk de leHACK), cela allait tout seul et l'extraction ne posait plus trop de problème. On trouvait alors un lien vers l'épreuve finale: la devinette de la mort.

La devinette de la mort était la suivante:

Already there when I started to hack, it is nowadays gone and will never come back. This platform was once among the bests, providing an early hacking contest and amazing tasks to solve without a rest.

Show me your abilities by telling me what this platform is. But don't yell it here, just whisper it to my ear, show me what it did look like, show me what I did look like at this time, and the black badge will no longer be mine.

Virtualabs

L'objectif était donc d'identifier une plate-forme où j'ai découvert le hacking, de me montrer à quoi elle ressemblait, et à quoi je ressemblais à cette époque (histoire de ressortir les photos dossier).

Le vainqueur

La première personne à m'avoir fourni tous les éléments, et je dis bien TOUS les éléments, est Vincent Dehors. Bravo à lui, il remporte le Black Badge leHACK 2019 ! Il y aura peut-être un visuel dans les semaines à venir, qui sait.

Write-ups

Encore bravo à vous deux d'avoir complété la majorité de ce challenge, j'espère que vous l'avez apprécié !

04
sept.
'19

Analyse forensique du crash d'un aéromodèle radio-commandé

Publié le 04 septembre 2019

Cela va faire presque deux ans que je pratique à nouveau l'aéromodélisme. Je suis tombé dedans à 14 ans, et j'avais du laisser cette activité en suspend lorsque j'entamais mes études supérieures. Il y a environ deux ans, je décidais de m'y remettre et faisais alors l'acquisition d'un avion radiocommandé thermique, car mes précédents modèles n'étaient pas terminés et avaient fini en bois de chauffage (ou presque). Tout se passait bien, jusqu'à la séance de la semaine dernière où mon avion s'est lamentablement écrasé dans un champ. C'est l'occasion de mener une petite enquête style BEA afin de trouver l'origine de l'accident.

Le crash

Je m'étais installé tranquillement sur le terrain du club (homologué DGAC), et j'ai entamé cette session de vol par la vérification du modèle. Cette étape est obligatoire, durant laquelle on effectue un ensemble de vérifications avant le vol. Les pilotes d'avions grandeurs (des "vrais" avions, les chanceux) suivent exactement le même procédé avant chaque vol. Je vérifie ainsi le bon état des servomoteurs, des connections électriques et électroniques, ainsi que l'état des commandes de gouvernes, les serrages des vis, etc. Tout est passé au crible avant la mise en route du modèle, afin d'éviter toute surprise en vol.

L'avion paré pour la session de vols

J'effectue ensuite plusieurs vols afin de m'entraîner aux atterrissages, car c'est une phase qui est relativement sensible et que je dois en particulier travailler. Oui, j'ai appris à piloter assez récemment, et ceci fait partie de l'entraînement du débutant. Tout se passe bien jusque là, mes atterrissages ne sont pas parfaits mais l'avion se pose en un morceau et en douceur à chaque fois. Après avoir usé un plein de carburant, je remplis à nouveau le réservoir et entame une autre série de vols, toujours dans l'optique d'affiner ma technique d'atterrissage.

Je pose l'avion une fois et je repars dans la foulée (un "touch and go"), j'entame une autre approche et me rend compte que cela va être difficile de poser. En effet, l'avion arrive trop haut et si je prends la décision de poser, il terminera sa course en dehors de la piste et certainement dans un sale état. Dans ce cas de figure, l'usage veut que l'on remette les gaz à fond et que l'on prenne de l'altitude, ce que je fais. Enfin, l'avion reprend de la vitesse mais reste en phase de descente. La commande de profondeur, qui gère l'inclinaison de l'avion, ne semble plus répondre. Je vois ainsi l'avion foncer plein gaz vers le sol, en légère descente, avec pour conséquence un crash assuré.

En dernier espoir et vu qu'il me restait encore un peu de marge, je décide de m'acharner sur la commande de profondeur. Et elle se remet à fonctionner ! L'avion cabre un peu brusquement et reprend de l'altitude. Malheureusement, vu que j'étais en panique j'ai un peu forcé sur la commande et du coup il risque le décrochage, et là encore c'est le crash assuré. J'essaie d'ajuster l'inclinaison en faisant piquer légèrement l'avion, mais rien n'y fait. C'est le décrochage. L'avion se met à piquer vers le sol, et je n'ai pu que couper les gaz et observer le résultat: un bruit sourd fait de bois qui craque, de toile qui se froisse et de moteur qui s'écrase dans la terre. Je ramasse les restes dans le champ voisin, je mets le tout dans la voiture et rentre chez moi.

Un avion au tapis, un !

Analyse de l'accident

Une fois à la maison, je tente de rassembler mes souvenirs. Pas facile, tout cela s'est déroulé en un temps relativement court, et je crois me rappeler de choses qui au final ne sont peut-être pas arrivées. Pendant un temps je pensais que la commande des gaz ne répondait plus, mais après quelques jours j'étais à nouveau persuadé qu'elle fonctionnait bien (cf. les faux souvenirs).

Tout comme le BEA mène l'enquête lors d'accidents ou d'incidents impliquant des aéronefs, je décidais de chercher l'origine du mien. A ce stade de l'enquête, je suspecte tout de même plusieurs organes d'être à l'origine du dysfonctionnement: le récepteur peut avoir cafouillé, les servomoteurs être tombés en panne, ou les commandes des gouvernes peuvent avoir lâché.

Première étape, analyser les commandes des gouvernes. Un problème mécanique est si vite arrivé, bien que j'ai vérifié ces dernières avant le vol. Aucune surprise de ce côté là, tout est bien fixé et rien n'a lâché. Cela ne semble pas venir de la mécanique. Je passe ensuite au récepteur, l'alimente de nouveau et vérifie la connexion avec la radiocommande. Pas de perte au niveau de cette dernière, et un servomoteur branché sur les gaz répond très bien. Je teste avec le même servomoteur l'ensemble des commandes, et tout fonctionne comme prévu. Le récepteur est donc peu susceptible d'avoir eu un défaut de fonctionnement, mais un défaut de réception n'est pas à exclure. Enfin, je reconnecte tous les servos au récepteur (à l'exception des ailes) et vérifie le fonctionnement de ces derniers. Et là, surprise ! Le servomoteur gérant la profondeur ne répond pas. Pire, lorsqu'il est actionné manuellement, il bouge et se bloque de manière intempestive !

Il ressort ainsi plusieurs hypothèses des premières constatations. La première hypothèse formulée est que le récepteur a eu des difficultés à recevoir les signaux de ma radiocommande. La seconde est que le servomoteur de la profondeur a eu un défaut de fonctionnement. La troisième est que la panne a été causée par un évènement inconnu qui n'a pas survévu au crash. Parmi ces hypothèses, la première est très peu probable car au moment de l'atterrissage, ma radiocommande était proche de l'avion. La troisième est très difficile à déterminer car elle nécessite une inspection minutieuse des débris, ce qui est plus complexe à faire sur un modèle réduit que sur un véritable avion. Imaginez, un modèle réduit n'utilise pas de tôle pour ses parois mais une simple toile tendue... Je décide donc de creuser la seconde hypothèse.

Analyse du servomoteur défectueux

Le servomoteur en question est un HS-311 conçu par Hitec. Ce type de servomoteur est peu onéreux et réputé pour être fiable, et est utilisé par de nombreux modélistes. Avant d'entrer dans les détails de l'analyse, quelques rappels sur le fonctionnement des servomoteurs.

Un servomoteur est un système électromécanique permettant de convertir une information de position (la commande transmise) en mouvement mécanique asservi (la position du pignon). Le servomoteur a donc un moteur pour provoquer le mouvement mécanique couplé à un capteur de position, généralement un potentiomètre relié aux pignons du mécanisme de réduction. Le servomoteur est ainsi capable de faire tourner le moteur dans un sens ou dans l'autre, en fonction de la position à atteindre. Son système de pignons de réduction permet d'assurer un certain couple et une résistance aux efforts.

Je décide alors de démonter intégralement le servomoteur, afin d'isoler l'électronique de la mécanique. Je mets de côté le circuit imprimé qui contrôle le moteur à courant continu, et dessoude le moteur. Dans un premier temps, je me concentre sur le moteur: je câble directement le moteur sur une batterie, et tente d'appliquer un effort sur le pignon principal. Et là, j'arrive à stopper la rotation du moteur, ce qui n'est pas du tout normal. En effet, le moteur devrait se remettre à tourner mais au lieu de cela, il reste immobile. On dirait bien que le moteur est à l'origine du problème.

Je démonte alors le moteur à coups de pince, et à l'aide d'une dose de force et de subtiles coups donnés sur l'axe arrive à le démonter intégralement. Si vous n'avez jamais vu l'intérieur d'un moteur à courant continu, les photos ci-dessous vous éclaireront.

Rotor monté sur le socle

Stator du moteur

Il s'agit d'un moteur à pinceaux (ou moteur "brushed"), qui font contact avec une bague spécifique (le commutateur) qui alimente ensuite les différentes bobines et fait tourner le rotor. Le stator quant à lui est simplement composé d'un gros aimant. Le moteur ici présent possède un rotor constitué de trois bobines, chacune ayant un contact dédié sur l'axe du rotor avec lequel les pinceaux sont en contact.

Vérifions le bon état des bobines, pour cela je mesure la résistance à l'aide d'un multimètre. Si cette résistance est non-nulle (une dizaine d'ohms) cela signifie que la bobine est opérationnelle. Si cette dernière est nulle ou infinie, cela signifie que la bobine a fondu (court-circuit) ou que le fil est rompu à un endroit. Dans mon cas, il se trouve que deux bobines ont une résistance infinie, et donc que leurs bobinages sont rompus.

La conséquence de ce défaut est triviale: pour une position spécifique du rotor du moteur, la bobine associée ne produira aucun champ magnétique et donc aucun mouvement. Ceci dit, le rotor a une certaine inertie et en temps normal celle-ci permet de passer au delà du bobinage défectueux et de garder le moteur en rotation. Cependant, si le servomoteur s'arrête sur une bobine défectueuse, cela va causer une défaillance dans le couple et potentiellement un arrêt du moteur. Autrement dit, le moteur ne redémarrera pas si ce dernier est déjà arrêté avec les pinceaux alimentant une ou deux bobines défectueuses.

Recherche de l'origine du défaut du moteur

Si l'on cherche sur Internet les spécifications du moteur, on tombe au bout d'un moment sur un moteur à l'allure très proche, le JL-RF020 de Shantou Jiali Micro Motor Co. Ltd, qui possède les mêmes dimensions et la même allure:

Vue de face du moteur trouvé dans le servo

Et voici la fiche technique du JL-RF020. Jugez de la ressemblance:

Fiche technique du moteur JL-RF020

Le moteur est ainsi annoncé avec une tension nominale de 4.5 volts et une tension maximale de 5.5 volts. Etrange, car la fiche technique du servomoteur indique que ce dernier accepte une tension d'alimentation allant de 4.8 volts à 6 volts. Cette tension d'alimentation est appliquée à chaque bobine du moteur, sachant que deux bobines sur 3 sont alimentées en permanence. A l'aide de mon multimètre, j'ai mesuré la résistance de la seule bobine restante: environ 14 ohms. Cela donne un courant maximal pour le moteur de:

I = U/R = 6.0 / (1/((1/14)+(1/14)) = 0.857 A

Chaque bobine est parcourue par un courant de 430 mA environ lorsque le servomoteur est soumis à une tension de 6 volts. Une rupture du fil de bobinage d'une bobine de moteur est très probablement due à une surintensité, ce qui a pour conséquence de faire fondre ce dernier et de couper le circuit. Comme un fusible. La résistance de la bobine étant fixe, seule une tension plus élevée que 6 volts peut provoquer une intensité supérieure à 430 mA.

La tension relevée sur l'accu NiMH utilisé dans mon avion était de 6.7 volts au moment du crash. Cette tension était relevée en temps réel et affichée sur ma radiocommande dans les informations de télémétrie. Calculons l'intensité du courant fourni au moteur:

I = U/R = 6.7 / 7 = 0.957 A

Une telle intensité est au-delà de ce que peut supporter le moteur. Si l'on regarde l'intensité maximale que peut supporter le fil du bobinage, en nous basant sur son diamètre (0.18mm), on peut se rendre compte que ce dernier tolère au maximum 430 mA, soit approximativement l'intensité parcourant le bobinage lorsque le moteur est alimenté en 6V.

Si l'on alimente le moteur avec 6.7V, l'intensité parcourant le bobinage provoque un échauffement qui peut être fatal au moteur. Cependant, le fil met du temps à chauffer et fondre, et il faut que cette intensité traverse le fil durant une certaine période de temps.

Origine de la surintensité

Tout porte à croire que le servomoteur a été victime d'une surintensité qui a provoqué la rupture d'un fil de bobinage du moteur et le blocage de ce dernier. Mais comment ce servomoteur s'est-il retrouvé alimenté par une tension supérieure à la tension maximale de fonctionnement (6V) ?

J'utilise un accumulateur NiMH ("Nickel - Metal hydride"), qui est composé de 5 cellules. Chaque cellule délivre 1.2V, soit 6V au total. Mais ça, c'est dans le meilleur des mondes. Car lorsque l'on charge une batterie NiMH, les cellules peuvent être chargées jusqu'à environ 120% de leur capacité, soit 1.44V chaque. Ce qui donne une tension de sortie de 7.2 volts, au lieu des 6 volts nominaux. De fait, l'emploi de cet accumulateur lorsqu'il est pleinement chargé augmente les risques de rupture du fil de bobinage du servomoteur provoqué par une surintensité.

Il aurait mieux fallu choisir un accumulateur de 4.8 volts (composé de 4 cellules), dont la tension maximale fournie à pleine charge est de 5.8 volts, ce qui ne risque pas d'endommager le servomoteur. Le site sur lequel j'ai acheté l'avion en question recommandait l'accumulateur de 6 volts, je n'ai pas forcément cherché à vérifier les spécifications de ce dernier et ai donc suivi les recommandations du vendeur.

Conclusion

Après investigation, le moteur du servomoteur gérant la profondeur a subi une surintensité qui a amené deux des trois bobinages du rotor à se rompre, provoquant un dysfonctionnement du servomoteur. La commande de profondeur étant très sollicitée notamment lors des phases d'atterrissage, la probabilité d'un défaut de ce servomoteur était relativement élevée.

Une pleine charge de l'accumulateur de réception a amené ce dernier à fournir une tension supérieure à la tension maximale supportée par les servomoteurs, ce qui est probablement à l'origine de la surintensité qui a causé la défaillance.

Avant cette session de vol, j'avais chargé à bloc l'accumulateur de réception bien que ce dernier ait été peu utilisé lors de la session précédente. Habituellement, l'accumulateur fournit une tension autour de 6 volts (entre 6 et 6.2 volts) car je le chargeais rarement au maximum. C'est donc ma méconnaissance du fonctionnement des accumulateurs NiMH et le fait que je n'ai pas consulté la documentation du constructeur du servomoteur qui sont à l'origine de ce crash.

Leçon apprise.

Failure is always an option


Les contenus disponibles sur ce blog sont publiés sous licence Creative Commons BY-NC-SA.
Vous pouvez réutiliser tout ou partie de ces contenus à condition de citer l'auteur et l'origine, vous ne pouvez en faire une utilisation commerciale, et enfin vous devez partager tout travail ou œuvre dérivée sous les mêmes conditions — c'est-à-dire avec la même licence d'utilisation Creative Commons.