Archive pour la catégorie ‘Bricolage’

 Youpi, testons les moteurs !

 30 décembre 2009  Bricolage  2 commentaires

J’avais longuement expliqué dans cet article les étapes de fabrication d’un câble parallèle pour relier le robot Youpi à un PC standard.

Aujourd’hui je vais comme promis diffuser les quelques lignes de code permettant de tester l’ensemble des moteurs. Le programme est grandement inspiré de celui que l’on peut trouver sur le site du BTS-IRIS de Niort.

C’est un programme développé à la va-vite en C. Il pourra servir de base pour tous ceux qui comme moi souhaitent vérifier que tous les moteurs sont en bon état de fonctionnement.

Le code

robotest.c :

/*
 Youpi Robot Test program
 ------------------------

 This program has to be run as root
 or with sufficient credentials (suid...)
*/

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/io.h>

// Change this to your parallel port
#define LPT 0x378

// Defines the byte type
typedef unsigned char byte;

/*
 This functions writes a byte to the parallel port
 Do not use any other way to do it as the robot needs to pause
 between each instruction.
*/
void writelpt(byte b) {
	int tempo = 1500;
	outb(b, LPT);
	usleep(tempo);
}

/*
 This is the main function
*/
int main() {

	//Variables
	int i,j;
	int steps = 600;

	//Welcome message
	printf("*** YOUPI ROBOT TEST PROGRAM ***\n");

	//Tries to access parallel port
	if(ioperm(LPT, 1, 1) != 0) {
		perror("ioperm");
		return 1;
	}

	//Initializes the robot
	printf(" * Initialization\n");
	writelpt(0x47);
	writelpt(0x00);

	//Orders earch motor to rotate
	for(j=0; j<6; j++) {
		printf(" * Test of motor %d\n", j);

		//...into one direction
		writelpt(0x80);
		writelpt(0x00);
		for(i=0; i<steps; i++) {
			writelpt(0x40+j);
			writelpt(0x00+j);
		}

		//...into the opposite direction
		writelpt(0xBF);
		writelpt(0x3F);
		for(i=0; i<steps; i++) {
			writelpt(0x40+j);
			writelpt(0x00+j);
		}
	}

	return 0;
}

Et le Makefile qui va avec :

CC=gcc
CFLAGS=-W -Wall -O

all: robotest

robotest: robotest.c
	$(CC) $(CFLAGS) -o $@ $<

clean:
	rm robotest

Quelques explications

Le manuel indique une vitesse de rotation maximale de 40°/s pour tous les moteurs, avec une résolution maximale de 0.03° par 1/2 pas. Chaque 1/2 pas est effectué grâce à l’envoi de 2 instructions par le port parallèle. Pour faire avancer le robot à cette vitesse maximale, il est nécessaire d’espacer chaque instruction d’un temps T en secondes, calculé ci-dessous :

Il faut donc espacer chaque instruction de 1500 µs, ce qui explique les 1500 à la ligne 27 du code. Descendre en dessous de cette limite est susceptible de provoquer des catastrophes inconnues, donc si vous essayez, cela sera à vos risques et périls.

Bugs connus

Avec un sommeil de 1500 µs entre chaque instruction, le programme devrait théoriquement être terminé en approximativement 2+6*(2+600*2)*2*0.0015 = 22 secondes, en négligeant le temps nécessaires aux autres instructions. Hors j’obtiens en moyenne un temps d’exécution à 58 secondes.

Ce phénomène est expliqué en partie par le paragraphe suivant, tiré de la page man 3 de usleep :

La période de sommeil peut être allongée par  la  charge  système, par le temps passé à traiter l’appel de fonction, ou par la granularité des temporisations système.

En résumé, lors de mon test, la vitesse de rotation de chaque moteur n’est pour le moment pas optimale. J’avais fait d’autres essais en réduisant significativement cette temporisation à quelques µs, ou en utilisant nanosleep afin d’avoir une granularité plus fine, mais le temps d’exécution total n’est jamais descendu en dessous de ces 58 secondes. Je ne sais pas encore comment optimiser cette vitesse, cela fait appel à des notions d’architecture système et de programmation temps réel qui me manquent à l’heure actuelle. Dans tous les cas, même si la vitesse est à l’heure actuelle bridée, le programme est néanmoins capable de démontrer le fonctionnement correct de chaque moteur.

Informations complémentaires

J’en profite pour placer un rappel : au lieu de me contacter personnellement pour me demander de l’aide à propos de ce robot, merci d’effectuer cette démarche en laissant un commentaire sur ce site afin que les questions et réponses profitent à tout le monde.

NB : vous pourrez maintenant trouver en un seul clic tous les articles de ce site relatifs au robot Youpi grâce au tag Youpi.

 Pong Clock :: calcul des trajectoires

 16 décembre 2009  Bricolage  Aucun commentaire

Deux rapides améliorations ont été apportées :

