Comme déjà évoqué précédemment je me suis mis à l'électronique amateur depuis quelques temps, et j'en arrive aujourd'hui au point où j'ai assez de matière pour écrire un nouveau petit billet. Dans ce billet je vais donc tenter d'expliquer clairement les problèmes qui se sont posés lorsque j'ai tenté de controller des moteurs avec mon micro-controlleur, et surtout la solution que j'ai trouvé ! Vous allez voir c'est amusant :)

La problématique

Tout est parti de l'envie de controller des moteurs à partir de mon arduino. Pour être plus précis je voulais controller des moteurs assez puissants pour pouvoir mouvoir un robot autonome embarquant donc l'arduino, des batteries, et tout un tas d'électronique et de mécanique utile ou inutile.

Concernant les moteurs le choix s'est immédiatement porté sur des moteurs à courant continu. J'aurai pu viser des servo-moteurs à rotation continue ou des moteurs pas à pas qui sont beaucoup plus simples à commander, mais ces solutions sont beaucoup plus honéreuses et ont donc vite été oubliées étant donné que le but est de jouer à moindre cout. Un moteur à courant continu c'est tout bête : on applique une tension entre les deux bornes du moteur et celui-ci se met à tourner à une vitesse proportionnelle à la tension appliquée¹. Petite subtilité : si vous fournissez une tension variable périodiquement (sinusoïdale, carrée, triangle, ou n'importe quoi d'autre) de fréquence "suffisante" le moteur ne prendra en compte que la moyenne de votre signal et tournera donc de façon régulière comme si vous lui aviez appliquée une tension continue équivalent à la moyenne de votre signal périodique².

Pour controller la vitesse de rotation d'un moteur à courant continu on a donc une solution ultra classique qui consiste à lui appliquer une tension périodique en forme de créneau de valeur maximale fixe. En faisant varier la proportion de temps où le créneau est haut par rapport à la proportion de temps où le créneau est bas on fait très simplement varier la moyenne de la tension appliquée, et donc la vitesse de rotation du moteur. Ce système est connu sous le nom "modulation de largeur d'impulsion" l'équivalent anglais c'est "Pulse Width Modulation" qui lui donne son patronyme le plus connu (même pour les francophone) : PWM ! Ca tombe bien : pleins de micro-controlleurs sont capables de sortir des PWM, et en particulier l'arduino sait faire ça très bien et très simplement grace à la commande analogWrite(PIN, valeur). Si on résume voilà la tête de deux signaux exemples, l'un avec une PWM qui a un voltage moyen de 2,5V (50% du temps à 5V, 50% du temps à 0V) et l'autre qui a un voltage moyen de 1V (20% de 5V, 80% du temps à 0V)³ :

Si on résume : je n'ai qu'à brancher une borne de mon moteur à la masse et l'autre borne à une broche de mon arduino sur laquelle j'utilise la commande analogWrite. Ainsi mon arduino va générer un signal PWM sur cette broche, signal que le moteur va comprendre comme un ordre de tourner à une vitesse correspondant à la moyenne de ma PWM, donc juste en jouant sur le second paramètre de analogWrite(PIN, vitesse) entre 0 et 255 je fait varier la vitesse de rotation de mon moteur de 0% à 100% de ses possibilités. Ca a l'air trop simple pour être vrai, mais en fait ça marche :) ! Par contre ce système a 2 gros problèmes, que nous allons voir les uns après les autres.

Sans puissance, la maitrise n'est rien

Lorsque je vous ai dit qu'un moteur à courant continu c'était simple et qu'il suffisait d'appliquer une tension à ses bornes pour qu'il tourne j'ai bien pris soin de préciser que ça ne marchait que si on lui fournissait une intensité de courant suffisante. C'est là que la premier problème se pose : un micro-controlleur (comme ceux qui sont au coeur des arduino) ce n'est pas prévu pour fournir une forte intensité de courant, et généralement ça n'en fournit pas assez pour faire tourner un moteur. A titre informatif l'arduino UNO peut sortir jusqu'à 40mA par PIN, ce qui est pile le courant consommé par un de mes mini-moteurs quand ils n'a aucune charge à entrainer (c'est donc, grossièrement, un dixième du courant maximal que ce même moteur est susceptible de demander s'il est chargé à son maximum). Sachant que mes mini-moteurs sont environ 3 fois plus petits qu'une pile AA j'espère que vous réalisez maintenant à quel point 40mA est une intensité liliputienne dans notre contexte :-) Le premier problème qui se pose à nous est donc : comment vais-je augmenter l'intensité du courant envoyé à mes moteurs :( ?

La réponse la plus triviale qui peut venir c'est : utiliser un transistor :) Pour ceux qui ne savent pas du tout comment marche un transistor sachez que, en très résumé, c'est un composant qui posssède trois pattes appelée "Base", "Collecteur", et "Emetteur".⁴ Dans le mode de fonctionnement qui nous intéresse voilà comment se comporte le transistor :

