Professeur de biochimie à l’université de Boston, il est plus connu pour ses oeuvres de science fiction et pour les ouvrages de vulgarisation scientifique qu’il a écrit. Sa série de livres « Fondation » a reçu le prix Hugo de la « Meilleure série de science fiction de tous les temps » alors que les temps n’était alors pas encore terminés (1966).

Asimov fut l’un des auteurs les plus prolifiques de tous les temps. Il a à son actif pas moins de 500 ouvrages, romans, nouvelles, articles scientifiques, manuels et autres publications. Il a marqué la science à tout jamais et fait office de visionnaire dans le domaine de la robotique.

Ses écrits sur les robots et sur les trois lois de la robotique restent une inspiration pour de très nombreux roboticiens et scientifiques et on espère, un jour, bénéficier de ces robots intelligents pourvus de cerveaux positroniques.

Sans lui, la robotique n’existerait probablement pas et notre association non plus.

Et pour toutes ces choses, Isaac Asimov, merci et joyeux anniversaire.

Plancher sur des projets, que ce soit en développment informatique, électronique, vidéo, mécanique, écriture diverse, … ça arrive à tout le monde. Nous finissons tous, chacun à notre manière, par produire des fichiers par nos créations.

Sauvegarder ces fichiers, c’est bien.
Sauvegarder ces fichiers à chaque version (et être capable de revenir en arrière), c’est mieux !
Pouvoir mixer plusieurs versions, c’est encore plus idéal.
Et travailler à plusieurs sans se marcher dessus, c’est carrément du bonheur.

Et bien git permet tout ça.

A la base, git a été créé pour aider au contrôle de version du noyau linux. Aujourd’hui de très nombreux projet l’utilisent comme Gnome, RubyOnRails ou même Android…

Nous verrons des cas d’utilisation qui permettront ensuite de généraliser à de très nombreuses méthodes de développement.

Dans la mesure où la connaissance n’est rien si elle n’est pas partagée, la DTRE se propose de former la relève à certains sujets qui lui tiennent à coeur. Parmi ces sujets, l’utilisation de systèmes de base UNIX dans le cadre robotique.

Cette formation a pour but de comprendre certains modes de pensée à acquérir pour bénéficier de la puissance de ces systèmes en robotique. Nous y verrons un brin d’histoire, quelques conventions, des mécanismes internes, et quelques autres détails nécessaires pour appréhender ce vaste domaine. Ce n’est pas une formation technique et nous ne verrons qu’extrêmement peu de code.

Nous espérons que cette formation aura suffisamment de succès pour en refaire régulièrement.

Il reste bon de préciser que même s’il n’y a besoin d’aucun niveau technique pour suivre cette formation, un minimum de bon sens et d’intérêt restent nécessaires.

Ceux qui sont inscrits au karting auront bien entendu le temps d’être à l’heure au rendez-vous.

Le but ? Construire un robot qui fonctionne, c’est à dire qui suive une ligne.

Leurs armes ? Une (et une seule) boîte de légos mindstorms.

Le premier jour, une présentation de Joseph (ponctuée de légères remarques de Garfield) a pu mettre nos chères ouailles au courant de leur mission : Naviguer sur tout le logo ESIEA rendu linéaire pour l’occasion. Les groupes sont répartis dans les trois labos de physique et d’électronique du deuxième étage. Dès le top départ, diverses stratégies de groupes se mettent en place : certains jouent tout sur la rapidité, d’autres garde la précision plus à coeur.

La compétition s’est, dans l’ensemble plutôt bien déroulé ! Le podium :

3°) Les Go et Lents

2°) The Killers

1°) Les Canards (qui, soit dit en passant on vaincu le record historique de 55 secondes en le passant à 51.72).

Félicitation à eux et à toutes les autres équipe qui se sont bien battus.

Je laisse ici ce billet pour vous montrer la gallerie de cette initiation à la robotique. Merci mille fois au BDA de l’ESIEA pour avoir pris ces photos

Ce guide est vraiment bien fait : des exemples clairs, des passages de bandes dessinés (et beaucoup d’images), des histoires délirantes qui permettent de comprendre en détail comment fonctionne Ruby !

N’ayant fait que du C auparavant et sachant que c’est le cas de certains d’entre vous, je vais exposer quelques avantages de Ruby:

Ruby est simple

C’est tout ce dont vous avez besoin dans votre fichier pour afficher votre message préféré !

Ruby est clair

C’est pas la classe ? Sérieusement, pour faire ça en C, on doit avoir un tableau, faire une boucle et un if. Là, c’est tout joli, tout mignon, tout clair, vite fait bien fait !

