Archives de catégorie : Robots

Générer un compilateur pour ARM

Pour développer des applications ou même pour générer un nouveau kernel pour ma carte CPU TS7200 ou TS7800, il me faut un compilateur. J’ai choisi pour le générer crosstool-ng.

crosstool-ng sert à construire des ToolChains. Les Toolchains (ou chaines de compilation) sont un élément essentiel dans un projet de développement logiciel. Elle servent à compiler, assembler et lier le code qui est en cours d’élaboration et qui sera exécuté par le processeur.

crosstool-ng

On télécharge crosstool-ng depuis : http://crosstool-ng.org/

J’ai choisi la dernière version lorsque au moment ou j’ai générer mon compilateur. C’était la version  http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.5.2.tar.bz2. La première chose à faire est d’extraire ce fichier dans un répertoire ou l’on veut générer l’outils.

$> cd ~/Projet
$> tar xjvz ~/Download/crosstool-ng-1.5.2.tar.bz2
$> cd crosstool-ng-1.5.2

Ensuite, on indique l’endroit ou l’on veut que crosstool-ng soit installé.

$> ./configure --prefix=/opt/crosstool-ng

Puis,

$> make
$> sudo make install

Enfin, on modifie le PATH pour avoir le répertoire « bin » dans la recherche des exécutables.
Le programme qui a été généré s’appelle {{ct-ng}}.

$> export PATH="${PATH}:/opt/crosstool-ng/bin"

Le compilateur arm-unknown-linux-gnueabi

J’utilise donc crosstool-ng pour générer un compilateur ARM pour ma cible TS7x00

Avec ct-ng, on a à disposition plusieurs exemples de configuration. On connait leur nom à l’aide de la commande

$> ct-ng help

On obtient une liste d’exemple:

  • alphaev56-unknown-linux-gnu
  • arm-cortex_a8-linux-gnueabi
  • arm-iphone-linux-gnueabi
  • arm-unknown-eabi
  • arm-unknown-elf
  • arm-unknown-linux-gnu
  • arm-unknown-linux-gnueabi
  • arm-unknown-linux-uclibc
  • arm-unknown-linux-uclibcgnueabi
  • armeb-unknown-eabi
  • armeb-unknown-linux-gnu
  • armeb-unknown-linux-gnueabi
  • armeb-unknown-linux-uclibc
  • armeb-unknown-linux-uclibcgnueabi
  • avr32-unknown-none
  • i586-geode-linux-uclibc
  • i686-nptl-linux-gnu
  • ia64-unknown-linux-gnu
  • mingw32,i686-none-linux-gnu
  • mips-ar2315-linux-gnu
  • mips-unknown-elf
  • mips-unknown-linux-uclibc
  • mipsel-unknown-linux-gnu
  • powerpc-405-linux-gnu
  • powerpc-860-linux-gnu
  • powerpc-e500v2-linux-gnuspe
  • powerpc-unknown-linux-gnu
  • powerpc-unknown-linux-uclibc
  • powerpc-unknown_nofpu-linux-gnu
  • powerpc64-unknown-linux-gnu
  • sh4-unknown-linux-gnu
  • x86_64-unknown-linux-gnu
  • x86_64-unknown-linux-uclibc

Je choisis arm-unknown-linux-gnueabi

$> ct-ng arm-unknown-linux-gnueabi

Puis je configure ct-ng

$> ct-ng menuconfig

Voici les modifications que j’ai fait dans la configuration standard.

  • Le répertoire ou je veux mettre le compilateur.
  • Le type d’architecture,
  • Le processeur
  • Non au debugger sur la cible
  • Pas de Fortran
  • Pas de Java
Paths and misc options  --->
 Prefix directory : {{/opt/x-toolx/${CT_TARGET} }}
 Target options  --->
 Architecture level : {{armv4t}}
 Emit assembly for CPU : {{arm920t}}
 Tune for CPU : {{arm920t}}
 C Compiler  --->
 [ ]  Fortran
 [ ] Java
 Debug facilities  --->
 [*] gdb  --->
 [ ]   Native gdb