• Quand on envoie un courant, même de faible intensité, sur la base du transistor celui-ci "ouvre une vanne" entre son collecteur et son emeteur ce qui permet de faire passer de l'une de ces pattes à l'autre environ 100 fois le courant que l'on a envoyé sur la base.
• Quand on ne fournit pas de courant sur la base du transistor alors celui-ci se comporte comme un interrupteur ouvert entre le collecteur et l'emetteur.

Une fois ce mécanisme bien compris il devient naturel d'envisager l'utilisation d'un transistor pour controller nos moteurs : on branche le signal PWM du micro-controlleur sur l'entrée "Base" du transistor et on se sert du courant 100 fois plus important circulant entre le collecteur et l'emetteur pour alimenter le moteur. Aussitôt dit aussitôt fait :

Le transistor que j'utilise est un 2N1711. Ce transistor a pour principale qualité de correspondre à mes besoins puisqu'en lui fournissant environ 5mA sur sa base il permet de faire circuler jusqu'à 500mA entre son collecteur et son émetteur. La seconde grande qualité de ce transistor c'est que je l'ai trouvé à pas trop cher dans une boutique d'électronique à Nation ^_^ ! Quoiqu'il en soit le montage fonctionne, et le moteur tourne ! ... Mais fournir une intensité suffisante n'est pas le seul problème que l'on doit traiter.

Quand je m'avance toi tu recules, comment veux-tu que je ...?

Jusqu'à présent le branchement de notre moteur est plutôt simple : on branche une borne à la masse, et on envoie la commande PWM (amplifiée ou non en puissance) sur l'autre borne. Ce cablage "fixe" est simple à comprendre mais il ne permet de faire tourner le moteur que dans un seul sens :-/ En effet pour le faire tourner dans l'autre sens il faudrait pouvoir inverser le cablage en live, ce qui n'est pas vraiment réaliste. Sachant qu'à terme on aimerait bien faire rouler un robot, et donc disposer d'une marche arrière, il faut se résigner à abandonner ce branchement (et nos transistors) afin de se pencher sur un montage un poil plus complexe.

La solution à ce petit problème a, heureusement, été donnée il y a longtemps : le pont en H ! Pour résumer ce qu'est le pont en H : c'est un montage qui permet d'inverser le sens de branchement d'un dipole à la volée, sans toucher aux branchements physiques. Bonne nouvelle : ce montage étant ultra-classique on trouve des dizaines et des dizaines de circuits intégrés implémentant des pont en H ! Seconde bonne nouvelle : ils font quasiment tous l'amplification d'intensité par la même occasion. Pour ma part j'ai acheté un L293D (parce que, comme pour les 2N7111, je les ai trouvé pas cher et qu'ils répondent à mes besoins) mais d'autres références existent comme par exemple les SN754410 ou les L298⁵.

Une fois notre pont en H à disposition le montage est simple. Tout d'abord les branchements essentiels pour que le circuit intégré puisse fonctionner :

• Une PIN à la masse (sans commentaire).
• Une PIN au voltage de référence correspondant au niveau "haut" logique (dans notre cas 5V car les signaux PWM générées par l'arduino sont entre 0 et 5V)
• Une PIN à l'alimentation de puissance des moteurs (dans mon cas une batterie de 7.2V, mais on peut remplacer par n'importe quoi fournissant de la puissance avec un voltage compris entre 5V et 36V). Les branchements de base effectués il suffit de relier "Input 1" et "Input 2" à deux bornes de l'arduino capables de générer des PWM, et "Output 1/Output 2" aux bornes du moteur. Pour faire tourner le moteur dans un sens il suffit par exemple d'envoyer une PWM sur "Input 1" et un signal nul sur l'autre; puis pour inverser le sens de rotation du moteur (sans toucher au cablage :D !) il suffit d'envoyer "0V" sur "Input 1" et une PWM sur "Input 2" ! Simple, non ^_^ ?

What else ?

Une fois que l'on est capables de faire tourner nos moteurs dans les 2 sens à une vitesse variable arbitraire on a déjà fait un grand pas vers la réalisation d'un robot mobile autonome, mais les pistes d'améliorations sont plus que nombreuses et feront peut-être l'objet d'articles ultérieurs. Pour vous donner quelques idées voici deux améliorations que j'ai déjà apporté à mon robot :) :