Pourquoi je vous dis tout ça ?
J’aimerais travailler avec des volontaires sur différents projets utilisant Ruby sur notre temps libre pendant l’année. Que ce soit un jeu, un site internet, un code Arduino (oui, on peut en ruby !!), bref n’importe quoi qui vous passe par la tête.

Mais pourquoi Ruby ?
Pour changer des langages qu’on pratique en cours et ainsi mieux juger des avantages et des défauts de chacun. Ruby est clair, simple, rapide à produire mais le C, beaucoup plus strict, est plus économe en mémoire, donc plus intéressant d’un point de vue algorithmique.

Pourquoi faire ça à la DTRE ?
En tant qu’association de robotique, nous nous devons de vous faire découvrir de nouveaux horizons, de vous pousser à aller plus loin, à innover ; et Ruby est l’un de ces langages de scripting extrêmement pratique pour implémenter rapidement des multitudes de fonctionnalités, sur une interface ou un réseau, par exemple…

Donc si ça vous branche, venez me voir à la cave, ou contactez-moi : david.bensoussan@dtre.fr.

La domotique, c’est un domaine dans l’air du temps. C’est tous ces trucs futuristes et cools qu’on peut voir dans « Le Cinquième Elément » ou « I, Robot ». C’est aussi bien le régulateur de température que Jarvis dans « Iron Man » (qui, soit dit en passant s’occupe également de la température) ! La domotique, c’est tout ça et bien plus encore (oui, oui, comme Denver).

Alors pourquoi n’est-ce pas étendu partout, depuis le temps qu’on en parle ? Pourquoi n’a-t-on pas un « appart’ du futur » alors que l’idée est très ancienne ?

Personnellement, et ça n’engage que moi, je vois trois problèmes majeurs à l’intégration de la domotique dans la vie de tout un chacun :

1. Un problème technique : Aujourd’hui, on cumule les difficultés pour essayer de faire quelque chose qui fonctionne. Des normes qui vieillissent mal et qui sont mal sécurisées sont encore et toujours utilisées avec l’excuse que « ça juste marche pour le moment ». De plus, une partie des infras existantes ne supportent que mal ces normes (même si les choses changent peu à peu).
2. Un problème financier : Les entreprises qui vendent de la domotique la vendent à prix d’or. Et pour cause : elle leur coûte chère à concevoir et à déployer. L’amateur qui veut se faire son système chez lui va devoir également dépenser des milles et des cents en matériel « spécial domotique ®©™ ».
3. Un problème de conception : Depuis que je m’intéresse à ce domaine, je n’ai, pour le moment, vu presque aucun système domotique réellement autonome. Ils sont tous contrôlés d’une façon ou d’une autre (et souvent via un boîtier de commande) par un humain. Oui, au lieu d’allumer la lumière sur le mur, il l’allume sur son boîtier… c’est un progrès, certes, mais ce n’est clairement pas ce que l’on pourrait attendre du Futur ! Un autre problème est la centralisation généralisée des réseaux domotiques : un contrôleur central qui gère tout et des modules basiques tout autour. Le contrôleur tombe, TOUT tombe…

Voici donc le bilan chronologique comme je peux le retranscrire après mes heures de sommeil rattrapée et quelques jours de stage.

C’est vendredi soir que tout a commencé. J’arrive à la DTRE vers 17h30 avec une bonne journée de travail. J’y suis accueilli par Loïc (Crocosheep) qui a visiblement bossé toute la journée sur son workshop de micro-railgun. Ayant fait l’acquisition, la veille de deux appareils photos jetables, je vois les condensateurs récupérés pour la mise à feu. Nous discutons un peu et David (Mini_P@da) arrive pour se joindre à nous.

En tant que responsable des conférences, il était nécessaire que nous produisions un système de gestion du temps de chaque intervenant, afin de faire respecter le planning. Qu’à cela ne tienne, nous nous mettons en tête de faire un bandeau de LEDs qui décroit en fonction du temps. Les branchements sont majoritairement gérés par David et je m’occupe du programme basique qui gère la vingtaine de diodes. Pendant ce temps, Loïc génère des petits arcs électriques et fait fondre son interrupteur.

Nous travaillons ainsi jusqu’à la limite de présence autorisée dans l’école et partons donc vers la NDH. David et moi (Franklin) nous séparons de Loïc aux Halles pour nous rendre à Disney directement (nous sommes passé par un magasin et nous sommes maintenant munis de chips et de thé glacé (« On ne vend plus de bière après 21h00″…)). Je porte mes sacs contenant quelque matériel (d’atelier et général) et David tient sur toute la longueur de son bras le bandeau de diodes assemblé.

