Depuis le temps que j’en parlais, voici quelques nouvelles de Robert ! Qui se porte à merveille, sauf qu’il a bien des soucis d’adhérence sur pas mal de sols (carrelage, moquette, …) Pas de chance, je n’ai que de la moquette et du carrelage chez moi

Robert - Premier prototype

Donc, comme vous pouvez le voir sur la photo, il est un peu … chevelu ! Disons qu’il porte bien son titre de prototype. Les cartes sont reliées à l’arrache pour l’instant, ça lui donne un certain cachet Bref, mes petites cartes sont enfin installées dessus. La carte fox (carte mère du robot) communique avec la carte Arduino (chargée des capteurs ultrasons) qui remonte les informations de distance. La carte Sabertooth, entre les moteurs, est quant à elle chargée de contrôler ces derniers. J’ai écrit un programme très basique (à l’occasion de Caprica 2010) qui donne son comportement au robot. Mais il s’avère qu’il n’est pas du tout au point. Mais grâce à lui je dispose au moins d’une première démonstration que voici :

J’ai profité de ce mercredi 11 novembre pour bidouiller un peu la fox

J’ai donc pu terminer mes fonctions d’entrée/sortie. J’en ai profité pour mettre un makefile et mettre une archive en ligne où vous pouvez télécharger mon code. Je pense que cela mérite quelques petites finitions, mais le code fonctionne bien chez moi en tout cas. Par défaut, mon main, dans led.c fait clignoter la ligne 9 du port J7. Pour faire clignoter la led rouge il suffira de changer PB0 par PC7. Je mettrai donc à jour l’archive tar.gz au fur et à mesure de mes modifications.

Capteur ultrason

Je me suis également essayé à l’intégration de mes capteurs ultrasons SRF05, mais je me heurte encore à plusieurs problèmes. J’arrive à émettre mes salves d’ultrasons sans soucis, mais c’est la récupération des données de distance qui est un peu plus compliquée. Le capteur renvoie un signal à l’état haut, de la durée correspondant à la distance mesurée. Avec un changement d’échelle on obtient alors la distance en cm. Seul soucis, les signaux à manipuler ici sont de l’ordre de la microsecondes, et je n’arrive pas encore à estimer la durée reçue. J’utilise la fonction clock() pour travailler sur une différence de cycles d’horloge, fonction qui semble être la plus précise en C. Cependant, la durée de l’état haut relevé grâce à cette fonction me retourne 0 en permanence… Soit la fonction est trop précise, soit quelque chose ne va pas dans mon implémentation. Je vais essayer de me renseigner s’il n’existe pas mieux que la fonction clock() pour mesurer des durées de l’ordre de la dizaine/centaine de microsecondes. J’espère donc pouvoir utiliser rapidement ces capteurs, ils sont à la base du repérage de Robert.

Après quelques longues recherches ce week-end, j’ai enfin réussi à trouver le (un) moyen d’utiliser les entrées / sorties de la foxboard G20. J’ai initialement orienté mes recherches sur la documentation du kernel qui pointait sur gpio.h. Cependant d’après le site d’avrfreaks où j’ai trouvé mon bonheur, gpio.h aurait tout simplement disparu des noyaux Atmel au profit de sysfs. Ainsi, la gestion I/O se fait par le biais de simples fichiers. J’ai donc commencé à me faire une petite bibliohèque de fonctions pour manipuler les fichiers sysfs. Ce n’est que le début, ça n’est pas encore complètement au point, mais quoi qu’il en soit, le code suivant fait déjà clignotter la LED rouge de la fox.

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
struct S_GPIO_LINE {
    char id_number[4];
    int direction;
    int value;
};
typedef struct S_GPIO_LINE S_GPIO_LINE;
 