• Dans l'article on utilise 2 signaux PWM pour controller un seul moteur mais ça serait mieux d'utiliser un unique signal PWM et un bit de sens en tout ou rien (l'arduino, comme tout les micro-controlleurs, n'étant capable de générer des PWM que sur un nombre réduit de ses sorties il est toujours bon d'économiser ces sorties là). Pour information ce petit tour de passe-passe peut être réalisé en utilisant, par exemple, un circuit intégré de la famille des 74XX pour faire de l'algèbre de bool sur nos signaux. En particulier le 7404 peut s'avérer utile (et suffisant :)) pour résoudre notre problème. Je vous laisse trouver la solution exacte ;-)
• Il n'y a pas d'isolation sérieuse entre nos moteurs et notre arduino. Donc si nos moteurs se mettent à générer de l'électricité pour une raison ou pour une autre (oui, ça peut arriver) toute la puissance électrique générée risque de remonter jusqu'à notre arduino et peut potentiellement le griller :-/ Pour contrer ce risque on peut utiliser des "optocoupleurs"⁶. Ces petits circuits intégrés ont pour unique fonction d'apporter justement une isolation entre commande et puissance. En très résumé vous leur donnez à manger un signal logique en entrée et il vous le recopie sur sa sortie en vous garantissant qu'aucun reflux de puissance ne pourra remonter sur le signal logique :) Pour les plus intéressés d'entre vous sachez que la magie s'opère généralement grace à une LED et un photo-transistor, et voilà quelques références si vous en cherchez : 4N35, PC845, etc.

1. pourvu que l'intensité du courant fournie soit suffisante ↩
2. La "magie" derrière tout ça c'est qu'un moteur à courant continu, de par sa construction même, peut être modélisé comme un circuit RLC qui s'avère être un filtre fréquentiel passe-bas :) ↩
3. La première PWM s'obtient avec analogWrite(PIN,125) et la seconde avec analogWrite(PIN,51) ↩
4. Je commence par parler des bipolaire car ils sont simples :) ↩
5. Les L298 proposent d'ailleurs nettement plus de puissance que les L293D, intéressez-vous à ceux là si vous voulez avoir des moteurs capables de bouger rapidement un robot digne de ce nom. ↩
6. un autre mot clef de la même famille c'est photocoupleurs ↩

Monsieur Soleil peut tout faire. Retour de l'être aimé, prédiction des résultats du loto, choix infaillible de la couleur de la cravatte, conjuration des problèmes d'impuissance, etc... Bon plus sérieusement je ne vais pas parler de ce type de guérisseur là, rassurez-vous. Je vais vous parler de Jason, figure de la mythologie grecque connu sous le surnom "le guérisseur"...bon non plus, ça c'était juste pour le jeu de mot (bien pourri). En fait je vais vous parler de JSON et, plus précisément, des JSON-RPC que j'ai eu la surprise de découvrir accessibles sur mon serveur...

Pour poser le cadre donc : j'ai un serveur multimédia (allumé H24¹, comme tout bon serveur qui se respecte) et l'autre jour alors que je faisais le petit nmap routinier de mon réseau local apparait une nouveauté sur ce serveur :

PORT     STATE SERVICE     VERSION
9090/tcp open  zeus-admin?

Autant vous dire que, sur le moment, j'ai un peu fait la gueule :-D Après enquête rapide il s'avère que c'est en fait le XBMC qui tourne sur mon serveur qui expose là l'une de ses nouvelles interfaces de commande... Dans les anciennes versions, XBMC exposait uniquement (pour autant que je sache) une interface de commande HTTP accessible après authentification et qui permettait ainsi de controller les lectures multimédia via le réseau (super pratique pour transformer votre téléphone android en télécommande wifi). Dans les dernières version l'interface HTTP est deprecated, et c'est l'interface JSON-RPC qui devrait la remplacer.

