4 Pi Epsilon Zero

Pour pallier à ces problèmes, certains États ont tenté de nouveaux systèmes dits "numériques" qui se basent principalement sur des ordinateurs "de confiance", sous forme de bornes, supposées sécurisées et accessibles depuis des bureaux de vote. Historiquement, la plupart de ces tentatives sont basées sur des protocoles opaques, dont la sécurité n'est garantie que par la parole du fabricant. 

En plus d'être un risque supplémentaire pour la fraude massive, de telles implémentations ne résolvent par le problème des coûts logistiques à chaque élections : il faut des gens pour surveiller les machines, pour les maintenir, et pour ouvrir les bureaux de vote. (D'ailleurs, une partie de ce personnel ne peut plus se composer de bénévoles, ce qui pousse à se poser des questions sur le gain financier réel de tels dispositifs.)

Maintenant que nous avons vu quels étaient les défauts du scrutin papier et pourquoi le vote électronique souvent proposé n'était pas mieux, penchons-nous sur le système proposé ici.

Cahier des charges d'un vote 

Chaque électeur doit pouvoir voter une et une seule fois

Le décompte doit être possible pour obtenir le résultat du vote

Le vote de chaque électeur doit être obfusqué suffisamment pour qu'il ne puisse être inquiété de représailles.

(Optionnel) Le dépouillement ne être possible qu'après la fin des votes.

Charges supplémentaires pour un "crypto-vote"

Chaque individu doit pouvoir vérifier le résultat des élections, le jour même comme dix ans plus tard

Chaque électeur doit pouvoir vérifier que son vote fait bien partie du total

Remarque et hypothèses

La méthode détaillée ci-dessous ne décrit pas chaque détail de l'implémentation. Elle propose parfois des solutions mais n'exclut pas des alternatives diverses, plus adaptées à d’autres applications.

A titre d'exemple, on va ici supposer que chaque électeur possède un ordinateur sécurisé et une connexion Internet. Un tel modèle est idéaliste dans un vote à l'échelle d'un pays, (mais pas pour un vote d'entreprise) mais gardez en tête qu'il peut être possible avec des moyens techniques appropriés de s'en approcher.

Après ce long prélude, rentrons dans le vif du sujet. Pour cela nous allons procéder de l'implémentation basique à la plus complète.

L'implémentation simple sans anonymat

Nous voulons utiliser l'inviolabilité de la blockchain pour stocker et publier le vote des électeurs.

Pour mettre en place un vote, l'organisme organisateur doit établir une liste publique de l'ensemble des électeurs et de leurs clés publiques. Pour cela il peut simplement publier dans une blockchain (signant de son autorité) l'ajout ou la suppression d'un électeur, ou le changement de sa clé publique.

Il suffit ainsi par exemple de se rendre en mairie pour effectuer une de ces opérations, ou pour obtenir plus d'informations sur un électeur existant (afin d'éviter l'existence d'électeurs fantômes)

Lorsque l'organisme veut organiser un vote, il en publie les détails (signés) dans la blockchain.

Alors, lorsque le scrutin est ouvert, chaque électeur peut effectuer un vote, le signer avec sa clé privée et le publier. Si l'électeur est valide et qu'il n'a pas encore voté, son vote est accepté dans la blockchain.

À la fermeture du vote (publiée par l'organisme à l'heure prévue), tout le monde peut faire les comptes et le résultat est sans appel.

Jusque là, on a beaucoup écrit pour ne pas dire grand chose de nouveau : cette implémentation, quoique efficace, ne remplit pas du tout le cahier des charges que l'on s'était donné.

Première approche d'obfuscation

Maintenant que l'on a décrit la "trame de base" du crypto-vote, intéressons-nous aux méthodes possibles pour permettre l'anonymat de l'électeur.

Il est a priori impossible d'avoir un système où l'anonymat est total, tout en donnant la possibilité de prouver que quelqu'un a voté et de d'être sûr que son vote fait partit d'un total. (Si vous trouvez un moyen, envoyez-moi un message !)