int load_gpio_line( S_GPIO_LINE *ps_line, char id_number[4], int i_direction )
{
    FILE *p_gpio_line;
 
    /* Exporting GPIO line */
    if ((p_gpio_line = fopen("/sys/class/gpio/export", "ab")) == NULL)
    {
        printf("Cannot open export file.\n");
        exit(1);
    }
    rewind(p_gpio_line);
    strcpy(ps_line->id_number, id_number);
    fwrite(&ps_line->id_number, sizeof(char), 2, p_gpio_line); 
    fclose(p_gpio_line);
 
    set_gpio_direction(ps_line, i_direction);
 
    return 0;
}
 
int set_gpio_direction( S_GPIO_LINE *ps_line, int i_direction )
{
    FILE *p_gpio_direction;
    char gpio_direction[35];
    char c_direction[4];
 
    sprintf(gpio_direction, "/sys/class/gpio/gpio%s/direction", ps_line->id_number);
 
    /* Setting line direction */ 
    if ((p_gpio_direction = fopen(gpio_direction, "rb+")) == NULL)
    {
        printf("Cannot open direction file.\n");
        exit(1);
    }
    rewind(p_gpio_direction);
    if( i_direction ) {
        strcpy(c_direction,"in");
        ps_line->direction = 1;
    }
    else{
        strcpy(c_direction,"out");
        ps_line->direction = 0;
    }
    fwrite(&c_direction, sizeof(char), 3, p_gpio_direction);
    fclose(p_gpio_direction);
 
    return 0;
}
 
 
int set_gpio_line(S_GPIO_LINE *ps_line, int value )
{
    FILE *p_gpio_value;
    char gpio_value[35];
    char c_value[2];
 
    if( ps_line->direction == 0 ) {
        sprintf(gpio_value, "/sys/class/gpio/gpio%s/value", ps_line->id_number);
 
        /* Setting value */
        if ((p_gpio_value = fopen(gpio_value, "rb+")) == NULL)
        {
            printf("Cannot open value file.\n");
            exit(1);
        }
        rewind(p_gpio_value);
        sprintf(c_value, "%d", value);
        ps_line->value = value;
        fwrite(&c_value, sizeof(char), 1, p_gpio_value);
        fclose(p_gpio_value);
    }
    else{
        printf("Wrong access.\n");
        exit(1);
    }
    return 0;
}
 
int main() {
 
    FILE *fp;
    S_GPIO_LINE s_led7;
 
    load_gpio_line(&s_led7, "103", 0);
 
    while(1)
    {
        set_gpio_line(&s_led7, 1);    
        usleep(100000);
        set_gpio_line(&s_led7, 0);
        usleep(100000);
    }
 
    return 0;
}

Prochaine étape, la lecture de données

Carte fox G20

Me voici enfin en la possession de la Fox Board G20 de chez Acmesystems. Je tiens à remercier le constructeur, qui m’a envoyé gratuitement une combo box, ayant pris connaissance de mes projets
J’ai donc reçu un sympathique colis d’Italie par Fedex mardi dernier. Et je viens juste de trouver le temps de tester la carte.

Tout d’abord, l’adresse ip par défaut de la G20 est 192.168.1.92, un simple

ifconfig eth0 192.168.1.111 netmask 255.255.255.0

suffit alors à configurer la connexion au PC. J’essaierai plus tard de brancher la carte directement à ma Neufbox pour ne pas avoir à configurer ma connexion à chaque fois.

On boote alors sur un Gentoo fraichement installée. Ça change pas mal de l’ancienne Fox, mais n’ayant pas de projet précis sous la main pour l’instant, il ne m’est pas possible de tester ses performances. Je songe certainement développer prochainement un driver linux pour ma caméra série ! Je testerai donc petit à petit ce qu’elle a dans le ventre et commence dès à présent à rédiger un nouveau tutoriel pour faire suite à mon introduction à la carte fox. Bref, plus d’infos et de découvertes au prochain épisode !

Fox Board G20

