De quoi a-t-on besoin ?
- Arduino. Il faut obligatoirement être sur des ports digitaux!!! Les ports PWM ne marchent pas comme on veut !
- 4 Boutons poussoirs
- 4 leds
- Fils
- Resistances (entre 20 et 100 Ohms)
- Une Pince

Temps nécessaire
J’ai personnellement mis quelques heures pour réaliser ce montage et le code.
Le programme était simple à faire, mais j’ai eu quelques prises de têtes sur le montage des fois (un fil mal cablé c’est chiant ^^).

Prérequis
- Configurer votre Arduino

Voir ici
J’ai personnellement utilisé un Arduino Mega 2560 mais n’importe lequel marche.

- Configurer les ports
Un port peut être configuré en entrée ou en sortie.

On configure par exemple une led en sortie (« OUTPUT ») sur le port 22.

On configure par exemple un boutton en entrée (« INPUT ») sur le port 23.

- Configurer un bouton poussoir
Voir [ici](http://arduino.cc/en/Tutorial/Button).

- Configurer une led
Voir ici.

Il se peut que les états s’inversent.

- Faire marcher un buzzer
Le configurer en sortie sur le port X, un son à la fréquence w, et de durée noteDuration.

- Configurer un Random
Le random sera utilisé pour que la séquence ne soit pas prédéfinie:

Le « randomSeed(analogRead(0)); » initialise le générateur de nombre pseudo-aléatoire, l’amenant à démarrer à un point arbitraire dans sa séquence aléatoire. Cette séquence, très longue, et arbitraire, est toujours le même.
random(x,y) génère un nombre compris entre x et y (y exclus).

Au travail !
Le code

void setup() {



  //Configuration des leds (sorties) et bouttons (entrées)

  // Bleu

  pinMode(22, OUTPUT);

  pinMode(50, INPUT);



  // Rouge

  pinMode(23, OUTPUT);

  pinMode(51, INPUT);



  // Vert

  pinMode(24, OUTPUT);

  pinMode(52, INPUT);



  // Jaune

  pinMode(25, OUTPUT);

  pinMode(53, INPUT);



  randomSeed(analogRead(0));



  //Buzzer

  pinMode(26,OUTPUT);



}



  //Ports d'entrées : 50==>Bleu

  // 51==>Rouge

  // 52==>Vert

  // 53==>Jaune



  // Leds: 22==>Bleu

  // 23==>Rouge

  // 24==>Vert

  // 25==>Jaune

void allumage_all()

{

  digitalWrite(22, HIGH);

  digitalWrite(23, HIGH);

  digitalWrite(24, HIGH);

  digitalWrite(25, HIGH);

}



void eteindre_all()

{

  digitalWrite(22, LOW);

  digitalWrite(23, LOW);

  digitalWrite(24, LOW);

  digitalWrite(25, LOW);

}



void fail()

{

  allumage_all();

  delay(200);

  eteindre_all();

  delay(200);

  allumage_all();

  delay(200);

  eteindre_all();

  delay(200);

  allumage_all();

  delay(200);

  eteindre_all();

  delay(1000);

}



void loop (){

  int tab[100];

  int rand;

  int bon = 1;

  int i;

  int j =50;

  int check = 0;



  for (i = 1; i < 100; i++)

    tab[i] = 0;

    i = 1;

    tab[0] = random(22,26);



  //Difficulté (tout les combien s'allument les leds)

    int diff = 3;



    while(1){



  //Allumage des leds

      if (bon == 1){

        for (i = 0; tab[i] != 0 ; i++){

          digitalWrite(tab[i], HIGH);

          delay(1000/diff);

          digitalWrite(tab[i], LOW);

          delay(1000/diff);

        }

      }



  //Joueur

      for(i = 0; tab[i] !=0 ; i++){

        while (check == 0){

          j = 50;



          while (digitalRead(j) == false){

            if (j == 54) break;

            j++;

          }

  // On joue un son quand on a appuyé

          tone(26,j*j,300);



          if (j == 54)  j = 50;

          else check = 1;

        }

        check = 0;



        if (tab[i] + 28 == j){

          digitalWrite(tab[i], HIGH);

          delay(200); // tout les combien de temps peut on appuyer sur un boutton

          digitalWrite(tab[i], LOW);

          delay(200);

          bon = 1;

        }

        else {// Trompé: on fait clignoter les leds 3 fois

          bon = 0;

          fail();



          //On fait répéter la séquence de led

          for (i = 0; tab[i] != 0 ; i++){

            digitalWrite(tab[i], HIGH);

            delay(1000/diff);

            digitalWrite(tab[i], LOW);

            delay(1000/diff);

          }

          j = 0;

        }

      }



    if (bon == 1){

      rand = random(22,26);

      tab[i] = rand;

      i++;

    }

  }

}

Je tiens juste à expliquer particulièrement ceci:

C’est la condition qui dit si le bouton est celui qui correspond à la led ou pas.
tab[i] est le pin de la led, et tab[i] + 28 serait le pin d’entrée du bouton.
Cette relation de 28 est arbitraire, elle permet juste d’éviter de faire 4 if différents. Ils auraient été utilisés pour vérifier l’association entre les leds et les bouttons.

Le montage
Le but est maintenant d’assembler le tout : bouttons, leds, buzzer.

C’est simple, il faut y aller au fur et à mesure. Tout d’abord, placer un bouton avec une led (voir comment placer une led et un boutton plus haut). Quand ça marche, répeter l’opération pour les 3 autres leds et bouttons. Voici ici un programme pour tester vos bouttons et Leds:

// Test bouttons

void setup() {

  // Bleu

  pinMode(22, OUTPUT);

  pinMode(50, INPUT);



  // Rouge

  pinMode(23, OUTPUT);

  pinMode(51, INPUT);



  // Vert

  pinMode(24, OUTPUT);

  pinMode(52, INPUT);



  // Jaune

  pinMode(25, OUTPUT);

  pinMode(53, INPUT);



}



//Ports d'entrées : 50==>Bleu

// 51==>Rouge

// 52==>Vert

// 53==>Jaune



// Leds: 22==>Bleu

// 23==>Rouge

// 24==>Vert

// 25==>Jaune



void loop() {

  // Bleu

  if (digitalRead(50) == true){

    digitalWrite(22, HIGH); // set the LED on

    delay(1000); // wait for a second

    digitalWrite(22, LOW); // set the LED off

    delay(1000); // wait for a second

  }



  // Rouge

  if (digitalRead(51) == true){

    digitalWrite(23, HIGH); // set the LED on

    delay(1000); // wait for a second

    digitalWrite(23, LOW); // set the LED off

    delay(1000); // wait for a second

  }



  // Vert

  if (digitalRead(52) == true){

    digitalWrite(24, HIGH); // set the LED on

    delay(1000); // wait for a second

    digitalWrite(24, LOW); // set the LED off

    delay(1000); // wait for a second

  }



  // Jaune

  if (digitalRead(53) == true){

    digitalWrite(25, HIGH); // set the LED on

    delay(1000); // wait for a second

    digitalWrite(25, LOW); // set the LED off

    delay(1000); // wait for a second

  }

}

Une fois ceci testé, il ne vous reste plus qu’à lancer le programme dessus, changer vos ports si vous voulez ou si vous en avez besoin.

Voilà, j’espère que vous vous en êtes sorti.

Hello tout le monde, mardi 28 février c’était la Robot Party à Meudon, et la DTRE était présente !
La Robot Party est un évènement d’une semaine durant laquelle le public a découvert l’histoire de la robotique (grâce à nous), vu des robots tels que le NAO, Nabaztags ou certains NXT exposés pour l’occasion.

La première chose dont je voudrai parler, c’est le public. On a donné une « conférence » à des enfants de 10 ans sur l’histoire de la robotique. Oui entre guillemets, parce que des enfants de 10 ans, ça se gère différemment. On a plutôt raconté l’histoire de la robotique. Depuis quand parle-t-on de robotique ? Qui en d’ailleurs parlé à la base ? Pourquoi y a-t-on pensé ?

Ce public est assez spécial. On a dû adapter nos slides, utiliser un vocabulaire différent, ne pas utiliser certaines références.
C’était vraiment intéressant, on les a fait participer en leur posant des questions et ils en posaient également.
J’ai pu remarquer l’intérêt des garçons: est-ce que les robots peuvent se battre ?
Et celui des filles: Est-ce que les robots peuvent tomber amoureux ? (avec un petit sourire timide)

J’ai été étonné de certains enfants. On leur parle d’énergie récupéré par les rayons du soleil :
« Oui c’est avec les panneaux photovoltaïques »…

Ils connaissent des choses en fait. Ok c’est intelligent un enfant (il faut juste le considérer tel quel).

Il y avait beaucoup de questions intéressantes. Est-ce qu’un robot peut rêver, tomber amoureux ? Comment fait un robot peut pouvoir imiter un humain et se faire passer pour lui ? C’est ce que des chercheurs essaient de faire, aujourd’hui !

C’était vraiment sympa, les enfants ont vraiment aimé, voici des photos:
Lien vers les photos

Nous devons fabriquer un lecteur/emetteur de puces RFID.

Ça veut dire quoi RFID ?
Radio Frequency IDendification.

Pourquoi Radio ?
L’activation requiert l’émission d’un signal. Il y a plusieurs plages de fréquences, en voici quelques unes standards pour les RFID (et autres tags NFC):
- 125 kHz.
- 13,56 MHz.
- 900 MHz.

A quoi servent-elles et où en trouve-t-on ?
Elles sont utilisées dans de multiples domaines. Prenons par exemple le transport de marchandises : on assigne une puce à un produit. Au départ, on compte le nombre de produit via un scan qui compte le nombre de puces et on fait pareil à l’arrivée. Ça va super vite, et ça prend beaucoup moins de temps que de compter à la main.

Exemple plus concret : les badges pour entrer dans les bâtiments sont en fait munis de puces RFID qui permettent  le contrôle d’accès !

Super, et comment ça marche ?
On peut mémoriser et récupérer des données en utilisant des radios étiquettes (tag). Ces tags possèdent une antenne qui leur permet de recevoir et de répondre à des requêtes radios émises depuis l’émetteur.
Petite explication technique :
Le dispositif utilise une antenne (en gros, une bobine) pour alimenter le tag RFID et lit la réponse.
Cette réponse est ensuite filtrée et manipulée en données interprétées. Dans le cadre de notre PPD, nous utilisons un Arduino pour interpréter ces données.

Le système de sécurité pourra enregistrer des codes, chacun composé d’un certain nombre de bit (une vingtaine par exemple) qui sont dérivés de chaque tag rfid (il est donc unique !)
Il pourra y avoir un système de validation, si le code est trouvé dans la base de données, il y aura une led rouge qui clignote lorsque ce n’est pas bon, vert quand c’est bon.
L’administrateur :
- Il peut ajouter des codes en initialisant des routines qui permettent d’ajouter un code à la base de données.
- Il peut retirer les codes.
- Lui seul connaît la liste de tous les codes.
- Valider le test (et faire clignoter vert), sans code.

Les thèmes explorés dans ce projet incluent la conception de filtres passifs, actifs, circuits d’amplifications, conception d’antenne RFID, la théorie de la RFID et la logique numérique.

Conception au niveau matériel:
Avant de commencer avec la conception de circuits réels, il est nécessaire de comprendre les principes derrière la technologie que ce projet a à exploiter : communication passive de RFID.
Les tags passifs RFID travaillent de tel manière qu’ils doivent être alimentés par un signal externe, qui, dans la plupart des cas est le signal porteur du lecteur.
Les cartes que nous possédons sont porteuses (répondent) de fréquence 125 KHz et la taille des tags peut être de 26 à 128 bits.

Dans les cartes, le type de modulation est FSK (Frequency-Shift Keying), que l’on peut traduire par : Modulation par Déplacement de Fréquence (MDF). C’est un mode de modulation de fréquence numérique dans lequel le signal modulé varie entre des fréquences prédéterminées. C’est le type de modulation le plus utilisé pour les cartes RFID.

Le FSK module le signal essentiellement en multipliant une faible amplitude,  une faible fréquence avec le signal porteur, créant un effet de modulation d’amplitude (AM effect). La plus basse fréquence enveloppant la fréquence porteuse. Pour passer d’un « 1 » à un « 0 », le tag  modifie les fréquences de modulation. Les 2 fréquences utilisées par nos cartes sont 12.5 KHz (125 KHZ/10) et 15.625 KHz (125 KHz/8), qui correspondent respectivement au 1 et au 0.

On tire cela du schéma de transmission tirée de la documentation Microchip pour les cartes RFID de fréquence 125 KHz :

Forme de signal du protocole FSK

La modulation produit un effet qui ressemble à cela.

 Le travail du circuit lecteur est de fournir la fréquence porteuse de 125 KHz, la transmettre au tag, et de détecter le couplage magnétique de celle-ci, ce qui ressemble à la figure du dessus.

Le diagramme en blocs pour notre circuit de lecteur peut être trouvé dans la figure ci-dessous :

Bien que chaque pièce du circuit et le programme seront décrit en détail plus tard, l’idée générale du fonctionnement du circuit est la suivante:

L’arduino fournit une minuterie pour 125 KHz d’ondes carrés pour notre fréquence porteuse. Le signal est ensuite envoyé à travers une bobine d’arrêt; un filtre passif passe-bas qui ne laisse plus qu’une onde sinusoïdale. L’onde sinusoïdale est ensuite amplifiée en utilisant un suiveur-emetteur PNP et un demi-pont pour maximiser l’expérience. Etant donné que notre circuit est un circuit L-C, il est très important d’atteindre l’impédance minimale, donc il nous faut  une amplification adéquate pour ne pas surmener l’arduino. Pour aider à réduire la tension, l’onde carrée de sortie de l’arduino est mis à travers plusieurs inverseurs parallèles.

Sur l’extrémité de réception, le signal est rectifié à moitié étant donné que la partie négative ne fais pas vraiment la différence, et est ensuite introduit à travers un filtre demi-onde RC pour éliminer la plupart des fréquences 125KHz et détecter le signal d’enveloppe.
Ce signal est ensuite filtré passe-bande en utilisant une série de filtres passe bande Double T active, et passe bas filtrée avec filtre actif Butterworth pour réduire le gain en fréquence en dehors de 10-20 KHz et augmenter ainsi le gain des signaux de  l’enveloppe tel que cela sature les ampli-op des filtres.
Comme étape final, le signal est soumis à un comparateur et diviseur résistif pour produire une onde carrée belle à des niveaux logiques.
Des portes D et compteurs sont utilisés pour extraire des données de la modulation des ondes carrées. Envoyé au microcontrôleur  et traitées.

Voilà, j’espère que ça vous a intéressé. J’ai préféré ne pas montrer tous les schémas. Une fois que ça fonctionnera je posterai un nouvel article !

Merci aux étudiants de l’université de Cornell pour leur explication sur les modules RFID que vous pouvez trouver ici.

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…