La police de caractères utilisée pour l’affichage des scores a été modifiée pour se rapprocher du jeu original, plus « carrée », composée de lignes simples. Ça n’a l’air de rien comme ça, mais j’ai dû « dessiner » les 10 chiffres pixel par pixel dans le code (par groupe de 8 pixels, pour être précis). Ce qui donne un truc très sympa dans ce genre là (une ligne = un caractère) :

unsigned char pongfont[4096] = {
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, // chr(0)
// [...]
254,254,198,198,198,198,198,198,198,198,198,198,198,254,254,0, // chr(48) = 0
24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,0, // chr(49) = 1
254,254,6,6,6,6,254,254,192,192,192,192,192,254,254,0, // chr(50) = 2
254,254,6,6,6,6,62,62,6,6,6,6,6,254,254,0, // chr(51) = 3
198,198,198,198,198,198,254,254,6,6,6,6,6,6,6,0, // chr(52) = 4
254,254,192,192,192,192,254,254,6,6,6,6,6,254,254,0, // chr(53) = 5
254,254,192,192,192,192,254,254,198,198,198,198,198,254,254,0, // chr(54) = 6
254,254,6,6,6,6,6,6,6,6,6,6,6,6,6,0, // chr(55) = 7
254,254,198,198,198,198,254,254,198,198,198,198,198,254,254,0, // chr(56) = 8
254,254,198,198,198,198,254,254,6,6,6,6,6,254,254,0, // chr(57) = 9
// [...]
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0  // chr(255) = ÿ
};
Mise à jour de la police de caractères, premières informations de trajectoire.

Mise à jour de la police de caractères, premières informations de trajectoire.

Enfin, pas forcément plus simple, sans être non plus très complexe, la détermination de la trajectoire qui sera suivie par la balle lorsqu’elle touche la raquette, jusqu’à la raquette adverse, affichée en vert sur ces captures d’écran en mode debug.

Le nombre de rebonds peut rapidement devenir important...

Le nombre de rebonds peut rapidement devenir important...

C’est à peu près tout ce qu’il est possible de faire à ce stade avec des images fixes. Les prochaines modifications m’amèneront certainement à me lancer à minima dans l’animation de la balle.

 Pong Clock, les premières images

 16 décembre 2009  Bricolage  Aucun commentaire

Voila enfin, en exclusivité mondiale, les premières images du développement de l’horloge Pong !

Avec également un petit bilan intermédiaire des frais :

  • 2/3 heures de développement
  • 200 lignes de code (sans la police de caractères)

Avec en contrepartie les résultats suivants :

  • Affichage du terrain, des raquettes, et de la balle.
  • Affichage du score (police non définitive) en fonction de de l’heure système.
  • Gestion d’une zone vide optionnelle au dessus du terrain, pouvant être dédiée à l’affichage des scores ou de tout autre information.
  • Taille du terrain, des raquettes, et de la balle customisables.
  • Gestion de plusieurs résolutions en 4/3 de 320*240 à 1600*1200.
  • Affichage des premiers éléments de débogage.

Pour faciliter mes tests, les développements sont effectués sur une machine virtuelle. Les captures d’écran sont également issues de cette VM. Voici l’écran d’initialisation :

L'écran de départ, balle au centre, score initialisé à l'heure courante : 20h27.

L'écran de départ, balle au centre, score initialisé à l'heure courante : 20h27.

Les éléments sont pour le moment tous fixes. Dès les premiers moments d’animation, je devrai contrôler que chaque élément reste dans son périmètre. C’est pourquoi j’ai d’ores et déjà commencé à afficher en surimpression quelques éléments de débogage.

  • En rouge le périmètre de mouvement de la balle, par rapport à son centre.
  • En bleu le rail des deux raquettes, par rapport à leur centre également.
Affichage des infos de débogage. Notez la zone vide en haut de l'écran, réduisant ainsi la taille du terrain.

Affichage des infos de débogage. Notez la zone vide en haut de l'écran, réduisant ainsi la taille du terrain.

Je trouve le résultat satisfaisant pour le moment. On attaquera les choses sérieuses la prochaine fois, puisqu’il faudra commencer à animer les différents éléments, et prévoir la trajectoire de la balle.

Stay tuned.

 Pong Clock, le spin-off

 18 novembre 2009  Bricolage, Projet Arcade  5 commentaires

Angoissé par la peur de l’échec dans la reconversion du PC portable en horloge Pong, je cherchais depuis un moment des idées alternatives de recyclage, histoire de me replier sur un autre projet qui permettrait de sauver l’ordinosaure d’une lente agonie.

Jusqu’au jour où l’idée de génie fut apportée par Sylvain : un cadre photo numérique !

Aujourd’hui je peux dire que l’idée est pleinement exploitable sur ce type de machine. SVGAlib est fait pour ça. Mieux, le programme qui contenait les lib SVGA compilées pour DSL, nommé zgv, est, si vous vous rappelez du billet précédent, un visualiseur d’images ! Cerise sur le gâteau, il peut même afficher des diaporamas !