La tant attendue carte fox G20 est enfin disponible sur le magasin en ligne d’Acmesystems.

On peut également remarquer que le nouveau wiki qui lui est dédié se remplit progressivement de contenu fort intéressant. On y apprend notamment que la compilation sous Gentoo se fera directement sur la FOX Board G20 et ne nécessite plus de SDK, la chaîne de compilation étant présente sur le système. On y trouve aussi un certain nombre d’info pour installer le SDK d’OpenWRT et travailler avec.

Bref, j’ai vraiment hâte de pouvoir la tester, héhé !

J’imagine que nous devrions la voir bientôt apparaître chez Lextronic, revendeur français d’Acmesystems.

Carte Fox

Il y a un moment que je l’avais annoncé. Voici enfin mon tutoriel d’introduction à la carte fox. Il s’agit de mon premier article pour le site Developpez.com. J’en profite pour en faire part ici également. Manque de chance, c’est après avoir terminé ce tutoriel qu’Acmesystems en a profité pour faire la promo de sa nouvelle carte G20. Quoi qu’il en soit, je pense que ce document pourra aider des gens même si la FOX LX832 a trouvé son successeur. De plus, les deux cartes ne semblent pas radicalement différentes et bon nombre d’informations seront bonnes à prendre pour la G20. De toute façon je songe à me procurer la nouvelle carte FOX à sa sortie en septembre pour rédiger un nouveau tutoriel.

N’hésitez pas à me faire part d’éventuelles remarques.

Voilà quelques temps que la société Acmesystems avait annoncé la sortie de sa nouvelle carte embarquée Fox G20. A vrai dire ils avaient surtout annoncé qu’ils arrêteraient la production de carte Fox à la date du 31 Juillet 2010, ce qui laissait pas mal de marge. Et j’ai eu la surprise aujourd’hui de découvrir qu’ils comptaient mettre en vente leur nouveau modèle G20 dès le mois de septembre. Aucune information n’était disponible encore la semaine dernière. Donc c’est une bonne surprise, d’autant plus que nous avons maintenant les caractéristiques de la G20.

Carte Fox G20

Basée sur la même carte que la Foxboard LX, la G20 embarque un module CPU, basé sur un processeur ARM9 de chez Atmel.

Au niveau des changements:

• On gagne 300Mz par rapport à l’ancien modèle, ce qui nous amène à 400MHz.
• La mémoire est doublée, passant de 32 à 64Mo de SDRAM.
• Les ports USB1 passent en USB2
• La consommation est presque divisée par 4, passant de 220mA à 60mA, ce qui nous amène à 0.3W ! Fantastique !

Au niveau des nouveautés:

• On gagne un port USB client
• Un lecteur microSD a été installé, qui nous permet de lire des cartes jusqu’à 4Go
• Une pile est maintenant présente sur la carte, ce qui nous permettra enfin de gérer correctement la composante temporelle sans ajout de circuit annexe.
• On gagne également 2 sorties PWM !
• Mais aussi un port série pour gérer un écran oLED 4Dsystem
• Ainsi que des entrées analogique avec convertisseur analogique numérique intégré !
• Et un port JTAG

Le tout fonctionnant sur l’OS Linux OpenWRT. Il semblerait également que l’on puisse installer simplement d’autres distrib telles que Gentoo et KaeilOS.

Acmesystems annonce la disponibilité de la G20 dès le 21 Septembre chez ses différents revendeurs (dont Lextronic en France). Le prix restant inchangé (139€ HT) par rapport au modèle actuel. Bref tout cela pour dire que nous avons là une superbe petite carte, qui va se retrouver très bientôt dans mes petits robots.

Pour plus d’informations, un nouveau Wiki a été mis en place pour accueillir la nouvelle documentation de la Fox G20.

Je vais donc surveiller de près ce petit wiki qui est en cours de remplissage depuis la semaine dernière.

Cartes Fox et Arduino