Pour ceux qui l'ignorent (comme moi il y a quelques semaines), le JSON-RPC c'est une méthode de RPC qui utilise la syntaxe JSON (on ne s'en douterai pas hein ?). Et pour la conclure l'explication : le JSON c'est une méthode de formatage de données dont l'esprit est de se rapprocher de la syntaxe....javascript. Je ne plaisante pas, JSON c'est même l'acronyme de "JavaScript Object Notation" si vous voulez tout savoir. Du coup une requête JSON-RPC ça ressemble à ça :

{"jsonrpc": "2.0", "method": "subtract", "params": {42, 23}, "id": 1}

Bon...c'est pas très joli mais ça reste compréhensible :) Du coup je me suis dit "voyons ce que l'on peut faire avec ça", mais avant d'exposer les résultats je dois faire un disclaimer : "j'ai peut-être été trop permissif dans ma configuration d'xbmc (même si j'en doute), donc ne blamons pas trop les réglages qu'on peut/doit faire pour utiliser une télécommande, c'est peut être ma faute". Maintenant répondons à "que peut on faire avec ça ?" :

Première chose : survoler la liste des procédures accessibles. La première qui a une tête sympa c'est "JSONRPC.Ping". Aussitôt identifiée aussitôt testée :

echo '{"jsonrpc": "2.0", "method": "JSONRPC.Ping", "id":"5"}' | nc serveurmultimedia 9090

Et réponse immédiate :

{
   "id" : "5",
   "jsonrpc" : "2.0",
   "result" : "pong"
}

Cool ça marche :-D !!!...Pas cool : j'ai pas eu besoin de m'identifier :-/

La paranoïa aidant la seconde procédure que je teste c'est "Files.GetDirectory"...forcément.

echo '{"jsonrpc": "2.0", "method": "Files.GetDirectory", "id":"peur", "params":{"directory":"/"}}' | nc serveurmultimedia 9090

Ah bah....ça marche :

{
   "id" : "peur",
   "jsonrpc" : "2.0",
   "result" : {
      "directories" : [
         {
            "fanart" : "special://masterprofile/Thumbnails/Video/Fanart/cfb24076.tbn",
            "file" : "/var/",
            "label" : "var"
         },
         {
            "fanart" : "special://masterprofile/Thumbnails/Video/Fanart/b1fe6366.tbn",
            "file" : "/usr/",
            "label" : "usr"
         },
         {
            "fanart" : "special://masterprofile/Thumbnails/Video/Fanart/dafd2084.tbn",
            "file" : "/tmp/",
...ETC...

Et vous savez le mieux ? Y'a une procédure Files.Download :-D !...Après l'avoir testé dans tout les sens il semblerait qu'en fait cette procédure ne soit, pour l'instant, pas implémentée (ouf !) et que de toute façon elle ne permette de télécharger que des ressources générées par XBMC (vignettes, etc.). M'enfin déjà le simple Files.GetDirectory c'est pas très joli²...Du coup une seule chose à dire : faites attentions aux permissions que vous mettez sur votre XBMC si vous voulez utiliser une télécommande réseau, il se peut que vous ouvriez des portes à n'importe qui ayant accès au port TCP.

Ceci étant dit, on va considérer que ça cloture la partie "sécu" de ce billet, et on va voir si on peut jouer avec ça sans vilaines pensées, par exemple essayons de faire les requêtes en python :

>>> import json, socket, random
>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100)), 'method':'JSONRPC.Ping'}
>>> s =  socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(("serveurmultimedia",9090))
>>> s.send(json.dumps(req))
>>> reponse = s.recv(1024)
>>> print reponse
{
   "id" : "82",
   "jsonrpc" : "2.0",
   "result" : "pong"
}

Intéressant...Du coup si jamais un script python sur android qui est en train d'exécuter time.sleep() ne consomme pas de CPU (donc de batterie) je pourrai m'écrire un script, utilisable sur mon téléphone, qui me réveille à l'heure de mon choix en jouant le média de mon choix sur mon serveur !!! Intéressant non ?

Pour que ça soit intéressant j'ai envie de lire un mp3 aléatoire. La logique de XBMC étant ce qu'elle est³ je dois d'abord récupérer les "sources" de music :

>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "Files.GetSources"
>>> req['params'] = {'media':'Music'}
>>> s.send(json.dumps(req))
>>> reponse = s.recv(10*1024)
>>> shares = json.loads(reponse)['result']['shares']
>>> for s in shares:
>>>    print s['file']
/mnt/raid0/musiquelegalementachetee/
...

Une fois les sources récupérées (et surtout les répertoires associées, dans l'attribu bien nommé "file"...) on peut utiliser Files.GetDirectory dont on parlait plus haut afin de récupérer l'ensemble des morceaux directement à la racine de notre source (j'ai la flemme de coder le récursif pour l'instant) :

>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "Files.GetDirectory"
>>> req['params'] = {'directory':shares[0]['file']}
>>> s.send(json.dumps(req))
>>> reponse = s.recv(100*1024)
>>> musics = json.loads(reponse)
>>> random.shuffle(musics['result']['files'])
>>> musique = musics['result']['files'][0]["file"]
>>> print musique
/mnt/raid0/musiquelegalementachetee/rickroll.mp3

Maintenant j'aurai adoré utilisé AudioPlaylist.Insert pour insérer la chanson à l'endroit de mon choix dans la playlist courante puis en lancer la lecture, sauf que quand je fais appel à AudioPlaylist.Insert j'ai une réponse Method not found....On va donc supposer que ce n'est pas encore implémenté :-( Résultat il ne me reste plus qu'à me rabattre sur AudioPlaylist.Add puis prier le guérisseur pour que lors de l'appel à AudioPlaylist.Play ce soit le bon morceau qui soit joué...Je l'ai donc fait :

>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "AudioPlaylist.Add"
>>> req['params'] = {"item": {"file":musique}}
>>> s.send(json.dumps(req))
>>> reponse = s.recv(1024)
>>> print reponse
{
   "id" : "2",
   "jsonrpc" : "2.0",
   "result" : "OK"
}
>>> req = {'jsonrpc':'2.0', 'id':str(random.randint(0,100))}
>>> req['method'] = "AudioPlaylist.Play"
>>> s.send(json.dumps(req))

Et là ça ne joue pas le bon morceau :-S ... Vérification de la playlist : mon morceau n'a même pas été ajouté en fait... Heureusement la communauté des dev de XBMC est plutôt très active et j'ai rapidement trouvé le problème :

The current playlist implementation/representation in json rpc has many (design) flaws and there are lots of unsupported things and it will hopefully be completely rewritten for the next release (if there's enough time). Until then it might be the safest approach not to use the Playlist methods (except SkipPrevious, SkipNext, GetItems, Clear, Shuffle and UnShuffle which should work as expected).

We're sorry for the inconvenience and hope to provide a much better solution in the next version

Donc voilà : actuellement il est impossible de faire ce que je voulais :-( ..Snif. La suite peut-être à un prochain numéro :) !

1. Que les amis de la planète se rassurent : c'est une machine à base d'atom qui consomme moins en H24 qu'une seule heure de jeu sur les dernières cartes graphiques à la mode ↩
2. Même si, comme moi, vous faites tourner votre XBMC avec des droits minimalistes ↩
3. et comme je n'utilise pas les fonctionnalitées "library" d'XBMC ↩

Après avoir passé des mois à faire de la sécurité informatique à haute dose on peut avoir envie de se changer un petit peu les idées (mais vraiment juste un peu). Ce genre de moment est l'occasion révée pour ressortir des vieux projets des placards ! Pour ma part j'ai ressorti 3~4 vieux projets et en moins de 2h ils ont tous, sauf un, dérivé vers la sécurité informatique (on ne se refait pas ^^ !). Histoire de jeter malgré tout une petite pierre hors de la thématique usuelle de ce blog je vais donc vous parler du dernier de ces projets (ça reste du Hack, ne vous inquiétez pas ;) )

Il y a fort fort longtemps dans une contrée pas si éloignée que ça j'ai participé deux années de suite à la coupe de France de robotique. Nos deux participations furent des fiascos mais tant pis, on s'était quand même bien amusé ! Mes responsabilités dans l'équipe se cantonnaient au domaine informatique¹ et il faut bien avouer que c'était pour le mieux car j'étais une quiche en électronique (surtout en comparaison avec les brutes qu'on avait de ce coté là !). Le temps a passé et j'ai toujours considéré que connaitre un peu d'électronique m'ouvrirait pleins de nouveaux horizons d'amusements... Il y a quelques mois de celà j'ai donc craqué et j'ai investi lourdement (au moins...pfiou....facilement...oula....25£ au bas mot :D !) dans un arduino !!! J'ai également ratissé ebay, dealextreme, et oomlout pour obtenir une plaque de prototypage, des cables, des résistances de toutes les valeurs possibles, quelques diodes, et un capteur de distance infra-rouge ².

Une fois tout ce petit matériel reçu j'ai enfin pu m'amuser à faire clignoter mes LED, à changer les patterns de clignotements en fonction de la distance retournée par le capteur, etc. Puis mon jouet est tombé dans l'oubli, submergé par un ras de marré de sécu informatique. La semaine dernière l'envie de ressorti mon arduino s'est fait sentir et en particulier celle de lui faire commander des moteurs ! Pour le signal de commande aucun problème, l'arduino possède une commande toute faite pour envoyer une PWM sur un port de son choix. Reste donc à acheter des moteurs adéquats, et à trouver une façon de leur envoyer de la puissance.

Pour faire simple j'ai d'abord acheté deux micro moteurs 6V consommant 40mA. C'est extrèmement faible, mais c'est pour une bonne raison : l'arduino est capable de fournir cette puissance là tout seul, sans électronique de puissance supplémentaire :) En choisissant ces moteurs je m'assure donc de pouvoir jouer un petit peu mais probablement pas de faire un robot capable de se déplacer. En effet l'arduino seul fournira à mes moteurs la modeste puissance de 0,2W³, à titre de comparaison à la coupe de France nos moteurs tournaient autour des 30~40W :-D

Seulement voilà : la livraison de mes moteurs devrait prendre au moins 10 jours :-( ...Du coup je me suis dit qu'en les attendant j'allais réfléchir à une carte de puissance capable d'alimenter de plus gros moteurs (et donc, pourquoi pas, de rendre mon arduino mobile). C'est à ce moment du billet qu'on retombe dans l'informatique (et qu'on compte sur les doigts d'une main le nombre de mes lecteurs qui sont arrivés jusqu'ici lol) : pour confirmer les cartes de puissance que je pourrait imaginer j'ai décidé de les simuler sur ordinateur plutôt que d'envoyer un mail toutes les 10mn pour demander leur avis à mes amis qui sont forts en électroniques. Mais pour simuler un circuit électronique il faut un logiciel de simulation électronique, or il s'avère que ce n'est pas si simple à trouver. C'est donc là que ce billet prend tout son intéret : vous faire part de mon retour d'expérience en la matière et vous éviter de galérer autant que moi si l'envie vous prend de faire mumuse avec un fer à souder virtuel.

Le cahier des charges est simple : il me faut un logiciel gratuit, fonctionnant sous linux, et qui soit capable de simuler tout les petits circuits simples auxquels je pourrai penser. Après quelques recherches sur google j'ai trouvé pas mal de pages faisant des comparatifs des différents logiciels disponibles malheureusement beaucoup des infos présentes sur ces pages étaient vieilles et ne correspondaient plus du tout à la réalité. Du coup j'ai passé plusieurs jours à débrousailler le terrain pour ne finalement conserver que deux logiciels valables : Oregano d'une part, et gEDA d'autre part.

Oregano

J'ai commencé par Oregano parcequ'il a une interface super user-friendly et semble monolythique (donc simple). A l'usage il est effectivement très agréable mais je lui ai très vite trouvé deux inconvénients :

• Impossible de trouver comment faire des mesures de courant. Poser des sondes de tension est enfantin, mais les sondes de courant doivent se cacher quelque part au fin fond d'un menu d'option et je ne les ai pas trouvé...
• régler finement les paramètres de ses composants (en particulier des semi-conducteurs) parait impossible. En pratique c'est possible mais ça n'a rien d'intuitif. En effet, alors que toute l'interface est ultra simpliste, il faut aller éditer l'onglet "model" des propriétés du composant pour y renseigner le model SPICE brute (ce qui est franchement cabalistique et semble contre-nature par rapport au reste de l'interface "clic clic").

Finalement je pourrai l'utiliser...d'autant qu'il permet d'exporter les schéma au format netlist (j'expliquerai ce que c'est un peu plus tard) et que je pourrai donc facilement faire mes mesures de courant. Mais bon...comme je suis passé à gEDA quand je n'arrivais pas à spécifier les caractéristiques d'un pauvre transistor bipolaire, je reste pour l'instant sur gEDA !

gEDA

Alors là c'est du lourd ! gEDA est en fait un conglomérat de plusieurs logiciels spécialisés chacun dans une étape du travail de l'électronique, ce qui lui permet d'être très puissant⁴ mais aussi de faire très peur aux débutants :-D En réalité, après m'être penché un petit peu sur le monstre, les fonctions que je souhaite réaliser se résument dans seulement deux tout petit logiciels qui se maitrisent finalement assez vite.

Tout d'abord il y a gschem qui permet de "dessiner" son schéma électronique. Le maniement est beaucoup moins intuitif que celui d'oregano mais au moins il est homogène : que celà soit pour paramétrer un transistor ou une résistance la démarche est la même (à savoir : vous n'avez qu'à ajouter manuellement à votre objet un paramètre de nom "value" qui contient le code SPICE du composant). Cet outil ne sert qu'à dessiner le schéma par contre, vous ne pourrez pas faire de routage avec, et vous n'avez pas à placer de sondes de tensions/courants/autre sur le schéma comme vous devez le faire avec oregano. Une fois le schéma dessiné vous le sauvegarder au format gschem (format par défaut) et vous passez au logiciel suivant...

...gspiceui ! Le petit logiciel gspiceui (qui ne fait pas parti de la suite gEDA d'ailleurs lol) va vous permettre de simuler votre circuit. D'ailleurs si vous êtes sous gentoo pensez à le compiler avec les flags "waveform" et "schematics"⁵, si vous êtes sous ubuntu n'utilisez pas la version packagée mais allez plutôt télécharger la dernière⁶.

Bref, pour réaliser une simulation avec gspiceui vous devrez importer le schéma réalisé avec gschem (menu File>Import), vous sélectionnez les composants du schéma que vous voulez observer, vous sélectionnez le type de simulation à faire (la simulation temporelle correspond à l'onglet "Transient"), vous choisissez les paramètres temporels de la simulation, les grandeurs que vous voulez observer (courant, tensions, etc.) puis il ne reste plus qu'à créer un fichier de simulation (menu Simulate>Create"), à lancer la simulation (menu Simulate>Run), et à lancer l'appli de visualisation de vos courbes (menu Simulate>Data viewer).

Une fois le "Data Viewer" lancé vous pouvez glisser/déposer les grandeurs que vous voulez observer depuis la fenêtre flotante contenant la liste de toutes les grandeurs disponibles jusqu'à la zone de traçage de courbe et voilà !

Il ne me reste plus qu'à conclure en vous disant qu'aussi bien oregano que gspiceui s'appuient en fait discrètement sur des moteurs de simulation électronique indépendants (le plus connu étant "SPICE", mais gnucap fonctionnant tout aussi bien si ce n'est mieux (c'est d'ailleurs ce dernier que j'utilise)) ; Que ces moteurs de simulation mangent des fichiers au format "netlist" qui sont générées par oregano ou gspiceui⁷ ; Que les deux derniers screenshots (gschem et gspiceui) correspondent justement à un schéma d'alimentation de puissance pour moteur que j'ai moi-même pensé ; Que cet amplificateur de puissance fonctionne ; Qu'il est super simple et tout pourri aussi bien en rendement qu'en fonctionnalités (il ne permet de faire tourner le moteur que dans un seul sens par exemple) ; Mais qu'il fonctionne (oui, j'en suis fier :-p !) ; Et enfin que je vous déconseille de l'utiliser en l'état car sur les screenshots il manque la diode de roue libre.

Allez, on se quite sur la description SPICE d'une diode (pour vous prouver que c'est vraiment cabalistique et que ça ne colle pas du tout avec l'interface bisounours d'oregano) :

MODEL 1N1004 D (IS=0.5UA RS=6 BV=5.20)

1. et un petit peu de mécanique quand ça se résumait à manier l'arme ultime du travail propre : le pistolet à colle ↩
2. le même type que ceux qu'on avait utilisé sur notre robot :) ↩
3. Souvenez-vous : P = UI. Dans mon cas I=40mA et U=5V (et non pas 6V, car l'arduino sort en 5V tout simplement) ↩
4. Vous pouvez tout faire avec gEDA, du design de schémas aux plans de routage en passant par les simulations électriques de tout poil ↩
5. sinon vous ne pourrez pas tracer de courbes, ou vous ne pourrez pas importer les schémas dessinés par gschem ↩
6. la version packagée sous ubuntu souffre d'un bug tout con qui rend le lancement de simulation impossible si vos paramètres de langue utilisent une virgule au lieu d'un point pour les nombres décimaux...ce qui est le cas en Français ↩
7. C'est justement lors de la génération des fichiers netlist que le problème de séparation des décimales rend la version de gspiceui packagée Ubuntu (9.98) inutilisable en environnement français ↩

Dans mon système de notation personnel j'ai obtenu un level up la semaine dernière (voire même plusieurs) ! Tout ces "level up" se sont concentrés en 3 jours, à savoir les 8, 9, et 10 juin 2011 et ça mérite bien un article "pot pourri" avec pleins de remerciement dedans (mais pas de technique, donc si c'est ça que vous aimez : passez tout de suite votre chemin et revenez pour le prochain billet :) )

Premier level-up : J'ai présenté, au SSTIC, un outils de cassage de mot de passe qui, en toute modestie¹, mérite qu'on y jette un oeil si jamais on est amené à casser fréquemment du mot de passe. C'est un outil que j'ai développé pour l'entreprise qui m'emploie actuellement en tant que pentesteur et que nous utilisons déjà allègrement donc vous pouvez vérifier que "je ne vous crapule pas"² : ça fonctionne. Pour les curieux les détails sont ici, là, et probablement bientôt sur le site du SSTIC dans la section Actes.

Second level-up : J'ai rencontré des gens dont j'admire des travaux/réalisations/écrits et qui se sont avérés super sympa. Pour être certain d'en oublier je n'en citerai que deux³ : Sid et Simon Marechal,

Troisième level-up : J'ai rencontré d'autres auteurs de travaux/réalisations/écrits admirables mais que je ne connaissais pas avant le SSTIC⁴ et qui se sont avérés être des personnes très intéressantes et que j'espère revoir l'an prochain (au plus tard :)). Encore une fois pour être certain d'en oublier je n'en cite que deux : Serianox et Nicolas Prigent.

Bref le SSTIC c'était vraiment excellent, mais il faut être rudement rapide pour obtenir des places (tout part en quelques heures) et l'an prochain je n'aurai certainement pas ma place réservée bien au chaud :-/ ... Je comptais conclure ce billet en vous résumant les conférences que j'ai le plus apprécié mais finalement c'est trop difficile tant j'ai aimé de conférences...Allez donc plutôt jeter un oeil chez les gens qui écrivent bien mieux que moi.

Me reste donc à remercier :

• tout ceux qui m'ont permis de travailler sur les Rainbow Tables probabiliste et d'arriver à ces résultats
• tout ceux qui m'ont permis de présenter ça au SSTIC⁵
• tout ceux qui m'ont écouté
• tout ceux qui sont venu me poser des questions après la conf ou juste me dire que c'était bien
• Milin et tout les autres⁶
• Ceux que j'oublie.

1. ou pas ↩
2. Pour citer Stéphane DUVERGER lors de son excellente conférence présentant ramooflax ↩
3. à noter qu'une rumeur voulait que Zythom soit au SSTIC cette année mais après moult débats sur la façon de prononcer "Zythom" et surtout après une enquête discrète lors du social event il m'a été impossible de confirmer/infirmer la rumeur :( ↩
4. on ne saurait tout connaitre ↩
5. ce qui inclus tout ceux qui travaillent pour que le SSTIC ait lieu ↩
6. remerciement privé, ouais je sais c'est mal ↩

Avec l'été qui revient le soleil se fait de plus en plus présent et c'est donc le moment de ressortir...son android ! Bah oui, avec le beau temps on se retrouve plus souvent à glander en plein air et pour geeker il n'y a alors rien de plus pratique/portable qu'un android :)

J'avais déjà expliqué dans un vieux billet comment installer un environnement d'émulation Android¹, et bien cette fois je vais parler de SL4A. SL4A c'est une application qui vous permet d'utiliser des langages de scripts populaires (LUA, ruby, python, etc.) sur votre android. Pour en profiter il suffit d'installer SL4A (soit depuis le market soit en téléchargeant l'APK directement depuis leur site. Pour l'installer sur emulateur ca fera donc adb install ~/droid/sl4a_r4.apk), de le lancer, de choisir "ajouter" dans le menu de l'application, puis de choisir l'interpretteur du langage de votre choix (pour ma part j'ai choisi Python ;) ).

Une fois SL4A installé et les interpretteurs de votre choix téléchargés et installés depuis SL4A vous avez accès à toute une API qui vous permet d'interragir, depuis vos scripts, avec le terminal Android. Vous pouvez par exemple accéder à la liste des contacts enregistrés, lire les capteurs divers et variés, utiliser l'apareil photo, envoyer/lire des sms, etc. Par contre, coder sur son téléphone ça devient vite fatiguant, donc un tout petit peu de préparation est utile pour coder à son aise.

Tout d'abord nous décidons de coder sur émulateur, ça évitera de mettre trop la grouille sur notre téléphone. Ensuite il faut savoir que les scripts que SL4A est capable de lancer sont stockés par défaut dans /mnt/sdcard/sl4a/scripts. Enfin il faut savoir un petit peu se servir de l'outil adb qui est fourni avec le SDK Android (mais vraiment juste "un peu" je vous rassure).

Pour coder à notre aise donc, nous allons commencer par lancer un AVD² (je vous conseille de lui accorder au moins 512Mo de mémoire vive, sinon ça rame vraiment trop !). Ensuite nous choisissons un répertoire sur notre machine hote qui servira de répertoire de développements³. Enfin, on va y coder notre premier petit script python pour android (avec VIM bien entendu) :

import android
droid = android.Android()
droid.makeToast("Bonjour le monde")

Pour info on aurait pu se contenter de print "Bonjour le monde" mais dans ce cas nous n'aurions pas eu d'interfaçage avec l'UI android et donc nous n'aurions pas pu afficher "Bonjour le monde" dans une petite info-bulle stylée en bas de l'écran. Bref, une fois le script écrit il faut le pousser sur l'AVD adb push bonjour.py /mnt/sdcard/sl4a/scripts/bonjour.py, il apparait alors dans le répertoire "scripts" de SL4A et en cliquant dessus ça fait bien apparaitre une mini info-bulle contenant "Bonjour le monde" :)

Maintenant on peut se pencher sur une amélioration de tout ça. Par exemple optimiser le push. Pour cette étape j'ai bêtement fait un Makefile :

all:
    ls *.py | xargs -I 'X' ../tools/adb push X /mnt/sdcard/sl4a/scripts/X
    ls *.py | xargs -I 'X' ../tools/adb shell rm /mnt/sdcard/sl4a/X.log

Grâce à cette "astuce" il me suffit de faire un "make" avant chaque test pour que l'ensemble de mes scripts soient poussés sur l'AVD, et ça ne me change pas trop des habitudes prises en C/CUDA⁴.

Une fois qu'on sait afficher du texte dans une info-bulle on peut se pencher sur toutes les autres fonctions de l'API et laisser courir notre imagination. Pour les besoins de la cause je conclue d'ailleurs ce billet par quelques exemples de scripts inutiles mais drôles (et donc indispensables) qui m'ont servi de tests :

IRC-like :

import android
droid = android.Android()

victime = droid.pickPhone()
droid.smsSend(victime.result , "I slap you with a large trout")

IRC-like++:

import android
droid = android.Android()

armes = ['Truite', 'Chaussette', 'Andouillette']
droid.dialogCreateAlert("Choix des armes")
droid.dialogSetItems(armes)
droid.dialogShow()
response = droid.dialogGetResponse().result['item']
try:
  response = armes[int(response)]
except:
  response = armes[0]

victime = droid.pickPhone()
message =  "Je viens de te baffer avec une "+response
droid.smsSend(victime.result , message)
droid.makeToast("ENVOYE : "+message)

1. si tant est que quelqu'un aurait eu besoin d'explications pour ça... ↩
2. AVD = instance d'android virtuel ↩
3. Répertoire dans lequel vous pourrez faire un petit bzr init && bzr add * && bzr commit si le coeur vous en dit. ↩
4. Pour en savoir plus sur ce que j'ai fais récemment en C/CUDA (et pourquoi j'ai délaissé ce blog pendant des mois) je vous invite à aller suivre le SSTIC puisque j'ai l'immense honneur d'y donner une conférence mercredi prochain :) ! ↩