Nous arrivons à l’entrée de Disney Village sans trop de mal et nous apprêtons donc à rentrer. C’est alors que nous découvrons la sécurité ! Le bandeau de gestion du temps paraît suspect (« C’est une bombe ? ») ; sans parler des pinces que nous transportions (dont la pince à sertir du RJ45, particulièrement douteuse). Mais … le tout passe plutôt bien après explication (nous sommes un peu plus étonnés que Loïc fasse passer un générateur le lendemain).

Nous voilà à présent David et moi-même dans l’Hotel New York, très classe, tout ça… Et grâce à Terry qui passait par là, nous trouvons les autres staff de Hackerzvoice et Sysdream. On dit bonjour, tout ça on teste un peu la scène, par principe, puis on se remet au boulot : debug du timer à LEDs, sertissage ethernet (d’ailleurs, salut Ezano, si tu me lis), sustentation avec des sandwiches qui déchirent (et des chips uniquement pour certains), discussion avec des orateurs de Hack In Paris, et aide à diverses autres tâches.

Nous découvrons également la salle : 2000 m², sonorisation complète, des chaises pour tout plein de personnes, un espace staff cosy et agréable. En soi, même pas peur, les chaises vides, ça ne juge pas. Bref, on se dit que le lendemain va déchirer. Et j’entends un « De toute façon, tu auras le temps de te chauffer, il n’y aura pas grand monde à la conf de 10h00″…

C’est fourbus et appréhendant l’évènement que nous allons nous coucher vers 03h30 ou 04h30. J’ai partagé la chambre avec David, virtualabs, Sorcier_FXK et Ezano (un majorité de membres HZV, donc). Je vous passe ma nuit de sommeil de une heure et demi absolument passionnante dans une baignoire du Sequoia Lounge .

Le Samedi, Jour-J ! Nous nous réveillons, douche rapide, petit-déj’ à l’arrache (pas très faim vu que le dîner avait été pris vers 02h00), on arrive dans la salle et déjà quelques geeks attendent. Nous terminons les derniers check avec la régie, tout semble nickel.

Les premiers gens arrivent et je comprends qu’il y aura en fait plus de monde que « un peu » devant moi. Des bugs sur les applications gérant les badges à l’entrée et on retarde la première conf, le temps que la majorité soit prête. Rien que d’annoncer un retard devant 200 personnes, ça fait drôle. Annoncer ensuite la NDH en elle-même et la conférence de virtualabs devant 600 ou 700 gens, c’est limite terrifiant (ils attendent, les bougres, 20 minutes de retard). Tr4nce et moi-même avons tout au long de la matinée essayé de combler le retard des confs en mangeant sur les pauses. Des conférences passionnantes, on rit, on s’indigne, on applaudit. A la fin j’apprends que le challenge public se déroule apparemment bien mais qu’il en est allé du contraire pour CTF. N’ayant toutefois pas suivi l’histoire, je ne m’étendrai pas dessus. Nous avons toutefois vu du staff déprimé et échaudé, des équipes sombrant dans la folie (des mecs jouaient à un jeu à boire à base de Shi Fu et Mi dans le désordre (si quelqu’un connait ce jeu, les commentaires sont là pour ça)). Beaucoup de participants et d’orgas sont fatigués et les couloirs sont jonchés de corps presque inanimés.

Revenons vers xxhyy (distorsion temporelle oblige, je ne saurais plus dire du tout ce qui c’est passé après les confs). C’est le moment que je choisis pour préparer mon workshop (sniffing physique passif de réseau ethernet) et former mon assistante Givre. David prévoit aussi le sien (musique 8-bit) et Loïc arrive avec un générateur prêté par Kama (président BDE) pour l’occasion et des appareils photo jetables en quantité (pour son micro-railgun). Victor et Edouard, arrivent également pour participer et aider à répondre aux questions.

Une fois la préparation faite (rapide pour apprendre la Givre), nous arrivons dans la salle ou beaucoup de monde se presse autour des ateliers et où les participants CTF s’impatientent. Observant que l’atelier de David se déroule bien (une quinzaine de personnes qui suivent activement, je trouve ça classe pour une première), je décide de me reposer en attendant mon tour. Je m’assoupis rapidement avec mon matériel d’atelier dans les poches et le câble rj45 enroulé autour du bras. C’est ce moment que choisit un photographe pour immortaliser une image de la nuit du hack pour le journal Libération, le tout sans que je ne m’en rende compte. Je ne m’étendrai pas sur le fait que je pense qu’il y a mieux qu’un Franklin endormi pour représenter la NDH ni sur le fait que l’article en lui-même laisse à désirer.