Je viens enfin de recevoir ma commande Lextronic ! Dans le colis, les deux cartes italiennes tant attendes : la Fox et l’Arduino. Je ne dépends plus des cartes de l’UTT pour développer mon robot maintenant. Et après de nombreuses recherches de doc, il s’avère que la carte Arduino est vraiment géniale en terme de possibilités. J’en dirai un peu plus sur cette nouvelle carte dès que je maîtriserai son fonctionnement. Sinon, je suis en train de rédiger des tutoriels sur la carte fox. Je compte déjà réaliser un tutoriel d’introduction à la carte pour idéalement décliner en plusieurs tutoriels par la suite du style :

• Communiquer avec la carte Fox – Bluetooth, Série, Wifi
• Utilisation et mise en place d’un serveur vidéo sur la carte Fox
• Utilisation des entrées sorties
• Mise en place d’une Interface GSM/GPRS – envoi de SMS
• Mise en place d’un serveur web (CGI/PHP)
• …

Suite au prochain épisode

Carte Fox

J’ai été amené à travailler dans le cadre de mes études sur un petit projet de développement d’une Interface GSM sur un système Linux embarqué. Ayant découvert la puissance du système, j’ai pensé vous faire part de mes découvertes sur l’utilisation de cette carte.

Dans mon cas le principe était de créer un système autonome d’envoi de SMS aux étudiants de mon école. L’idée étant de pouvoir envoyer les résultats des examens directement par SMS aux étudiants, ce qui est ma foi fort sympatique

Le Matériel

Alors, tout d’abord : Carte FOX Késako !? Il s’agit d’un système embarqué à bas coût utilisant le système d’exploitation Linux. La carte est dotée d’un processeur AXIS à 100MHz et de 32 MB de RAM, de connectiques USB, Ethernet, d’un port série console ainsi que 40 pins pouvant être reliées à plusieurs BUS de données. Elle permet de développer en bon nombre de langages : C, C++, PHP, PYTHON, Shell, … et permet des connections HTTP, FTP, SSH et TELNET. De petite taille et faible consommation électrique (1 W) est idéale pour mettre en place rapidement des projets de type embarqué.

Modem GSM

Le modem GSM utilisé ici est un modem de la marque Telit. Il est relié à la carte FOX par l’intermédiaire d’une carte d’extension. La carte FOX peut communiquer avec le modem par l’intermédiaire du port série /dev/ttyS2. Une simple utilisation de carte SIM classique permet de se connecter au réseau GSM. Il est possible de trouver cette carte seule sur le site d’ACME SYSTEMS à 176 € frais de port tout compris. Si l’on ajoute le kit GPRS cela monte jusqu’à 626 €, ce qui commence déjà à faire beaucoup. Je pense qu’une solution plus abordable serait de relier la carte basique à un téléphone portable pour communiquer en série étant donné que dans notre cas nous n’avons pas besoin de tous les éléments de la carte d’extension.

Les modems GSM utilisent un protocole de commandes appelées « commandes AT ». Chaque constructeur fait un peu ce qu’il veut avec ses normes, ce qui fait que chaque modem est plus ou moins différent et qu’il faut se référer à la doc du constructeur. Ces commandes AT sont donc envoyées via le port série pour soumettre différentes commandes au modem. On peut notamment dans notre cas manipuler et envoyer des SMS par l’intermédiaire de celles-ci.

Environnement de développement

La compilation d’un programme en C sur la carte fox nécessite un compilateur croisé permettant de compiler le code C pour les processeurs AXIS. La compilation directe sur la carte n’étant pas possible, il faut par conséquent utiliser un SDK pour compiler le programme. J’ai travaillé avec le SDK Axis fourni pour la carte fox.

Avant toute chose il faut se rendre dans le dossier du SDK (~/devboard-R2_01 pour ma part) et y taper la commande suivante afin d’initialiser l’environnement de développement.

. init_env

