La liaison série du Raspberry Pi

29 janvier 2014

Ayant du tripatouillé un peu pour faire marcher l’UART sur le Raspberry Pi, nous avons récupéré nos notes pour en faire un petit article disponible ici, sagement rangé dans notre rubrique Raspberry Pi.

0 commentaire

Gyroscope opérationnel !

27 janvier 2014

Nous avons eu un peu de mal, mais nous avons enfin un gyroscope opérationnel !

Nous récupérons une valeur toutes les 50 µs, ce qui est énorme comparé à notre précédent gyroscope. Nous n’étions qu’à 4 ms. Ceci nous permettra de garder un angle précis même lors de petits chocs !

Concernant le reste de la carte électronique, il reste encore un peu de travail. Nous avons passé beaucoup de temps sur les protocoles de communication. Ceci nous permet de déboguer plus facilement notre code. C’est ainsi que nous avons fini par comprendre que notre code était bon et que malgré la fiche technique de notre gyroscope (ADXRS453) il fallait le calibrer.

Un petit schéma de ce qui nous reste à faire :

Architecture électronique

Ça a l’air énorme, mais le gros du travail se trouve autour des moteurs de propulsion et des codeurs. Nous avions déjà codés la gestion des servomoteurs et des capteurs ultrason sur un microcontrôleur quasi-identique les années précédentes. Si tout se passe comme pour l’I2C, ajouter la gestion des capteurs et des servomoteurs devrait nous prendre une petite semaine.

Enfin dernier point qui nous cause du soucis : nous n’avons pas encore alimenté la partie puissance de notre carte. C’est à ce moment là que nous risquons de causer de dégâts !

0 commentaire

Un petit pas en programmation

7 janvier 2014

Hier, notre très cher oscilloscope a décidé de grésiller, de produire une petite fumée grise et d’émettre une odeur assez particulière. C’est donc à regret que nous avons accepté sa lettre de démission...

Nous avons aussi initialisé notre environnement de développement pour notre PIC 18F4550. Notre objectif était d’établir une liaison série fiable entre le PIC et le Raspberry Pi. Ceci en plusieurs étapes. D’abord, nous espérions recevoir une trame du PIC sur le Raspberry Pi puis dans un second temps arriver à lire une trame du Raspberry sur le PIC.

À notre premier essai le Raspberry Pi ne reçoit aucune donnée. La commande suivante n’affiche rien :

cat /dev/ttyAMA0

Ayant repris un code utilisé l’année précédente pour le PIC, nous accusons le Raspberry Pi. À raison, la liaison est accaparée par le noyau, voir ça par ici.

Après la modification, nous ne recevons toujours rien. Nous regardons du coté du PIC et nous nous apercevons que nous notre horloge est mal configuré ! Il faut toujours commencer par faire clignoter une DEL pour tester l’horloge du microcontrôleur ! Mais nous avons oublié de relier ce PIC à une DEL sur la carte.

Le Raspberry Pi reçoit enfin la trame correctement. Nous utilisons le mode debug du PIC pour vérifier qu’il reçoit correctement les données du Raspberry Pi. Le PIC reçoit ce qu’il émet à deux modification près : les caractères de fin de ligne sont modifiés et la chaine est préfixée par un caractère étrange (généralement 0xF8).

C’est la configuration du port série qui nous renvoie nos entrées, on peut le désactiver avec stty. Pour connaitre la configuration actuelle :

$ stty -F /dev/ttyAMA0 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Vous êtes heureux, vous ouvrez un autre terminal pour lire le manuel et comprendre tout ces paramètres :

man stty

Tous les paramètres echo sont liés au renvoi des chaines en entrée. Les préfixer d’un "-" permet de les annuler. Nous utilisons :

sudo stty -F /dev/ttyAMA0 115200 cs8 -cstopb -onlcr -echo -echoe -echok -opost

Nous supprimons ainsi l’écho intempestif, mais nos trames envoyées avec :

echo -e -n "Ceci est test\x00" > /dev/ttyAMA0

présentent toujours un caractère de trop en début de trame.

Il s’agit d’un bug du Raspberry Pi, rapport n° 148. À chaque ouverture du port série, le Raspberry Pi émet un caractère. Ce caractère peut varier, il n’est pas question de créer une bidouille dans le code du PIC pour le supprimer. La solution consiste à garder ouvert la liaison. En C, un simple fopen ferait l’affaire. En bash, il existe une solution simple qui consiste à ouvrir le port, à l’affecter à un descripteur de fichier (9 dans notre exemple) et à ne pas fermer ce descripteur de fichier :

$ exec 9> /dev/ttyAMA0

Et voila ! Notre liaison Raspberry Pi <=> Pic 18F est fonctionnelle !

Il nous reste un dernier soucis que nous n’avons pas résolu. Nous n’arrivons pas à programmer le PIC lorsque celui-ci est relié au Raspberry Pi. Nous supposons que c’est parce que nous avons relié le RESET du PIC à une broche GPIO du Raspberry Pi. Cette broche à probablement une protection contre les surtensions et nous empêche d’obtenir les 13V requis pour programmer le PIC. Mais ce sera probablement l’objet d’un autre billet.

0 commentaire

Connexion !

17 décembre 2013

Auparavant, nous utilisions un "bootloader [1]" USB. Mais ce système présente certains inconvénients dont celui de nécessiter un vrai programmateur de microcontrôleur pour programmer le bootloader.

Comme nous passons à une nouvelle famille de puce, notre ancien programmateur (soudé à la main) n’est plus compatible. Nous avons donc acheté le matériel nécessaire et prévoyons d’adapter nos codes.

Ce soir, premiers essais avec le Pickit 3 et MplabX. C’est particulièrement frustrant de prendre du temps pour retrouver nos marques, mais nous espérons que ceci sera payant.

Programmation de la carte 2014

Une soirée pour allumer 3 DEL, nous avons vu mieux. Mais nous inaugurons aussi notre nouvelle carte !

1 commentaire

Testez 5 fois !

12 décembre 2013

Lorsque j’étais au club robotique de mon école, nos robots ne marchaient pas. Lorsque par hasard, l’un de nos essais marchait nous considérions cela comme suffisant et nous espérions avoir de la chance lors de l’homologation. Nous avons vécu de nombreux échecs formateurs puis, avec Poivron Robotique, j’ai essayé de faire des robots qui marchent.

Mais qu’est-ce qu’un robot qui marchent ? Il est toujours possible de se retrouver dans un cas où une défaillance imprévisible bloque le robot. Nous ne cherchons pas non plus à réaliser un robot parfait. Il est clair que les tests unitaires des actionneurs doivent marcher à tout les coups. Mais lorsqu’on en vient à tester la stratégie complète, de nombreux facteurs interviennent tels que l’éclairage du terrain, la position exacte de départ du robot ou les perturbations dans les ultrasons. De notre côté, nous tenons à nous assurer que notre robot fonctionne parfaitement au moins une fois sur deux.

La probabilité qu’une action, qui marche une fois sur deux, fonctionne 5 fois de suite avec succès est de 3%. Si nous faisons marcher notre robot 5 fois de suite avec succès, nous avons alors 97% de chance qu’il fonctionne plus d’une fois sur deux.

Bref, tant que vous n’arrivez pas à faire fonctionner votre truc avec succès 5 fois de suite, remettez-vous à l’ouvrage !

0 commentaire