Bref, je me réveille, anime mon atelier tant bien que mal, Givre manipulant avec brio le cutter et le briquet (heureusement, parce que je n’aurais pas pu). Beaucoup de questions dont une qui m’a moi-même laissé perplexe pendant un temps mais tout se passe bien. J’enchaîne sur des anecdotes de DataCenter (ça fait toujours marrer les gens les fails dans les milieux qui paraissent pros (ça les fait « lulzer » diront certains :p)).

Tout le monde commence à fatiguer, il y a un Open Bar duquel je profite. Après une courte pause, nous décidons de partir, le temps de dire au revoir à tout le monde.

Et voilà.

Pour résumer :

• Une super ambiance
• Une logistique plus que satisfaisante
• Des très bons sandwichs
• Des conférences intéressantes dans l’ensemble
• Un peu plus de 800 personnes m’ont vu les annoncer
• Pleins de contacts et de connaissances avec des gens trop cools
• Une cinquantaine de personnes différentes sur les trois ateliers DTRE
• Un super polo, un super t-shirt, un super badge staff et une encore plus super badge électronique
• Oh et accessoirement, mon mac déverouillé avec une session root ouverte en pleine estrade pendant que je dînais

Ce fût donc un évènement plus que passionnant pour nous et nous sommes fiers et heureux d’y avoir participé ce qui, j’espère, sera plus appuyé l’année prochaine.

Des photos devraient bientôt apparaître dans la galerie quand Pippon se bougera le popotin…

Cette année, comme vous le savez, la DTRE se prend en main et s’efforce de se diversifier tout en restant fidèle à elle-même ! C’est tout naturellement (et, je dois avouer, avec beaucoup d’enthousiasme) que nous avons répondu à l’appel des organisateurs de la Nuit Du Hack (NDH) afin d’animer des ateliers tout au long de la nuit.

Cet événement rassemble plein de personnes passionnées par le hacking (dans tous les sens du terme) et qui se réunissent depuis 2003 pour partager leurs connaissances et leurs intérêts. Autrement dit, c’est un rendez-vous à ne pas manquer pour qui veut en savoir plus sur de nombreux domaines (principalement de la sécurité. Je vous invite à lire le programme qui promet d’être passionnant à tous les niveaux!).

La NDH, c’est aussi l’occasion de pratiquer pour de vrai diverses techniques pendant des ateliers organisés tout au long de la nuit. Et c’est à ce moment là que nous intervenons… littéralement ! La DTRE animera cette année trois superbes ateliers :

• De 23h00 à 01h00, de la musique 8-bits sur microcontrolleurs… on vous en a déjà parlé, c’est fun, c’est cool, c’est hype et c’est animé par Mini_P@da (David qui, quand on lui file un projet à faire en un mois le termine à 80% en… une journée… ).
• De 01h00 à 02h00, de la fabrication de micro-railguns… on laisse un peu ça discret mais une surprise de taille vous est réservée pour l’année prochaine concernant cette techno. Cet atelier est animé par « Crocosheep » (Loïc, quoi… Le mec qui s’occupe entre autres de la majorité des parties mécaniques des futurs gros robots de la DTRE (présentés dans de prochains articles)).
• De 02h00 à 04h00, de la fabrication de sniffeurs ethernet passifs, pour pouvoir lire tout ce qui passe entre deux machines (branchées en ethernet, j’entends), animée par moi-même, Grufgrim (Franklin, <mettre un adjectif mélioratif ici> et accessoirement futur prez’ de la DTRE (et ouais, très bientôt en plus )).

Bref, on a la classe . Il s’agira du premier événement majeur de la DTRE 2011-2012 et ça va dépoter !

(Inutile de dire que nous vous encourageons à acheter votre billet et à venir )

Comme certains d’entre vous l’ont probablement observé lors des journées portes ouvertes/journées de liste/journées concours/journées où on n’avait rien d’autre à faire, nous avons interfacé le jeu lightcycle dans TRON ( Armagettron ) avec des « manettes » faites maison (une plaque de prototypage et deux boutons, quoi) et avec mon ordi, un MacBookPro 3,1 qui en l’occurence tournait sous Mac OS 10.6 (ma Gentoo n’a pas encore de serveur X installé et configuré et la réalisation devait se faire en environ 2 heures…).