Par contre il est possible d'offrir un anonymat partiel : l'idée est de mélanger le vote de plusieurs électeurs. (Après tout, c'est ce que fait une urne !)

Imaginons que 50 électeurs forment un groupe choisi aléatoirement. Au sein de ce groupe, tout le monde partage son vote publiquement. 

Une fois que tout le monde est à même de faire un total, chacun construit un message contenant ce total, le signe, prouvant qu'il a vérifié que son vote est bien dedans, puis l'envoie aux 49 autres. Au final, le groupe finit par construire un message contenant le total des 50 voix accompagné de 50 signatures. Ce message peut alors être publié. Si aucun des 50 membres n'a déjà voté, alors ce "dépouillage" est inclu dans la blockchain. Sinon, les électeurs doivent recommencer jusqu'à ce que leur vote soit pris en compte (Il serait possible de détecter ce genre d'individus malfaisants plus tôt pour économiser des calculs, mais comme ce genre d'attaque ne casse pas la sécurité, nous ne l'aborderons pas ici.)

Remarque : Il est bien évident que chaque votant ne va pas s’amuser à faire ça à la main, il a pour ça un logiciel libre de confiance effectuant ses actions automatiquement !

Avec cette méthode, seuls 49 autres personnes au monde ont connaissance de votre vote. (On va voir qu’on peut faire mieux) Pour se protéger de ces inconnus, chaque communication au sein du groupe d'effectue ainsi :

Alice veut envoyer son vote à Bob : Alice chiffre son vote avec la clé publique de Bob, puis seulement signe ce message. Ainsi, Bob peut vérifier que le message provient d’Alice, et l'ouvrir. Seulement, Bob ne peut pas faire fuiter le vote avec la signature d’Alice (pour prouver ses dires) sans publier aussi sa clé privée, information sensible et attaché à l’identité de Bob.

Dans cette méthode, on peut se demander pourquoi 50 ? Ce nombre est clairement arbitraire, mais permet d'avoir un nombre réduit de transactions (environ 50 par personne) tout en garantissant suffisamment de diversité pour obfusquer le vote de chacun. (En effet, si les 50 personnes votent toutes pareil, alors leurs votes ne sont plus anonymes, comme si un bureau de vote obtenait par hasard 100% de vote pour un candidat)

Problème : Il est possible d'imaginer une société secrète constituée de 2% des électeurs. Si chacun de  ces membres envoyaient secrètement les votes des 49 autres à la société secrète, elle serait en mesure de casser l'anonymat de presque tous les électeurs.

Diviser pour mieux régner

La solution à ce problème est de réduire la taille des groupes à 2 !

C'est quoi cette histoire ?

Évidemment on ne va pas s'arrêter là, on va imbriquer le processus évoqué plus haut comme des poupées russes.

Un groupe de deux se forme, ils obtiennent un total de leur deux voix comme indiqué précédemment. Ils choisissent alors un autre groupe de  deux et leur envoient ce total. L'autre groupe fait de même. Il est alors possible pour chacun de calculer le total des 4, de le signer et de l'envoyer aux autres. Ainsi, le groupe de 4 a construit le total des 4 voix vérifié par tous. Ils n'ont plus qu'à trouver un autre groupe de 4 et recommencer la procédure !

Lorsqu'ils ont atteint une certaine taille, par exemple 1024, les participants ne cherchent pas d'autres groupe mais publient alors le total avec les 1024 signatures dans la blockchain.

De cette manière, une seule personne au monde connaît votre vote, deux si vous avez votez comme votre binôme, 4  ou 8 si les probabilités ont une dent contre vous. (De cette manière aucune société secrète n'aura votre vote).

Pour finir le cahier des charges, ajoutons qu'il est possible (de manière assez partielle) d'empêcher le dépouillement public avant la fin du suffrage.

Pour cela il suffit que les 1024 personnes ne publient pas directement le total mais : le total juxtaposé à une "graine" (=un grand nombre aléatoire), le tout haché par une fonction à sens unique. Les 1024 signent ce hash, et c'est ce hash qui est inclu dans la blockchain.

Lorsque le scrutin est fermé, tout le monde publie le total et la graine associé à son bloc. (Chaque individu est en mesure de le faire, individuellement des 1023 autres), permettant au reste du monde de vérifier que ce total + graine correspond bien au hash publié précédemment.

La dernière implémentation proposée répond ainsi à l'ensemble du cahier des charges que l'on s'était posé. Il permet en théorie de garantir l'intégrité d'un vote, le tout pour une infrastructure quasi inexistante.

Limites

Comme d'habitude, il est important de s'intéresser aux faiblesses du système que l'on propose.

Premièrement, notre protocole se base sur la cryptographie asymétrique et sur la blockchain, il a donc les éventuelles faiblesses associées. Mais comme nous l'avons discuté, ces faiblesses sont quasi-inexistantes.

Dans le cas de notre implémentation, on introduit deux nouveaux vecteurs d'attaque :

1. La clé privée de l'organisme devient une donnée très sensible, toutefois on peut construire un "édifice de clés" avec plusieurs clés certifiées et une hiérarchie entre elles permettant de gérer d'éventuelles fuites.

Un "tricheur" appartenant à cet organisme pourrait abuser de son pouvoir pour créer des comptes fantômes lui permettant de voter plusieurs fois, il est donc nécessaire qu'il y ai sur la liste des votant une transparence suffisante pour éviter de genre d'attaque.

2. Enfin, en supprimant l'environnement contrôlé qu'est l'isoloir, on permet à des individus d'en contraindre d'autres à "voter devant eux", créant un possible marché parallèle des voix. Cette possibilité est un vrai problème pour une implémentation à grande échelle, trois solutions me semblent alors envisageables :

1. Restaurer l'environnement contrôlé en permettant par exemple de voter avec son smartphone uniquement depuis un lieu sécurisé.

2. Donner la mission aux forces de l'ordre de traquer ce genre de pratiques en les rendant illégales.

Imaginer votre banque : elle peut se résumer en quelque sorte à un organisme qui détient une liste de comptes et une liste de transactions. Lorsque vous voulez effectuer une transaction, vous en informez votre banque, celle-ci vérifie si votre crédit est suffisant, et l’ajoute éventuellement. Le récepteur vérifie alors auprès de la banque que la transaction soit bien enregistrée, et accepte de vous laisser repartir avec votre nouvelle voiture.

Ce qui est implicite dans cette situation, c’est que tout le monde fait confiance à la banque. On lui fait confiance pour bien tenir ses comptes, on lui fait confiance pour ne pas se faire pirater, on lui fait confiance pour ne pas faire faillite, etc.

Imaginez que vous ne vouliez pas faire confiance à votre banque, voire même, allons plus loin, vous ne voulez pas de banque ! Cependant, vous voulez quand même acheter une voiture, et l’or pèse un peu trop lourd pour vous.

C’est alors qu’entre en scène le Bitcoin : L’idée est d’avoir un journal des comptes et des transactions, publique et décentralisé. N’importe qui peut se créer un compte et si quelqu’un possède déjà des sous (des transactions qui pointent sur son compte), il peut y ajouter des transactions sortantes vers le compte du vendeur de voitures.

Tout cela est bien gentil, mais si tout le monde peut modifier la base de données, alors ça ne va pas marcher du tout !

Et c’est à ça que sert la cryptographie asymétrique :  La signature cryptographique permet de s’assurer que seul le détenteur d’un compte peut signer des transactions provenant de ce compte.

Oui mais s’il n’y a pas de centralisation, tout le monde aura une version différente du journal des transactions !

Et d’ailleurs, je peux dire à certaines personnes que je fais un virement à mon vendeur de voiture, et à d’autres que je fais un virement vers un autre compte que je possède ! Qui va croire quoi et comment mon vendeur pourrait-il accepter une telle monnaie ?

Ce sont à ces problèmes-là que répond la Blockchain.

Avec un système “centralisé”, on peut définir un serveur central comme celui ayant toujours raison. Mais pour un système décentralisé, il est nécessaire que tout le monde puisse se mettre d’accord sur une version.

L’idée proposée par la blockchain et de construire un journal de transactions constitué de blocs qui s’enchaînent les un les autres. (D’ou blockchain, où “Chaîne de blocs” en français)

Dans chaque bloc du réseau Bitcoin sont enregistrées environ 10 minutes de transactions. Pour être incluses dans un bloc, ces transactions doivent être valides (signées et avec provision) vis-à-vis des blocs précédents. L’idée pour empêcher le problème de la double dépense évoqué plus tôt est celle la plus ingénieuse de la blockchain : la preuve de travail.

La preuve de travaille (ou Proof of Work)

Pour qu’un bloc soit considéré comme “valide” par le reste du réseau, l’idée de la preuve de travaille est d’obliger, à ce qu’il se termine par la solution à un problème mathématiquement difficile. Tellement difficile qu’en moyenne, sur les millions d’ordinateurs du réseau, le premier trouvera une solution au bout de 10 minutes en moyenne.

C’est-à-dire un problème “mathématique” ?

Imaginer que vous avez une fonction dite “à sens unique”, c’est-à-dire qu’il vous est facile de calculer le résultat à partir d’une entrée ( f(x) à partir de x ), mais très difficile de déterminer pour quelle entrée on va avoir un résultat donné ( x à partir de f(x) ). 

Pour réaliser ce genre de fonction, on utilise des fonctions de hachage (ou “hash”) qui sont des algorithmes où de nombreuses permutations mélangent le message d’entrée dans tous les sens, d’une manière reproductible, mais très difficile à inverser !

Exemple d’un schéma qui fait peur : basé sur la méthode de hachage SHA-256 utilisé par Bitcoin.

Un problème “difficile” peut être par exemple de trouver une entrée commençant par un certain message (ici “Hello, world!”) dont la transformation par une telle fonction (ici SHA-256) débute par au moins trois zéros :

"Hello, world!0" => 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64 "Hello, world!1" => e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8 "Hello, world!2" => ae37343a357a8297591625e7134cbea22f5928be8ca2a32aa475cf05fd4266b7 ... "Hello, world!4248" => 6e110d98b388e77e9c6f042ac6b497cec46660deef75a55ebc7cfdf65cc0b965 "Hello, world!4249" => c004190b822f1669cac8dc37e761cb73652e7832fb814565702245cf26ebb9e6 "Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

La seule façon de trouver une telle solution est de tester des combinaisons au hasard jusqu’à trouver une qui satisfait au problème !

Pourquoi fait-on tout ça ?

Pour prouver qu’on a travaillé ! En effet quelqu’un qui trouve une solution à un tel problème a forcément dû dépenser beaucoup de puissance de calcul à la chercher.

L’intérêt pour la Blockchain

Plus haut, nous avions évoqué le problème dans un système décentralisé de mettre tout le monde d’accord sur la “bonne version” du journal des transactions. L’idée proposée par la blockchain est de dire que quiconque a la chaîne la plus longue a raison.

Cette idée est très puissante, c’est d’ailleurs la raison pour laquelle Bitcoin marche aussi bien !

Pour bien comprendre, détaillons un peu comment Bitcoin fonctionne :

Chaque ordinateur du réseau a l’histoire complète des blocs

Chaque ordinateur du réseau essaie de construire le prochain bloc. (On parle de minage, ou mining)

Pour ce faire, chaque ordinateur écoute les nouvelles transactions publiées, vérifie qu’elles sont valides (signées et approvisionnées) et éventuellement les inclut dans le bloc qu’il essaie de construire.

Ce bloc doit contenir un “hash” du bloc précédent, permettant de référencer clairement le block précédent, mais aussi d’éviter que quelqu’un ne commence à chercher une solution avant les autres.

Le problème à résoudre est basé sur un hash des transactions et de la référence au bloc précédent avec une difficulté adaptée automatiquement de telle sorte qu’un “mineur” parmi tous trouve environ toutes les dix minutes.

Lorsqu’un mineur trouve une solution, il publie son “bloc” contenant :

La référence au bloc précédent

La liste des nouvelles transactions

La “preuve de travail”

Lorsqu’un mineur travaillant sur un bloc reçoit une solution proposée par un autre mineur, il la vérifie (bloc et transactions individuellement). Si tout est correct et que bloc proposé est le suivant du dernier validé (ou s’il appartient à une branche valide et plus longue), alors, il ajoute le bloc à la chaîne qu’il a en mémoire et recommence à chercher le prochain bloc

Ce cycle est le cœur de la blockchain. 

Maintenant que nous avons vu comment ça marche, voyons pourquoi ça marche.

Pourquoi ça marche

Le processus décrit ci-dessus permet de maintenir un journal des transactions commun à tout le monde, et personne ne peut imposer sa version au reste du réseau sans réussir à miner un bloc sur deux.

Si jamais deux mineurs trouvent en même temps une solution et que des temps de latence ou des problèmes de connexion font qu’une partie du réseau reçoit une solution avant l’autre, alors la blockchain se divise en deux “branches”. Une telle situation ne mènera pas à l’anarchie puisque la première des deux branches à trouver une solution (et donc à devenir la plus longue) l’emportera sur l’autre par définition de la méthode. Dans ce cas les mineurs perdants abandonnent leur branche et se remettent à travailler sur la branche gagnante.

Non instantanéité

Une conséquence importante est que pour qu’une transaction soit considérée comme définitive, il faut attendre quelques blocs, le temps d’être sûr que la branche dans laquelle est enregistrée la transaction ne va pas être écrasée par une autre branche dans laquelle les comptes ont d’abord été vidés !

Pour réussir une attaque de ce type (on parle “d’attaque double dépense”), il est nécessaire de laisser un peu d’avance à la branche principale (le temps que la transaction soit considérée comme valide) puis la rattraper avec notre branche, sachant qu’on est en compétition avec le reste du monde réuni !

Il est donc nécessaire d’avoir plus de la moitié de la puissance de calcul du réseau pour casser la blockchain, ce qui peut être considéré comme impossible pour un seul individu.

Pourquoi miner ?

Pour que tout le système décrit plus haut puisse fonctionner, il faut que de nombreux serveurs tournent en permanence, effectuant des quantités astronomiques de calcul, sachant que tout cela a un coût.

Certaines personnes choisissent de miner pour le bien du réseau, mais pour que le système soit vraiment efficace il est important que les mineurs soient récompensés.

Dans le cas du protocole Bitcoin, chaque ordinateur ajoute dans la liste des transactions du bloc en cours, une transaction qui pointe vers son compte personnel. Ainsi, si le bloc est admis dans la chaîne, le mineur se retrouve récompensé d’une somme en bitcoin.

Dans le cadre de blockchains qui ne sont pas des monnaies, il faut trouver une autre façon de donner intérêt aux gens de miner, par exemple, il serait possible pour un organisme ou un état de promettre de faire des virements traditionnels à quiconque a trouvé une solution.

Au delà du Bitcoin

Il a beaucoup été question du bitcoin dans ce billet, et c’est logique puisque c’est grâce à cette crypto-monnaie que l’on a inventé la Blockchain. 

Cependant, cette invention dépasse largement son application aux crypto-monnaies. Il est tout à fait possible de tenir un journal de tout et n’importe quoi : des tweets, des transactions immobilières, des biographies, des déclarations de revenu, voir mêmes des votes.

L’idée du chiffrement asymétrique est qu’on utilise deux clés différentes : une dite privée que l’on doit garder secrète, et une dite publique qu’on diffuse le plus possible.

Le crypto-système de ce type le plus répandu (et le premier) est RSA (cf. Wikipedia), je ne rentrerai pas ici dans les détails (qui sont pourtant fascinants !) sachez simplement qu’il repose sur la difficulté mathématique de factoriser de très grands nombres !

- Il est ainsi possible (c’est l’illustration ci-dessus), pour un inconnu qui s’est procuré votre clé publique de chiffrer un message que seul vous, possédant l’autre clé (la clé privée) pourra déchiffrer.

L’analogie qu’on utilise souvent pour parler de cette méthode est celle qui consiste à dire que Alice met son message dans une boîte aux lettres fermée à clé ; et que seul Bob a la clé de la boîte aux lettres pour la récupérer ! Sauf que cette boite aux lettres est mathématiquement quasi-inviolable !

- Ce système offre une autre fonctionnalité, tout aussi intéressante : c’est la signature numérique.

L’idée est que la méthode précédente peut être utilisée dans l’autre sens : il est possible de chiffrer un message avec la clé privée que seul quelqu’un avec la clé publique pourra déchiffrer ! 

Quel intérêt me direz-vous ? Et bien si la clé publique a permis de déchiffrer un message, cela prouve que l’émetteur du message est bien détenteur de la clé privée.

C’est plus ou moins de cette manière que le protocole HTTPS du navigateur vérifie l’identité du serveur web associé à une adresse web. 

Généralement, pour éviter au récepteur de déchiffrer des documents de centaines de mégaoctets, on envoie plutôt le message en clair, accompagné d’une “signature”.

En quelques mots, cette signature n’est autre que le message condensé en une cinquantaine de caractères par une fonction dite “de hachage” puis chiffré via la clé privée. Il suffit ainsi au récepteur de comparer le message reçu “haché” par la même méthode à la signature déchiffrée pour s’assurer de l’identité de l’émetteur et de l’intégrité du message !

Toutefois, on peut seulement se souvenir que grâce à cette méthode, il est possible d’apposer sa signature sur un message, certifiant au reste de monde que l’on est l’émetteur du dit message ; et certifiant qu’il n’a pas été modifié par un tiers parti !

Pour résumer, on a deux fonctionnalités offertes par la cryptographie asymétrique :

- La possibilité de placer un message dans une boîte aux lettres que seule une personne bien précise pourra ouvrir.

- La possibilité de signer un message permettant à quiconque de vérifier l’identité de l’émetteur et l’intégrité du message.

Je tiens à finir en évoquant une question importante dans ce genre de domaine : Quelles sont les limites de sécurité de ces systèmes ?

RSA comme tous les autres crypto-systèmes asymétriques fondent leur sécurité sur des problèmes mathématiquement durs, ce qui signifie qu’il faut beaucoup beaucoup de calculs pour résoudre le problème sans connaître la clé secrète.

Par exemple pour casser RSA 2048 bit (un standard plutôt élevé), il faut factoriser un nombre ressemblant à :

16158503035655503650357438344334975980222051334857742016065172713762327569433945446598600705761456731844358980460949009747059779575245460547544076193224141560315438683650498045875098875194826053398028819192033784138396109321309878080919047169238085235290822926018152521443787945770532904303776199561965192760957166694834171210342487393282284747428088017663161029038902829665513096354230157075129296432088558362971801859230928678799175576150822952201848806616643615613562842355410104862578550863465661734839271290328348967522998634176499319107762583194718667771801067716614802322659239302476074096777926805529798115328

Sachant qu’il n’existe pas de méthode possible aujourd’hui autre que tenter toutes les possibilités une par une ! Même avec des centres de données comme ceux d’une agence gouvernementale, cela pourrait prendre des siècles voire plus, le tout pour une seule clé !

Conclusion : la sécurité du système repose uniquement sur la capacité de l’utilisateur à garder sa clé privée secrète.

1. Déjà, parce que notre modèle ne permet pas de méthode élégante pour gérer une tête ! En effet, dans le modèle suivant :

Il suffit d’aimants pour diriger la tête car il y a “mobile” qui garde son centre de gravité vers le bas. Et donc un aimant correctement positionné fait le travail.

En revanche, dans notre modèle, une telle chose n’est pas possible car aucun point à l’intérieur ou à l’extérieur ne “reste en haut”.

A moins de barder la surface de la boule électroaimants tous les centimètres carrés (ce qui techniquement et financièrement me parait compliqué) ou d’avoir une surface refroidit à -140°C super-conductrice et un aimant qui lévite au dessus (ce qui serait certes extrêmement cool, mais encore moins réalisable) ; notre modèle n’offre aucun moyen de gérer une tête depuis la boule.

2. La deuxième raison est qu’il est possible de faire une tête “autonome”. Voilà par exemple la réalisation d’un maker sur le sujet :

(Allez voir à 11:52 pour voir la démo)

Dans cette vidéo, la tête contrôle carrément l’équilibre de la boule, ce qui impose d’avoir une boule très légère. Cependant, si on posait cette tête sur notre modèle, la tête n’aurait qu’à se maintenir à la verticale quand la boule avance, et bouger à sa guise sur le haut “stable” de la sphère.

Il est important de préciser qu’un moteur physique n’est pas forcément une simulation parfaite de la réalité : dans Super Mario les déplacements ne sont pas régis par les mêmes lois que les objets du monde “réel” 

Revenons en à notre projet : pour simuler la physique de BB8, nous aurions pu utiliser un moteur physique déjà existant. Pour cela il serait nécessaire de décrire (c’est à dire modéliser) chaque objet de notre situation. Hors jusqu’à maintenant, nous nous somme contenté de dire “une boule ici, une roue accélérée là” sans rentrer dans le détail.

Pour ne pas avoir à modéliser chaque pièce en détail (roues, axes, moteurs, fixations, engrenages, matériaux, frottement) une option serait d’avoir un moteur physique faisant juste ce que l’on a besoin sans demander plus d’information. 

Comme une telle bibliothèque n’existe surement pas, encore moins dans le langage que nous le voudrions, notre choix a été de la créer nous-même.

Avec quelques connaissance en mécanique du solide, et sans avoir à se soucier des collisions entre objets, une telle chose n’est pas si difficile.

Deux options sont alors possibles : 

Décrire chaque objets (une boule, six roues) et leur interactions (liaisons, rotations possibles). Puis faire tourner les équations de base la physique dessus,  avec comme difficulté principale de prendre en compte les liaisons. (Si je tourne la boule dans un sens, je tourne certaines roues mais pas d’autre, etc.)

Décrire le strict nécessaire : par exemple pour une roue, la vitesse de rotation autour de son axe est la seule information nécessaire à la modélisation. Et prendre en compte chaque effets de chaque interactions.

La méthode 1 est plus “brutale” mais a le mérite d’être plus exhaustive. Elle est certainement plus difficile à coder “conceptuellement” car la description des objets, des liaisons et les changement de repère sont dur à intuiter. Cependant, elle a l’avantage de décrire parfaitement la physique sans le moindre doute.

La méthode 2 repose sur le fait qu’on cherche à simuler une situation bien précise, et donc plus facile à coder, mais a le défaut d’être plus répétitive dans le code. L’autre défaut que j’avais sous estimé est le risque d’oublier des choses.

En effet, avec la deuxième méthode on peut penser qu’on a un moteur correct car les déplacements semble naturels, alors qu’on a oublié un pan entier de la physique !

Dans ma précédente simulation, j’avais à moitié oublié l’effet gyroscopique !

J’en avais un peu parlé, je m’étais appuyé de l’illustration suivante :

Lorsque l’on pivote une roue autour d’un axe autre que son axe de rotation, on fait varier le moment cinétique de la roue. En plus d’exercer de la résistance à la rotation, l’effet gyroscopique entraîne de bien étrange effets :

Pour faire simple, lorsqu’on exerce un couple dans une direction X à une roue tournant selon Y, on observe un couple selon Z :

Ce couple (en bleu) est proportionnel au moment d’inertie de la roue (en rouge) et à la vitesse de rotation autour de l’axe de rotation (en vert).

Il nous faut donc ajouter ces forces dans la simulations, ce qui donne la nouvelle version suivante.

On remarque que les mouvements semblent plus chaotiques que sans l’effet gyroscopique (on peut le désactiver dans les paramètres de simulation).

Pour l’instant, nous nous sommes contenté de dire qu’on “faisait tourner la roue” et que la boule tournerait dans le sens opposé.

La façon la plus simple de faire ça est évidement avec un moteur électrique DC (à courant continu). Je vous invite à lire cet excellent article sur les moteurs (et leur contrôle via arduino).  

Je retiendrais 3 points qui me sont importants ici :

1. Couple et vitesse: Chaque moteur a deux caractéristiques importantes :

 Son couple (la force de rotation)

Sa vitesse maximale (au delà de laquelle le moteur n’exerce pas de couple) 

2. Les réducteurs : Si vous avez déjà démonté quoi que ce soit doté d’un moteur, vous avez très probablement vu des engrenages entre l’axe du moteur et la pièce qui peut bouger : ce sont des réducteurs. Ces engrenages permettent de décupler le couple (la force) exercé par le moteur, en contrepartie d’une diminution de la vitesse.

3. Le frein magnétique : Lorsqu’une tension apparaît aux bornes d’un moteur, il se met à tourner. Mais comme souvent en physique, l’inverse est aussi vrai : si on fait tourner un moteur, une tension apparaît aux bornes du moteur, d’où on peut en tirer un courant et donc de l’énergie (c’est le principe d’un générateur électrique). Si maintenant on court-circuite le moteur :

Alors il ne peut y avoir de tension, donc le moteur s’arrête ! Un court-circuit stopperait net la rotation, mais entraînerait un très fort courant dans le fil qui fondrait en quelques millisecondes ! Pour éviter cela, en pratique on place une résistance en haut du cercle rouge. Plus la résistance est petite, plus le frein est fort, mais plus l’énergie dissipée sous forme de chaleur est importante.

En conclusion :

Pour un prototype, il va falloir choisir des moteurs assez puissants (mais pas trop car plus c’est puissant plus c’est cher !), des réducteurs adaptés à nos moteurs et nos besoins.

Grâce au frein magnétique, on va pouvoir accélérer et freiner sans avoir besoin de quoi que ce soit d’autre !

Maintenant qu’on a ce qu’il faut pour décrie notre BB8, on a tout ce qu’il faut pour le simuler !

C’est à dire simuler o.O ?

Et bien il nous suffit de décrire numériquement chaque objet (boule et roues), ses masses, positions, vitesses, les interactions, calculer les vitesses et positions aux instants suivants et recommencer pour avoir une idée de ce qu’il se passe à chaque instant.

Pour cela, tous les langages informatiques sont bons mais j’ai opté pour Javascript pour sa rapidité à coder (en une journée ce fût fini !), sa portabilité (vous allez pouvoir tester ça en suivant le lien plus bas !) et surtout pour excellente libraire three.js pour avoir de beaux rendus 3D !) 

Le code procède en plusieurs étapes :

Initialisation des paramètres physiques (masses, longueurs, couples, moment d’inertie, frottements)

Initialisation des positions et des vitesses de rotation des objets à 0

Boucle qui calcule les nouvelles positions/vitesse à l’instant suivant

Bilan des forces

Moteurs

Freins

Frottements

Calcul du moment d’inertie effectif

Application de Newton : nouvelles vitesses/positions

Affichage en temps réel de la simulation via three.js (à une fréquence plus petite)

Avant de vous laissez enfin jouer avec le simulateur, je tiens à revenir sur un dernier point que j’avais laissé en suspens la dernière fois : l’effet toupie.

La loi la plus importante de la mécanique classique peut être exprimée ainsi :

La variation du moment cinétique d’un objet est égale à la somme du moment des forces extérieures (les couples).

Ce qui veut dire : “Quand on fait tourner l’objet, il tourne” ! (Mais de manière quantitative donc c’est mieux !) 

La conséquence sur notre BB8 est la suivante : lorsqu’un roue tourne rapidement, si on pivote la boule de quelques degrés, on déplace le moment cinétique de la roue, on crée alors une variation de moment cinétique de la roue. 

[Les flèches en noir représentent les moments cinétiques avant et après, la flèche orange différence de moment cinétique]

En conséquence, pour déplacer de quelques degrés, on a donc dû exercer une force plus importante que si la roue avait été à l’arrêt.

La simulation proposée ici prend ce phénomène en compte en calculant un moment d’inertie effectif de la boule, mais je ne suis pas à 100% sûr de la validité de cette modélisation. (J’en reparlerai probablement).

[Edit: En effet l’effet gyroscopique est mal pris en compte, voir le billet suivant : “Moteur physique et effet gyroscopique” ]

Vous pouvez accéder ici au simulateur.

Le moteur X est contrôlé par les touche E, D,C. ( + , frein , - )

Le moteur Y est contrôlé par les touche R, F,V. ( + , frein , - )

Le moteur Z est contrôlé par les touche T,G,B. ( + , frein , - )

Pour une meilleure visibilité, un bout de chaque roue est coupé : c’est juste je l’affichage !

J’espère qu’avec ça vous avez bien compris comment ça marche :)

Si vous avez pas mal joué avec les configurations et les situations, vous avez vu que les déplacements ne sont pas si simples. En effet pour pouvoir contrôler la boule de manière intelligente, il faut accélérer ou ralentir les roues à des moments précis.

Sauf que cette symétrie a un coût et pas des moindres ! En effet nous l’avions dit, le principal facteur limitant de propulsion et le moment d’inertie de la boule (cf Wikipedia). Pour faire simple le moment d’inertie d’un objet autour d’un axe correspond à la “difficulté” pour le faire tourner autour de cet axe.

Pour calculer le moment d’inertie autour d’un axe de rotation, on somme chaque masse en multipliant par la distance au carré à l’axe. En pratique, pour que la boule tourne facilement, il faut non seulement qu’elle soit assez légère, mais surtout que les objets massiques qui la compose (à exception de la paire de roue que l’on accélère) soit proche de l’axe central !

Par conséquent, si on regarde le modèle imagé plus haut, si jamais on faisait tourner les deux roues en orange dans un sens, le reste de la boule tournerait dans l’autre sens, mais les 4 autres roues extrêmement massive (et loin de l’axe) ralentiraient le tout.

En résumé :

Soit on choisit de se mouvoir dans toutes les directions à petite vitesse

Soit on diminue 4 roues au minimum ce qui booste la vitesse dans une direction, et on profite du surplus de place pour booster encore la puissance des deux moteurs principaux.

Je vous laisse deviner mon option préférée !

(Indice: La deux)

Ici j’ai fais varier la taille des roues, on aurait très bien pu jouer sur les matériaux et leur masse pour parvenir au même résultat.

Avec ce modèle, il suffira au droïde de s’orienter dans la bonne direction grâce aux petites roues (voir de s’y maintenir) puis il pourra partir à toute allure en avant ou en arrière.

Il nous faut maintenant évoquer un point théorique que l’on a pas encore évoqué : comment avec le modèle des masses tournantes est-ce qu’on se déplace dans une direction quelconque du plan ? 

Avec les “marteaux tournant” ça aurait déjà été un problème pas si évident, mais avec le modèle des “deux roues motrices”, ça revient au problème de tourner autour de l’axe vertical.

La première idée qui m’est venue “naïvement” était qu’il suffisait de faire tourner une roue plus vite que l’autre. Cette idée est en fait fausse mais m’a conduit à une autre idée, donc j’en reparlerai plus loin dans ce billet.

Une solution possible repose sur la même technique que les roues motrices à un détail près. Le cas est simple si on traite le problème à l’arrêt :

A l’arrêt, il suffit de faire tourner les petites roues du haut et du bas dans un sens pour que la boule pivote dans l’autre sens.

Ici je représente le sens de rotation par un cône similaire au vecteur rotation (vers le haut pour une rotation direct = antihoraire)

Pourquoi on s’embête avec ça ? Pour ne pas tout foirer dès que ça devient compliqué ! 

En effet que se passe t-il si on essaie de tourner en accélérant doucement pendant qu’on avance à vitesse constante ? Et bien au bout d’un demi-tour, on va se retrouver à tourner dans l’autre sens :

D’ailleurs, à y regarder de plus près, dès qu’on n’est pas exactement en haut, on se met aussi à tourner autour de l’axe vert (par exemple à un quart de tour, on tourne uniquement autour de l’axe vert).

Ce qu’on voit là est en fait un symptôme d’un problème plus grand : notre système n’a pas forcément tendance à rester droit. Et si les roues principales ne sont pas à la verticale, l’accélérer risque de provoquer un grand bazar ! Cela dit, la solution apparaît aussi clairement : 

Il suffit de donner un petit coup d’accélération sur chaque paire de roue au bon moment pour conserver la position voulue, ou pour tourner.

Sachant qu’au demi-tour suivant, pour tourner la boule dans le même sens on donnera un coup d’accélération dans le sens opposé (au sens dans lequel on l’avait donné précédemment... c’est pas si simple !) Le tout fera que chaque petite roue devrait rester globalement statique (pas de vitesse continue).

On sens bien qu’implémenter tout ce qu’on a évoqué là n’est pas trivial ; cela dit avec des gyroscopes et des accéléromètres pour avoir une idée précise du déplacement du droïde, ce n’est au final pas si compliqué.

“Tout ça est bien joli mais pourquoi on n’a pas fait tourner les roues à différentes vitesses ? Ça aurait été plus simple non ?”

Ça n’aurait surtout eu aucun effet ! Ce n’est pas si simple à intuiter alors imaginez la situation suivante : 

Le droïde est à l’arrêt. On accélère une roue dans un sens et l’autre roue dans le sens opposé. La roue numéro 1 va avoir tendance à faire tourner la boule autour l’axe (Ox) dans le sens positif. La roue 2 va pousser la boule à tourner autour de ce même axe (Ox) dans le sens négatif et avec la même amplitude.

Conséquence:  la boule ne bougera pas du tout. Il en va de même pour les situations ou une route tourne plus vite que l’autre : on peut réussir à faire “avancer” la boule, mais pas à tourner autour d’un autre axe que (Ox).

Pour comprendre cela plus en détail, il faut faire un peu de mécanique du solide. Pour ceux à qui la “relation antisymétrique” ou  “règle de transport des moments” parlent, sachez que le résultat suivant vient de là :

Peu importe où se situe la roue tournante sur son axe, les effets seront les mêmes.

Ici, si on néglige le poids qui perturberait la situation, les trois situations sont strictement équivalentes !

Quel intérêt ? Et bien j’étais parti sur l’idée de six roues motrices car mon intuition me disait que ça suffirait à produire tous les mouvements possibles, sans perturbation et le tout sans avoir des roues qui se croisent.

De ce résultat on en déduit qu’il est en fait possible de faire la même chose avec seulement trois roues motrices : une principale et deux petites. De plus, nous n’avons pas besoin de les centrer (sinon elles se gêneraient), il suffit juste de faire une seconde roue statique symétrique pour éviter que le poids ne perturbe pas la boule.

En orange : les roues motrices, en noir les roues statiques pour “symétriser” la répartition des masses.

Les avantages sont notables : moins de moteurs donc moins d’électronique et plus de place.

Cependant, un inconvenant à prendre en compte est qu’en faisant ainsi le moment d’inertie de la boule augmente. (Et même de façon importante si la masse des roues est grande devant la masse de reste de la boule)

Deux pistes sont à creuser :

Soit transmettre la rotation d’un seul moteur aux deux roues. (Via un enchevêtrement d’engrenage pas des plus simples, ou quitte à sacrifier le milieu)

Soit laisser l’autre roue tourner librement en limitant les frottements, ainsi les poids s’équilibreront et la deuxième roue n’ajoutera que peu de moment d’inertie à la boule.

Ceux qui connaissent bien le calcul du moment d’inertie savent à quel point l’espace central (et dans un second plan l’espace proche de l’axe principal) est important : tous les éléments massifs mis ici freinent très peu la rotation de la boule. C’est là qu’on va par exemple mettre les gros moteurs ou des batteries assez lourdes. 

On a donc tout intérêt à garder cet espace disponible pour ces éléments là, et ne pas l’encombrer avec des systèmes de transmission divers.

1. Soit on fait travailler le poids pour déplacer la boule, en effet en déplaçant un marteau de sa position d’équilibre, et en la fixant par exemple à 90°, le moment du poids va faire tourner la boule :

Il suffit alors grâce au moteur et à l’aide d’un gyroscope de maintenir le marteau à l’horizontale pour avoir une vitesse constante dépendant de la masse du marteau.

Ce mode revient en fait au principe classique évoqué dans mon précédent billet sauf qu’on réduit les 3 axes de rotations imbriqués à six fois un axe de rotation, permettant ainsi d’avoir une boule solide avec des zones à notre disposition pour y mettre ce que l’on veut.

Les inconvénients de cette méthode ? Ils sont nombreux:

Pour avoir une accélération correcte, il faut des masses importantes.

Pour contrôler des masses importantes, il faut des moteurs avec de forts couples

Pour gérer la position des masses, il faut des moteurs pas à pas, dont la vitesse de rotation doit pouvoir être importantes car les marteaux doivent tourner aussi vite que la boule.

En plus des moteurs puissants et donc onéreux, il faut pouvoir gérer toutes les marteaux pour que leurs positions ne parasite pas le mouvement de rotation.

2. La méthode deux repose sur la conservation du moment cinétique : on peut aussi le voir comme une conséquence de le troisième loi de newton : "Tout corps A exerçant une force sur un corps B subit une force d'intensité égale, de même direction mais de sens opposé, exercée par le corps B.”

Si on applique un couple (ie. on fait tourner) sur l’axe de la masse, on applique aussi un couple opposé sur le moteur qui voudrait lui tourner dans le sens opposé.

 On peut donc accélérer la boule en accélérant les deux marteaux symétriques :

Avec cette méthode, on peut accélérer la boule dans la direction de notre choix, avec une certaine puissance, et ainsi contrôler sa vitesse de rotation ; le facteur limitant étant le moment d’inertie de la boule.

Une question que je me pose toujours, même avec les futurs designs est la suivante : si on maintenait la boule en place (sans rotation) et qu’on accélérait à fond deux marteaux, puis au bout de quelques secondes on lâchait la boule, resterait-elle en place puisqu’il n’y a plus d’accélération, ou se mettrait-elle à tourner dans le sens opposé ? 

Cette question est importante car elle revient à se demander si la boule pourrait rouler longtemps dans une même direction malgré les frottements avec le sol qui la ralentirait. On va pour l’instant supposer que la réponse est favorable à ce que l’on veut faire, et donc que ce mode de propulsion est viable ! (J’en reparlerai quand j’aurai trouvé la solution)

[Edit: La réponse est que la boule ne bougerai pas, ce qui nous gênera mais ne rendra pas ce mode de déplacement impossible]

On pourrait imaginer une machine hybride utilisant les deux méthodes pour se propulser à grande vitesse ou se positionner de manière précise, cependant la gestion des marteaux asymétriques et les moteurs pas à pas puissants nécessaires me semble une difficulté majeure à la réalisation d’un prototype. 

La méthode 1 ayant les défauts que j’ai déjà évoqués, je serrait tenté de partir sur un système complètement basé sur la méthode 2.

Le principal problème à ça est la gestion de la position des marteaux, cependant avec un peu d’astuce on peut se débarrasser complètement de ce problème ! En effet, avec la méthode 2, seul le moment d’inertie de marteau nous intéresse, on peut donc soit le symétriser (deux marteaux symétriques par rapport à l’axe de rotation), soit carrément répartir la masse sur un cercle comme une roue de vélo massique.

Ainsi, la gestion des positions devient inutile et l’invariance par rotation des roues (si on tourne la roue de x dégrés, la répartition des masses reste inchangée) permet de rendre “indépendantes” les trois paires de roues.

Alors comment récupère-t-on un BB8 de nos jours ? Et bien c’est plus simple qu’il n’y parait ! Sachez premièrement que pour le tournage, les studios Disney ont fabriqué un véritable prototype (en partenariat avec la start-up Orbotix), donc le principe n’est pas irréalisable.  D’ailleurs, si vous aimez la simplicité et les jouets pour enfants, Sphereo propose un véritable BB8 miniature télécommandé pour une somme plutôt raisonnable.

“Et si moi j’en veux un taille réelle ?”

Eh bien, c’est possible, beaucoup de projets ont fleuri sur le net ces derniers jours. En effet, l’idée de départ n’est pas si compliquée :

Cette image est tirée de excellent site www.howbb8works.com, n’hésitez pas à aller y faire un tour, ils ont même une animation 3D de ce modèle !

“Bon et bien c’est réglé alors ! Tu ne pouvais pas me filer ce lien plus tôt !?”

Eh bien non, globalement tous les modèles existants sur le net (que j’ai pu trouver) sont basés sur le principe suivant :

“Oui et bien ? Elle est très bien cette façon de faire non ?”

Elle a le mérite d’être efficace et assez directe. Mais elle a un gros désavantage : sa boule extérieure.

Je m’explique, un des premiers obstacles quand on veut réaliser un prototype comme celui la chez soi est de trouver une boule de bonne taille, assez solide pour résister aux chocs, pas trop lourde et lisse à extérieure comme à l’intérieur !

Vous pensez peut-être que ce n’est qu’un problème de trouver le bon fabriquant, mais la faiblesse du modèle est là. La paroi extérieure sera toujours le maillon le plus faible du système, et il n’est pas vraiment possible de le renforcer par une structure interne vu que tout doit coulisser sans frottement ! 

De plus, si vous voulez pousser le réalisme encore plus loin, par exemple en intégrant un compartiment interne, une caméra (dans la boule), un pico-projecteur ou un lanceur de fléchettes, et bien tout ça risque d’être impossible !

Quelle solution alors ?