Le robot se déplace !

27 avril 2014

D’après notre dossier "Projet", c’était notre objectif pour le début du mois d’avril. À trois jours du mois de mai, nous pouvons annoncer fièrement que notre robot se déplace.

Fin mars, nous avions déjà notre asservissement polaire de codé. Depuis nous avons pas mal travaillé sur notre code qui gère les consignes à base de points de passage et de points "but". Pour être plus précis, notre robot avance (et recule) en suivant des séries de points qui forment des courbes de Bézier.

Les courbes de Bézier présentent trois avantages :

1. Par construction, elles tiennent compte de l’orientation du robot au départ et à l’arrivée du trajet.
2. Elles sont faciles à construire, leurs équations ne sont pas liées au repère
3. C’est classe !

0 commentaire

Wifi et asservissement polaire

29 mars 2014

Voila deux mois que nous n’avions pas donné de nouvelles. Disons que notre robot nous occupait trop pour qu’on puisse écrire des articles.

Nous avons pas mal avancé sur la propulsion du robot. Chaque moteur est asservi en vitesse, la position du robot est estimée à partir du gyroscope (pour son orientation) et des codeurs des moteurs (pour l’avancement). Nous obtenons une position fiable tant que les roues ne glissent pas. Pour éviter les glissements, nous limitons les variations de consigne de vitesse en entrée de l’asservissement des moteurs. Pour atteindre la position souhaitée, nous avons eu la joie d’implémenter un asservissement polaire, tel que celui décrit par RCVA.

Ça semble bien marcher, mais comme nous n’avons pas bien fixé notre gyroscope, il nous faut délaisser la programmation au profit d’un peu de mécanique avant de valider tout ça.

Enfin, pour communiquer avec le robot lors de ses déplacements, nous avons configuré le Wi-Fi sur notre Raspberry Pi. Notre article détaille la configuration pour transformer un Raspberry Pi en point d’accès Wi-Fi.

Côté gyroscope, avec tout ce code qui a été rajouté, nous ne sommes plus capables de le lire toutes les 50 µs. Nous sommes tombés à 500 µs en espérant pouvoir à nouveau augmenter la fréquence de lecture une fois le reste du code terminé.

0 commentaire

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