J’ai fait le test en 10 minutes : sur le portable, si je ne force pas un affichage en 320×240, mes images s’affichent, mais sont parfois décalées de quelques pixels sur la droite pour une raison inconnue. Éventuellement à tweaker légèrement en fonction du portable. Pour info, zgv a un pendant sous X11 nommé xzgv.

J’enregistre mes réglages sur DSL de la manière suivante (force la résolution, le nombre de couleurs, et les paramètres de zoom) :

alias zgv='/opt/zgv/zgv2 -p -j -z -m "320 240 8"'

Je peux ensuite lancer un diaporama avec la commande suivante :

zgv /path/to/my/pictures/*

Et voila, la preuve en image, un cadre photo numérique artisanal réalisé sans effort. :)

Pour un peu, on pourrait croire que je prône mon propre culte de la personnalité...

Pour un peu, on pourrait croire que je prône mon propre culte de la personnalité...

PS : pas de panique, pour le moment ma roadmap en ce qui concerne le laptop est toujours l’horloge Pong. ;)

 Le pixel infernal

 17 novembre 2009  Bricolage, Projet Arcade  3 commentaires

Dans l’article précédent, je détaillais mes premières étapes de la transformation d’un vieil ordinateur portable en horloge Pong, à savoir l’installation d’un Damn Small Linux sur le système.

L’étape suivante n’est pas de tout repos, puisqu’il faut maintenant afficher à l’écran les graphismes de mon choix. En l’occurrence, un terrain, deux raquettes carrées, une balle carrée, et un score qui évolue en fonction de l’heure. Mais ne plaçons pas la charrue avant les bœufs, autant commencer doucement, et tenter d’afficher dans un premier temps un modeste pixel.

Car à ce stade, DSL démarre en mode console.

Elle est belle, ma console, elle est belle !

Elle est belle, ma console, elle est belle !

Après un peu de nettoyage dans les scripts de démarrage de DSL, j’obtiens beaucoup moins d’erreurs lors du boot. À terme, mon but est d’avoir un affichage le moins verbeux possible pendant le boot, histoire de donner à la future horloge un petit côté appliance. Comprenez par là que les messages affichés pendant la phase de démarrage sont totalement inutiles aux yeux des non-informaticiens, il sera donc intéressant d’en diminuer le nombre, tout en gardant la possibilité de les afficher moyennant la manipulation appropriée (un paramètre passé au noyau, par exemple). Mais ceci est purement cosmétique et ne constitue pas la priorité n°1.

Nous sommes donc en mode console. Le mode console, c’est une division de l’écran en 80 colonnes et 25 lignes, chaque case située à leur intersection pouvant afficher exactement un caractère, ni plus ni moins. C’est donc fait pour afficher du texte, de manière (quasi) exclusive.

Alors, grâce à des bidouilles comme figlet, déjà utilisé sur mon minitel, il est possible de dessiner avec les caractères de la console, mais on est très loin de maîtriser ce qui sera affiché au pixel près.

Mince, figlet me dit que je devrais aller me coucher !

Mince, figlet me dit que je devrais aller me coucher !

Alors, comment diable afficher un simple pixel sur l’écran ? Linux utilise généralement un serveur X11 pour tout ce qui touche au mode graphique. C’est sur X11 que vient se greffer le gestionnaire de fenêtres qui affiche à l’utilisateur un bureau ergonomique et coloré. Bien que le gestionnaire de fenêtres sur DSL soit extrêmement léger, le pauvre portable avec ses 8 Mo de RAM n’a pas les ressources suffisantes pour en profiter. J’ai quand même fait le test pour rigoler, je peux afficher un bureau (640×480, 16 couleurs) en moins de 3 minutes, le tout étant suivi par une interminable période de swap, pendant laquelle il est inutile d’espérer lancer la moindre commande. En définitive, on abandonne complètement l’idée.

Le bureau, c'est possible, à condition d'avoir le temps...

Le bureau, c'est possible, à condition d'avoir l'éternité devant soi...

Dans mon cas, le salut ne sera pas apporté par X11. Il me faut quelque chose de plus léger pour afficher mon pixel. Quelque chose qui me permette de programmer des applications graphiques sans passer par X11. Quelque chose comme SVGAlib.

Caution - Geek content

Attention, à partir d’ici, ça devient un poil plus technique. Le passage qui va suivre est susceptible de déclencher des nausées, voire des vomissements, chez les non-informaticiens. Je décline toute responsabilité.

SVGAlib est une bibliothèque graphique de bas niveau pour Linux. Tout à fait dans l’esprit de ce dont j’ai besoin. En plus, le site fourmille d’exemples. Je recopie le code permettant d’afficher un simple pixel à l’écran et le compile dans la foulée.

#include <stdlib.h>
#include <vga.h>

int main(void)
{
   vga_init();
   vga_setmode(G320x200x256); // Passe l'écran en résolution 320x200, 256 couleurs
   vga_setcolor(4);           // On sélectionne la couleur rouge
   vga_drawpixel(10, 10);     // On dessine le fameux pixel

   sleep(5);                  // On attend 5 secondes...
   vga_setmode(TEXT);         // On repasse en mode console

   return EXIT_SUCCESS;       // Et on sort fièrement dans la bonne humeur
}

À ce stade, transférer le programme compilé pour le tester sur le portable est une activité relativement chronophage. Rappelez-vous : pas de lecteur CD, pas de carte réseau.

Je décide donc d’installer une copie de DSL dans une machine virtuelle (qui elle est équipée d’une carte réseau virtuelle) et sur laquelle je peux transférer mes versions compilées à grands coups de netcat.

Bien que la compilation (en environnement Debian) se passe sans trop de problèmes bloquants, la première exécution du programme dans la machine virtuelle ne se termine pas par un franc succès. Les libs SVGA sont absentes par défaut dans DSL. Qui pourrait en faire un reproche, s’agissant d’une distrib allégée ?

À tout hasard, je choisis de copier les libs de ma Debian dans DSL. Cette solution barbare fait lamentablement planter le programme avec pour toute sortie la célèbre Segmentation Fault. Je ne saurais pas expliquer exactement pourquoi, il existe de nombreuses raisons pour que cette opération ne fonctionne pas. Les libs ne sont pas optimisées pour 486, elles ne sont pas compilées pour fonctionner sur un noyau 2.4, elles sont compilées avec des options propres à Debian, etc… Un coup dans l’eau.

À cet instant, je suis confronté au moment d’angoisse que tout développeur a connu, quand il sait que toutes les solutions simples n’ont pas fonctionné, et qu’il va falloir sortir l’artillerie lourde sans savoir dans quelle direction tirer. J’en profite pour remercier tipeon, qui a toujours de bonnes idées lorsque je lance des appels à l’aide à la cantonade sur les forums ;)

Je commence à envisager de cross-compiler ces libs moi-même, quand, au détour d’une recherche sur le net, entre deux sites pornographiques, je découvre sur cette page un visualiseur d’images utilisant SVGAlib et porté sur DSL : ZGV. Les libs étant comprises dans l’archive, je les déploie sur ma machine virtuelle, relance mon programme, et constate avec le plus grand bonheur un écran vierge, à l’exception d’un petit pixel rouge en haut à gauche de l’écran. Bingo ! :)

C’est un petit pixel pour le geek, mais un bitmap géant pour la communauté.

À partir de ce moment, le concept est démontré, il est donc possible d’utiliser SVGAlib pour afficher de manière instantanée à peu près n’importe quel graphisme sur commande à partir de la console. La preuve avec ce second exemple qui sera plus parlant qu’un bête pixel rouge :

Un joli dégradé de bleu, merci SVGAlib !

Un joli dégradé de bleu, merci SVGAlib !

Voila qui termine la partie qui à mon sens pouvait poser le plus de difficultés. Le reste, bien que pas forcément évident au premier abord, pourra se résumer à un peu de programmation et un peu de bon sens. Mais je ne manquerai pas de le détailler.

À bientôt pour la suite des aventures du laptop qui ne voulait pas mourir ;)

 Le recyclage, c’est l’avenir

 17 novembre 2009  Bricolage, Projet Arcade  2 commentaires

Ce week-end, j’ai eu l’occasion de concrétiser quelque chose qui me tenait à cœur depuis longtemps : passer une nuit torride avec Gemma Atkinson donner une seconde vie à un ordinateur portable cacochyme. Chacun ses fantasmes, l’un n’empêche pas l’autre.

Cela fait effectivement un long moment que je guette l’opportunité de transformer une antiquité informatique en horloge Pong, objet de décoration post-vintage affichant le sommet de la geekitude. Oui, le mot existe, en tous cas selon Google.

J’ai donc retroussé mes manches et inspecté le matériel à ma disposition : deux portables Compaq Contura. Des ordinosaures portables en puissance, équipés d’un processeur 486 cadencé à 33 MHz, de 8 Mo de RAM, et respectivement 250 et 350 Mo de disque dur. En d’autres termes, n’importe quel téléphone mobile d’aujourd’hui affichera plus de puissance de calcul. Je remercie au passage Kiwi et HKI pour m’avoir permis de disséquer les deux bécanes.

Après un premier état des lieux, un des laptops boote sur un magnifique bureau Windows 3.1, le second ne daigne pas démarrer. Les batteries ainsi que les piles au lithium sont mortes dans les deux cas.

Windows 3.1, un OS que les moins de vingt ans ne peuvent pas connaître...

Windows 3.1, un OS que les moins de vingt ans ne peuvent pas connaître...

Suite à ce constat, je décide de mettre le portable inerte de côté, en conservant toutefois son disque dur qui servira de base pour les opérations. Foutu pour foutu, autant flinguer ce disque là avec mes expérimentations en premier.

Depuis le temps que je réfléchis à ce projet, j’ai dans l’idée qu’il me faut un OS minuscule mais efficace. Traduisez : un Linux. Je me tourne assez rapidement vers Damn Small Linux (DSL), une distrib dont la taille du Live CD ne dépasse pas 50 Mo, optimisée pour occuper une place réduite en mémoire et tourner ainsi sur les plus petites configs.

Ma décision est prise rapidement, exit DOS/Windows 3.1 et place à un système d’exploitation digne de ce nom.

Un premier problème se présente toutefois rapidement : comment installer un système d’exploitation de 50 Mo sur une machine qui n’a ni lecteur CD, ni carte réseau ? Examinons les possibilités :

  • Le diviser en 35 disquettes de 1.44 Mo, booter sur la première disquette, passer 2 heures à lire chaque disquette une par une et tout recommencer lorsque l’opération foire à la 34ème. Non, ça sent le vécu, très peu pour moi.
  • Transférer le contenu du CD par câble série. À 9600 bps, je peux avoir mes données en 12 heures en comptant uniquement le payload. Mieux vaut oublier. En plus il faudrait d’abord booter sur un Linux qui piloterait le port série, une sorte de concept de la poule et le l’œuf réactualisé. Mieux vaut trouver une méthode qui évite les migraines.
  • Démonter le disque dur, le brancher dans une carcasse de PC desktop équipé d’un lecteur CD et au besoin d’une carte réseau, et lancer l’installation à partir de ce poste. Voila une solution jouable.
Le disque dur et son adaptateur, prêt à être connecté

Le disque dur et son adaptateur, prêt à être connecté

En fouillant dans mes pièces détachées, je retrouve une nappe IDE 3.5″ vers 2.5″ qui m’a été généreusement donné par karamilo, que je remercie. Sans cet adaptateur, impossible d’aller plus loin.

Je branche donc le disque dans une des carcasses de PC qui squattent mon séjour. La poisse fait son œuvre : je flingue une alim silencieuse récente pendant l’opération. :(

Montage temporaire pour l'installation de DSL

Montage temporaire pour l'installation de DSL

Heureusement, ce ne sont pas les alims qui manquent dans mon capharnaüm. Après remplacement, le PC desktop peut booter sur le CD d’installation de DSL. L’installation est effectuée en quelques minutes.

Vient enfin le moment de vérité : le portable va-t-il démarrer correctement DSL une fois le disque dur reconnecté ? Avec Windows, en général, rien n’est moins sûr. Avec Linux, en général, c’est du gâteau, pour peu qu’on ait un noyau générique et des périphériques pas trop hors normes. Cette fois-ci ne fait exception à la règle. :)

Damn Small Linux en plein processus de démarrage

Damn Small Linux en plein processus de démarrage

La première étape est donc terminée : le vieillissant portable et son non moins vieillissant Windows 3.1 font peau neuve avec un Damn Small Linux qui me servira de base pour afficher l’horloge Pong si chère à mes rêves.

Mais cela, nous le verrons un autre jour. Stay tuned…

PS : je m’excuse pour la piètre qualité des photos et promets d’investir dans un appareil numérique digne de ce nom très bientôt.

 C’est fou ce qu’on peut trouver dans les poubelles !

 11 novembre 2009  Bricolage  3 commentaires
Les gens jettent n'importe quoi n'importe où, et moi je récupère tout et n'importe quoi.

Les gens jettent n'importe quoi n'importe où, et moi je récupère tout et n'importe quoi.

Moi qui me disais justement que je me construirais bien un serveur de sauvegardes en complément, je tombe justement sur 4 carcasses de PC au coin de la rue devant chez moi. Ni une ni deux, je les remonte dans mon humble demeure pour les autopsier à l’abri des regards indiscrets, tel un Léonard de Vinci des temps modernes.

Verdict : ce sont des vielles bécanes de la catégorie des ordinosaures (en l’occurrence de l’époque Pentium III/SDRAM), pas encore branchées, assez complètes dans l’ensemble. Ça serait bien le diable si je ne trouvais pas un moyen de les recycler en tout ou partie. J’ai déjà quelques idées en vrac, selon les possibilités :

  • Un serveur dédié de sauvegardes
  • Un serveur dédié domotique
  • Un petit media center
  • Un PC dédié à mes futurs montages expérimentaux à base de PIC.
  • Un pilote plus élaboré pour les robots Youpi.
  • Une structure de base pour une autre mamecab où même simplement une mini-cab (pourquoi pas avec le Hotrod)
  • Un PC d’appoint avec suite bureautique Open Office (ainsi que son pare-feu intégré :) ) et/ou quelques jeux pas gourmands (Half-Life/Counter Strike, Unreal Tournament, World of Goo, Braid, Wormux…)
  • Un début de cluster pour concurrencer Google ou casser des clés RSA. (Je rigole :) … Quoique…)
  • Ou tout simplement un surplus de pièces de rechange à rajouter au stock existant.

Et puisque ce sont des machines d’un autre âge, je compte bien profiter de leur consommation électrique réduite. Si un environnement graphique est requis, je pense qu’un petit Xubuntu / Fluxbuntu sera en mesure de leur redonner une seconde jeunesse. Sinon, une Debian en mode texte fera, comme d’habitude, parfaitement l’affaire.

 On a retrouvé le prototype du T-800 !

 30 mai 2009  Bricolage  14 commentaires

Alors qu’il arpentait le bric-à-brac incommensurable de son fournisseur de breloques habituel, dont je tairai le nom, mon père était désappointé. Il n’avait pas encore trouvé de gadget inutile et encombrant à acheter ce jour là.

Soudain il tomba nez à nez (ou plutôt nez à bras) avec deux massives armatures articulées, et terminées par une pince.
_ « Fichtre, se dit-il, ça ne vaut pas une armoire normande ou une borne Jeutel de 150 kg, mais on va faire avec. »
C’est comme ceci que le garage de mes parents se trouva investi par deux bras mécaniques articulés, pour le plus grand bonheur de toute la famille qui aime bien voir débarquer des objets hétéroclites dans la maison.

Le genre d'appareil pas très commun dans les chaumières, sauf peut-être chez le Dr Emmett Brown

Le genre d'appareil pas très commun dans les chaumières, sauf peut-être chez le Dr Emmett Brown

Dès que j’ai découvert ces objets merveilleux dans le garage de mes parents, je n’ai pas pu m’empêcher de me poser mille questions. Est-ce que ça fonctionne encore ? Avec quoi ça s’interface ? Comment le tester ? Qu’est-ce qu’on va pouvoir faire de marrant avec ? Et ainsi une longue quête commença.

Vue sous différents angles

Vue sous différents angles

Les machines sont estampillées « YOUPI – JD PRODUCTIQUE« . Je me mis immédiatement en quête d’informations.

Ma première conclusion fut la suivante : j’avais en face de moi le tout premier prototype du T-800. Ce robot a hérité d’un nom de code à consonance enfantine « Youpi » pour ne pas éveiller les soupçons sur ses capacités meurtrières inégalées. La société JD Productique n’est autre qu’une filiale française de Cyberdyne Systems. Mais cette hypothèse n’a pas tenu très longtemps, car la machine ne présentait aucune trace de BIOS bootant sur le réseau Skynet :p

La ressemblance est frappante. Ou pas.

La ressemblance est frappante. Ou pas.

Mes recherches suivantes, effectuées en n’étant pas sous l’emprise de la drogue, révélèrent que le robot Youpi est un formidable outil vendu principalement à des fins d’apprentissage, possédant 6 moteurs de grande précision, 5 degrés de liberté, et pilotable par le port parallèle. Je passe le détail sur les specs, elles sont disponibles ici.

Je m’attelle donc à tester rapidement le fonctionnement des robots. En vrac, il faut :

  • Nettoyer les composants, dégripper les engrenages et retendre les courroies.
  • Mettre à disposition un PC pour la partie software.
  • Construire un câble pour interconnecter les deux équipements.
Les éléments assurant la transmission ont subi les affres du temps et de la poussière

Les éléments assurant la transmission ont subi les affres du temps et de la poussière

Je décide de remettre à plus tard les tâches de nettoyage et passe directement à l’étape informatique. Je sélectionne parmi les machines entassées dans le garage quelques candidats pour le pilotage du bras mécanique. Le vainqueur est un foudre de guerre qui m’a été donné par Ben (merci à lui), jugez plutôt :

  • Processeur Pentium 233
  • Mémoire 64 Mo EDO
  • Disque dur IDE 850 Mo

Oui, ça fait rire, à l’époque du Phenom III et du Core i7, mais c’est dans les vieux pots qu’on fait les meilleures soupes. Et puis on est toujours content d’avoir du vieux matos sous la main pour ce type de bricolage.

Duel de titans

Duel de titans

J’installe une Debian sur le poste. La copie des fichiers lors de l’installation prend loooooooooooooooooongtemps. Pas parce que c’est du Debian hein, parce qu’on est sur du très vieux matos pas du tout optimisé. Comme dirait Indiana Jones, « sa place est dans un musée !« .

Installation de Debian sur l'antiquité

Installation de Debian sur l'antiquité

Pendant ce temps, je fouille dans les tiroirs pour en extraire un câble de liaison parallèle DB-25 à sacrifier. J’enlève sa coque de protection, repère et note les codes couleur des fils électriques.

09_dsc03375

25 fils à répertorier et à réorganiser, en avant la musique

Les correspondances couleurs/broches sont notées à l’arrache sur des feuilles volantes, comme d’habitude. Le brochage à utiliser est fourni dans la documentation du Youpi (page 22 pour les fainéants).

Mes notes de travail, toujours aussi soignées...

Mes notes de travail, toujours aussi soignées...

C’est ensuite parti pour la grande étape de soudure. Avec les moyens du bord. On dit toujours qu’il faut de bons outils pour bien travailler, et c’est vrai. J’avais à ma disposition un fer à la panne gigantesque, reposant dans une enclume faute de support plus approprié, avec le câble d’alim grossièrement rafistolé. Attention cher lecteur, chère lectrice, laisser reposer un fer à souder panne en haut est dangereux, ce câble et mes mains peuvent en témoigner. Inexorablement, avec un matériel pareil, pour mes soudures, j’ai fait du travail de cochon.

Plan de travail avec les moyens du bord

Plan de travail avec les moyens du bord

Note pour plus tard : idée de cadeau pour la fête des pères, un fer à souder à panne fine et un support de fer.

Connecteurs DB-25 après intervention

Connecteurs DB-25 après intervention

Une fois le travail de soudure terminé, on peut couper les fils restants ou les laisser dans le vide, l’important étant qu’ils ne créent pas de contact supplémentaire. On peut ensuite rajouter les capots en plastique.

Connecteurs DB-25 finalisés

Connecteurs DB-25 finalisés

On peut donc repartir sur le PC. Une fois le système installé, il faut juste ajouter quelques packages en fonction du langage de programmation choisi. J’ai orienté ma démarche vers le C car j’avait quelques exemples de programmation du Youpi en C sous la main. J’ai donc installé à minima les packages gcc, make, et leurs dépendances. Mais rien n’interdit d’utiliser Python, Perl, ou Microsoft Virtual Cobol 2009 Professionnal Edition si vous le trouvez. La partie backend du programme doit juste se contenter d’envoyer des octets sur le port parallèle de la machine.

Un morceau du programme à l'écran

Un morceau du programme à l'écran

Les premiers tests sont fructueux, les moteurs sont actionnés et le bras se met en mouvement. Dans la foulée je réalise une routine qui teste la rotation de tous les moteurs dans les deux sens.

Image de prévisualisation YouTube

C’est assez lent pour le moment, il y a des petits blocages par endroits, mais ça fonctionne bien dans l’ensemble. Un nettoyage (eh oui, l’étape volontairement oubliée) du robot de fond en comble devrait améliorer la situation.

Le second bras articulé a donné de moins bons résultats. Tous les moteurs ne fonctionnent pas. Selon les options, il finira peut-être en pièces détachées.

En ce qui concerne le frontend, rien n’a encore été développé. On peut imaginer en vrac un pilotage au clavier, au joystick, à la webcam, ou une routine totalement automatisée.

Il reste encore une question en suspens : quelle application vais-je pouvoir tirer de tout ce bazar, maintenant qu’il fonctionne à peu près ?

En plus il va falloir être original, en général ça existe déjà. Je me donne un délai de quelques mois pour y réfléchir et trouver une idée sympa. Cher lecteur, chère lectrice, toi qui es tombé sur cet article par hasard, tes idées m’intéressent.
Autres liens sur le même sujet :
Le site d’Edouard Forler
Le site du BTS-IRIS de Niort

Mise à jour du 09/12/2009 :

Vous avez été plusieurs à me contacter via le formulaire disponible sur ce site pour des demandes d’aide ou d’avis. Je suis disposé à vous aider, mais au lieu de me contacter directement, merci de poser vos questions en commentaire de cet article. Ainsi vos questions seront capitalisées et profiteront à la petite communauté de personnes qui utilisent un robot Youpi, et cela évitera que plusieurs personnes me posent la même question.

 L’horloge Pong, inutile donc indispensable

 6 janvier 2009  Bricolage  Aucun commentaire

Nombreux sont ceux qui connaissent déjà le concept de l’horloge Pong. Pour les néophytes, il s’agit d’un écran sur lequel se déroule une partie de Pong entièrement contrôlée par ordinateur (COM Vs COM). L’heure est symbolisée par le score. Évidemment, chaque minute, une des deux raquettes perd la balle et le score – donc l’heure – est incrémenté.

pong_clock

Souvenirs, souvenirs...

Mi-décembre, mon agrégateur RSS adoré me renvoya sur le blog Invaded de Misteriddler pour y découvrir une horloge Pong home made et très bien réalisée. Cela me donna l’envie de me lancer moi aussi dans ce projet un peu fou – et complètement inutile il faut bien l’avouer – en vue de décorer ma future gameroom.

Quelques jours plus tard, les vacances de Noël m’ont permis de descendre faire de la spéléologie dans les fonds de tiroirs du garage. Résultat : 2 laptops sont présent. Cool. Aucun d’eux ne fonctionne. Pas cool.

Il va donc falloir remettre le projet à plus tard, mais je garde assurément l’idée sous le coude.

En attendant, j’ai toujours mon horloge Minitel, synchronisée par NTP, qui passe toute seule à l’heure d’été :) Pour les curieux, le montage est détaillé ici et le « graphisme » est géré par le programme open source figlet.

horloge-minitel

La console du serveur a d'autres utilités...

 Et la lumière fut !

 5 août 2008  Bricolage, Projet Arcade  Aucun commentaire

Réalisation d’un spot commandé par un détecteur de rythme

Après le tuto concernant le son, voici celui dédié à la lumière.

Partant de l’observation d’une borne Dance Dance Revolution, j’ai remarqué la présence de deux panneaux lumineux en façade qui s’illuminent de manière synchronisée avec la musique. C’est en général du plus bel effet. C’est pour cette raison que j’ai voulu en adapter le principe sur la mamecab.

Le concept est le suivant :
En termes de contraintes fonctionnelles, j’ai voulu que des panneaux lumineux s’éclairent quand le joueur est sur Stepmania ou quand la mamecab fait office de jukebox (Winamp). Mais j’ai également désiré qu’ils ne s’éclairent pas en mode arcade, pour ne pas gêner un joueur en plein combo dans Street Fighter II. Une activation conditionnelle donc, et si possible pas commandée manuellement pour ne pas ajouter un énième switch en façade, celle-ci est déjà bien assez trouée.
En termes de contraintes techniques, il faut que les lumières s’éclairent en rythme avec la musique bien sûr. Il faut aussi que l’éclairage soit assuré en basse tension (plusieurs diodes haute luminosité en façade) comme en haute tension (lampes 40W/60W colorées derrière le marquee). N’étant ni électronicien ni expert en traitement du signal, il fallait aussi une solution assez souple et dont la majeure partie pouvait être traitée informatiquement.

J’en suis donc arrivé à la conclusion que je devais réaliser le montage suivant, en 3 parties :

  • La partie logicielle analyse le son à la volée, détecte l’application lancée, détecte le rythme de la musique s’il y en a, et commande l’éclairage par le biais du port série.
  • La partie matérielle est composée du dispositif de commande, qui va décider ou non de faire passer le courant en haute comme en basse tension, en fonction de ce qui transite sur le port série.
  • L’autre moitié de la partie matérielle est l’éclairage lui-même, composé de lampes et de diodes.

Disclaimer :
Les conseils de cet article sont donnés SANS AUCUNE GARANTIE. Le montage électronique présenté comporte des éléments haute tension. Toutes les précautions d’usages doivent être prises avant manipulation.  Une exposition au courant électrique est susceptible de provoquer des conséquences pathologiques graves pouvant entrainer la mort.

Les joyeusetés étant dites, continuons. Nous allons commencer par la partie hardware, la partie software n’étant pas finalisée au moment de l’écriture de cet article.

Inutile de dire que l’on ne va pas brancher directement la sortie du port série sur le 220V. Il est nécessaire dans ce montage d’isoler proprement la partie commande de la partie puissance. La clé de ce concept réside dans l’utilisation du MOC3043, un pilote de triac avec couplage opto-électrique et isolation à hauteur de 7500V.

Un schéma valant mieux qu’un long discours, je ne m’attarderai pas sur les composants qui entourent le MOC3043, ils sont sensiblement les mêmes d’un site web à l’autre.

Schéma complet du montage, fait avec amour et patience

Un commentaire rapide pour ceux à qui ça ne parle pas du premier coup d’oeil :

  • En bas à gauche la connexion au port série, qui requiert l’activation de RTS pour commander la lumière.
  • En haut à gauche la partie basse tension, destinée à accueillir une ou plusieurs DEL. Cette partie du montage est commandée par un banal transistor.
  • A droite la partie haute tension, commandée par le MOC. On n’oublie pas de mettre un fusible et un switch approprié pour des raisons de sécurité.

On achète ensuite les composants à son magasin d’électronique préféré. La somme investie était de l’ordre de la quinzaine d’euros, le plus cher étant… le boitier en plastique (presque la moitié du prix).

Les composants nécessaires au montage

On s’active ensuite au fer à souder. On obtient un résultat très beau côté composants…

Résultat côté composants...

… et moins beau côté pistes. J’ai un peu merdé dans la zone basse tension, car j’ai voulu ajouter quelques résistances avec un jumper pour ne pas avoir à brancher autre chose que la charge. Ce n’est pas du plus bel effet, mais la partie haute tension est nickel, et c’est le principal.

Résultat côté pistes...

On glisse le tout dans le boitier. Ci dessous une photo avec tous les connecteurs annexes, avant de visser l’ensemble.

Positionnement dans le boitier

Impératif : avant de brancher le montage, on vérifie au testeur que toutes les liaisons sont correctes entre les pistes, et qu’il n’y a pas de contact entre les pistes qui ne doivent pas être connectées. Puis on fait un double-check. Puis on fait un triple-check. On ne rigole pas avec ça, c.f. disclaimer pour tous ceux qui n’ont pas compris.

Pour tester le fonctionnement de la partie haute tension sans la connecter au port série, on peut dans un premier temps envoyer la commande avec un petit montage sur pile. Pour la petite anecdote, je l’ai fait en prenant soin de m’équiper de bottes et de gants en caoutchouc. Oui, j’avais l’air con, mais je suis toujours en vie.

Si tout va bien jusque là, le plus dur est passé. On peut connecter le montage sur la sortie série du PC. J’ai effectué le test suivant avec la partie software partiellement finalisée (elle détecte les basses mais pas forcément le rythme) et avec la première lampe trouvée au garage. C’est un halogène, ce qui explique probablement l’extinction progressive sur la vidéo.

Image de prévisualisation YouTube

Résultat parfaitement conforme à mes attentes. Il ne reste plus qu’à améliorer le software.

La suite dès que possible !