Enfin, je lance la compilation du compilateur 😉

 $> ct-ng build

Et voila, on peut maintenant utiliser tous les outils se trouvant sous /opt/x-toolx/arm-unknown-linux-gnueabi/bin/ .On peut par exemple compiler le fichier lcdmesg.c comme ca :

/opt/x-toolx/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc lcdmesg.c -o lcdmesg

Carte de détection ultrason – MSU04

Les modules ultrasons permettent une mesure de distance. Le principe est la transmission d’un «paquet» d’ondes ultrasoniques,  et la mesure du temps après lequel l’écho revient sur le récepteur. La distance de l’objet qui a produit l’écho peut alors être mesuré en connaissant la vitesse de propagation du son dans le milieu et la durée de vol

  • Distance = (Vitesse de propagation . durée de vol)/2

Dans l’air, à pression standard et à 20°C, la vitesse du son est d’environ c=343m/s. Les ondes ultrasoniques, qui ont des fréquences typiques entre 40 et 180 kHz sont en générale produites par un transducer de type piezo.

Ce module nécessite une demande de mesure (impulsion >= 10us) sur l’entrée « Trigger ». Il fournit en réponse un signal « Echo-Pulse » dont la durée (100us < E <18ms) est proportionnelle à la distance séparant le radar d’une cible (3cm < D < 3m).

MSU04_Chronogram

Caractéristiques du module:

  • Alimentation : + 5 Vcc.
  • Consommation : 30 à 50 mA environ.
  • Angle de détection : 55 ° env.
  • Distance de détection : 3cm à 3m.
  • Dimensions : 43 x 20 x 17 mm.

MSU04_Dessous

La carte vision – CMUCAM 2 – Présentation

La carte CMUcam2 a été créés par l’institut de robotique  de l’université Carnegie Mellon University.