Ensuite, il faut choisir le compilateur AXIS

make cris-axis-linux-gnu

On doit alors créer un Makefile pour notre programme. Voici celui que j’ai créé :

AXIS_USABLE_LIBS=UCLIBC GLIBC
include $(AXIS_TOP_DIR)/tools/build/Rules.axis
PROGS = sms
INSTDIR= $(prefix)/mnt/flash
INSTMODE= 0755
INSTOWNER= root
INSTGROUP= root
OBJS = main.o atcommand.o modem.o
all: $(PROGS)
$(PROGS): $(OBJS)
$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
scp sms root@fox01:/mnt/flash/tx
clean:
rm -f *.o
rm -f sms

Il n’y a alors plus qu’à faire un make pour compiler le programme et à l’envoyer sur la carte en FTP ou SCP. Ayant dû compiler à de très nombreuses reprises mon programme, j’ai rajouté l’envoi du fichier dans le makefile via la commande scp. Les fichiers utilisateurs sont déposés sur la carte Flash dans le répertoire /mnt/flash. Attention toutefois, car la mémoire flash EPROM est limitée en nombre d’écritures. Il vaut mieux tant que possible éviter d’écrire dans cette mémoire régulièrement. Privilégier la RAM (dossier /var par exemple) plutôt que sur la carte flash. Seul soucis, la carte se réinitialise à chaque redémarrage, par conséquent les tests peuvent être faits en RAM et une fois que l’application compilée est stable il est préférable de la déposer sur la carte flash afin de ne pas perdre le programme à chaque reboot.

La connexion à la carte fox se fait en telnet (ou ssh) simplement à l’aide de la commande suivante grâce à un simple telnet

telnet adresse_ip_de_la_fox

Développement du programme

Utilisation des commandes AT

Le modem se commande directement grâce aux commandes AT. Ces commandes AT suivent une certaine syntaxe et nécessitent une mise en forme particulière pour leur envoi sur le modem. Ce dernier reconnaît plusieurs caractères de contrôle :

<CR> : Caractère de retour chariot : Sa valeur ASCII en décimal est fixée à 13 par défaut. (et peut être changée grâce au paramètre AT S3) Sa valeur hexadécimale quant à elle est 0x0D.

<LF> : Caractère d’interligne : Sa valeur ASCII en décimal est fixée à 10 par défaut

<CTRL+Z> : Combinaison des touches CTRL et Z. Sa valeur hexa est 0x1A

Ces caractères sont demandés et utilisés par le modem pour identifier les commandes AT. Chacune d’entre-elles utilise ces caractères de contrôle plus ou moins différemment. Voici un aperçu des différentes commandes que j’ai utilisées avec leurs caractères de contrôle.

ATE0<CR>
Cette commande permet de désactiver la commande écho (ATE1 la réactive). Cela demande donc au modem de ne pas répéter systématiquement les commandes qui lui sont envoyées.

AT+CMGF=1<CR>

Cette commande permet de régler le format de message pour l’envoi de SMS. Par défaut, le modem est en mode PDU (AT+CMGF=0). C’est-à-dire que l’envoi de message se fait en hexadécimal. AT+CMGF=1 permet de passer en mode texte, ce qui simplifie les manipulations de SMS.

AT+CMGS= »06XXXXXXXX »<CR>

Cette commande permet de commencer la rédaction d’un SMS. On précise en argument le numéro de téléphone choisi. En retour on obtient le caractère d’invite de commande « > » qui nous invite à rentrer le texte du SMS.

Texte du SMS<CTRL+Z><CR>
Cette fin de commande permet alors de préciser le texte et de valider l’envoi du SMS par un CTRL+Z et un retour chariot.

Il est important de noter que l’envoi de la commande AT d’envoi de SMS se fait en 2 parties et pas en un coup. (j’ai testé pendant plusieurs semaines… ça ne marche pas ^^)

