Dans le cadre de la Coupe de Robotique EUROBOT, j'ai eu l'infini bonheur d'installer une carte Soekris (www.soekris.com) sous Linux. Celle-ci a la particularité de n'avoir ni clavier, ni écran, dispose d'un port IDE 2.5"", d'un port CF (Compact Flash), de 2 liaisons RS232 et de 3 ports Ethernet. Elle est basée sur une géode 266 Mhz et 128 Mo de RAM. Ce PC a été conçu pour faire un firewall ou un tout petit serveur. Pour environ 300€, c'est une bonne petite machine qui ne consomme quasiment pas d'énergie.

Le PC en question est le cœur du robot engagé à l'ex coupe e=m6 par mon équipe « Astromech » (équipe d'anciens participants). J'ai décidé de coder l'IA en Perl et en utilisant le module Inline::C qui permet d'inclure du code C directement dans le code Perl. Le code C est compilé à la volée (mais avec un cache) donc gcc est nécessaire.

Habituellement, les PC embarqués sont sous-employés, l'utilisation d'un langage haut niveau permet de gagner du temps de développement sans que cela ne gène trop les performances globales. L'utilisation du module Inline::C permet d'optimiser les parties jugées trop lentes et d'inclure du code d'autres personnes pour certains algorithmes calculatoires.

L'intérêt de Perl est donc de pouvoir être modifié sur la machine sans nécessité de recompilation. J'ai donc aussi besoin de SSHD et d’Emacs.

Il n'y a donc que 2 moyens pour installer un Linux : créer une image disque sur une autre machine, copier l'image sur la carte Compact Flash, puis booter dessus. Je peux aussi installer un Linux sur un disque dur externe depuis une machine de travail et recopier le tout sur la Compact Flash avec le Soekris.

La dernière méthode est sans doute la plus rapide. Mais je voulais avoir une installation sur un disque dur en lecture seule pour minimiser tout problème de corruption disque en cas de coupure de courant. De plus, la mémoire flash ne supporte qu'un nombre limité d'écriture. Le programme d'IA reste lui sur une partition read/write pour être plus facilement mis à jour.

Les outils disponibles

J'ai donc fait la tournée des distributions livecd, read-only par nature. http://www.damnsmalllinux.org/ propose une distribution de 50 Mo qui fait papa maman mais pour la bureautique. Rajouter les programmes manquants n'est pas chose si aisée que ça, même si un système de paquetages existe.

Xwoof se veut la même chose, mais qui tient sur une disquette (le site web semble mort).

Faire sa propre distribution LFS est aussi possible. le hardware étant fixe, cela simplifie beaucoup de choses. Mais tout compiler jusqu'à Perl et gcc me parait hors de porter sans parler d'Emacs. J'imagine la looongue liste de dépendance de tous ces programmes.

A Solution Linux, on me parle de « DFS Build » qui est un constructeur de Live CD pour Debian. « Debix » semble faire la même chose.

http://www.emdebian.org/ semble encore plus prometteur : il s'agit d'une nouvelle distribution basée sur Debian dont la cible est les systèmes embarqués avec leurs contraintes de mémoire et d'installation. Malheureusement, cela n'est encore qu'un « work in progress ».

Buildroot est un ensemble de scripts pour construire une chaîne de cross compilation basée sur µClibc avec le système de base qui va avec. C'est intéressant, mais je n'ai pas de contraintes si fortes en place. Je dispose d'une Compact Flash de 256 Mo.

Comme je n'ai jamais trop voulu m'embêter avec les installations, j'utilise une Mandrake... Euh pardon, une mandriva, dont le gestionnaire de paquetage (urpmi) dispose d'une fonction d'installation dans un chroot. Je peux donc construire une distribution à recopier ensuite sur une Compact Flash.

Problème : la distribution serait toujours sur une partition autorisant l’écriture. La rendre read-only nécessite de jouer sur /var/ et fait intervenir beaucoup de programmes qui me dépassent et je n'ai pas le temps de creuser.