Elle est composée d’un micro-controlleur SX52 créé, à l’origine, par la la société [Ubicom->http://www.ubicom.com] et maintenu, pour les quelques pièces qu’il reste, par  la société [Parallax->http://www.parallax.com]. Le CPU est interfacé d’un coté, avec une caméra CMOS OV7620 de chez Omnivision. Il communique de l’autre coté avec l’hôte (type micro-contrôleur ou PC) au travers d’un port série RS-232 ou TTL (Les commandes disponibles sont détaillées dans la partie logiciel)

Manuel utilisateur au format PDF présente :

  • La description de l’ensemble des fonctionnalités
  • Le schéma électronique
  • La fonction et la syntaxe de chaque commande.

Les fonctions principales

  • Suivi d’un bloc de couleur jusqu’à 50 images/seconde (la fréquence dépend de la résolution de l’image et de la taille de la fenêtre)
  • Suivi de mouvement en utilisant la différenciation image à 26 trames par seconde
  • Trouve le barycentre des données de suivi
  • Fournit des données de couleur et de variance
  • Fournit l’histogramme jusqu’à 28 bins pour chaque canal de couleur
  • Processus Horizontalement Edge images filtrées
  • Transfert en temps réel de pixels traqués dans une image
  • Possibilité de fenêtrage de l’image
  • Régler les propriétés de l’image
  • Dump une image brute (un ou plusieurs canaux)
  • Résolution max 176 x 255
  • Le port série supporte les vitesses: 115200 57600 38400 19200 9600 4800 2400 1200
  • 5 sorties pour le contrôle de servomoteurs
  • Utilise automatiquement les servomoteurs de deux axes pour le suivi de la couleur
  • Sortie vidéo Noir et Blanc analogique (PAL ou NTSC)
  • Personnalisation de sortie de paquets
  • Mode basse consommation (Power down)
  • Traitement d’image multi-passe sur une image en mémoire.

Et en plus détaillé

  • Color Tracking. La CMUcam2 permet le pistage de couleurs. Un mode facultatif « bitmap line » transmet une image bitmap des pixels d’un suivi. Il y a aussi un « line mode » qui fournit des statistiques de pixels suivi pour chaque ligne, y compris les positions moyennes, minimum et maximum des pixels d’un suivi. Ceci est très utile pour le suivi en ligne. Il y a aussi un mode où l’interprétation des limites de suivi peut être inversée. Dans ce cas les pixels en dehors des limites de suivi sont considérés comme « bons ». Ceci est utile pour suivre un objet sur un fond homogène. Il est également utile pour détecter les bords quand le mode différenciation de pixels (décrit ci-dessous) est activé. L’option de filtrage du bruit permet le réglage de la quantité de filtrage pour les situations bruyantes.
  • Statistiques de l’image. La CMUcam2 permet le calcul de la moyenne et la variation des statistiques des zones d’image. Comme dans le CMUcam1, un mode en ligne facultative est mise en œuvre qui transmet la moyenne de chaque ligne de l’image. Il y a également un mode « line » amélioré, qui inclut en option des informations sur la variation ligne par ligne.
  • Détection de mouvement. Les commandes de détection de mouvement (par différence d’image) permettent de capturer une version basse résolution de l’image courante et de la comparer en permanence les nouvelles images. La CMUcam 2 indique si une partie de l’image change plus que ce qui a été spécifié. Ces paquets peuvent décrire le centre de gravité ou fournir une image bitmap des blocs d’images qui ont changé. Ce mode peut aussi être combinée avec la différenciation de pixel (décrit ci-dessous) pour faire une détection de mouvement plus robuste aux changements d’illumination.
  • Histogramme. Ces commandes peuvent être utilisées pour capturer un histogramme unidimensionnel d’un canal de couleur unique à une résolution jusqu’à 28 bins. L’histogramme fourni des informations utiles qui résume l’apparence d’une image. Le processeur hôte peut, à l’aide de cette information, détecter les obstacles, des objets spécifiques ou permettre sa localisation.
  • Fenêtrage. La CMUcam2 met en œuvre la capacité de limiter le traitement pour une petite région (sous-fenêtre) de l’image complète. Cette fonction est encore plus utile car elle peut être utilisée pour examiner de plus près ces sous-fenêtre d’une seule image stockée dans le frame buffer. Aussi, en réduisant la taille de la fenêtre verticale peut être utilisé pour augmenter considérablement les trames traitées par seconde, en réduisant considérablement le nombre de pixels qui doivent être traités par la CMUcam2.
  • Personnalisation des paquets de sortie. Ces commandes permettent à l’utilisateur de personnaliser chaque paquet généré par chaque commande pour retourner uniquement les valeurs nécessaires pour une application particulière. Ca réduit la quantité de données transmises et traitées par le processeur.
  • Différenciation de pixel. Dans ce mode optionnel de différenciation de pixel, les pixels sont pré-traités avant qu’ils ne soient répercutés sur le reste de la CMUcam2. Cette étape de pré-traitement envoie les nouvelles valeurs de pixels au reste du code. Ces valeurs sont la différence entre la valeur du pixel actuel et le précédent. C’est une opération très puissante qui peut être utilisé pour aider à la détection d’obstacles ou pour un suiveur de ligne.
  • Réduction de la fréquence d’échantillonnage. En mode d’échantillonnage, le logiciel de  CMUcam2 réduit la résolution de l’image de la caméra avant son traitement. L’avantage est qu’il y a beaucoup moins de pixels à traiter et à transmettre. Comme c’est fait par le logiciel, la réduction de la fréquence d’échantillonnage engendre seulement une très faible augmentation de la vitesse de traitement. Le principal avantage est de réduire la quantité de données transmises. Dans le cas d’un sous-échantillonnage dans une image fenêtrée, on peut facilement réduire la taille des données et donc de réduire le temps de transmission d’un facteur de 2 à 4 ou plus. De même, lorsque les modes en ligne bitmap sont utilisées, la taille de l’image bitmap peut être considérablement réduite, diminuant la quantité de données que le processeur doit recevoir et traiter.
  • Contrôle des servos. La CMUcam2 supporte jusqu’à cinq servos. Le code du contrôleur de servo est implémenté comme un processus de fond de sorte que le signal de sortie est toujours stable et il peut être utilisé comme n’importe quel contrôleur de servo. En outre, la CMUcam2 peut être configurée pour le contrôle automatique de panoramique et d’inclinaison. Dans ce mode, la CMUcam2 mettra à jour les positions de ces 2 servos à chaque fois qu’il est commandé pour suivre une couleur.
  • Power Saving. Entièrement nouveau dans le CMUcam2 sont les modes d’économie d’énergie. Dans certaines applications, la CMUcam2 n’est pas nécessaire pour traiter en permanence les données d’image. Dans ces cas, elle peut être commandé pour baisser sa consommation. Aucune commande de suivi ou d’asservissement qui se passera lorsque la CMUcam2 est dans un de ces modes. L’envoi d’une commande simple par la liaison série réveille la caméra en quelques millisecondes.

Le capteur CCD – OV7260

Le capteur video est un capteur CMOS Couleur et Noir et blanc.

OV7260-Dessus-180x131
capteur CCD OV7260 – Vue de dessus coté capteur
OV7260-Dessous-200x136
capteur CCD OV7260 – Vue de dessous coté connecteur

Les principales caractéristiques sont :

  • 326,688 pixels, 1/3” lens, VGA / QVGA format
  • Read out – progressive / Interlace
  • Data format – YCrCb 4:2:2, GRB 4:2:2, RGB Raw Data
  • 8/16 bit video data: CCIR601, CCIR656, ZV port
  • Video Timing – 525 line, 30 fps
  •  Wide dynamic range, anti-blooming, zero smearing
  •  SCCB (Serial Camera Control Bus) interface
  • Electronic exposure / Gain / white balance control
  • Image enhancement – brightness, contrast, gamma, saturation, sharpness, window.
  • Internal / external synchronization scheme
  • Frame exposure / line exposure option
  • Alimentation 5 Volts.

Le bootloader Redboot

Ayant changé ma carte TS7200 par une TS7800, je n’utilise pas redboot sur MyBot, mais je laisse cet article au cas ou quelqu’un en aurait besoin.

Redboot

Les cartes TS7200  de chez Technology System sont livrées avec Redboot déjà installé en flash.

La configuration par défaut de Redboot sur la carte TS7200 est la suivante, et on peut l’obtenir avec la commande fconfig -l :

RedBoot> fconfig -l
 Run script at boot: true
 Boot script:
 .. fis load vmlinux
 .. exec -c "console=ttyAM0,115200 root=/dev/mtdblock1
Boot script timeout (100ms resolution): 1
 Use BOOTP for network configuration: false
 Gateway IP address: 192.168.0.11
 Local IP address: 192.168.0.50
 Local IP address mask: 255.255.255.0
 Default server IP address: 192.168.0.11
 dns_ip: 192.168.0.11
 Network hardware address [MAC]: 0x00:0xD0:0x69:0x41:0xFC:0xA7
 GDB connection port: 9000
 Force console for special debug messages: false
 Network debug at boot time: false

Avec cette configuration, le kernel Linux vmlinux est chargé depuis la flash interne depuis le système de fichier de redboot. La liste de partition Redboot peut être obtenue avec la commande fis list, et le résultat est :

 RedBoot> fis list
 Name             FLASH addr  Mem addr    Length      Entry point
 (reserved)       0x60000000  0x60000000  0x00620000  0x00000000
 RedBoot          0x60620000  0x60620000  0x00040000  0x00000000
 vmlinux          0x60660000  0x00218000  0x000C0000  0x00218000
 RedBoot config   0x607C0000  0x607C0000  0x00001000  0x00000000
 FIS directory    0x607E0000  0x607E0000  0x00020000  0x00000000

La section (reserved) contient 3 blocs qui seront accessible par Linux à travers mtdblock0, mtdblock1 ou mtdblock2

Le mapping de ces 3 blocs est le suivant :

0x000000000000-0x000000020000 : "TS-BOOTROM"
0x000000020000-0x000000620000 : "RootFS"
0x000000620000-0x000000800000 : "Redboot"

Le File System fourni est donc bien en /dev/mtdblock1

Différentes solutions pour démarrer

Le Kernel et le File Sytem peut être localisé à plusieurs endroits. Pour choisir, il faut modifier la configuration de redboot avec la commande fconfig.

La première commande concerne le kernel.

Le Kernel en flash interne

 fis load vmlinux

Pour cela, il faut que le kernel soit dans la flash au bon endroit. La procédure est la suivante:

  • On regarde ou est localisé zImage
RedBoot> fis list
 Name              FLASH addr  Mem addr    Length      Entry point
 (reserved)        0x60000000  0x60000000  0x00620000  0x00000000
 RedBoot           0x60620000  0x60620000  0x00040000  0x00000000
 zImage            0x60660000  0x00218000  0x00140000  0x00218000
 RedBoot config    0x607C0000  0x607C0000  0x00001000  0x00000000
 FIS directory     0x607E0000  0x607E0000  0x00020000  0x00000000
  • On efface l’ancienne image
RedBoot> fis delete zImage
 Delete image 'zImage' - continue (y/n)? y
 ... Erase from 0x60660000-0x607a0000: ..........
 ... Erase from 0x607e0000-0x60800000: .
 ... Program from 0x01fe0000-0x02000000 at 0x607e0000: .
  • On charge zImage en RAM
RedBoot> load -v -r -b 0x00218000 -h 192.168.2.1 -m tftp zImage
 -
 Raw file loaded 0x00218000-0x003477d3, assumed entry at 0x00218000

Il faudra noté la taille du code transféré pour la commande suivante.

0x003477D3 - 0x00218000 = 0x0012F7D3
  • Enfin, on tranfère la zone de RAM en Flash

On peut le faire avec la commande suivante

fis create -b <mem_base> -l <image_length> [-s <data_length>] [-f <flash_addr>] [-e <entry_point>] [-r <ram_addr>] [-n] <name>

pour créer une section dans le File System de redboot.

RedBoot> fis create -b 0x00218000 -f 0x60660000 -l 0x0012f7d3 -r 0x00218000 -e 0x00218000 zImage
 ... Erase from 0x60660000-0x607a0000: ..........
 ... Program from 0x00218000-0x003477d3 at 0x60660000: ..........
 ... Erase from 0x607e0000-0x60800000: .
 ... Program from 0x01fe0000-0x02000000 at 0x607e0000: .

Le Kernel en Compact Flash

load -r -b 0×00218000 -m disk hda1:zImage
  • Le Kernel par tftp sur un PC
load -v -r -b 0x00218000 -h 192.168.2.1 -m tftp zImage

La seconde commande concerne le File System

  • File System en flash interne
exec -c "console=ttyAM0,115200 root=/dev/mtdblock1 init=/sbin/init rootdelay=2"
  • File System en Compact Flash
exec -c "console=ttyAM0,115200 root=/dev/sda1 init=/sbin/init rootdelay=2"
  • File System par NFS sur un PC
exec –c "console=ttyAM0,115200 root=/dev/nfs ip=192.168.2.2 nfsroot=192.168.2.1:/home/gil/Projets/ts7200/rootfs-debian init=/sbin/init rootdelay=2"

Le kernel Linux sur une carte TS7200

Au départ, je devais utiliser cette carte sur MyBot, c’est pour cela que j’ai commencer à regarder comment utiliser un kernel que j’avais recompilé. Par la suite, j’ai plutôt choisi la TS7800 pour ces capacités. Je laisse quand même cet article pour ceux que ca intéresse.

Kernel 2.6.29-ts

Les cartes TS7200 sont livrées avec un kernel 2.4.x. Au lieu d’utiliser les cartes comme ca, j’ai décidé qu’il serait mieux de pouvoir modifier le kernel et donc qu’il était nécessaire de le recompiler. Comme point de départ, j’ai choisi un 2.6.29 déja patché pour les cartes de chez Technologic System.

Il est assez dur à trouver, allez voir ici ftp://ftp.embeddedarm.com/application-kits/ts-wifibox/sources/tskernel-2.6.29-ts-src.tar.gz, il y est peut-être encore.

Kernel 2.6.29

Sinon on peut toujours récupérer le kernel 2.29 sur le git officiel et appliquer les patchs qui se trouve ici http://mcrapet.free.fr/linux-2.6.29.1-ts7200_matt-7.txt. Allez sur son site http://mcrapet.free.fr, on y trouve des patchs pour d’autres versions de kernel, à vous de voir.

 $> cd ~/Projet

On récupère l’arborescence complète Linux, attention c’est gros.

$> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
$> cd linux-git

On peut lister toutes les versions disponibles

$> git tag -l

On choisit notre 2.6.29

$> git checkout -f v2.6.29

Et on applique les patchs

$>  git apply ../linux-2.6.29.1-ts7200_matt-7/linux-2.6.29.1-ts7200_matt-7.patch

La compilation du Kernel

On extrait d’abord l’arborescence complète que l’on vient de télécharger (ou on va directement dans le répertoire dans le cas du kernel récupéré par git)

$> cd /home/gil/Projets/ts7200
$> tar xzvf /home/gil/Download/tskernel-2.6.29-ts-src.tar.gz
$> cd linux-2.6.29-ts

On recopie les configs que l’on a récupérées ici : http://mcrapet.free.fr/.

$> cp ../linux-2.6.29.1-ts7200_matt-7/configs/ts72* arch/arm/configs/.

Maintenant, la compilation proprement dit.

On efface tout pour repartir d’une configuration intacte.

$> make ARCH=arm CROSS_COMPILE=/opt/x-toolx/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi- distclean

On applique la config ts7200_eabi_full_defconfig.
Pour info, voici les configurations disponibles

 

  • ts7200_eabi_full: Parfait pour le développement, NFS/USB root support, NOR flash support.  ETH, CF (compact flash), I2C, SPI, GPIO, LED, RTC (ep93xx-rtc & rtc-m48t86), HID are embedded.
    • zImage is ~1.9mo. Note: NFS client est environ 200kb.
  • ts72xx_eabi_full: La même que « ts7200_eabi_full » mais sans les spécificités de la TS-7200.  No MTD (NOR flash) support, no PATA (compatch flash).
    • zImage is ~1.8mo.
  • ts7250_eabi_full: La même que « ts72xx_eabi_full » mais avec les spécificités de la TS-7250.  MTD (NAND flash) support.
    • zImage is ~1.8mo.
  • ts72xx_eabi_mid: La même que « ts72xx_eabi_full » mais USB/HID/SCSI sont mis en modules.   Disabled « CPU Frequency scaling » & « CPU idle PM support ».
    • zImage is ~1.6mo.
  • ts72xx_eabi_small: La même que « ts72xx_eabi_mid » mais I2C, SPI, LED, EXT2 & EXT3 mis en modules.
    • zImage is ~1.4mo.
 $> make ARCH=arm CROSS_COMPILE=/opt/x-toolx/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi- ts7200_eabi_full_defconfig

J’ai choisi la configuration mais je veux aussi un kernel le plus petit possible car il doit remplacer celui présent dans la flash embarquées sur la carte. La place disponible est 0x160000 Octets.

Voici un exemple, mon fichier .config, avec ça on obtient un kernel 2.6.29 de 0x12F7BC Octets.

$> make ARCH=arm CROSS_COMPILE=/opt/x-toolx/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi- menuconfig

Ensuite, on lance la compilation

$> make ARCH=arm CROSS_COMPILE=/opt/x-toolx/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-

Puis l’on recopie les modules dans l’arboresence correspondante de notre « File System ».

$> sudo make ARCH=arm CROSS_COMPILE=/opt/x-toolx/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi- INSTALL_MOD_PATH=/media/disk modules_install

Une fois que l’on a un kernel, on peut le recopier dans le répertoire accessible par tftp.

$> cp arch/arm/boot/zImage /tftpboot