J’avais longuement expliqué dans cet article les étapes de fabrication d’un câble parallèle pour relier le robot Youpi à un PC standard.

Aujourd’hui je vais comme promis diffuser les quelques lignes de code permettant de tester l’ensemble des moteurs. Le programme est grandement inspiré de celui que l’on peut trouver sur le site du BTS-IRIS de Niort.

C’est un programme développé à la va-vite en C. Il pourra servir de base pour tous ceux qui comme moi souhaitent vérifier que tous les moteurs sont en bon état de fonctionnement.

Le code

robotest.c

/*
Youpi Robot Test program
------------------------

Author: AlphaK - www.alphak.net
Revision: 2010-07-16

This program has to be run as root
or with sufficient credentials (suid...)
*/

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/io.h>

// Change this to your parallel port
#define LPT 0x378

// Defines the byte type
typedef unsigned char byte;

// Defines the time between each instruction
int tempo = 2000;

/*
This functions writes a byte to the parallel port
Do not use any other way to do it as the robot needs to pause
between each instruction.
*/
void writelpt(byte b) {
	outb(b, LPT);
	usleep(tempo);
}

/*
This is the main function
*/
int main() {

	//Variables
	int i,j;
	int steps = 600;

	//Welcome message
	printf("*** YOUPI ROBOT TEST PROGRAM ***\n");

	//Tries to access parallel port
	if(ioperm(LPT, 1, 1) != 0) {
		perror("ioperm");
		return 1;
	}

	//Initializes the robot
	printf(" * Initialization\n");
	writelpt(0x47);
	writelpt(0x00);

	//Orders earch motor to rotate
	for(j=0; j<6; j++) {
		printf(" * Test of motor %d\n", j);

		//...with the correct tempo value
		tempo = (j == 0) ? 2000:1500;

		//...into one direction
		writelpt(0x80);
		writelpt(0x00);
		for(i=0; i<steps; i++) {
			writelpt(0x40+j);
			writelpt(0x00+j);
		}

		//...into the opposite direction
		writelpt(0xBF);
		writelpt(0x3F);
		for(i=0; i<steps; i++) {
			writelpt(0x40+j);
			writelpt(0x00+j);
		}
	}

	return 0;
}

Et le Makefile qui va avec :

CC=gcc
CFLAGS=-W -Wall -O

all: robotest

robotest: robotest.c
	$(CC) $(CFLAGS) -o $@ $<

clean:
	rm robotest

Quelques explications

Le manuel indique une vitesse de rotation maximale de 40°/s pour tous les moteurs, avec une résolution maximale de 0.03° par 1/2 pas. Chaque 1/2 pas est effectué grâce à l’envoi de 2 instructions par le port parallèle. Pour faire avancer le robot à cette vitesse maximale, il est nécessaire d’espacer chaque instruction d’un temps T en secondes, calculé ci-dessous :

Il faut donc espacer chaque instruction de 1500 µs, ce qui explique les 1500 à la ligne 27 du code. Descendre en dessous de cette limite est susceptible de provoquer des catastrophes inconnues, donc si vous essayez, cela sera à vos risques et périls. Note : comme me l’a fait remarquer cosmos dans les commentaires, pour le moteur de la base ayant une résolution de 0.04° par 1/2 pas, ces espacements doivent monter à 2000µs selon cette même formule.

Bugs connus

Avec un sommeil de 1500 µs entre chaque instruction, le programme devrait théoriquement être terminé en approximativement 2+6*(2+600*2)*2*0.0015 = 22 secondes, en négligeant le temps nécessaires aux autres instructions. Hors j’obtiens en moyenne un temps d’exécution à 58 secondes.

Ce phénomène est expliqué en partie par le paragraphe suivant, tiré de la page man 3 de usleep :

La période de sommeil peut être allongée par  la  charge  système, par le temps passé à traiter l’appel de fonction, ou par la granularité des temporisations système.

En résumé, lors de mon test, la vitesse de rotation de chaque moteur n’est pour le moment pas optimale. J’avais fait d’autres essais en réduisant significativement cette temporisation à quelques µs, ou en utilisant nanosleep afin d’avoir une granularité plus fine, mais le temps d’exécution total n’est jamais descendu en dessous de ces 58 secondes. Je ne sais pas encore comment optimiser cette vitesse, cela fait appel à des notions d’architecture système et de programmation temps réel qui me manquent à l’heure actuelle. Dans tous les cas, même si la vitesse est à l’heure actuelle bridée, le programme est néanmoins capable de démontrer le fonctionnement correct de chaque moteur.

Informations complémentaires

J’en profite pour placer un rappel : au lieu de me contacter personnellement pour me demander de l’aide à propos de ce robot, merci d’effectuer cette démarche en laissant un commentaire sur ce site afin que les questions et réponses profitent à tout le monde.

NB : vous pourrez maintenant trouver en un seul clic tous les articles de ce site relatifs au robot Youpi grâce au tag Youpi.

Mise à jour du 18/04/2015

J’ai de bonnes raisons de penser que mon calcul de temporisation dont la formule est exposée ci dessus est faux. Mes nouveaux calculs indiquent que les instructions devraient être séparées de 375 µs (respectivement 500 µs pour le moteur de la base) au lieu des 1500 µs (respectivement 2000 µs). Si cela est exact, les vitesses d’exécution de robotest et de Youba pourraient être améliorées jusqu’à x4 ! D’autre part on peut envisager l’utilisation de l’instruction nanosleep qui serait susceptible de réduire le temps de sommeil « inutile » (c.f. explications ci-dessus). Je n’ai malheureusement pas la possibilité de tester ces changements actuellement, ne disposant pas du Youpi à mon domicile. Cela pourra néanmoins s’arranger dans les prochaines semaines. Je vous ferai part des améliorations disponibles dès que cela sera possible.