Le modem répond à ces commandes par des messages de retour. Ces derniers indiquent si celles-ci ont été exécutées avec succès ou non. La plupart de ces réponses sont entourées des caractères <CR><LF> Il y a toutefois des exceptions, notamment pour AT+CMGS qui renvoie +CMGS: <mr> ou +CMS ERROR: <err> Mais dans la plupart des cas les retours sont rapportés de la manière suivante :
<CR><LF>OK<CR><LF>
<CR><LF>ERROR<CR><LF>
<CR><LF>…<CR><LF>

Ces commandes AT doivent être transmises au modem par le port série /dev/ttyS2. Il existe plusieurs façons de communiquer sur le port série :

Termnetd (http://foxlx.acmesystems.it/?id=69)

Il s’agit d’un processus permettant de relier un port TCP/IP à un port série de manière transparente. Une fois que le deamon est lancé sur la carte fox, il est possible de se connecter depuis l’extérieur grâce à la commande telnet adress_ip_fox 7000. Le port 7000 (choisi dans la config de termnetd) redirige directement sur le port série et il est alors possible de rentrer manuellement des commandes AT et de voir leur comportement direct sur le modem. Ce programme est utile pour comprendre le fonctionnement des commandes AT.

Script Chat (http://linux.about.com/od/commands/l/blcmdl8_chat.htm)
Il est possible d’utiliser la commande UNIX chat permettant de dialoguer de manière automatisée avec le modem.

/usr/sbin/chat -V -s -f  > /dev/ttyS2 < /dev/ttyS2 2>

La réponse du modem est alors enregistrée dans le fichier de résultat choisi.

Programme en C
Il est également possible de dialoguer avec le modem via un programme C. Le dialogue se fait alors en écrivant et en lisant sur /dev/ttyS2. La prise en main est beaucoup plus complexe que les 2 précédentes méthodes, mais permet une totale maitrise du modem.

Développement en C

Le code pour envoyer un SMS n’est pas bien compliqué, mon but n’est pas là de copier/coller intégralement mon code, mais plutôt d’expliquer les grandes lignes son fonctionnement et de vous donner envie de bidouiller une carte fox ^^

L’idée est donc d’initialiser tout d’abord la connexion série à l’aide de Termios. La documentation sur le site du constructeur regorge d’informations et propose du code tout fait pour gérer la connexion série. Une fois la configuration réalisée (c’est très rapide à réaliser), il n’y a plus qu’à faire un write sur /dev/ttyS2

char command1[50];
char command2[50];
sprintf(command1, "AT+CMGS="%s"x0D", number);
sprintf(command2, "%sx1Ax0D", text);
write (tty_fd, command1, strlen(command1));
sleep(1); // attend la réponse du modem afin d'envoyer la seconde partie
write(tty_fd,command2,strlen(command2));

Et le SMS est envoyé ! Après libre à vous de rajouter à la suite une lecture de la réponse du modem (gentil petit read). Dès lors il est possible de se faire une petite fonction d’envoi de SMS à partir d’arguments tels que le numéro de téléphone et le texte du message. J’en ai profité pour me rajouter un système de logs et de manipulation du modem (redémarrage, arrêt). Je me suis créé une interface web en bash (scripts cgi) et par simples appels de notre programme C il est alors possible de se construire une application métier complexe. On a plus qu’à brancher notre carte fox sur le réseau et celle-ci peut envoyer des SMS à distance de manière assistée grâce à des formulaires web !

Préparation de la carte FOX

Dernier point de précision: au démarrage, le modem n’est pas allumé ni configuré. Il faut par conséquent créer un script de démarrage à déposer dans /etc/init.d/boottime . Voici le script que j’ai utilisé:

#!/bin/sh
# démarrage du modem
setbits -p b -b 7 -s 1
# Lancement de termnetd (pour les tests)
/mnt/flash/termnetd
# Initialisation série du modem (mon petit programme d’initialisation de la connexion série)
/mnt/flash/tx/sms -init
sleep 20
# Initialisation AT du modem
/usr/sbin/chat -V -s -f /mnt/flash/tx/scripts/scriptAT.chat >
/dev/ttyS2 < /dev/ttyS2 2> /mnt/flash/tx/scripts/scriptAT_result.txt
# Ecriture des logs (pour le fun ^^)
echo “`date` : MODEM start” >> /mnt/flash/tx/log/fox.log

On commence par allumer le modem, on initialise la connexion série avec le programme en C puis attend 20 secondes que le modem soit identifié sur le réseau. Le temps choisi est totalement arbitraire. Cela semble fonctionner correctement avec cette période, mais idéalement il serait intéressant d’interroger le modem pour déterminer s’il est bien connecté au réseau. Ensuite on exécute un script chat que voici :

ABORT BUSY
ABORT 'NO CARRIER'
ABORT ERROR
'' AT
OK ATZ
OK 'ATE0'
OK 'AT+CMGF=1'
OK ''

Ce dernier permet de désactiver l’écho afin de ne pas recevoir mes commandes en double, et permet d’activer le mode texte pour l’envoi de SMS. Par défaut l’envoi de SMS se fait en mode PDU (sous forme hexadécimale), ce qui est bien plus compliqué à utiliser. Une fois ce script exécuté, le modem est prêt à être utilisé. On peut rajouter un log à la fin pour identifier le démarrage du modem.

La carte fox est une carte embarqué assez simple à prendre en main, les utilisations sont assez illimités. Le rêve de tout bidouilleur !
Je songe à m’en commander une très bientôt, je ne peux pas résister à tant de potentiel de bidouille.

A suivre : Comment connecter la carte fox au réseau GPRS pour pouvoir aller sur le net et envoyer des mail

Voilà des années que je rêve de créer mon propre robot, j’ai enfin franchi le pas ! Je développe, depuis Février dernier et avec un autre étudiant, un robot wifi commandé par wiimote doté d’une caméra 360° pour retransmettre ce que voit le robot dans les moindres recoins. Nous utilisons une carte fox pour le coeur du robot et une carte SSC-32 pour le contrôle des servomoteurs. Le tout relié en wifi à un PC débarqué qui s’occupe de l’envoi des commandes au robot. Une manette de wii étant reliée au PC en bluetooth pour commander le robot. Je profite donc de ce premier article pour présenter un peu ce projet, qui sera j’espère, le premier de tout une lignée.

J’avais la possibilité de travailler sur un projet libre sur les systèmes embarqués dans le cadre de mes études. J’ai sauté sur l’occasion pour développer le robot wifi de mes rêves. Et révélation ! Ce n’est pas aussi dur que l’on pourrait imaginer.

Notre ami le robot

Au départ nous pensions utiliser un pc portable, lui mettre des roues et en faire un robot autonome. Nous avons réalisé :

• qu’un pc tel quel n’a pas d’entrée / sorties utilisables. Il faut se concocter une carte électronique pour gérer tout ça depuis l’usb et ça revient à prendre un marteau piqueur pour écraser une mouche finalement.
• qu’il est mieux de dissocier l’électronique logique de celle de puissance. Donc l’alimentation des servos doit se faire à part.

Par conséquent, nous avons abandonné l’idée du robot-pc et sommes passés à la carte fox, que nous connaissons déjà bien et qui bénéficie d’une multitude de ports d’entrée sortie Nettement plus intéressant pour un robot embarqué.

Nous étions initialement partis sur un robot à moteurs brushless (moteurs d’avions) pour la direction. La première étape a consisté à produire un signal PWM (signal carré servant à faire marcher les moteurs). Comme de gros débutants, nous avons essayé de produire un PWM depuis la carte fox. Premier échec, la fréquence de la carte fox ne nous permettait pas de descendre en dessous de 1 seconde de sleep pour générer notre signal PWM. Ce qui était fort embêtant, vu que la période du signal recherché est de l’ordre des millisecondes. Nous avons feinté et avons travaillé directement avec les cycles d’horloge. Miracle, cela a très bien fonctionné. Nous avions notre moteur qui démarrait comme on l’entendait… sauf que malins comme nous étions nous n’avions pas pensé qu’en lançant d’autres processus le programme ne pouvait plus fonctionner. Tout notre travail était donc réduit à néant.

Qu’à cela ne tienne, nous sommes passé au développement sur PIC18 pour gérer N signaux PWM en communiquant en série avec la carte fox. Malgré de nombreuses tentatives infructueuses, nous n’avons pas réussi à obtenir une communication série stable entre le PC et le PIC. Au grés de nos recherches sur Internet, nous sommes tombés sur la carte SSC-32 que l’on peut voir juste en dessous sur la photo.

Intérieur du robot avec une vue directe sur la carte SSC-32

Cette petite carte (pour les fainéants) sort jusqu’à 32 PWM et peut communiquer avec un PC en série par commandes ASCII. Il n’y a qu’à l’alimenter. Déjà beaucoup plus simple ! Nous sommes passés également aux servomoteurs au passage, laissant tomber les moteurs brushless, plus complexes à utiliser et beaucoup plus chers. Mais ce n’est que partie remise

Quand nous avons pu faire bouger notre premier servo, nous nous sommes attelés au client serveur entre la fox et le pc débarqué (un eeepc). Dans l’absolu rien de bien complexe, il s’agit d’un client/serveur basique en C qui envoie les commandes à la fox qui à son tour dialogue avec la SSC-32. Le plus ajouté étant la wiimote, que nous avons choisie pour commander notre robot. Après avoir luté pour compiler la librairie libwiimote nous avons réussi à transmettre les infos de la manette, du PC à la fox. Miracle ! Notre robot fonctionne

Je vous passe les photos de notre premier prototype en carton ! Nous nous sommes créé un chassis un peu plus digne en lego et avons installé tout notre bazar. Hormis le fait que les câbles (série et Ethernet) font 3m de long (on cherche des câbles beaucoup plus courts) et qu’il est encore alimenté par fils, le robot se déplace sans problème et bouge sa caméra.

J’oubliais ! Nous avons opté, bourrins que nous sommes, pour un routeur wifi branché en Ethernet à la carte fox. Il s’est avéré que la transmission du flux vidéo depuis le serveur vidéo de la fox descendait à moins d’une image par seconde lorsque nous utilisions une clé wifi usb … assez embêtant. Pas de problèmes, nous avons carrément embarqué le routeur. Maintenant, il s’avère que certains routeurs peuvent carrément être utilisés comme systèmes embarqués avec un noyau linux. Donc à terme, si l’on souhaite optimiser, il faudra trouver une solution et virer soit la fox, soit le routeur pour ne pas avoir 2 fois le même appareil.

Donc actuellement nous travaillons sur l’autonomie du robot, c’est à dire la mise en place de batteries pour alimenter tout ça. Nous pensons peut être également nous procurer une FONERA 2.0 pour remplacer le gros routeur. Elle ne consomme que 5 V, comme la fox, ce qui nous facilite la tâche et est carrément moins encombrante. Ensuite il va falloir résoudre un certain nombre de bugs du robot, qui a la fâcheuse habitude de recevoir des commandes fantômes et donc à faire NIMPORTE QUOI. Cela semble venir de mon code ^^ donc nous ne sommes pas perdus. L’étape suivante sera sans doute de se faire une interface sur le pc serveur débarqué et d’essayer de faire quelques bidouilles en traitement d’images pour que le robot repère un peu son entourage.

Voilà pour aujourd’hui. La suite au prochain épisode !

N’hésitez pas à venir réagir à cet article.