Cet article présentera une méthode pour procéder à cet interfaçage. Probablement pas la meilleure, ou la plus optimisée, mais c’est une méthode qui fonctionne.

Tout d’abord, nous aurons besoin :

• De fils électriques et de la pince à dénuder qui va avec (voire vos dents, si vous êtes Victor)
• De trois cartes de prototypage (deux pour les manettes, une pour le support)
• D’un arduino (dans notre cas, un arduino Uno)
• De quatre boutons poussoirs (deux par manette)
• De quatre résistances de 2.2KΩ
• De vos mimines

Commencez par réaliser le montage suivant relativement simple :

Le montage d'une "manette" de tron

Vous observerez qu’il n’y a qu’une seule manette de faite. Il est probable que vous arriviez vous-même à faire la seconde sur le modèle de la première.

Branchez cette seconde manette sur les pins 4 et 5 de l’arduino. On évitera d’utiliser les pins 0 et 1 dans la mesure où celles-ci servent à la communication série que nous verrons après.

Ce montage permet, simplement, de brancher deux boutons sur l’arduino et de faire en sorte que celui-ci capte du « 0″ lorsque les boutons ne sont pas appuyés et du « 1″ lorsqu’ils le sont.

Nous allons à présent faire un code arduino simple pour envoyer des caractères ascii par le port série à l’ordinateur.

Ce code est relativement simple et envoie simplement sur le port série une lettre (‘a’, ‘z’, ‘e’ ou ‘r’) selon le bouton pressé.

Attaquons maintenant la partie AppleScript. Je précise qu’il est normalement simple sous linux d’utiliser la Xlib ou autre pour simuler des entrées claviers. Toutefois, ayant 45 minutes restantes et n’ayant toujours pas envie de compiler de serveur X, nous nous en passerons !
Notre algo est simple : lire le port série, envoyer ça comme si on tapait au clavier… le tout en boucle.

Pour lire le port série, même si une commande shell ou une lecture de fichier fonctionne impeccablement, je préfère utiliser la bibliothèque applescript SerialPortX. C’est propre, ça fonctionne pas mal, et ça plante quand on tente de lire un truc qui n’existe pas.

Pour envoyer des données comme si elle étaient tapées au clavier, on utilisera le bout de code suivant :

Cette fonction enverra le code « k » voulu comme s’il était entré au clavier. Seul problème : comment connaître le bon code pour chaque lettre ? C’est là qu’intervient l’application Full Key Codes. Cette dernière va vous fournir tout ce qui est nécessaire.

Je crois qu’on a tout :

Voilà un applescript naïf qui fonctionne :

Voilà. Oui le code pourrait être très facilement mieux, mais autant ne pas tout vous filer tout cuit…

Si vous testez un peu le tout, vous observerez un bug récurrent : si un des deux joueurs s’acharne sur sa manette, le second ne pourra pas du tout jouer ou placer une action…

Ce bug est en fait dû à la bibliothèque « Serial » arduino qui gère tout ça et qui ajoute un délai de beaucoup entre deux utilisation du port série… Heureusement, il existe un truc qui marche (testé et approuvé par moi si vous utilisez le port série pour plein de petits messages et pas pour du gros message).

Nous voici donc avec un jeu fonctionnel et prêt à vous éclater en JPO et autres événements.

Le bien fameux bras cocktail.

Parce qu’à la DTRE, on est comme vous, on aime bien les bonnes chose à boire.

Parce que prendre de la bière en soirée, ça fait un peu perdre en classe.

Parce que même si le mojito c’est pratique, ça peut revenir cher.

Parce que le barman, quand tu lui demandes un « Pac-Man », il n’en a jamais entendu parler.

Parce que en lui demandant, tu as plus envie de te démonter les cordes vocales.

Parce que le barman, en plus, même quand tu lui expliques, t’as trop de gingembre dans ton verre…

Parce que six moteurs à asservir ensembles, ça peut être super sympa pour apprendre.

Parce que l’idée d’avoir un robot qui vous sert comme dans « Le cinquième élément » vous plaît.

Parce que vous aimez bosser sur un truc où les calibrages seront un privilège…

Parce que tout ça, le projet « bras cocktail » de la DTRE est là, mis en place, n’attendant que votre participation.

Le principe de ce projet est son automatisation ou plutôt son informatisation pour pouvoir lui faire réellement servir des cocktails en tout genre via une interface simple et intuitive.

N’hésitez pas à nous poser des questions sur ce projet par mail ou en passant nous voir.

A bientôt.