Mklivecd (http://livecd.berlios.de/) est décrit dans un des derniers numéros de Linux Magazine. Il s'agit d'un script qui récupère une installation Mandrake pour en faire un livecd (j'utilise la version CVS).

Je dispose ainsi de la distribution avec son système de paquetages que je connais, un moyen de la rendre read-only, mais il faut encore faire booter un disque dur avec une image prévue pour CD-ROM.

Comme le but final est d'avoir un Linux qui tourne dans le Soekris pour la semaine dernière (ou était-ce le mois précédent ?), je ne cherche donc pas à faire un script de génération d'image de Mandrake pour disque dur. Il ne s'agit pas de faire dans la finesse et la beauté, mais d'y aller le plus vite possible.

La création du root file system

1er étape, se créer un chroot avec une Mandrake toute fraîche dedans. Les commandes suivantes préparent un répertoire à recevoir le chroot. Je ne comprends toujours pas pourquoi MandrakeSoft n'inclut pas tout ça dans urpmi. A noter aussi que les outils Mandrake n'aiment pas les paths relatifs et les erreurs retournées dans ce cas ne sont pas clair du tout.

mkdir -p ./mandrake_chroot/var/lib/rpm &&

rpm --initdb --root `pwd`/mandrake_chroot/

Je peux maintenant lancer l'installation dans le chroot (encore en utilisant un path complet).

urpmi --excludedocs --root `pwd`/mandrake_chroot basesystem \

tar lilo vim-minimal rpm kernel-tmb-2.6.7-2.tmb.6mdk \

screen gcc perl-Inline openssh-server openssh-client wireless-tools \

mgetty udev mediacheck emacs-nox sudo curl locales-fr \

perl-Parse-RecDescent perl-devel &&

J'ai directement mis tous les paquets qui m'intéressent et même un peu plus. J'ai précisé le kernel en dur pour être sûr de celui que j'utilise, pour que cela soit toujours le même et surtout pour éviter qu'il me pose la question.

Mes « médias » Mandrake pointent sur des serveurs Internet. C'est suffisant pour installer un logiciel de temps en temps. Mais quand on fait de telles installations, on recommence souvent. Et c'est très long ! (Je ne suis qu'en ADSL 512/16) Le plus simple est de se créer un « média » local qui contienne les paquets utilisés.

On récupère les URL des paquets :

.urpmq --source -d > ./media_local/paquet_url.txt

Puis on télécharge tout dans un répertoire. Il y en a pour 77Mo (allez prendre un café, discutez avec votre copine/copain. Si ! si ! La personne qui se demande comment vous faites pour passer autant de temps avec votre PC et qui boude sur le canapé,...) :

cd ./media_local/

cat paquet_url.txt | xargs -l wget

On crée son repository local (mini) sous utilisateur root (avec son path complet !) :

urpmi.addmedia mini file:/`pwd`/media_local/

Ensuite, on peut installer le chroot avec nos paquets locaux avec la commande semblable à la précédente :

urpmi --media mini --excludedocs --root `pwd`/mandrake_chroot basesystem \

tar lilo vim-minimal rpm kernel-tmb-2.6.7-2.tmb.6mdk \

screen gcc perl-Inline openssh-server openssh-client wireless-tools \

mgetty udev mediacheck emacs-nox sudo curl locales-fr

perl-Parse-RecDescent perl-devel &&

L'option --media permet de préciser l'endroit où aller chercher les paquets à installer.

Si on veut en rajouter dans le repository, il faut l'enlever (urpmi.removemedia) puis le reconstruire avec urpmi.addmedia. A ce stade, on dispose d'un système complet, on peut jouer avec, en faisant :

chroot ./mandrake_chroot/

On peut maintenant modifier des fichiers de configuration ou faire toutes sortes d'adaptations avant de transformer tout cela en image read-only.

Adaptation de la distribution

Pour pouvoir déboguer la distribution, il faut pouvoir voir la séquence de boot au travers du lien série (la cible n'ayant pas d'écran). Pour cela, il faut modifier le fichier ./mandrake_chroot/etc/inittab du chroot. Il faut remplacer :

1:2345:respawn:/sbin/mingetty tty1

par :

1:2345:respawn:/sbin/agetty -L 19200 ttyS0 ansi

Cela consiste à définir la première console (habituellement F1) comme étant un port TTY réel (le port com1). La commande suivante permet de faire le remplacement :

sed "s_1:2345:respawn:/sbin/mingetty tty1_1:2345:respawn:/sbin/agetty -L 19200 ttyS0 ansi_" ./mandrake_chroot/etc/inittab > tmp &&

cat tmp > ./mandrake_chroot/etc/inittab;

Il faut rajouter "ttyS0" dans ./mandrake_chroot/etc/securetty pour permettre la connexion de root par la console série.

echo "ttyS0" >> ./mandrake_chroot/etc/securetty

Dans le chroot, il faut aussi définir l'utilisateur (robot) qui utilisera le Soekris et mettre les mots de passe (qui seront figés).

chroot ./mandrake_chroot/

adduser robot

Malheureusement, passwd ne semble par marcher à ce stade. Est-ce la nécessité d'utiliser adduserdrake ? Est-ce à cause d'une configuration de PAM avancée ? ("passwd: User not known to the underlying authentication module ") Bref, je n'ai pas le temps de creuser et je ne crois pas trop à une attaque sur le robot : il ne sera pas en direct sur Internet. Par contre, utiliser la carte Wi-Fi embarquée serait problématique.

Je résous à la hache : il faut modifier ./mandrake_chroot/etc/passwd et virer les !! et ne laisser aucun caractère entre les 2 ":". Cela veut simplement dire qu'il n'y pas de mot de passe pour ces utilisateurs-là. L'intérêt de créer un utilisateur pour le programme d'IA est d’éviter qu'un bug puisse faire des choses bizarres dans les fichiers root.

Comme un souci n'arrive jamais seul, j'ai découvert que SSHD n'accepte pas les connexions sans mots de passe. Il faut donc modifier la configuration :

sed "s_#PermitEmptyPasswords no_PermitEmptyPasswords yes_" ./mandrake_chroot/etc/ssh/sshd_config > tmp;

cat tmp > ./mandrake_chroot/etc/ssh/sshd_config

Bon. A ce stade, un ssh sans mot de passe, surtout sur l'utilisateur root, semble ne pas servir à grand chose. L'avantage est d'avoir un shell distant et un transfert de fichier intégré. Avec le recul, telnetd et FTPD m'auraient suffi et m'auraient causé moins de soucis (problème de performance).

Pour pouvoir rajouter ensuite, d'autres appels de programmes sans devoir modifier la distribution read-only, on appelle un dernier script root dans le répertoire de l'utilisateur robot.

echo 'exec /home/robot/final_init dev/console 2>&1' >> ./mandrake_chroot/etc/rc.local

Ce script final_init m'a permis d'ajouter toutes les commandes qui ne marchaient pas « out of the box » comme par exemple, le chargement du driver de carte réseau et la configuration de l'adresse IP sans devoir refaire une image à chaque fois. Oui, cela n'est pas propre, mais ce n'est pas le but.

Création de l'ISO

mklivecd crée un fichier iso totalement inutile pour une image de disque dur. Il va falloir maintenant la transformer.

J'ai tout de même du modifier le script qui recherche et monte le CD-ROM pour remplacer le tout par des accès au disque. Le basesystem créé par mklivecd est minimaliste avec un gros fichier image utilisant le système Squashfs qui est un système de fichier compressé performant contenant la Mandrake montée ensuite par une interface loop.

Pour faire propre il aurait fallu modifier le programme mklivecd, puis refaire une install. Mais je n'ai pas voulu prendre le temps...

J'ai modifié directement le fichier /usr/share/mklivecd/linuxrc qui gère le démarrage avant de lancer les scripts de la MDK. C'est gruick ? Oui, je sais. En gros, je vire la détection du CD-ROM en commentant les lignes :

#findcdroms ""

#findcloop ""

Et ensuite, à la fin du fichier, je rajoute la gestion du disque dur (seules les lignes commençant par des « + », sont à ajouter (sans les « + » !)) :

+run(){

+echo $@

+$@

+}

+#extraction de ce qu'il faut pour monter /dev/hda :

+run insmod /lib/modules/2.6.7-2.tmb.6mdk/kernel/jbd.ko

+run insmod /lib/modules/2.6.7-2.tmb.6mdk/kernel/ext3.ko

+run insmod /lib/modules/2.6.7-2.tmb.6mdk/kernel/loop.ko

+run insmod /lib/modules/2.6.7-2.tmb.6mdk/kernel/zlib_inflate.ko

+run insmod /lib/modules/2.6.7-2.tmb.6mdk/kernel/squashfs.ko

+

+run mknod /dev/hda b 3 0

+run mknod /dev/hda1 b 3 1

+run mknod /dev/hda2 b 3 2

+

+run busybox ls /dev

+run busybox ls /initrd

+run busybox mount -r /dev/hda1 /initrd/cdrom

+run busybox mount -r -t squashfs -o loop /initrd/cdrom/livecd.sqfs $MNTLIVECD

+

+## fin

+

+#pour debug:

+#execshell

+

echo "--- Exiting LINUXRC ----------------"

exec /etc/rc.d/rc.sysinit dev/console 2>&1

exit 0

La modification permet de télécharger les modules nécessaires, de créer les devices correspondant au disque dur puis de monter l'image Squashfs là où le script de mklivecd s'attend à le trouver pour continuer le boot.

Le /usr/share/mklivecd/rc.sysinit doit aussi être modifié pour monter le /home. Ici, il s'agit d'une partition « à coté » de la partition read-only.

setupdir_cow "home" "fmask=666,dmask=777"

else

echo -n " Building /home structure: "

+ #cp -a $MNTLIVECD/home /

+ mkdir -p /home

+ mount /dev/hda2 /home/

fi

printok

set_progress

Le code à rajouter/modifier commence par les « + ».

Voici la commande qui va bien pour créer l'image :

mklivecd --bootopt console=ttyS0,19200n8 --noprompt --keyboard fr --resolution normal --looptype sqfs --kernel 2.6.7-2.tmb.6mdk --root ./mandrake_chroot mklivecd.iso

A ce stade, on dispose d'une image iso bootable. Si vous n'avez pas encore modifié les fichiers de démarrage utilisés par mklivecd, il est possible de tester l'image produite par cet outil dément qu'est Qemu.

qemu -nographic -boot d -cdrom mklivecd.iso

L'option -nographic permet de voir ce qui sort par le lien série. Cela permet à ce stade d'éviter d'user des CD à des fins de tests. N'oubliez pas que la console qui affiche les données système sortent maintenant uniquement par le lien série et non plus par l'écran où il ne se passe plus grand-chose. (d'où l'utilisation de -nographic)

La création de l'image disque

J'ai un bel iso mais impossible de trouver un moyen pour « transformer » ce fichier. Pas grave, ma hache est encore sortie.

Je me crée mon image disque. Avec une CF de 250 Mo, 140 Mo pour le système en ext3 doit être suffisant pour tout le monde. J'utilise l'ext3 pour avoir un système journalisé plus robuste que ext2. Il n'y a pas vraiment de raison de ne pas avoir utilisé Reiserfs.

rm -f astrolinux.img

dd if=/dev/zero of=astrolinux.img bs=1M count=140

yes | mkfs.ext3 astrolinux.img

Ensuite ? Je recopie le contenu de l'iso dans l'image disque. C'est moche. Je sais, j'ai honte.

mkdir -p ./iso

mount -o loop mklivecd.iso ./iso

mkdir -p ./result

mount -o loop astrolinux.img ./result

cp -rp ./iso/* ./result/

A ce stade, nous avons le contenu de l'iso dans astrolinux.img. Il faut maintenant installer le système de boot. mklivecd utilise isolinux pour rendre le CD-ROM bootable. Ce système est très courant dans les livecd. Il nécessite juste un fichier de configuration. Extlinux est le programme équivalent pour booter depuis une partition ext2/3 comme son nom l'indique.

Malheureusement, le boot avec Extlinux ne dépasse pas le stade de l'affichage de « Extlinux... ». La mailing list du projet ne m'a pas été d'un grand secours.

J'ai résolu le problème en utilisant LILO. LILO est très très (mais alors très très) stupide. Il croit toujours qu'on le lance de la machine qui devra booter plus tard et a besoin d'un certain nombre de répertoires. On passe donc son temps à le tromper.

mkdir ./result/boot

mkdir ./result/etc

mkdir ./result/dev

cp -p ./script/lilo.conf ./result/etc/

umount ./result ./iso

rm -fr ./result ./iso

Mon lecteur de carte Compact Flash est vu comme un /dev/sdb1 d'où les 2 directives au début à adapter selon votre cas. La commande bios permet de dire de booter en fait sur le premier disque et root permet de dire que, en fait, cela sera le /dev/hda1 qu'il faut utiliser. J'ai recopié la ligne append générée par mklivcecd. On voit d'ailleurs l'utilisation de la console pour la sortie des messages de boot et le control de LILO. Le contenu de mon ./script/lilo.conf :

lba32

boot=/dev/sdb

disk=/dev/sdb

bios=0x80

root=/dev/hda1

delay=20

vga=normal

default=Linux

image=/isolinux/vmlinuz

label=Linux

initrd=/isolinux/initrd.gz

append="livecd=livecd initrd=/isolinux/initrd.gz root=/dev/rd/3 devfs=nomount acpi=ht nomce keyb=fr con

sole=ttyS0,19200n8"

A ce stade, on a notre image de prête. Malheureusement, LILO ne peut pas être lancé sur l'image directement. Ce qui est vraiment gênant, c'est que l'on ne peut plus tester l'image avec Qemu. Il faudrait sans doute se tourner vers Grub qui est vraiment plus puissant.

On recopie l'image sur la Compact Flash. Celle-ci est partitionnée en 2. La première partition est /, la seconde /home. cfdisk /dev/sdb1 permet de faire cela simplement si votre Compact Flash apparaît sous sdb1.

dd if=astrolinux.img of=/dev/sdb1 bs=1M

LILO nécessite les fichiers spéciaux des disques du système hôte pour fonctionner.

mkdir -p ./CF

mount /dev/sdb1 ./CF

mknod ./CF/dev/sdb b 8 16

mknod ./CF/dev/sdb1 b 8 17

mknod ./CF/dev/sdb2 b 8 18

mknod ./CF/dev/hda b 3 0

mknod ./CF/dev/hda1 b 3 1

mknod ./CF/dev/hda2 b 3 2

mknod ./CF/dev/hda3 b 3 3

mknod ./CF/dev/hda5 b 3 5

mknod ./CF/dev/hda6 b 3 6

mknod ./CF/dev/hdb b 3 64

mknod ./CF/dev/hdb1 b 3 65

mknod ./CF/dev/hdb2 b 3 66

lilo -r ./CF &&

umount ./CF &&

rm -rf ./CF

Comme le /home de notre nouveau Linux utilise la deuxième partition, il ne faut pas oublier de recopier le contenu du répertoire ./mandrake_chroot/home/. Dans le cas contraire, notre utilisateur robot n'aurait pas de répertoire de travail (/home/robot).

yes | mkfs.ext3 /dev/sdb2

mkdir -p ./home

mount /dev/sdb2 ./home

cp -rp ./mandrake_chroot/home/* ./home/

umount /dev/sdb2

rm -r ./home

Il ne faut pas oublier de démonter proprement la CF avant de la retirer. Le débit est très faible vers la carte et la main est rendue au shell avant que les copies ne se terminent. Les données sont dans les caches disque. gkrellm peut servir à montrer le débit vers le disque (~3Mo en lecture, ~1.5Mo d'écriture). C'est le même problème qui peut arriver avec une clef USB.

La finition

Votre Compact Flash contient maintenant votre distribution toute fraîche. Il ne reste plus qu'à l'installer dans le lecteur CF du Soekris puis de brancher la bête. Il est d'ailleurs impressionnant de devoir chercher les leds pour savoir si elle est allumée. Il n'y a aucune pièce mécanique donc aucun bruit.

La séquence de boot est assez longue (1 minute 30). A la séquence classique, Mandrake se rajoute la séquence de mklivecd qui copie un certain nombre de répertoires en ramdisque. Je pensais prévoir un système de reprise en cas de reboot sauvage pendant un match mais cela aurait été bien trop de temps (un match dure 1 min 30).

Les commandes suivantes permettent de récupérer l'image sur disque pour la sauvegarder et surtout pour la tester avec Qemu.

dd if=/dev/sdb of=cf.img bs=5M

qemu cf.img

permet de voir ce qu'afficherait un écran, ici pas grand-chose, vu que la console est déroutée vers le port série.

qemu -nographic cf.img

démarre Qemu et retourne dans le shell la sortie qui va normalement vers le port série.

Minicom permet de surveiller le boot. Il s'agit d'un émulateur de terminal qui fonctionne avec les liens série. Faites attention au droit du fichier /dev/tty1 de votre machine de développement. Parfois, il faut configurer Minicom en root pour avoir le droit d'accéder au port série.

Pour l'instant, on peut interagir avec la machine uniquement au travers de la liaison TTY. Pour faire mieux, il faut configurer le réseau. Pour aller au plus vite, j'ai mis les commandes dans le fichier /home/robot/final_init. La méthode propre serait d'utiliser les outils/fichiers de configuration de la Mandrake et notamment le système de démarrage standard.

Pour cela, il faut pouvoir faire une configuration dans le chroot de la machine de développement, or beaucoup d'outils s'attendent à tourner sur la machine cible. Le processus de démarrage mis en place par mklivecd permet de détecter automatiquement une grande partie des périphériques. Malheureusement, ce n'est pas le cas pour le Soekris.

Le contenu de /home/robot/final_init suit :

#!/bin/bash

modprobe natsemi

ifconfig eth0 192.168.0.60

service sshd start

chmod o+rw /dev/ttyS1

sudo -u robot /home/robot/ia_launcher &

La première ligne permet de lancer le driver des cartes réseau, la deuxième de mettre une IP à la première interface Ethernet, la troisième de lancer le serveur ssh, la 4ième permet de rendre le deuxième port série accessible à tout le monde (je communique avec le reste du robot par là). La dernière ligne permet de lancer un autre script avec les droits de l'utilisateur robot.

Le script /home/robot/ia_launcher, comme son nom l'indique, permet de lancer l'IA du robot.

A l'utilisation

Ce GNU/Linux a donc tourné pendant des heures dans le robot. Durant les intensives séances de développement, malgré les coupures de courant, aucune corruption du système de fichier à déplorer. La machine n'a jamais planté non plus.

Le robot et le Soekris étaient directement reliés à 2 batteries 12 V (24 V donc) 7 ampères/heure. Cela nous donnait 8h d'autonomies. Pendant le développement, le temps d'utilisation des moteurs du robot est faible devant celui du PC. C'est la principale source de consommation d'énergie. On est loin ici des 3A demandés par les cartes EPIA.

Pour des raisons de débogage, l'IA du robot crachait beaucoup de logs, qui étaient censés être écrits sur un serveur NFS. Mais les faits ont voulu que ses logs soient finalement écrits sur la Compact Flash. J'ai eu très peur de la « brûler ». Une mémoire Flash n'aime pas être réécrite tout le temps. Et pourtant, je n'ai eu aucun souci, grâce sans doute à sa qualité.

Emacs à travers une liaison série n'est pas très utilisable. Et même en mode pur texte, cela n'est pas évident (pas de souris). J'ai pu apprécier l'utilité de la commande C-z qui permet de retourner sous le shell sans le fermer, car il faut bien le dire, le bestiau est long à démarrer sur une si petite machine (le premier admirateur de vi qui ricane, je l'abats à vue).

Au final, je codais sur une machine de développement et je transférais le code avec SCP.

Perl avait été choisi car, en général, le temps final CPU utilisé est proche de 1% sauf utilisation de traitement d'image. Le but était de gagner du temps de développement. Le développement était effectivement beaucoup plus rapide. Par contre, le Perl était vraiment lent. Cela a limité les performances du robot.

Le codage de l'IA ayant été commencé sur une machine de bureau, le problème a été vu tard. Je n'ai pas cherché à optimiser le code Perl. Je pense qu'il doit être possible d'optimiser en passant systématiquement les arrays et les hashs par référence.

Le code Perl a été écrit en Perl objet. Cela fait utiliser des gros hashs qui contiennent les données des objets. Si use strict; permet de détecter les variables mal écrites, cela n'est pas le cas pour des clefs qui n'existent pas. Perl renvoie bien un warning (« Attention utilisation d'une valeur non initialisé » ou un message approchant) mais mon affichage (mes logs) était très verbeux donc les messages étaient noyés dedans.

On peut vraiment perdre beaucoup de temps avec ce genre d'erreur (en effet, le codeur à 5h du mat' n'est plus très frais). Après quelques recherches (merci rgs !), le module Hash::Util fournit un moyen de verrouiller les clefs dans un hash (documentation dans perldoc Hash::Util). Ainsi, on peut empêcher de créer de nouvelles clefs et détecter facilement ce genre d'erreur.

D'un autre coté, je n'ai jamais eu le problème d'une IA qui plante. C'est toujours stressant d'avoir un robot qui part en live au bout de 30 s car le programme segfault ! Cela s'est vu notamment sur des robots utilisant des microcontrôleurs ayant un compilateur C pas toujours bien mature.

ssh a participé aussi au fait de ralentir l'IA. Les log étaient importants et le processus de chiffrement charge le petit Geode. Le ralentissement est d'autant plus gênant qu'il n'apparaît que lorsque l'on débogue le programme. L'utilisation de l'option de ssh -c blowfish a permis d'utiliser un algo de compression plus léger et de gagner quelques dizaines de millisecondes de cycles sur 180.

La conception de la distribution Astrolinux a été un des défis techniques relevés par notre équipe durant l'année pour participer à la compétition. Je remercie Michael Scherer (MISC) pour son aide sur urpmi à travers #mandrivafr du réseau IRC freenode.

J'encourage tout le monde à participer à cette énorme aventure qu'est une participation à Eurobot, tout en sachant bien qu'il s'agit d'un trou noir à temps libre !

<>

<><>Nicolas Boulay, Ingénieur conception en électronique numérique chez EADS Astrium Vélizy.

<>