DÉPARTEMENT DE GÉNIE ÉLECTRIQUE - Robofoot...

DÉPARTEMENT DE GÉNIE ÉLECTRIQUE

PROJET SPINOS: CONCEPTION ET CONTRÔLED’UN ROBOT MOBILE À VITESSES DIFFÉRENTIELLES

Rapport de projet de fin d’études soumiscomme condition partielle à l’obtention du

diplôme de baccalauréat en ingénierie.

Date: 5 décembre 2001

Présenté par:

Matricule:

Directeur de projet:

Julien Beaudry

Romano M. DeSantis

Projet de fin d’études: Conception et contrôle d’un robot mobile à vitesses différentielles Automne 2001

ÉCOLE POLYTECHNIQUE DE MONTRÉAL I

Sommaire

Ce rapport consiste en un résumé du travail accompli durant l’année 2000-2001 au sein du groupe SAE

Robotique de l’École Polytechnique en rapport avec un projet de robot mobile à vitesses différentielles, le

projet SpinoS. Ce projet est né en octobre 2000 dans le but premier de permettre au groupe d’améliorer ses

performances à la compétition française à laquelle il participe depuis quelques années, le Championnat

mondial de robotique mobile.

Une révision presque complète de la conception du robot, aux niveaux mécanique, électrique et informatique

est présentée dans un premier temps. La description du module de prise de décision du robot est ensuite

présentée. Ce module est crucial à une caractéristique intrinsèque de tout robot développé par le groupe SAE

Robotique, soit l’autonomie complète. Finalement, une révision du fonctionnement et des performances des

différents contrôleurs qui ont été développés par l’équipe du projet au cours de la dernière année est effectuée.

Ce robot possède une configuration à vitesses différentielles et il offre des performances mécaniques

intéressantes. Sa structure électronique offre une puissance de calcul amplement suffisante pour des

algorithmes haut niveau et elle favorise la modularité des éléments pour un ajout/retrait facile de capteurs sur

le robot. L'architecture informatique se veut simple et modulaire et elle utilise les concepts de programmation

par objets. De plus, cette architecture utilise un processus séquentiel de prise de décision pouvant utiliser de

multiples machines à états imbriquées. Ce processus assure l'entière autonomie du robot.

De nombreux objectifs initiaux ont été identifiés dès le début de ce projet. La grande majorité d’entre eux ont

été atteints et l’équipe SAE Robotique continuera à développer les éléments nécessaires pour atteindre la

totalité de ces objectifs.


Table des matières

Sommaire ................................................................................................................................. I

Table des matières .................................................................................................................. II

Remerciements ........................................................................................................................ IV

Liste des tableaux .................................................................................................................... V

Liste des figures ....................................................................................................................... VI

Liste des symboles ................................................................................................................... VIII

Introduction ............................................................................................................................. 1

Exposé du problème ................................................................................................................ 2Nécessité d’un nouveau robot ......................................................................................... 2Description de la compétition ......................................................................................... 2

Les objectifs du projet SpinoS ............................................................................................... 5

Processus de développement du projet ................................................................................. 6

Conception du robot ............................................................................................................... 8Conception mécanique .................................................................................................... 8Conception électrique et électronique ............................................................................. 26Conception informatique ................................................................................................. 46Module de prise de décision et de commande (cerveau) ................................................ 57

Modèle du robot ...................................................................................................................... 66Géométrie du robot .......................................................................................................... 66Modèle cinématique du robot .......................................................................................... 67Modèle dynamique du robot ........................................................................................... 68

Contrôleurs et simulation ....................................................................................................... 70Contrôleur en boucle ouverte .......................................................................................... 70Contrôleur en boucle fermée ........................................................................................... 74Contrôleur de suivi de ligne ............................................................................................ 78

Recommandations et améliorations possibles ...................................................................... 89

Conclusion ............................................................................................................................... 91

Bibliographie ........................................................................................................................... 93

ÉCOLE POLYTECHNIQUE DE MONTRÉAL II


Annexe 1: Contribution des membres .................................................................................. 94

Annexe 2: Résultats des essais d’asservisssement en vitesse ............................................... 95

Annexe 3: Spécifications du robot SpinoS ............................................................................ 100

Annexe 4: Coût de fabrication du robot SpinoS .................................................................. 101

Annexe 5: Code source ........................................................................................................... 102

Annexe 6: Schémas électroniques .......................................................................................... 103

Annexe 7: Plans mécaniques .................................................................................................. 104

Annexe 8: Fiches techniques .................................................................................................. 105

ÉCOLE POLYTECHNIQUE DE MONTRÉAL III


ÉCOLE POLYTECHNIQUE DE MONTRÉAL IV

Remerciements

J’aimerais tout d’abord remercier M. Romano M. DeSantis et M. Richard Hurteau pour m’avoir fourni un

support théorique et matériel essentiel au développement de ce projet. J’aimerais également remercier tout

particulièrement mes parents qui m’ont apporté un support moral indispensable durant mes longues semaines

de travail à l’École Polytechnique. Il est également l’occasion de remercier toute l’équipe SAE Robotique dans

un premier temps pour avoir accepté de se lancer dans ce projet de robot mobile et ensuite pour avoir fourni

les ressources nécessaires au développement du projet. Finalement, un remerciement spécial doit être attribué

à Philippe Abdel-Malek qui a accepté, sans même être membre de l’équipe et pour une récompense minime

face à la valeur du travail accompli, de participer à la conception mécanique et surtout d’effectuer la fabrication

d’un robot exceptionnel.


ÉCOLE POLYTECHNIQUE DE MONTRÉAL V

Liste des tableaux

Paramètres du robot pour le choix des moteurs ........................................................................ 14

Paramètres des moteurs du robot .............................................................................................. 14

Puissance demandée à l’alimentation +5V ............................................................................... 42

Puissance demandée à l’alimentation +12V ............................................................................. 43

Structure de FIFO_CMD .......................................................................................................... 49

Structure de FIFO_ENC ........................................................................................................... 49

Structure de FIFO_STRIP ........................................................................................................ 50

Description des états de la MSA principale .............................................................................. 58

Description des états de la MSA de ramassage de boule .......................................................... 60

Description des états de la MSA de reprise de ligne ................................................................ 62

Description des états de la MSA de ramassage de boule en zone libre .................................... 63

Description des états de la MSA de reprise de ligne en zobe libre ........................................... 65

Paramètres géométriques du robot SpinoS ............................................................................... 67

Description des états de la MSA de suivi de ligne ................................................................... 86


Liste des figures

Piste officielle de la compétition 2000 (16m x 8m) .................................................................. 4

Double plan incliné de la piste de compétition ......................................................................... 5

Base mécanique du robot SpinoS: modélisation 3D ................................................................. 10

Base mécanique du robot SpinoS: résultat ............................................................................... 11

Roues motrices du robot SpinoS ............................................................................................... 13

Profil de vitesse pour l’évaluation du couple en régime continu des moteurs .......................... 18

Perte de motricité sur le plan incliné ........................................................................................ 21

Suspension du robot SpinoS ..................................................................................................... 22

Robot muni de sa suspension sur le plan incliné ...................................................................... 22

Roue-libre (modélisation 3D) ................................................................................................... 23

Surface adhésive et rembourrage pour le ramassage de boules ................................................ 24

Module de ramassage de boules en action ................................................................................ 26

Structure électrique et électronique du robot SpinoS ............................................................... 27

Ordinateur embarqué du robot SpinoS ..................................................................................... 29

Disque dur Microdrive 1Gigaoctets d’IBM inséré dans le module T069 de Kontron .............. 30

Schéma-blocs du système de contrôle des moteurs .................................................................. 34

Pont en H (hacheur de courant) du robot SpinoS ..................................................................... 35

Schéma d’un hacheur de courant .............................................................................................. 36

Ligne de capteurs infrarouge du module de suivi de ligne ....................................................... 37

Module de suivi de ligne du robot SpinoS ................................................................................ 39

Configuration des détecteurs catadioptriques pour le ramassage de boules ............................. 40

Schéma du circuit d’alimentation du robot SpinoS .................................................................. 42

Structure du logiciel de contrôle du robot SpinoS .................................................................... 48

Processus de filtrage des données du module de suivi de ligne: a) données brutes b) résultat après fil-trage .......................................................................................................................................... 52

Diagramme d’états de la MSA principale ................................................................................. 59

Diagramme d’états de la MSA de ramassage de boule ............................................................. 61

Séquence de positionnement pour ramassage de boule ............................................................ 61

ÉCOLE POLYTECHNIQUE DE MONTRÉAL VI


Diagramme d’états de la MSA de reprise de ligne ................................................................... 62

Diagramme d’états de la MSA de ramassage de boule en zone libre ....................................... 64

Diagramme d’états de la MSA de reprise de ligne en zone libre .............................................. 65

Géométrie du robot SpinoS ....................................................................................................... 67

Modèle cinématique du robot SpinoS ....................................................................................... 67

Schéma-blocs du contrôleur en boucle ouverte: situation réelle .............................................. 71

Schéma-blocs du contrôleur en boucle ouverte: simulation ..................................................... 71

Vitesse tangentielle du robot en fonction de la tension appliquée aux moteurs ....................... 72

Vitesse tangentielle maximale du robot (simulation) ............................................................... 73

Vitesse angulaire maximale du robot (simulation) ................................................................... 73

Schéma-blocs du contrôleur en boucle fermée: situation réelle ............................................... 75

Schéma-blocs du contrôleur en boucle fermée en simulation .................................................. 75

Modèle du contrôleur de moteur ............................................................................................... 76

Résultat du filtrage des données recueillies du programme de contrôle ................................... 77

Schéma-blocs du contrôleur de suivi de ligne: situation réelle ................................................ 79

Schéma-blocs du contrôleur de suivi de ligne: simulation ....................................................... 79

Modèle utilisé pour le calcul de la position de la ligne ............................................................ 81

Position de la ligne pour essai non discrétisé (2m/s) ................................................................ 83

Position de la ligne pour essai discrétisé (2m/s) ....................................................................... 84

Position de la ligne pour essai discrétisé avec filtre pour la dérivée (2m/s) ............................. 84

Position de la ligne pour essai discrétisé, deux courbes consécutives(2m/s) ........................... 85

Diagramme d’états de la MSA de suivi de ligne ...................................................................... 87

Position désirée de la ligne en courbe ....................................................................................... 88

ÉCOLE POLYTECHNIQUE DE MONTRÉAL VII


ÉCOLE POLYTECHNIQUE DE MONTRÉAL VIII

Liste des symboles

l : distance entre les roues motrices du robot (m)

Ra : rayon des roues motrices du robot (m)

ds : distance entre l’axe des roues motrices du robot et la ligne de capteurs du module de suivi de ligne (m)

ls : largeur du module de suivi de ligne (m)

M : masse du robot (kg)

J : inertie de rotation du robot ( )

: coefficient de friction cinétique des roues du robot

x, y : position du centre de l’axe des roues motrices du robot par rapport à un référentiel fixe (m)

: orientation du robot par rapport à un référentiel fixe (rad)

Vu : vitesse tangentielle du robot (m/s)

: vitesse angulaire du robot (rad/s)

Vud : vitesse tangentielle désirée du robot (m/s)

: vitesse angulaire désirée du robot (rad/s)

lp : position de la ligne selon le module de suivi de ligne (m)

lpdes : position de la ligne désirée sur le module de suivi de ligne (m)

: orientation du moteur gauche du robot (rad)

: vitesse angulaire du moteur gauche du robot (rad/s)

: orientation du moteur droit du robot (rad)

: vitesse angulaire du moteur droit du robot (rad/s)

V1 : tension appliquée au moteur gauche du robot (V)

V2 : tension appliquée au moteur droit du robot (V)

Ff1 : force de friction appliquée sur la roue gauche du robot (N)

Ff2 : force de friction appliquée sur la roue droite du robot (N)

KP : gain proportionnel des contrôleurs de moteurs du robot

KD : gain dérivatif des contrôleurs de moteurs du robot

KP : gain intégrateur des contrôleurs de moteurs du robot

Kvff : gain anticipatif des contrôleurs de moteurs du robot

KPS : gain proportionnel du contrôleur de suivi de ligne

KDS : gain dérivatif du contrôleur de suivi de ligne

KIS : gain intégrateur du contrôleur de suivi de ligne

kg m2⋅

µc

θ

ω

ωd

θ1

ω1

θ2

ω2


1. Introduction

Le groupe SAE Robotique participe depuis maintenant 7 ans au Championnat mondial de robotique mobile

qui se déroule en France à chaque année. Elle y a présenté différents robots qui ont toujours su se démarquer

par l’utilisation d’idées et de concepts originaux dans le but d’obtenir des performances satisfaisantes. Ses

deux principales créations, Bazou et B0b4, ont été en mesure de fournir à l’équipe des résultats très

satisfaisants en compétition. Bazou a obtenu les 5e et 4e places au classement général lors de ses deux

participations. B0b4, de son côté, a été en mesure d’améliorer la position de l’équipe au classement

général en obtenant la 3e place durant deux années consécutives.

Le robot B0b4 a d’ailleurs été bien près de permettre à l’équipe de monter sur la plus haute marche du podium.

Dans le but de continuer dans cette veine de succès et de combler certaines lacunes et problèmes de fiabilité

qui ont été les principaux éléments limitatifs des performances du robot B0b4, l’équipe a entrepris en automne

2000 la création d’un tout nouveau robot: SpinoS. Grâce à l’expérience et au bagage de connaissances acquis

par l’équipe depuis ses débuts, il est maintenant possible de créer des robots mobiles autonomes de plus en

plus rapidement et qui offrent des performances sans cesse améliorées. C’est donc dans cet environnement

qu’a vu le jour le projet faisant l’objet du présent document.

Ce rapport présente dans un premier temps la problématique et les objectifs initiaux de ce projet. Ensuite, un

survol de la conception du robot, tant au niveau mécanique, électrique qu’informatique est effectué. Il est alors

l’occasion de décrire et de justifier les différentes solutions retenues et de détailler les caractéristiques

spécifiques au robot développé. Finalement, la description des différents contrôleurs développés et quelques

résultats obtenus sont présentés et discutés.

Le projet de fin d’études étant l’occasion rêvée d’effectuer une synthèse des diverses notions acquises au cours

de quatre années d’études au baccalauréat en génie, l’auteur a saisi l’occasion de diriger le projet de robotique

mobile présenté dans ce rapport et de participer à la conception et au développement de nombreuses solutions

implantées. Ce rapport est donc l’aboutissement d’un projet de fin d’études au baccalauréat en génie

électrique. Ce rapport a en fait deux objectifs. Il se veut premièrement le résumé du travail accompli par

l’étudiant durant la dernière année sur ce projet passionnant de robotique mobile. Mais il se veut également le

document le plus complet possible pour laisser au groupe SAE Robotique un document résumant la presque

totalité des facettes de ce projet. Un document donc qui pourra servir de référence pour la continuité du projet,

mais également de référence lors de la prochaine conception de robot mobile visant à améliorer les

performances obtenues du présent projet.

ÉCOLE POLYTECHNIQUE DE MONTRÉAL 1


2. Exposé du problème

2.1 Nécessité d’un nouveau robot

Comme il a été mentionné en introduction, le robot B0b4 a su améliorer les performances de l’équipe en

compétition. Ce robot, de conception mécanique originale, offrait des caractéristiques mécaniques

impressionantes. Il représente le robot rouleur le plus complexe jamais développé par l’équipe, mais également

celui qui permettait une tenue de route1 surpassant les possibilités de la grande majorité des différentes

configurations possibles pour un robot mobile muni de roues.

Par contre, des limitations au niveau du positionnement et du contrôle de ce robot nous portaient à croire qu’il

serait très difficile de réussir à améliorer nos performances en compétition. En effet, sa configuration

mécanique étant relativement complexe, le positionnement à l’aide des encodeurs optiques était imprécis. Pour

effectuer des opérations semblables à celles demandées par l’évolution en zone libre en compétition, il est

nécessaire de compter sur un positionnement précis. De plus, vue sa configuration mécanique, la

manoeuvrabilité de ce robot était restreinte. Pour permettre l’évolution du robot dans un espace restreint, il

était désiré d’obtenir une manoeuvrabilité accrue. Ce robot n’était pas donc pas tellement bien adapté pour

l’élaboration d’algorithmes de haut niveau permettant des opérations variées. Il était optimisé pour le suivi de

ligne à haute vitesse.

De plus, de nombreux problèmes de fiabilité et de durabilité étaient apparus en compétition et lors de différents

tests. Pour effectuer des tests de façon plus soutenue et régulière, ces problèmes de fiabilité constituaient

clairement un problème.

Ainsi, pour viser de nouveaux objectifs, l’équipe avait besoin de créer un nouveau robot.

2.2 Description de la compétition

La compétition du Championnat mondial de robotique mobile (http://www.robotik.org) aura lieu en avril 2002

dans la région parisienne, en France. Cette compétition a lieu dans le cadre du Festival International des

Sciences et Technologies. Durant une semaine, les équipes complètent des essais sur piste, compétitionnent

lors des épreuves et assistent et participent à des conférences scientifiques. Les participants y viennent d’écoles

d’ingénierie de plusieurs coins de la planète: France, Portugal, Allemagne, Russie, Corée, États-Unis, Mexique

1. L’objectif en compétition étant de parcourir un trajet le plus rapidement possible, la tenue de route ou plutôt la stabilité durobot en courbe est un critère essentiel à la réussite en compétition.


http://www.robotik.org


et Canada. La compétition de robots rouleurs comporte deux catégories: monotype et libre. La catégorie

monotype utilise une plateforme standard (structure mécanique et moteurs) imposée, tandis que la catégorie

libre, dans laquelle nous évoluons, comporte très peu de restrictions et les robots qui y compétitionnent

présentent des designs très variés. Des prix de design et de rédaction technique sont attribués aux équipes se

démarquant dans ces catégories. De plus, un classement général est établi en considérant les résultats des

équipes à chacune des trois épreuves et l’équipe gagnante se voit récompensée. Voici un résumé des épreuves

ainsi qu’un schéma de la piste officielle de l’année dernière:

• 1ère épreuve, vitesse pure : Cette épreuve consiste à compléter le tracé le plus rapidement possible. Cetteépreuve ne comporte ni relief, ni boules de billard à ramasser. Le classement est établi selon le tempsmis pour franchir la ligne d’arrivée.

• 2e épreuve, franchissement d’obstacle : Cette épreuve consiste aussi à compléter le tracé le plusrapidement possible. Toutefois, un double plan incliné de 11,3 degrés est disposé à une positionarbitraire sur le tracé. Le classement est établi selon le temps mis pour franchir la ligne d’arrivée. Lafigure 2-2 présente un schéma du plan incliné de la compétition.

• 3e épreuve, ramassage de boules : Cette épreuve consiste à compléter le tracé en y ramassant les boulesde billard qui sont disposées sur la piste et en les rapportant à la ligne d’arrivée. Trois boules de billard

sont disposées à 80cm du tracé à des positions arbitraires, tandis qu’une 4ème boule est disposée à uneposition arbitraire dans la "zone libre". Les boules sont disposées sur des portoirs de 20cm de hauteur etun matériau réfléchissant sert à les détecter. Des pénalités sont attribuées aux boules non ramassées etaux portoirs tombés. Le classement est établi selon le nombre de pénalités. En cas d’égalité, le tempsd’exécution de l’épreuve sera considéré.

À toutes les épreuves, le robot devra s’arrêter automatiquement à la ligne d’arrivée.

La figure 2-1 présente la piste officielle de la compétition qui eut lieu en mai 2000. La piste de l’édition 2002

sera similaire et les dimensions du terrain seront les mêmes, soit 16m par 8m. Elle est composée de 4 cases de

8m par 4m sur lesquelles est tracée une ligne qui doit être suivie par le robot. Les courbes du tracé présentent

toutes un rayon de courbure de 1m. Il n’est pas permis de fournir au robot les paramètres du tracé, sous peine

de disqualification. Le robot doit découvrir le tracé par ses propres moyens.



Figure 2-1: Piste officielle de la compétition 2000 (16m x 8m)



Figure 2-2: Double plan incliné de la piste de compétition

3. Les objectifs du projet SpinoS

Deux objectifs principaux ont été identifiés dès le début du projet. Ce sont ces objectifs qui ont motivé l’équipe

à viser la perfection tout au long du processus de développement. Voici donc ces 2 objectifs principaux:

• Remporter le Championnat Mondial de Robotique Mobile en y présentant un robot-rouleur autonomecapable de battre les records de performance établis en compétition.

• Créer un robot modulaire offrant des possibilités d’évolution intéressantes, ce qui nous permettra dedévelopper des méthodes de contrôle variées, une fois la compétition remportée, et de déterminer un

nouvel objectif principal pour le projet.1

En plus des deux objectifs principaux, certaines caractéristiques essentielles ont été identifiées. La version

finale du robot doit donc être en mesure de respecter ces critères de performance:

• vitesse maximale en ligne droite supérieure à 2m/s

• accélération en ligne droite supérieure à 2m/s2

• vitesse angulaire maximale supérieure à 4 rad/s

• suivi de ligne avec une vitesse moyenne de plus de 2m/s

• poids total incluant les batteries de moins de 15kg

Finalement, ce robot doit être conçu et fabriqué à coût minimal , le budget alloué à ce projet étant de 2000$

pour la première année.

1. Il a d’ailleurs été prévu dès la naissance de ce projet d’en faire éventuellement un robot joueur de soccer. L’équipe étant àla recherche de nouveaux défis à relever, la création d’une équipe de robots joueurs autonomes est un défi de taille quipourrait éventuellement être visé. Grâce à la coopération de professeurs et d’étudiants de la section Automatique du DGE,une éventuelle participation à la compétition RoboCup pourrait même être envisageable.

π



NOTE: les critères de performance considèrent le robot sans le module de ramassage de boules

4. Processus de développement du projet

Le projet résumé dans ce rapport est d’envergure importante et il est clair qu’il serait impossible d’effectuer

tout ce travail de façon individuelle. Ce projet est en fait le fruit du travail acharné d’une équipe d’étudiants en

génie passionnés par la robotique. Ayant comme objectif de décrire le projet dans son ensemble, l’auteur en a

profité pour documenter des parties du projet qui ne sont pas nécessairement de sa propre création, mais qui

méritent d’être décrites. L’annexe 1 présente les membres de l’équipe qui ont contribué au développement de

ce projet et certains y contribuent d’ailleurs toujours.

Un travail de gestion a donc dû être effectué pour coordonner le travail des différents membres de cette équipe

et diriger le projet dans la direction désirée. En fait, cette équipe était composée d’un nombre minimal de

membres compétents. Le temps alloué à la gestion de ce projet se devait d’être minimal puisqu’un travail

technique acharné était également nécessaire. Le but était donc d’identifier l’équipe principale du projet dès la

naissance de ce projet. En regroupant dès le départ toutes les personnes qui effectueront les tâches principales

de conception et de développement, il est possible de permettre à tous les membres de participer à

l’identification des principaux objectifs et de débuter le travail avec une vision des choses qui soit homogène

pour tous les membres.

La gestion de ce projet fut donc une tâche relativement simple puisque tous les membres étaient alors d’accord

pour travailler dans la même direction. Il était alors suffisant d’identifier toutes les tâches nécessaires à la

réalisation du projet et de déterminer de façon rigoureuse l’échéancier qui se devait d’être suivi. En fait,

l’équipe étant réduite au nombre minimal de gens compétents nécessaires, il n’était pas justifié d’utiliser des

outils de gestion complexes qui auraient allourdi et ralenti le processus de gestion inutilement.

Le présent rapport ne se veut pas un résumé des aspects de la gestion du projet mais bien de ses aspects

techniques. Nous n’entrerons donc pas dans des détails de gestion. Par contre, nous pouvons résumer le

processus de développement de ce projet par quelques grandes étapes chronologiques qui ont permis de

respecter des échéances serrées. Voici donc ces grandes étapes:

1)Naissance du projet (octobre 2000): des nouvelles idées et concepts prometteurs sont apportés et le débutd’un nouveau projet est justifié.

2)Identification des objectifs principaux (octobre 2000): avant même d’élaborer les solutions, il est crucialde se donner des objectifs ambitieux qui serviront de guide tout au long du projet.



3)Identification des critères de performance (octobre 2000): ces critères doivent être déterminés avant dedébuter la conception de façon à influencer les différents choix effectués durant la conception du robot.

4)Début de la conception et développement des solutions (octobre 2000): les solutions peuvent donc êtreélaborées et développées. Il est nécessaire avant de débuter le développement de compléter autant quepossible les différentes étapes de conception.

• mécanique: disposition des éléments, conception des composantes, choix des matériaux, validation desmoteurs, fabrication d’un prototype, début de la fabrication du robot final, recherche de solution pour leramasse-boules.

• électrique: définition du circuit d’alimentation (choix des composantes), définition du systèmeélectronique (choix des composantes), réingénierie du module de suivi de ligne.

• informatique: choix de l’architecure, définition de la structure temps réel, définition de la structureorientée-objet, développement du programme de contrôle.

• contrôle: définition du système et des contrôleurs, développement des modèles de simulation.

5)Validation des contrôleurs par simulation et du programme de contrôle sur un banc d’essai (décembre2000). Ces deux éléments sont intimement reliés et donc les deux étapes doivent être synchronisées.

6)Mise en fonction d’un prototype de module de suivi de ligne (janvier 2001): tests sur un prototype pourvérifier le bon fonctionnement du circuit.

7)Mise en fonction d’un prototype du robot (janvier 2001): nécessite que le développement de l’électriqueet de l’informatique soit à toute fin complété. Tests des contrôleurs et validation des concepts.

8)Révision et mise en fonction du robot (février 2001): révision si les tests sur le prototype l’exigent, puismise en fonction du robot de compétition (sans le module de ramassage de boules).

9)Implantation et tests des algorithmes pour la compétition (février 2001): il est alors possible de compléterle programme informatique pour y implanter et tester les différents algorithmes nécessaires à lacompétition.

10)Mise en fonction du module de ramassage de boules (mars 2001).

11)Fabrication du module de suivi de ligne (été 2001).

12)Fin des tests sur les algorithmes de compétition (été 2001).

Voici donc les principales étapes du développement du projet. Évidemment, un échéancier beaucoup plus

précis fut nécessaire. Des imprévus sont également survenus en cours de route pour perturber ce processus,

mais il a tout de même été suivi rigoureusement. La mise en fonction du module de suivi de ligne a toutefois

été retardée et les algorithmes ont été complétés sans ce module.



5. Conception du robot

5.1 Conception mécanique

5.1.1 Recherche de solution

De nombreuses configurations sont possibles pour un robot mobile muni de roues. Depuis quelques années

déjà le groupe SAE Robotique conçoit et fabrique de tels robots. À chaque nouvelle conception, l’équipe se

base sur les expériences vécues en compétition (révision des différentes configurations et performances des

équipes de compétition) et sur les objectifs de performance fixés pour le nouveau robot pour décider de la

configuration à adopter pour la nouvelle conception. Parmi les différentes configurations, mentionnons celles

qui ont été considérées au début du projet présenté dans ce rapport:

• robot tricycle: un moteur de propulsion couplé à 2 roues motrices et un moteur de direction couplé à uneroue directionnelle. Le centre de masse se retrouve le plus près possible de l’axe des roues motrices.

• robot à vitesses différentielles asymétrique: 2 moteurs de propulsion et de direction couplés à deux rouesmotrices. Les roues motrices sont disposées à l’avant ou à l’arrière et une roue-libre assurant la stabilitéest disposée à l’autre extrémité du robot. Le centre de masse se retrouve le plus près possible de l’axedes roues motrices.

• robot à vitesses différentielles symétrique: 2 moteurs de propulsion et de direction couplés à deux rouesmotrices. Les roues motrices sont disposées au centre du robot et 2 roues-libres assurant la stabilité sontdisposées à l’avant et à l’arrière du robot. Le centre de masse se retrouve le plus près possible de l’axedes roues motrices.

• robot à 4 roues motrices et directionnelles (configuration de B0b4, notre robot précédent): 4 rouesmotrices jumelées 2 à 2 (côté gauche ensembles et côté droit ensembles), 2 moteurs de propulsion(vitesses différentielles), un pour les roues de gauche et un pour les roues de droite, 2 moteurs dedirection, un pour les roues avant et un pour les roues arrière. Le centre de masse se retrouve le plus prèspossible du centre du robot.

La configuration qui a été choisie est la configuration à vitesses différentielles symétrique. Nous

n’énumèrerons pas les qualités et les défauts de chacune des configurations puisque cela serait trop long. Par

contre nous pouvons justifer le choix effectué en mentionnant les principales qualités de cette configuration

qui, dès le départ, ont été jugées plutôt intéressantes dans le but de respecter les objectifs de ce projet.

Voici les principaux avantages de cette configuration :

• Simplicité de contrôle : la cinématique et la dynamique du robot sont très simples, facilitant ledéveloppement de contrôleurs haut niveau.

• Positionnement précis : le positionnement du robot à l’aide de ses encodeurs optiques est relativementprécis comparativement à d’autres configurations.



• Symétrie: ceci constitue le point fort de cette structure. La symétrie permet des performancesintéressantes en rotation puisque le centre de masse peut être situé au centre du robot, sur l’axe des rouesmotrices. Elle permet également un contrôleur beaucoup plus évolué dans le cas où la mécanique etl’électronique sont symétriques. Il est alors possible de créer un programme de contrôle qui tient comptede cette symétrie et qui est en mesure d’inverser son comportement lorsque nécessaire.

• *Bonne fiabilité mécanique : le nombre de membrures et de composantes étant réduit, les bris seront peufréquents.

• *Bonne fiabilité électronique : le nombre d’actuateurs étant réduit, les bris des circuits de puissanceseront peu fréquents.

• *Faible coût de fabrication : la quantité de matériau et de composantes est réduit.

*: avantages par rapport à notre configuration précédente uniquement

5.1.2 Disposition des éléments

La configuration du robot étant établie, nous connaissons maintenant les différents éléments qui doivent se

retrouver sur la base mécanique du robot. Ainsi, nous devons trouver un moyen d’agencer les roues motrices

(2), les moteurs (2) et les roues-libres (2) en utilisant une structure légère et suffisamment rigide. La base

mécanique se doit également d’incorporer les batteries (2) du robot puisqu’elles représentent près du tiers du

poids du robot et il est donc nécessaire de les soutenir par une structure suffisamment rigide. Les lignes qui

suivent présentent les principales règles qui ont été suivies pour déterminer la disposition de ces différents

éléments et la base mécanique qui en a résulté.

Nous cherchons tout d’abord à limiter l’inertie de rotation et à conserver la symétrie du robot. L’inertie de

rotation du robot, comme nous le verrons en section 6.3, peut être modélisée comme étant celle d’un disque.

Comme l’inertie d’un disque varie en fonction du carré de son rayon, nous chercherons à conserver la majorité

du poids vers le centre du robot. De plus, nous savons que la majorité du poids proviendra des batteries. Nous

désirons donc conserver les batteries le plus près possible de l’axe des roues motrices. Ces batteries doivent

également être sufisamment basses pour permettre au robot d’atteindre les vitesses et accélérations désirées

sans danger de chavirer. Les batteries seront donc disposées le plus près possible de l’axe des roues motrices

et le plus près possible du sol. En conservant les roues motrices, les moteurs et les batteries disposés près du

centre du robot et de façon symétrique à l’axe des roues motrices, nous obtenons ainsi une inertie qui sera

relativement faible et nous conservons le centre de masse au centre de l’axe des roues motrices.

Nous cherchons finalement à minimiser le volume occupé par le robot. Pour ce faire, nous désirons dans un

premier temps minimiser la longueur de l’axe des roues motrices. L’utilisation de joints de petite taille, entre

les axes des roues et les axes des moteurs est alors nécessaire1. Ensuite, les roulements à billes utilisés pour



soutenir les roues motrices ont été insérés à l’intérieur de ces dernières (un peu comme un frein est inséré à

l’intérieur d’une roue de voiture). Nous avons toutefois conservé un espace entre les deux moteurs pour

permettre l’ajout de moteurs plus puissants, possiblement plus longs, si nécessaire. Finalement, les roues-libres

ont été disposées de façon à ce que les points de rotation de ces roues et les points de contact des roues motrices

forment un cercle.

Le résultat que nous avons obtenu peut être observé en modélisation 3D sur la figure 5-1 et la base mécanique

réellement obtenue est présentée en figure 5-2. Nous pouvons observer sur ces figures que les plaquettes

rectangulaires disposées de chaque côté de l’axe des roues motrices correspondent aux supports à batteries.

Nous obtenons donc un résultat satisfaisant, soit une base qui soit symétrique et qui présente une faible inertie

de rotation. Nous obtenons également une structure légère qui pèse un total de 3,3kg ce qui inclut un poids de

1,1kg pour les moteurs.

Figure 5-1: Base mécanique du robot SpinoS: modélisation 3D

1. Le modèle FSR12-4-4-A de Ruland a alors été utilisé



Figure 5-2: Base mécanique du robot SpinoS: résultat

5.1.3 Choix des matériaux

La contrainte maximale détermineé initialement pour le poids total du robot SpinoS est de 15kg. De plus, les

batteries et les moteurs, supportés par la structure mécanique, représentent un poids total d’environ 6,5kg.

Ainsi, la structure mécanique du robot SpinoS se doit d’être très légère, pour permettre d’incorporer sur le

robot le plus grand nombre de modules possibles (charge utile) tout en respectant la contrainte de poids, et elle

doit également offrir une rigidité suffisante, pour supporter le poids important du système électro-mécanique

et ne pas se déformer lors des mouvements brusques du robot. Face à ces éléments, l’utilisation d’un alliage à

base d’aluminium constitue un choix évident étant données les propriétés mécaniques et les principales

caractéristiques appréciables de ce type d’alliage. Voici donc les principales qualités de l’aluminium qui ont

été considérées pour confirmer la validité du choix de ce matériau:

• légèreté: grâce à la faible masse volumique de l’aluminium (2700kg/m3, soit près de 3 fois inférieure àcelle des alliages d’acier), nous pouvons espérer un poids total faible pour la structure.

• ductilité: cette caractéristique facilite l’usinage des alliages d’aluminium à l’état solide. Il devient doncrelativement facile de mettre en forme et de fabriquer les différentes pièces de la structure mécanique.

• possibilité de traitements (écrouissage, addition d’éléments d’alliage et traitement thermique): cestraitements permettent de modifier de façon appréciable les propriétés mécaniques initiales del’aluminium. Il est donc possible, selon l’application donnée, d’améliorer certaines propriétés cruciales.

• résistance à la corrosion: évidemment, il est peu souhaitable que notre structure soit sensible à la



corrosion et que son état se détériore avec le temps.

• conductibilité électrique: cette propriété est particulièrement intéressante au niveau de la conception dusystème électrique, puisque la structure peut être utilisée comme la mise à la terre du système.

L’alliage d’aluminium qui a été choisi pour la structure est le 6061, un alliage à durcissement structural qui

offre une résistance à la fatigue relativement intéressante, particulièrement suite à l’application d’un traitement

thermique T6, mais surtout une soudabilité excellente ainsi qu’une bonne résistance à la corrosion.

En date d’écriture de ce rapport, le poids total du robot SpinoS est de 13,7kg, ce qui est très satisfaisant et qui

laisse place à des ajouts futurs de modules électroniques ou mécaniques.

5.1.4 Choix des roues

Les roues motrices du robot doivent être identifiées très tôt dans un tel projet puisque les performances du

robot dépendent grandement de leurs dimensions. Le couple fourni par le moteur ainsi que la vitesse maximale

du robot sont des exemples de paramètres qui varieront en fonction du rayon des roues motrices.

Les critères que nous avons considérés pour le choix des roues ont été établis en fonction des performances

que nous désirions obtenir à la compétition (les critères de performances établis précédemment). Nous visons

donc une accélération maximale suffisamment grande ainsi qu’une excellente adhérence latérale (pour les

courbes). Pour obtenir une accélération intéressante, il est nécessaire de choisir des roues de rayon assez faible

puisque l’inertie de rotation vue par le moteur est directement proportionnelle à ce rayon. Par contre, la vitesse

maximale étant elle inversement proportionnelle à ce rayon, il est important de ne pas trop le diminuer.

L’accélération maximale dépendra aussi de l’adhérence du pneu. Ensuite, l’adhérence latérale dépend de la

forme des roues, ainsi que du matériau de la surface de contact avec le sol.

Les roues de notre robot précédent avaient été choisies en fonction des mêmes critères. Ces roues, dont un

exemplaire est présenté à la figure 5-3, sont des roues de voitures téléguidées de haute performance (format

1:5). Elles ont un rayon de 5,25cm, ce qui est assez petit vue la taille du robot. Nous verrons à la section 5.1.5

que ce rayon permet de respecter les critères de performance désirés. De plus, ces roues sont munies d’un pneu

à crampons de caoutchouc qui offre une surface de contact au sol de 4cm. Ces roues offrent ainsi une excellente

adhérence. En fait, nous n’avons pas effectué de tests exhaustifs sur l’adhérence des pneus (nous n’avons pas

identifié les coefficients de friction statique et dynamique pour une surface de référence), mais nous savons,

grâce à des tests simples, que l’adhérence latérale est excellente et nous pouvons espérer une accélération de

plus de 3,5m/s2 sur une surface suffisamment rugueuse et propre (comme la piste de compétition).



Figure 5-3: Roues motrices du robot SpinoS

Ces roues répondaient donc à nos critères et nous en avions 4 en très bon état à notre disposition. Nous avons

donc décidé de les conserver pour le robot SpinoS.

Il est important de noter cependant que ce type de roues n’est pas suggéré pour un positionnement précis. En

effet, la large surface de contact au sol peut amplifier l’erreur sur la mesure de l’orientation du robot. Pour un

positionnement précis, il est préférable d’utiliser une roue qui offre une surface de contact minimale.

5.1.5 Choix des moteurs

Le choix des moteurs d’un robot est généralement une tâche fastidieuse. Il faut dans un premier temps

déterminer avec suffisamment de précision le travail qui sera accompli par chacun des moteurs. Évidemment,

pour pouvoir valider un moteur, il faut connaître les spécifications que nous voulons atteindre. Il est ensuite

possible d’utiliser une méthode itérative, afin de trouver le bobinage et l’engrenage, pour une certaine gamme

de moteurs, qui permettront de répondre aux besoins.

Le problème est toutefois beaucoup plus simple lorsque nous connaissons les caractéristiques d’un moteur

ainsi que le travail qu’il doit accomplir et que nous désirons le valider. Tel était notre situation, puisque nous

avions la possibilité de récupérer des moteurs qui ont servi sur notre robot précédent. Ces moteurs avaient très

peu servi et nous en avions 4, donc la possibilité de créer un premier prototype et de conserver par la suite deux

robots fonctionnels. Le moteur en question est un moteur de la compagnie Pittman, le modèle GM9236S015.



Les sections suivantes présentent le processus utilisé pour valider ce modèle de moteur. La méthodologie

employée pour la validation est basée sur les développements présentés en pages 8 et 9 de [2].

5.1.5.1 Spécifications du robot

Le tableau 5-1 donne les paramètres du robot qui sont nécessaires au calcul des moteurs. La masse du robot

est considérée de 15kg pour déterminer les performances optimales que nous obtiendrons du robot. Toutefois,

si le poids du robot devait être supérieur à 15kg, l’accélération maximale des moteurs devrait être diminuée.

Pour ce qui est du coefficient de friction cinétique, celui-ci est approximé, car il est très difficile de le connaître

précisément.

5.1.5.2 Spécifications des moteurs

Le tableau 5-2 présente les paramètres du moteur GM9236S015 de Pittman.

Tableau 5-1 : Paramètres du robot pour le choix des moteurs

Paramètre Symbole Valeur

Masse du robot M 15kg

Distance entre les roues motrices l 40cm

Rayon des roues motrices Ra 5,25cm

Coefficient de friction cinétique des roues au sol 0,02

Tableau 5-2 : Paramètres des moteurs du robot


Tension de référence E 24V

*Constante de couple KT 0,0458

*Constante de force contre-électromotrice KE 0,0458

Résistance interne RT 2,49

Vitesse sans charge 82,7rad/s

Couple maximal absolu TPK 2,02

Couple maximal en régime continu TC 0,339

Couple de friction TF 0,033

µc

N m A⁄⋅

V rad s⁄⁄

Ω

ωrouemax

N m⋅

N m⋅

N m⋅



*: valeurs avant l’engrenage

5.1.5.3 Vitesse maximale du robot en translation et en rotation

Le vitesse maximale sans charge du moteur est de 4916rpm (5.9 x 87,24rad/s) selon ce qui est spécifié à la

page 12 de [3]. Cette valeur correspond au maximum obtenu sans charge et il est donc à prévoir en réalité des

valeurs à peine inférieurespuisque la charge est généralement minime lorsque le robot roule à vitesse constante

(cette charge dépend de la friction). Voici donc les calculs pour déterminer la vitesse maximale du robot en

translation et en rotation:

• Vitesse maximale en translation:

Cette valeur est largement supérieure au critère de performance établi à 2m/s.

• Vitesse maximale en rotation:

Cette valeur est également largement supérieure au critère de performance établi à 12.57rad/s

5.1.5.4 Couple nécessaire à l’accélération et accélération maximale

Le couple nécessaire à l’accélération en translation peut être calculé ainsi:

où A correspond à l’accélération du robot et FF à la force de friction.

Coefficient de frottement visqueux b 3,54x10-6

Ratio d’engrenage n 5.9:1

*Résolution de l’encodeur cnts 500 tics/tour

(5.1)

Tableau 5-2 : Paramètres des moteurs du robot


N m⋅ rad s⁄( )⁄

Vumaxωrouemax

Ra⋅ 4916rpm5.9 60s min⁄⋅---------------------------------- 2π 0.0525m⋅ ⋅ 4.58m s⁄= = =

ωmax

Vumax

l 2⁄----------- 4.58m s⁄

0.2m--------------------- 22.90rad s⁄= = =

TACC RA

M A⋅2

------------- FF+ ⋅ TF+=



La modélisation de la friction n’est pas tellement élaborée. Elle considère un coefficient de friction cinétique

ainsi que la force normale sur le plan. Elle pourrait être modélisée de façon beaucoup plus rigoureuse, mais ce

modèle permet tout de même de donner au moteur une charge acceptable. La friction est donc approximée

ainsi:

Pour le couple maximal, nous pouvons considérer le couple maximal absolu du moteur qui est de 2,02 .

En remplaçant cette valeur dans l’équation 5.1, nous obtiendrions une accélération maximale de:

Toutefois, cette valeur consitue la limite absolue du moteur et il est fortement déconseillé de demander le

couple maximal au moteur. Le moteur risque alors de chauffer et de perdre plus rapidement de son efficacité.

L’engrenage du moteur s’usera également plus rapidement pour un couple élevé (le couple maximal que

l’engrenage peut prendre est de 2,12 ). De plus, la valeur de la friction est approximative et pourrait être

légèrement supérieure. Nous pouvons donc considérer un couple maximal égal à 75% du couple maximal

absolu. Cette proportion est arbitraire, mais elle devrait nous assurer d’une durée de vie du moteur acceptable

et de performances intéressantes. Nous obtenons alors une accélération maximale en translation de:

Cette valeur est supérieure au critère de performance établi à 2m/s2 et elle pourra être utilisée par le contrôleur

d’asservissement en vitesse pour générer le profil trapézoïdal (voir section 5.2.2.5). L’accélération angulaire

demandée aux moteurs et utilisée par le contrôleur sera donc

.

NOTE: la valeur maximale pour l’accélération en rotation n’est pas calculée. Nous savons que l’inertie vue

par le moteur est beaucoup plus faible en rotation qu’en translation, donc l’accélération en rotation pourrait

être plus élevée. Toutefois, nous allons éviter de modifier constamment l’accélération maximale du profil

trapézoïdal. Nous allons donc conserver une accélération maximale de 3,57m/s2 et nous obtenons alors une

accélération angulaire maximale de 17,85rad/s2.

FF µc N⋅ 0.0215kg 9.81m s

2⁄⋅2

----------------------------------------⋅ 1.47N= = =

N m⋅

Amax2M-----

TPK TF–

Ra--------------------- FF– ⋅ 2

15------ 2.02 0.033–

0.0525------------------------------ 1.47– ⋅ 4.85m s

2⁄= = =

N m⋅

Amax2M-----

TPK 0.75⋅ TF–

Ra------------------------------------ Ff– ⋅ 2

15------ 2.02 0.75⋅ 0.033–

0.0525--------------------------------------------- 1.47– ⋅ 3.57m s

2⁄= = =

αmax Amax Ra⁄ 3.570.0525---------------- 67.96rad s

2⁄= = =



5.1.5.5 Décélération maximale

La décélération maximale est supérieure (en valeur absolue) à l’accélération maximale puisque la friction aide

le robot à freiner. Nous pouvons donc calculer la décélération maximale ainsi:

Cette valeur ne sera toutefois pas utilisée puisque l’accélération maximale en translation sera considérée

comme la limite absolue.

5.1.5.6 Profil de vitesse et couple continu

Avant de pouvoir calculer le couple en régime continu que devra fournir le moteur, il est nécessaire de définir

un profil de vitesse qui représente fidèlement les mouvements que le robot devra effectuer. Un profil de vitesse

trapézoïdal permet des calculs simples et il permet également de représenter un profil réaliste.

Nous savons que notre robot évoluera sur une piste semblable à celle présentée à la figure 2-1. Cette piste

devrait donc avoir une longueur d’environ 60m et environ la moitié de ce parcours serait en ligne droite. En

suivi de ligne optimal, nous prévoyons une vitesse 2,5m/s en ligne droite pour le robot et une vitesse de 1,8m/

s en courbes. En supposant qu’il y ait 7 lignes droites et 7 courbes, nous obtenons une longueur moyenne pour

les courbes et les lignes droites de 4,3m. Nous pouvons en déduire un certain profil trapézoïdal (en passant de

2,5m/s à 1,8m/s puis à 2,5m/s de façon cyclique), mais il serait important de tenir compte des accélérations

(positives et négatives) demandées au robot lors du départ, de l’arrêt et des variations de courbes. Pour ce faire,

nous pouvons augmenter la vitesse maximale en ligne droite à 2,8m/s, ce qui diminuera le temps de parcours

à vitesse constante (faible couple) et augmentera celui en accélération (couple élevé). Nous obtenons ainsi un

profil de vitesse suffisamment sévère pour bien évaluer le travail demandé aux moteurs. La figure 5-4 montre

le profil de vitesse retenu et les périodes et distances associées (l’échelle de distance est déformée).

(5.2)Tdec RaM A⋅

2------------- Ff– TF–⋅=

Amin2–

M------

TPK 0.75⋅ TF+

Ra------------------------------------- Ff+ ⋅ 2–

15------ 2.02 0.75⋅ 0.033+

0.0525--------------------------------------------- 1.47+ ⋅ 4.13m s

2⁄–= = =



Figure 5-4: Profil de vitesse pour l’évaluation du couple en régime continu des moteurs

Nous pouvons donc calculer les couples et durées associés aux différentes périodes en utilisant des équations

de cinématique et les équations 5.1 et 5.2.

• Période 1:

• Période 2:

• Période 3:

V (m/s)

1,8

2,8

temps (s)

distance (m)

t1

d1t2

d2t3

d3

t4

d4

4,3m 4,3m

t12.8m s⁄ 1.8m s⁄–

3.57m s2⁄

------------------------------------------- 0.280s= =

d1 1.8m s⁄ 0.280s⋅ 0.5 3.47m s2⁄ 0.280s( )2⋅ ⋅+ 0.640m= =

T1 0.052515 3.57⋅

2--------------------- 1.47+ ⋅ 0.033+ TPK 0.75⋅ 1.515N m⋅= = =

d2 4.3m 0.64m– 3.66m= =

t23.66m

2.8m s⁄------------------ 1.307s= =

T2 0.052515 0⋅

2------------- 1.47+ ⋅ 0.033+ 0.110N m⋅= =

t3 t1 0.280s= =

d3 d1 0.64m= =



• Période 4:

Pour vérifier que nous respectons le couple maximal en régime continu du moteur en question, nous devons

calculer le couple rms ainsi que la vitesse angulaire moyenne pondérée:

Selon l’équation (5) en page 3 de [2], nous calculons le couple maximal en régime continu:

Nous remarquons donc que le couple rms dépasse le couple maximal admissible. Nous risquons donc d’user

prématurément les moteurs du robot en les utilisant selon le profil de vitesse établi. Toutefois, la piste de la

compétition ne fait qu’environ 60m et nous ne la parcourons qu’une seule fois par épreuve, ce qui donne une

durée d’utilisation d’environ 28s. La durée est donc faible et nous ne risquons pas d’endommager les moteurs.

Toutefois, pour une utilisation continue, nous devons réduire les accélérations pour limiter le couple demandé

aux moteurs. Pour les nombreux tests et les démonstrations, une valeur beaucoup plus conservatrice de 2m/s2

sera utilisée. La valeur maximale de 3,57m/s2 sera donc seulement utilisée pour optimiser le contrôleur de suivi

de ligne utilisé en compétition.

5.1.5.7 Courants et tensions nécessaires aux moteurs

Il est également nécessaire de vérifier les courants et tensions que demanderont les moteurs. Nous pourrons

alors s’assurer que nos batteries pourront offrir la tension nécessaire et évaluer l’autonomie électrique du robot.

T3 0.0525–15 3.57⋅

2--------------------- 1.47– 0.033–⋅ 1.296N m⋅= =

d4 4.3m 0.64m– 3.66m= =

t43.66m

1.8m s⁄------------------ 2.03s= =

T4 T2 0.110N m⋅= =

TRMS

TI

2TI⋅( )∑

TI∑-------------------------- 1.515

20.28⋅ 0.11

21.307⋅ 1.296

20.28⋅ 0.11

22.03⋅+ + +

0.28 1.307 0.28 2.03+ + +-------------------------------------------------------------------------------------------------------------------------------------------- 0.544N m⋅= = =

ωavg1

0.0525---------------- 2.3 0.28 2.8 1.307 2.3 0.28 1.8 2.03⋅+⋅+⋅+⋅

0.28 1.307 0.28 2.03+ + +----------------------------------------------------------------------------------------------------------------⋅ 42.04rad s⁄= =

Tcont 5.9 0.9155 25–

13.5--------------------- 0.007328 401.45 5.9⋅ ⋅

9.549-------------------------------------------------------– 0.78 0.029⋅ ⋅ ⋅ ⋅= 0.007328– 0.297N m⋅=



• Période 1:

• Période 2:

• Période 3:

• Période 4:

Nous remarquons que la tension pour la période d’accélération dépasse légèrement la tension des batteries de

24V lorsque la vitesse est près de la vitesse maximale demandée de 2,5m/s. Cette constatation a très peu

I1

T1

KT n⋅-------------- 1.515

0.0458 5.9⋅---------------------------- 5.61A= = =

E1 RT I KE n ω⋅ ⋅+⋅ 2.49 5.61 0.0458 5.92.5

0.0525----------------⋅ ⋅+⋅ 26.84V= = =

η1

P1in

P1out------------

T1 ω⋅E1 I1⋅--------------- 1.515 47.62⋅

26.84 5.61⋅------------------------------- 47.91= = = =

I20.11

0.0458 5.9⋅---------------------------- 0.407A= =

E2 2.49 0.407 0.0458 5.92.5

0.0525----------------⋅ ⋅+⋅ 13.88V= =

η20.11 47.62⋅13.88 0.407⋅------------------------------- 92.7= =

I31.296

0.0458 5.9⋅---------------------------- 4.80A= =

E3 2.49 4.80 0.0458 5.91.8

0.0525----------------⋅ ⋅+⋅ 21.22V= =

η31.296 34.29⋅21.22 4.80⋅------------------------------- 43.63= =

I40.11

0.0458 5.9⋅---------------------------- 0.407A= =

E4 2.49 0.407 0.0458 5.91.8

0.0525----------------⋅ ⋅+⋅ 10.28V= =

η40.11 34.29⋅10.28 0.407⋅------------------------------- 90.15= =



d’importance puisque la seule conséquence qui sera remarquée est une légère baisse de l’accélération près de

la vitesse maximale, le profil trapézoïdal sera donc légèrement arrondi. Pour le reste des valeurs, il n’y a aucun

problème et elles permettront de valider les batteries, les ponts en H ainsi que de calculer l’autonomie

électrique.

5.1.6 Suspension

La deuxième épreuve de la compétition comporte un double plan incliné de 11,3 degrés. Face à cet élément, il

fallait dans un premier temps vérifier si la configuration choisie allait permettre au robot de passer le plan

incliné sans problème. La réponse est non, puisque les roues-libres avant et arrière soulèvent les roues motrices

à l’entrée et à la sortie du plan. La figure 5-5 illustre cette situation. Ayant, à ce moment, seulement deux points

d’appuis, il est clair que la stabilité n’était pas assurée et la solution n’était pas valable.

Figure 5-5: Perte de motricité sur le plan incliné

Il était donc nécessaire de développer un système permettant aux roues motrices de garder contact avec le sol.

De plus, un critère de 20 degrés a été établi pour l’angle du plan incliné que le robot devait pouvoir passer.

Plusieurs solutions ont été étudiées, la grande majorité étant des concepts de suspension à différents endroits

sur la base mécanique. Le fait d’ajouter une suspension directement aux roues-libres complexifiait grandement

la conception et la fabrication de ces roues et il était difficile de respecter la contrainte de 20 degrés.

La solution retenue est considérée comme étant la plus simple (parmi les concepts soulevés!) et elle permet

facilement de respecter la contrainte de 20 degrés. On peut voir le résultat final à la figure 5-6. Nous

remarquons donc que les plaques qui supportent les roues-libres sont munies d’un axe de rotation situé près de

l’axe des roues motrices. Nous remarquons également que chacune de ces plaques est munie de deux

ensembles ressort-amortisseur. Cet ensemble est en fait un produit commercial pour voitures téléguidées de

haute performance (format 1:8). Il a en fait été nécessaire de changer le ressort des ensembles pour des ressorts

roue motrice



à constante d’élasticité plus élevée pour réussir à contrer l’inertie appliquée à ces ressorts. Cette solution

permet un angle d’ouverture positif (roues-libres vers le haut) mais également négatif (roues-libres vers le bas),

ce qui évite au robot de basculer au sommet du double plan incliné. Le comportement sur le plan incliné du

robot muni de cette suspension est illustré en figure 5-7. Cette solution nous assure donc le passage sans aucun

problème du plan incliné.

Figure 5-6: Suspension du robot SpinoS

Figure 5-7: Robot muni de sa suspension sur le plan incliné

5.1.7 Roues-libres

Les roues-libres assurent la stabilité du robot pour les différents mouvements possibles. Comme il a été

mentionné précédemment, nous disposons d’une roue-libre à l’avant et d’une autre à l’arrière pour obtenir des

performances intéressantes. Nous savons que les mouvements de ces roues, en particulier lorsque le robot

passe d’une vitesse tangentielle positive à une vitesse tangentielle négative, engendrent des perturbations sur



les mouvements du robot. Plus le poids et la friction de ces roues seront importants, plus les perturbations

seront importantes. Nous cherchons donc à obtenir une roue-libre qui soit la plus légère possible et qui offre

un roulement à friction très faible. Nous désirons également une roue-libre qui puisse s’ajuster en hauteur, de

façon à pouvoir s’adapter à une variation du rayon des roues motrices.

Nous avons tout d’abord effectué une recherche pour trouver un modèle de roue-libre qui réponde à nos

besoins. Nous avons réalisé que de telles roues (légères avec peu de friction) étaient introuvables et que nous

devions donc les concevoir et les fabriquer. Après un court processus de conception et un choix judicieux de

matériaux et de composantes, nous avons obtenu le résultat illustré (en modélisation 3D) à la figure 5-8.

Figure 5-8: Roue-libre (modélisation 3D)

La roue comme tel est constituée d’un mince disque d’aluminium et ce disque est entouré d’un anneau de

caoutchouc ("O-ring"). La rotation de la roue est assurée par deux petits roulements à billes. Nous obtenons

ainsi une roue légère et ayant une bonne adhérence avec le sol. Ensuite, le support de la roue est constitué d’un

étrier fait d’un matériau composite léger et rigide. Dans cet étrier est insérée une vis (permettant l’ajustement

de la hauteur de la roue) qui sert de lien entre l’étrier et le point de fixation et de rotation de la roue-libre (disque

à trois trous au-dessus). Le point de fixation et de rotation permet de fixer la roue-libre à la base mécanique du

robot et elle permet également à la roue de s’orienter selon le sens du mouvement. La rotation de cet axe est

assurée pas un roulement à billes. Nous obtenons donc un résultat très satisfaisant puisque la roue obtenue est

très légère grâce à l’utilisation de matériaux légers, qu’elle offre un frottement est minime grâce aux

roulements à bille et finalement qu’elle est ajustable en hauteur comme nous le désirions au départ.

5.1.8 Module de ramassage de boules de billard

Le module de ramassage de boules doit être en mesure de récupérer une boule de billard située sur un portoir



dont les dimensions sont spécifiées dans les règlements de la compétition (voir figure 2-1), soit 4x20cm. De

plus, le portoir est relativement léger et une pénalité est attribuée lorsqu’un portoir tombe durant le ramassage.

Le processus de développement de notre solution a en fait débuté il y a un peu moins de 2 ans lorsque l’équipe

devait résoudre le même problème pour une participation à la compétition avec notre robot précédent, B0b4.

Après de nombreuses discussions et scéances de remue-méninges, une idée plutôt géniale a été soulevée par

un membre. Cette idée constitue le point fort de la solution. En fait, elle la simplifie considérablement

puisqu’elle permet l’utilisation d’un outil non articulé pour récupérer la boule: une simple surface adhésive!

L’idée est de se fier sur une surface suffisamment adhésive pour récupérer la boule. L’idée complète de la

solution est donc de réussir à transporter une surface adhésive au-dessus de la boule pour qu’elle puisse s’y

coller, et ensuite revenir vers le robot en conservant la boule collée à la surface.

Pour que la surface soit suffisamment adhésive, il a fallu faire quelques tests pour réaliser que l’utilisation

d’une couche d’épaisseur assez faible (de 1 à 2cm suffisent) de matériau de rembourrage disposée entre une

surface rigide (une plaque d’aluminium en l’occurence) et la surface d’adhésion permettait une adhésion

beaucoup plus forte de la boule. En effet, grâce au rembourrage, il suffit d’écraser légèrement la surface

d’adhésion sur la boule pour obtenir une surface de contact beaucoup plus grande et donc une meilleure force

d’adhésion. La figure 5-9 illustre l’utilité du rembourrage. La surface d’adhésion peut être constituée

simplement d’un ruban adhésif de bonne qualité (par exemple du fameux et valeureux "duct tape"!).

Figure 5-9: Surface adhésive et rembourrage pour le ramassage de boules

Une fois cette idée mise de l’avant et approuvée, il fallait trouver un moyen de déplacer notre outil de

récupération du robot à la boule et ensuite de la boule au robot. C’est à ce niveau que nous avons laissé tomber

le module précédent qui était trop difficilement intégrable à la base mécanique. Encore une fois, après de

nombreuses discussions et remue-méninges, une excellente idée fut soulevée: l’adaptation d’un bras Rhino

rembourrage

surfaceadhésive

surfacerigide



XR31 pour en faire un module de ramassage de boule! La structure mécanique de ce bras robotisé est

particulièrement bien adaptée à notre problème pour plusieurs raisons. Premièrement, le bras comporte des

joints couplés ce qui permet de conserver notre surface d’adhésion parallèle avec le sol. Ensuite, sa structure

mécanique est conçue pour fonctionner avec des moteurs Pittman et nous en avons plusieurs modèles (usagés,

mais toujours fonctionnels!) en réserve. Finalement, son intégration au robot était facilement réalisable.

En fait, seulement deux membrures ainsi que la base du bras sont nécessaires. Pour mieux voir la solution dont

il est question, la figure 5-10 présente le module de ramassage de boule attaché au robot en train d’effectuer le

ramassage. On peut y remarquer le bras robotisé adapté qui est seulement formé de sa base et de deux de ses

membrures originales. Grâce aux couplages des joints des deux membrures utilisées, il est possible d’utiliser

un seul moteur pour déplacer la surface d’adhésion de l’arrière vers l’avant et du haut vers le bas

simultanément, tout en conservant la surface d’adhésion parallèle au sol. Il suffit ensuite de faire touner le

moteur en sens inverse pour revenir au point initial2. Il est nécessaire également, selon les règlements de la

compétition, de conserver les boules ramassées à l’intérieur du robot. Pour ce faire, un tube cylindrique de

10cm de diamètre (non présent sur la figure) et d’une longueur de 25cm (pour contenir 4 boules) est fixé à la

base du bras robotisé. Les boules y pénètrent grâce à un petit clapet qui fait décoller la boule de la surface

adhésive. Finalement, il est nécessaire de fixer la base du bras à la base du robot mobile. Un lien rigide est alors

disposé entre les deux bases et une roue-libre supplémentaire est disposée en-dessous de la base du bras

robotisé pour lui permettre de suivre les mouvements du robot mobile. Ainsi, l’orientation du bras robotisé est

simplement contrôlée grâce au contrôle de l’orientation du robot.

Concernant l’outil de ramassage, la surface adhésive, il est imporant de mentionner que cette dernière offre

une surface de ramassage de 9,14x16,76cm. Les dimensions de cette surface sont importantes puisqu’elle

permettent de déterminer la précision minimale acceptable pour notre algorithme de ramassage. Cette

contrainte constitue en fait un avantage considérable par rapport à une solution qui utiliserait un outil plus

évolué de ramassage. En effet, considérons par exemple l’utilisation d’une pince motorisée pour le ramassage

de la boule. Il serait nécessaire à ce moment de positionner la boule parfaitement au centre la pince pour eviter

d’échapper la boule ou encore de faire tomber le portoir. Il serait donc probablement nécessaire d’utiliser une

boucle de rétroaction pour ajuster la position de la pince. Dans notre cas, nous pouvons considérer que notre

algorithme est suffisamment précis pour nous assurer que la boule se retrouvera assurément à une certaine

position sur la surface d’adhésion. Ainsi, il n’est pas nécessaire d’utiliser une rétroaction pour positionner

1. Le Rhino XR3 est un bras robotisé éducationnel à 6 degrés de liberté. Il est utilisé pour les laboratoires d’un cours de robo-tique de l’École Polytechnique. Le comité SAE Robotique avait en sa possession un exemplaire non fonctionnel.

2. Un seul axe, asservi en position angulaire est nécessaire pour contrôler l’outil du module de ramassage.



l’outil par rapport à la boule. Cela simplifie et accélère grandement la séquence de ramassage. Nous devons

toutefois vérifier que la précision de l’algorithme est suffisante et des essais ont démontré que oui.

Figure 5-10: Module de ramassage de boules en action

La solution présentée dans cette section est donc le résultat du travail d’habiles bricoleurs. Évidemment, si

nous avions eu plus de temps et d’argent pour développer notre solution, nous n’aurions probablement pas

récupéré du vieux matériel et aurions passé par un processus de développement beaucoup plus rigoureux.

Néanmoins, le résultat obtenu est très satisfaisant puisque la solution est simple, tant au niveau mécanique

qu’au niveau contrôle, et elle est surtout très efficace. D’ailleurs, ce module ne sert qu’à l’épreuve de

ramassage de boules pour la compétition et n’est donc à peu près jamais utilisé. Il était donc important de ne

pas investir une somme énorme de temps dans cette solution pour ne pas nuire au développement du reste de

ce projet.

5.2 Conception électrique et électronique

La conception électrique et électronique doit débuter avec le choix de l’architecture. Le choix de l’architecture

du système électrique et électronique constitue en fait l’identification de toutes les composantes qui formeront

le système. Nous pouvons diviser cette architecture en deux sections, soit l’alimentation et l’électronique de

contrôle. Les sections suivantes présentent l’architecture qui a été retenue.

5.2.1 Structure globale

La figure 5-11 présente la structure du système électrique et électronique du robot SpinoS. Les prochaines



pages décrivent chacun des éléments de cette structure, ainsi que les entrées/sorties entre chaque élément. Les

fiches techniques des principaux éléments de cette structure peuvent être retrouvées dans le répertoire

fiches_techniques du CD joint à ce rapport.

Figure 5-11: Structure électrique et électronique du robot SpinoS

5.2.2 Électronique de contrôle

L’électronique de contrôle correspond en quelque sorte au système nerveux du robot. Elle doit être consituée

dans un premier temps d’une unité de traitement informatique (micro-contrôleur ou ordinateur embarqué) qui

permet d’implanter les différents algorithmes désirés. Ensuite, un système permettant l’asservissement des

moteurs doit être utilisé. Ce système est généralement constitué d’un contrôleur de moteurs effectuant

l’asservissement (ce contrôleur pourrait aussi être implanté dans le logiciel), de circuits électroniques

permettant d’acquisitionner les encodeurs des moteurs (ou autres capteurs permettant de fermer la boucle de

contrôle) et de générer les signaux de commande appropriés et finalement de circuits amplificateurs permettant

de transmettre la commande désirée aux moteurs. Ensuite, il est nécessaire d’incorporer un système sensoriel

au robot: les capteurs. Pour effectuer de la vision artificielle, il est nécessaire d’utiliser une carte de capture

vidéo ("frame grabber") pour numériser et transmettre un signal reçu d’une caméra vidéo (généralement un

signal analogique) à l’unité de calcul. Si nous désirons également utiliser différents capteurs sur le robot, il est

DC-DCPC

embarqué

Acquisitionvidéo

CarteI/OCapteur 1

CartePMD

Capteur 2

Pont enH

: alimentation: signaux numériques: signaux de puissance: signaux analogiques

Caméra1

MoteurDC

Encodeur

.

.

.

X 3

PC/104+(PCI) PC/104

(ISA)

Capteur 3

Caméra2

Batteries24V

STRIP CATAS



nécessaire de compter sur une interface entre ces capteurs et l’unité de calcul. Généralement, des cartes

d’entrées/sorties analogiques et/ou numériques peuvent être utilisées. Il est alors possible d’incorporer au

robot une multitude de capteurs utiles. Voici donc les éléments de base qui permettent d’obtenir un système

électronique modulaire pour un robot mobile.

5.2.2.1 Ordinateur embarqué

• Fabricant: Kontron Communications

• Modèle: Viper830

Les deux principales options envisageables pour répondre aux besoins de calculs et de souplesse de notre

application robotique sont l’utilisation d’un ordinateur embarqué ayant les principaux éléments d’un

ordinateur complet ou encore l’utilisation d’un circuit dédié (généralement fait sur mesure) muni d’un micro-

contrôleur comme unité de calcul.

Les avantages du circuit à micro-contrôleur sont principalement sa simplicité, son économie d’énergie et le

petit volume qu’il occupe. Vue la puissance de calcul toujours grandissante des micro-contrôleurs et les outils

de développement disponibles, cette option est intéressante pour une application ne nécessitant pas de

programmation en langage de très haut niveau (par exemple le C++) ni de vision artificielle. Il était prévu dès

le début du projet que l’utilisation d’un langage de très haut niveau ainsi que de la vision artificielle étaient

nécessaires et il fallait donc oublier cette solution.

L’ordinateur embarqué est très semblable à un ordinateur de bureau puisqu’il utilise généralement une

architecture similaire. De plus, les différents bus externes de l’ordinateur de bureau sont adaptés ou remplacés

par des bus respectant des standards d’informatique embarquée (PC/104, PC/104+, CompactPCI, STD32, etc.)

permettant ainsi l’utilisation de cartes beaucoup plus compactes et robustes. Les ordinateurs embarqués

retrouvés sur le marché présentement incorporent généralement, à même la carte mère, la grande majorité des

éléments de base d’un ordinateur de bureau: CPU, mémoire vive, processeur graphique avec mémoire vive,

contrôleur Ethernet, etc. Cette solution était donc à nos yeux beaucoup plus intéressante. Cette solution est

d’ailleurs préconisée au sein du groupe depuis maintenant plusieurs années.

Le choix de l’ordinateur comme tel ne fut pas bien difficile, puisque Kontron Communications (il n’y a pas

très longtemps Teknor), un fabricant d’ordinateurs industriels, nous offrait généreusement une commandite.

Parmi leurs produits, un seul était particulièrement bien adapté à nos besoins, soit la carte Viper830. Cette carte

mesure 18,1x12,2cm et elle inclut sur la carte-mère les bus PC/104 et PC/104+, un processeur graphique avec



mémoire vidéo, une connexion Ethernet, de la mémoire vive (128Mo) et un processeur Intel Celeron cadencé

à 566MHz. L’utilisation du bus PC/104+, en réalité le bus PCI, est intéressante puisqu’elle permet un taux de

transfert suffisamment rapide pour la carte d’acquisition vidéo. Grâce à cet ordinateur, nous pouvons

facilement incorporer les cartes de contrôle développées par l’équipe et utiliser notre système d’exploitation

préféré et les langages de programmation choisis. La figure 5-12 présente donc l’ordinateur embarqué utilisé

sur le robot avec une carte de contrôle sur le bus PC/104. Les spécifications (mécaniques et électriques) des

standards PC/104 et PC/104+ peuvent être retrouvées à cette adresse: (http://www.pc104.org/technology/

pc104_tech.html).

Figure 5-12: Ordinateur embarqué du robot SpinoS

5.2.2.2 Disque dur

• Fabricant: IBM

• Modèle: DSCM-11000

L’utilisation d’un disque dur standard pour ordinateur de bureau n’est pas conseillée pour une utilisation sur

un robot mobile dûe à sa faible résistance aux chocs et vibrations mécaniques et au grand volume qu’il occupe.

D’ailleurs, nous avons vécu de nombreuses mauvaises expériences par le passé, par exemple un disque dur

commençant à mal fonctionner durant une compétition! Trois options beaucoup plus robustes et moins

volumineuses sont alors à envisager: disque dur d’ordinateur portable, module de mémoire Flash compatible

IDE et disque dur miniature. Le disque dur de portable est plus robuste et moins volumineux qu’un disque dur

standard, ce qui constitue donc une nette amélioration. Il est également possible d’obtenir un espace de


http://www.pc104.org/technology/pc104_tech.html

http://www.pc104.org/technology/pc104_tech.html


mémoire considérable (quelques Go) pour un prix assez faible. Pour ce qui est des modules de mémoire Flash,

ils occupent un volume généralement très petit et ils offrent une quantité de mémoire toujours grandissante (le

maximum disponible étant de 512Mo à l’heure actuelle). Ils sont toutefois assez coûteux et le taux de transfert

de données est plus faible que celui d’un disque dur standard. Le disque dur miniature est en fait un produit

développé récemment par IBM, le Microdrive. Ce disque utilise principalement la même technologie qu’un

disque dur standard, mais miniaturisée. Il présente à peu près les mêmes caractéristiques que les modules de

mémoire Flash, malgré un prix légèrement plus faible, un taux de transfert légèrement plus élevé et une

quantité de mémoire supérieure (le maximum disponible étant de 1Go à l’heure actuelle). Les deux dernières

options sont particulièrement intéressantes à utiliser avec notre ordinateur embarqué, puisqu’un module, le

T069, permet d’insérer le module en dessous des cartes PC/104 et PC/104+. Le module de mémoire ne prend

donc à ce moment aucun espace supplémentaire. Le disque dur miniature de 1Go est particulièrement

intéressant puisqu’il prend très peu d’espace (4,3x3,6x0,5cm), consomme peu d’énergie et offre une quantité

de mémoire amplement suffisante pour installer un système d’exploitation muni de nombreux utilitaires. On

peut voir le disque miniature en question inséré dans le module T069 à la figure 5-13.

Figure 5-13: Disque dur Microdrive 1Gigaoctets d’IBM inséré dans le module T069 de Kontron

5.2.2.3 Carte d’entrées/sorties

• Fabricant: Versalogic

• Modèle: PCM-3724

Afin de permettre une installation simple et rapide de nouveaux capteurs de toute sorte sur le robot, il est

nécessaire de compter sur une interface simple et fiable entre l’ordinateur et les différents capteurs. Cette

interface doit évidemment être déterminée en fonction de l’ordinateur, mais également en fonction des



différents capteurs nécessaires au robot. Dans notre cas, nous n’avons identifié aucun capteur générant des

signaux analogiques comme étant nécessaires au robot, nous savions donc à priori qu’une carte à entrées/

sorties analogiques n’était pas nécessaire. Par contre, nous avons rapidement identifié de nombreux capteurs

à signaux numériques (module de suivi de ligne, détecteurs catadioptriques, capteurs de contact, capteurs

d’inclinaison, détecteurs de proximité, etc.). Il nous fallait donc trouver une carte comportant de nombreuses

entrées/sorties numériques et s’intégrant facilement à notre ordinateur. Une carte en format PC/104 était un

choix intéressant puisque de nombreux produits sont disponibles sur le marché. La carte que nous avons

choisie, la PCM-3724 fabriquée par Versalogic, comporte 48 entrées/sorties numériques et s’interface sur le

bus PC/104. Nous avons choisi cette carte puisqu’elle est peu coûteuse et que le pilote d’interface était très

facile à développer. Les 48 entrées/sorties sont partagées en 6 ports (A0, B0, C0, A1, B1, C1) de 8 bits. Chacun

des ports est configurable en entrée ou en sortie et il est possible d’utiliser une interruption sur chacun des bits

0 des ports C0 et C1.

5.2.2.4 Carte d’acquisition vidéo

• Fabricant: Sensoray

• Modèle: 311

Cette carte permet de faire l’acquisition d’un signal vidéo analogique provenant d’une caméra vidéo afin

d’effectuer la vision artificielle nécessaire au contrôle du robot. Il existe plusieurs cartes différentes sur le

marché dont plusieurs sont en format PC/104 ou PC/104+. Nous devions choisir en premier lieu le format que

nous désirions utiliser. L’élément décisif à ce moment était le taux de transfert de données des 2 bus (ISA et

PCI), car il est clair que l’acquisition d’image vidéo à une qualité et une vitesse satisfaisantes demande un taux

de transfert élevé. Sur le bus ISA (PC/104), qui fonctionne sur notre ordinateur à 8,33MHz avec 16bits de

données, nous obtenons un taux de transfert maximal de 8Mo/s. Sur le bus PCI (PC/104+), qui est configuré

sur notre ordinateur à 33MHz avec 32bits de données1, nous obtenons un taux de transfert maximal de 132Mo/

s. Supposons que nous désirions acquisitionner une image en couleur, disons en RGB 4bits (16bits au total),

d’une dimension de 640x480 pixels à un taux de 30images/s, ce qui correspond à une qualité d’image

acceptable mais non optimale. Nous aurions ainsi besoin d’un taux de transfert de 640x480x16x30/8 =

18,4Mo/s, ce qui dépasse les spécifications du bus ISA et qui respecte amplement celles du bus PCI. Nous

avons donc choisi de regarder strictement les différentes cartes disponibles en format PC/104+.

Les principaux critères de sélection furent le prix de la carte ainsi que la qualité d’image obtenue. En fait, nous

1. Ceci correspond aux spécifications du standard PC/104+. Le bus PCI se fait maintenant en version beaucoup plus rapide,par exemple 133MHz avec 64bits de données qui offre un taux de transfert maximal de 1Go/s.



n’avons trouvé qu’un seul type de carte qui soit vraiment moins dispendieux, pour une qualité plus

qu’acceptable que les autres cartes sur le marché. Ce type de carte est composé d’un circuit intégré Bt848 (ou

encore Bt878) qui assure une qualité d’acquisition raisonnable à coût intéressant. Plusieurs manufacturiers

produisent ce type de carte. Nous avons choisi le modèle 311 du fabricant Sensoray puisque le prix était

intéressant et nous pouvions obtenir le produit dans un délai assez court. La carte retenue utilise donc le

standard PC/104+ et elle permet d’acquisitionner une image couleur sous différents formats. Les formats

intéressants sont les modes RGB 15,16,24 ou 32bits/pixel. En utilisant une caméra en format NTSC, nous

pouvons recueillir jusqu’à 30images/s d’une dimension maximale de 752/480pixels. Une caractéristique

particulièrement intéressante de cette carte est qu’elle permet l’entrée de deux signaux vidéos distincts. Cette

possibilité vient rejoindre l’idée de conserver un robot entièrement symétrique, tant aux niveaux mécanique,

électronique et informatique. Il y aurait ainsi possibilité de disposer une caméra vers l’avant et une caméra vers

l’arrière. Cette carte répond donc amplement à nos besoins.

NOTE: Cette carte n’est présentement pas utilisée puisque la vision artificielle n’a pas encore été implantée

sur le robot.

5.2.2.5 Carte de contrôle de moteurs

Le contrôle des moteurs peut être fait par logiciel ou encore grâce à une carte dédiée. Le contrôle logiciel est

intéressant puisqu’il permet d’implanter les algorithmes de contrôle comme nous le jugeons nécessaire. Cette

solution offre donc une flexibilité intéressante et peut être suffisamment performante si la boucle de contrôle

est suffisamment rapide. Évidemment, il sera alors nécessaire d’ajouter l’électronique permettant de lire les

encodeurs et de générer la commande à envoyer aux moteurs.

Une carte dédiée est quant à elle une solution entièrement matérielle et elle est généralement composée de

micro-contrôleurs ou de circuits spécifiquement conçus pour le contrôle de moteurs. De plus, elle inclut

généralement l’électronique permettant de lire les encodeurs et générer les signaux de commande. La

performance obtenue grâce à une telle carte peut être supérieure à celle obtenue d’une solution logicielle

puisque la boucle de contrôle peut être beaucoup plus rapide. Les gains des contrôleurs peuvent également être

ajustés précisément pour un contrôle robuste et performant. Cette solution offre toutefois peu de flexibilité

puisque seuls les modes de contrôle disponibles peuvent être utilisés.

Nous avons retenu la solution matérielle puisque nous pouvions compter sur une carte que nous utilisons

depuis quelques années maintenant et qui nous offre des performances très satisfaisantes. La carte en question



a été conçue et fabriquée sous forme de circuit imprimé respectant le format PC/104 par un ancien membre de

l’équipe dans le cadre d’un projet de fin d’études. La carte, qui est d’ailleurs présente sur la figure 5-12, est

principalement composée de 3 circuits intégrés: un FPGA et deux circuits dédiés PMD (Performance Motion

Devices). Les circuits PMD permettent d’asservir en position ou en vitesse, par des compensateurs PID, 4

moteurs DC. Le premier circuit intégré (I/O) gère la communication entre les entrées/sorties du système et le

processeur hôte tandis que le second circuit (CP) calcule et envoie les commandes aux moteurs sous forme de

signal à PWM ("Pulse Width Modulation"). La description complète de ces circuits peut être trouvée en [7].

Le FPGA sert principalement d’interface entre les circuits PMD et l’ordinateur embarqué. Il est donc en

mesure de recevoir des instructions (par exemple l’ajustement des gains ou la mise à jour des valeurs désirées)

provenant du bus ISA (PC/104) et de les transmettre aux circuits PMD. Il est également en mesure de prendre

des données des registres des circuits PMD (par exemple les données des encodeurs) et de les transmettre au

programme de contrôle. La période de la boucle de contrôle est spécifiée lors de l’initialisation des circuits

PMD. La période minimale permise dépend du nombre d’axes asservis. Chaque axe demande une période

minimale de 100us ce qui fait une période minimale de 300us dans notre cas. Nous choisissons d’utiliser la

période minimale pour obtenir un contrôle le plus précis possible. La description complète du projet qui a mené

à la création de cette carte peut être trouvée en [4].

Nous utilisons donc cette carte pour asservir en vitesse les deux moteurs des roues motrices et asservir en

position le moteur du ramasse-boules. Pour l’asservissement en position, deux modes sont disponibles: mode

trapézoïdal et mode "S-curve". Pour le mode trapézoïdal, l’accélération et la vitesse maximales doivent être

spécifiées de façon à ce que le contrôleur génère un profil de vitesse trapézoïdal adéquat à chaque mise à jour

de la position désirée. Pour le mode "S-curve", la dérivée de l’accélération (le "jerk") doit également être

spécifiée de façon à générer un profil de vitesse continu (presque trapézoïdal, mais avec les coins arrondis).

Ce mode est d’ailleurs utilisé pour le moteur du ramasse-boules. Pour l’asservissement en vitesse, un profil

trapézoïdal doit être utilisé. On doit, dans ce mode, spécifier au contrôleur l’accélération désirée et il générera

un profil trapézoïdal à chaque mise à jour de la vitesse désirée.

Il est important de bien comprendre le fonctionnement du système de contrôle des moteurs pour ainsi le

maîtriser. Ce système peut être résumé par le schéma-blocs présenté à la figure 5-14. On y retrouve

premièrement le contrôleur de vitesse comme tel, formé du bloc de ’Génération de trajectoire’ qui s’occupe de

mettre à jour l’orientation désirée pour respecter le profil trapézoïdal spécifié, de la mesure de l’erreur sur

l’orientation du moteur et finalement d’un bloc ’PID+Vff’ qui est en fait un compensateur PID avec gain

anticipatif sur la vitesse angulaire désirée (terme ’Vff’). Le compensateur PID se charge de déterminer la

commande à envoyer au moteur sous forme de PWM1 (d’amplitude 0-5V, donc en valeur absolue) et le sens



de rotation désiré (’SENS’) puisque le PWM est en valeur absolue. Ces deux signaux sont reçus par le pont en

H qui s’occupera d’amplifier le signal de commande 0-5V en un signal 0-24V selon le sens de rotation désiré

et de fournir également le courant nécessaire au moteur (le fonctionnement du pont en H est décrit en section

5.2.2.6). Évidemment, le moteur réagira à la tension reçue du pont en H et l’orientation du moteur pourra être

mesurée par le contrôleur grâce à l’encodeur optique du moteur. Le fonctionnement est le même, quel que soit

le mode d’asservissement choisi, puisque la génération de trajectoire se charge de mettre à jour l’orientation

désirée en respectant les paramètres du mode choisi. Il est important de remarquer que le compensateur est

donc appliqué sur l’orientation. Il est donc nécessaire d’ajuster les gains du contrôleur pour une commande en

orientation sans génération de trajectoire. De cette façon, si la réponse est ajustée de façon optimale, nous

sommes assurés d’obtenir une réponse excellente sur une grande plage d’entrées. La réponse devrait donc être

excellente peu importe le mode de contrôle choisi puisque l’asservissement se fait toujours en orientation. Le

choix des gains peut donc se résumer au choix des gains d’une boucle d’asservissement PID sur l’orientation

d’un moteur DC. Le gain anticipatif doit toutefois être considéré pour l’asservissement en vitesse.

Figure 5-14: Schéma-blocs du système de contrôle des moteurs

5.2.2.6 Hacheurs de courant

Les hacheurs de courant constituent les amplificateurs qui permettent de transmettre aux moteurs les signaux

de commande, obtenus de la carte de contrôle, en amplifiant leurs tensions et leurs courants. Les hacheurs de

courant (ou ponts en H dans notre cas) sont beaucoup plus efficaces au niveau énergétique que des

amplificateurs linéaires. C’est la principale raison qui a motivé l’équipe à utiliser ce type d’amplificateur

1. PWM (’Pulse Width Modulation’): modulation de la longueur d’impulsion d’un signal généralement dans le but d’enrécupérer la valeur moyenne.

PID+Vff

Génération detrajectoire

Pont enH

24 VDCM encE

theta des.

theta

PWM

SENS

+

-

+

-

-+



depuis plusieurs années. Cette solution est d’ailleurs la plus courante pour l’alimentation de moteurs DC à

balais. Il existe quelques versions commerciales de circuits étant bien adaptés pour notre type de moteur.

Toutefois, nous pouvions encore une fois compter sur un circuit ayant été conçu et fabriqué par un ancien

membre de l’équipe dans le cadre d’un projet de fin d’études. La version obtenue de ce projet de fin d’études

est le fruit de quelques années d’expérience de l’équipe avec ce type de circuit et elle vient résoudre le principal

problème des versions précédentes: la fiabilité. En effet, dû aux importantes crêtes de courant et de tension aux

bornes des transistors du circuit amplificateur et aux courants importants demandés par les moteurs en

accélération, la dissipation thermique est importante et les composantes doivent être en mesure d’effectuer

cette dissipation. Le circuit présenté à la figure 5-15 montre un pont en H utilisé pour l’alimentation d’un

moteur. On peut remarquer le dissipateur de chaleur muni d’un ventilateur, un ensemble qui permet une

dissipation thermique beaucoup plus grande. Ces circuits ont été réalisés sous forme de circuits imprimés très

compacts (8,26cm X 5,46cm). Les détails sur la conception et le fonctionnement de ce circuit peuvent être

trouvés en [5].

Figure 5-15: Pont en H (hacheur de courant) du robot SpinoS

Les hacheurs de courant sont principalement constitués de MOSFETs (transistors à effet de champs) agencés

en pont en H, d’un circuit d’alimentation des grilles des MOSFETs, d’un circuit d’isolation par optocoupleurs

et d’éléments de protection contre les surcharges de courant et de tension. Grâce au pont en H, ce circuit

permet de contrôler la vitesse d’un moteur DC en amplifiant la tension et le courant du signal MLI provenant

des cartes d’asservissement tout en respectant le sens de rotation demandé. Le concept du pont en H est assez

simple et il est illustré à la figure 5-16. Les MOSFETs sont représentés comme des interrupteurs contrôlés

puisqu’ils agissent effectivement comme des interrupteurs. Le contrôleur d’alimentation des grilles reçoit les

signaux ’PWM’ et ’SENS’ de la carte de contrôle et il s’occupe d’activer les MOSFETs appropriés selon le



sens de rotation demandé. Ainsi, en fonction du bit de sens, le signal ’PWM’ sera transmis à la paire de

MOSFETs 1-3 ou 2-4. Nous remarquons donc que la tension aux bornes du moteur est inversée selon la paire

de MOSFETs qui est activée, ce qui permet au moteur de tourner dans les deux sens. Il est important de noter

que le signal PWM a une fréquence fixée à 24,5kHz, ce qui est amplement suffisant pour que le moteur ne voit

à peu près que la valeur moyenne (fréquence DC) du signal PWM, puisque le circuit électrique du moteur est

un filtre passe-bas.

Figure 5-16: Schéma d’un hacheur de courant

5.2.2.7 Module de suivi de ligne

Le détecteur de ligne au sol, module “STRIP” sur le schéma électrique, est le module qui nous permet de

localiser la ligne au sol. Le circuit développé pour le projet SpinoS constitue en fait une révision du circuit

développé initialement par des anciens membres de l’équipe. Les détails sur la conception et la fabrication de

ce circuit peuvent être trouvés dans [6]. Puisque la révision de ce circuit devrait faire l’objet d’un rapport à elle

seule et que tel n’est pas l’objet du présent rapport, seuls quelques détails sur le fonctionnement et la révision

de ce circuit seront présentés. Le lecteur est donc invité à lire le rapport du circuit initial.

Les éléments permettant de détecter la ligne sont de petits capteurs infrarouge mesurant le contraste d’une

surface de réflexion. La capteur en question est le OPB706A fabriqué par OPTEK. Ce capteur est constitué

d’une diode émettrice de lumière infrarouge et d’un phototransistor. Grâce au signal mesuré du

phototransistor, nous sommes en mesure de connaître le contraste de la surface sur laquelle la lumière

infrarouge a été émise. Ce que nous cherchons à faire avec ce capteur est de différencier des surfaces de tons

de gris différents, en l’occurence le noir et le blanc. Puisque nous désirons être le plus insensible possible aux

différentes sources de lumière infrarouge (l’éclairage à 60Hz en est une source importante), nous pulsons le

Contrôleur/Driver

PWM

SENS

Batt

--

+

PWM2

PWM1

M

1

23

4



signal infrarouge à 1,5kHz et mesurons la réception de façon synchronisée. Cette technique, bien documentée

dans [6] est très efficace pour une immunité aux sources externes. Le circuit de détection de la ligne est donc

composé de 32 capteurs infrarouge disposés en ligne. Ce circuit est illustré à la figure 5-17. On peut voir sur

l’image que cette partie du circuit n’est composée que des 32 capteurs, il est donc nécessaire d’utiliser un

circuit de traitement pour retrouver la position de la ligne.

Figure 5-17: Ligne de capteurs infrarouge du module de suivi de ligne

Le circuit de traitement doit permettre dans un premier temps de discrétiser le signal reçu de chacun des

phototransistors et ensuite transmettre cette information à l’ordinateur embarqué par une interface quelconque.

La discrétisation est effectuée à l’aide de comparateurs qui comparent le signal reçu (filtré par un filtre passe-

bande à 1,5kHz) avec un signal de référence, un seuil de différentiation. Si le signal est plus élevé que le seuil

pour un capteur donné, le signal sortant du comparateur sera un ’1’ logique et nous pouvons alors considérer

ce bit comme étant blanc. Si le signal reçu est au contraire inférieur au seuil de détection, la sortie du

comparateur sera un ’0’ logique et ce bit sera considéré comme étant noir. Il est important de mentionner que

le seuil de différentiation est ajustable et qu’il est possible d’ajuster la sensibilité du circuit pour être en mesure

de différencier différentes couleurs suffisamment contrastées. Par exemple, il serait possible de détecter une

ligne de couleur jaune peinte sur un fond de couleur verte (un vert suffisamment foncé par contre!).

Grâce aux comparateurs, nous avons donc obtenu les 32 bits de la ligne de capteurs, il reste seulement à les

transmettre à l’ordinateur embarqué. L’interface la plus simple pour transmettre ces bits est évidemment la

carte d’entrées/sorties numériques. Toutefois, nous ne désirons pas occuper un total de 32 bits sur la carte

d’entrées/sorties puisque nous devons tout de même garder suffisamment d’entrées/sorties pour d’autres

capteurs (même si ces entrées/sorties ne sont pas toutes occupées dans le présent, il est certain que des capteurs

seront ajoutés au robot). La solution la plus facile pour diminuer le bus entre la carte d’entrées/sorties et le

module de détection est le multiplexage. Nous décidons donc de multiplexer les 32bits en 4 séries de 8bits.

Nous avons donc besoin d’un bus de 8bits pour les valeurs des capteurs et de 2bits pour la sélection de la série.

Nous désirons également bloquer l’acquisition des capteurs durant la lecture des bits. Puisque la séquence de



lecture avec multiplexage n’est instantanée, nous devons éviter que l’état de certains bits des capteurs change

durant la lecture. Nous obtiendrions alors beaucoup trop de lectures de ligne erronées dans le programme de

contrôle (voir section 5.3.5.3). La solution à ce problème qui a été retenue est d’entrer les signaux des

comparateurs dans des bascules bloquantes qui agissent en fait comme des mémoires. Durant la séquence de

lecture, un bit sera reçu de la carte d’entrées/sorties permettant de bloquer l’état des bascules. Les 32bits seront

alors bloqués durant la séquence de lecture et ne pourront changer qu’une fois la séquence terminée. Nous

obtenons donc un total de 11 bits entre la carte d’entrées/sorties et le module de détection de ligne.

Le module de suivi de ligne en entier est montré à la figure 5-18. Nous remarquons que la ligne de capteurs et

le circuit de traitement sont divisés sur deux circuits imprimés distincts. Ceci constitue la première différence

majeure par rapport au circuit initial. La raison de cette division est que la ligne de capteurs doit se retrouver

devant le robot très près du sol (environ 3cm maximum pour une détection adéquate). Il était plutôt difficile

d’aller disposer le circuit en son entier dans une telle position vue la position de la roue-libre. De plus, il était

nécessaire de protéger le circuit de traitement des chocs et vibrations mécaniques qui peuvent être importants

à l’avant du robot. Il a donc été nécessaire de séparer les deux circuits et de les relier par des câbles plats haute

densité. Une attention particulière a dûe être portée aux différents points de masse des circuits pour préserver

autant que possible la qualité des signaux des phototransitors. L’autre différence majeure du circuit est que le

circuit initial utilisait un FPGA pour effectuer le multiplexage et le bloquage des données. Suite aux problèmes

de programmation que nous avons vécus auparavant et à la simplicité du circuit impliqué, nous avons décidé

d’utiliser des circuits logiques discrets.



Figure 5-18: Module de suivi de ligne du robot SpinoS

Il serait important de mentionner les motivations qui nous ont incité à utiliser ce genre de circuit.

Premièrement, nous avions la preuve du fonctionnement d’un tel circuit suite aux performances du robot

précédent qui utilisait le circuit initial. Ensuite, une caractéristique intéressante de ce circuit est sa fréquence

d’échantillonnage élevée (1,5kHz) comparativement par exemple à une solution utilisant la vision artificielle

(30 ou 60Hz). Cette caractéristique permet à la boucle de contrôle (le contrôleur de suivi de ligne) d’être

beaucoup plus fluide. Finalement, sa position, soit à l’avant du robot à 30cm de l’axe des roues motrices en

particulier, permet de combler le retard dû entre autre à la boucle de contrôle qui n’est pas infiniment rapide

mais surtout dû au temps de réponse relativement lent du système électro-mécanique. Cet écart par rapport à

l’axe des roues comporte un autre avantage qui est d’informer non seulement sur l’écart latéral du robot par

rapport à la ligne mais également de l’écart d’orientation du robot par rapport à la tangente de la ligne. Cette

caractéristique est particulièrement intéressante au niveau du contrôleur de suivi de ligne et elle est expliquée

à la section 7.3.Parmi les défauts de ce type de circuit, notons qu’il consomme relativement beaucoup

d’énergie pour le peu de capteurs qu’il possède. De plus, le fait de ne contenir que 32 capteurs nous donne une

position de ligne qui ne soit pas particulièrement précise.

NOTE: Ce circuit n’est pas fonctionnel présentement dû à une légère erreur sur le circuit imprimé. Nous

prévoyons le rendre fonctionnel pour le début du trimestre d’hiver 2002.

5.2.2.8 Détecteurs catadioptriques

• Fabricant: Allen-Bradley

• Modèle: RightSight (42EF-D1MNAK-F4)

Les détecteurs catadioptriques1, module “CATAS” sur le schéma électrique, sont couramment utilisés sur les

chaînes de montage automatisées pour détecter la présence d’objets à proximité. Ils sont donc généralement

utilisés comme détecteurs de proximité. Ces détecteurs étant constitués d’un émetteur et d’un récepteur de

lumière infrarouge, la détection d’objet est grandement influencée par la couleur et le refléchissement des

surfaces à détecter. La qualité de la détection dépend donc d’une multitude de facteurs et cela en fait donc une

solution assez peu fiable pour la détection d’objets. Cependant, la sensibilité du capteur est ajustable et il est

possible de l’ajuster de façon à le rendre insensible à toute surface, peu importe la distance, sauf une surface

réflectorisée2 (surface spécialement conçue pour réfléchir la lumière). La surface réflectorisée peut alors être

détectée à une distance intéressante qui n’est pas spécifiée dans la fiche technique, mais qui est supérieure à

1. Relatif à un système optique permettant de réfléchir des rayons lumineux vers leur source d’émission.2. Se dit d’une surface ou d’un matériau spécialement conçu pour réfléchir la lumière.



4m si on se fie à des tests effectués récemment.

Nous savons qu’en compétition les boules de billard sont montées sur un support recouvert d’un matériau

réflectorisé d’une largeur de 4cm. Il est donc possible, en positionnant les détecteurs catadioptriques à des

positions adéquates, de détecter la présence de boules de billard à ramasser. De plus, l’ouverture du cône de

détection des capteurs est faible, soit de 5 degrés, permettant ainsi une évaluation assez précise de l’orientation

de l’objet détecté par rapport au robot. Pour permettre la détection et le ramassage des boules de billard en

compétition, la solution retenue demande l’utilisation de trois détecteurs. Premièrement, deux détecteurs sont

placés à l’avant du robot, orienté de chaque côté du robot selon un axe parallèle à l’axe des roues motrices. Ces

deux détecteurs permettront de détecter la présence de boules à ramasser et le robot pourra ensuite s’arrêter

pour effectuer le ramassage. Un troisième détecteur, situé à l’arrière sur le module de ramassage de boules et

orienté vers l’arrière du robot, permet au robot de s’orienter de façon adéquate pour lancer le bras de

ramassage. La section 5.4.1.3 présente plus en détails la séquence de ramassage de boule. La figure 5-19

présente le robot et la configuration des détecteurs catadioptriques retenue. Il est important de noter que ces

capteurs sont interfacés en passant par la carte d’entrées/sorties numériques et qu’un petit circuit est nécessaire

pour rendre le signal de sortie des capteurs compatible TTL.

Figure 5-19: Configuration des détecteurs catadioptriques pour le ramassage de boules



5.2.3 Alimentation

5.2.3.1 Circuit d’alimentation

La figure 5-20 présente le schéma du circuit d’alimentation du robot. Ce circuit est très simple, mais il répond

pleinement aux besoins de sécurité et de flexibilité. Premièrement, on remarque les deux entrées disponibles,

sélectionnées à l’aide d’un interrupteur 3 positions, soit les batteries lorsque le robot est en mouvement et une

source 24V à courant continu externe pour le développement ou lors de tests stationnaires. Il est à noter que la

source externe n’est pas réellement à 24V mais bien à 29V puisqu’elle est également utilisée pour la recharge

des batteries. Ensuite nous retrouvons le circuit d’alimentation des moteurs qui est composé bien sûr des

moteurs et des ponts en H, mais aussi d’un interrupteur d’urgence en cas de pépin. Notons que cet interrupteur

doit accepter un courant de plus 30A puisque ce circuit est composé de 3 moteurs et que chaque moteur

demandera un maximum de 10A. Il est important de mentionner que les ponts en H et l’alimentation externe

contiennent des protections contre les court-circuits.

L’alimentation de l’électronique est assurée par deux convertisseurs DC-DC, un fournissant du 12V et l’autre

du 5V. Nous remarquons le condensateur de filtrage à l’entrée et ceux à la sortie des DC-DC. Ces

convertisseurs permettent d’atténuer le bruit électrique et les perturbations, mais il permettent également de

passer d’une entrée 24V à une autre sans avoir à fermer l’ordinateur. Cela veut donc dire que la constante de

temps résultante vue de la charge 5V (alimentation du PC) est suffisamment lente pour permettre à la tension

de rester au-dessus du seuil de réinitialisation de l’ordinateur ("reboot"). Pour se faire, des condensateurs

totalisant 13,2mF sont disposés à l’entrée et un condensateur de 3,3mF est disposé à chacune des sorties.

Une attention particulière doit être portée à la masse, puisqu’il ne faut en aucun temps relier la masse de

l’électronique de contrôle à celle du circuit des moteurs. Cela résulterait en un bruit beaucoup trop élevé pour

l’alimentation des circuits électroniques, et les circuits de protection de l’ordinateur le feraient redémarrer

régulièrement (fait vécu!). Ce bruit est causé principalement par les variations de courant dans les moteurs qui

causent des crêtes de tension et par les hacheurs de courant qui produisent un bruit élevé. Nous remarquons

donc sur le schéma que la masse de l’électronique de contrôle est bien isolée du reste du circuit. En effet, grâce

aux convertisseurs DC-DC, il est possible d’effectuer une telle isolation.



Figure 5-20: Schéma du circuit d’alimentation du robot SpinoS

5.2.3.2 Choix des convertisseurs DC-DC

• Fabricant: Astec

• Modèle: AK60A-024L-050F10

• Fabricant: Power-One

• Modèle: HBS050YH-A

Les convertisseurs DC-DC permettent de transforrmer la tension d’alimentation du robot, soit les 24V

provenant des batteries en niveaux de tension utilisés par l’électronique de contrôle, soit du +5V et du +12V.

Pour ce faire, nous utilisons deux convertisseurs distincts.

Pour choisir ces convertisseurs, il est nécessaire d’évaluer la puissance demandée par la totalité des circuits

pour un niveau de tension donné. Ces différentes valeurs de puissance se retrouvent dans les fiches techniques

des différents circuits. Voici donc ces évaluations ainsi que les choix qui en ont découlé:

Tableau 5-3 : Puissance demandée à l’alimentation +5V

Composante Puissance demandée (W)

Ordinateur embarqué 18

Disque dur miniature 0,6

Carte de contrôle 1,5

Carte d’entrées/sorties 0,5

Carte d’acquisition vidéo 1,5

24 VDC 24 VDC

DC-DC5V

DC-DC12V

moteurs(ponts en H)

boutonpanique

électroniquede contrôle

+

-

+

+

-

-



Nous avons donc une demande totalisant environ 22,6W sur l’alimentation 5V. Évidemment, cette demande

pourra varier dans le temps (par exemple en fonction de l’utilisation du CPU) et nous ne pouvons prévoir tout

ce qui sera ajouté au système sur cette alimentation dans l’avenir. Il est donc primordial de conserver une

certaine marge entre la puissance disponible et la puissance demandée. Par exemple, nous considérons qu’un

module de 40W devrait être suffisant. Toutefois, le choix d’un module répondant à nos besoins n’a pas été une

tâche facile puisque la disponibilité des pièces est assez restreinte. En effet, malgré la multitude de produits

définis dans les fiches techniques, seulement quelques produits étaient disponibles chez les distributeurs.

Le produit retenu, répondant à nos besoins et qui était disponible sans délai excessif, est le modèle AK60A-

024L-050F10 du fabricant Astec. Ce convertisseur DC-DC 24-5V offre une puissance maximale de 50W en

sortie. Son efficacité peut atteindre un maximum de 83%1 et il comporte plusieurs protections contre les

surtensions et les court-circuits. Il procure également une excellente isolation électrique entre l’entrée (bruitée

à cause des moteurs) et la sortie (la moins bruitée possible). Ce module est très compact, soit de dimensions

58,42x61,0x12,7mm. Finalement, pour permettre un dissipation thermique suffisante et ainsi permettre

d’obtenir la puissance maximale sans problème, de nombreux modèles de dissipateurs sont disponibles. Nous

avons choisi le modèle APA-501-60-005 de Astec qui offre une résistance thermique assez faible de

2,8

Nous obtenons donc une demande d’environ 15,7W sur l’alimentation 12V. Encore une fois, nous devons

conserver une certaine marge de manoeuvre pour permettre des ajouts futurs. Nous pourrions considérer

Circuit d’adaptation des détect. catadioptriques 0,5

TOTAL: 22,6W

1. L’efficacité d’un convertisseur DC-DC est maximale pour sa puissance maximale. Elle décroît toutefois de façon impor-tante et non-linéaire lorsque la puissance demandée est inférieure à la puissance maximale. Il est d’ailleurs recommandéde ne jamais utiliser un tel convertisseur à moins de 10% de sa puissance maximale.



Module de détection de ligne 12

Détecteurs catadioptriques 1,3

Caméra 2,4

TOTAL: 15,7W



°C W⁄



également qu’un maximum de 40W serait amplement suffisant. Encore une fois, ce module ne fut pas facile à

trouver dû à la disponibilité restreinte des pièces. Nous avions l’intention d’utiliser un module semblable à

celui utilisé pour l’alimentation 5V, soit le module AK60A-024L-120F04 de Astec qui offre une puissance

maximale de 48W. Toutefois, ce produit n’était pas disponible et nous avons dû rechercher un produit similaire

chez un autre fabricant. Nous avons trouvé le modèle HBS050YH-A de Power-One qui offre une puissance

maximale de 50W et qui possède principalement les mêmes caractéristiques que le modèle Astec. Il est de

dimensions similaires (57,9x61,0x12,7mm) ce qui nous permet d’utiliser le même dissipateur de chaleur que

le module 5V et possède des caractéristiques électriques similaires.

5.2.3.3 Choix des batteries

• Fabricant: Panasonic

• Modèle: LC-R127R2P

Le choix des batteries est crucial dans le processus de conception d’un robot mobile puisqu’il implique

d’importantes contraintes aux niveaux de la conception mécanique et de l’autonomie électrique.

Effectivement, le volume occupé par les batteries et le poids qu’elles possèdent influencent de façon

importante la conception mécanique au niveau de la disposition des éléments et au niveau du choix des

moteurs. Il est donc inévitablement nécessaire de faire des compromis entre autonomie électrique et poids des

batteries pour ainsi obtenir un robot qui offre des performances en accélération satisfaisantes et une autonomie

électrique également satisfaisante.

Il existe trois principales familles de batteries rechargeables qui sont appropriées pour une utilisation dans un

robot mobile (utilisation cyclique, décharge rapide et courants demandés de quelques ampères): les batteries à

acide-plomb ("SLA"), les batteries au Nickel-Cadmium ("Ni-Cad") et les batteries au Nickel-Hydride de métal

("Ni-MH"). Les deux dernières familles (Ni-Cad et Ni-MH) offrent une densité d’énergie beaucoup plus

grande que la première (SLA), la plus grande densité étant offerte par les batteries Ni-MH. Ces batteries sont

toutefois beaucoup plus dispendieuses que les batteries à acide-plomb1 et elles demandent également une

attention plus soignée au niveau de la recharge. La solution à acide-plomb constitue donc une solution très peu

dispendieuse et la recharge de ces batteries est assez facile. Par contre, leur densité d’énergie est assez faible

et elles impliquent donc un poids important, ce qui limite les peformances du robot. Vu notre budget assez

limité pour le projet, et surtout notre utilisation généralement assez peu respectueuse de nos batteries, le choix

de la solution acide-plomb est approprié.

1. Pour une même quantité d’énergie, une solution à batteries Ni-Cad coûte environ 6 fois plus cher qu’une solution à acide-plomb, tandis qu’une solution à Ni-MH coûte environ 8 fois plus cher.



Pour déterminer l’énergie que devra contenir nos batteries pour respecter le critère d’autonomie fixé à

30minutes lors d’une utilisation en compétition, il est nécessaire d’évaluer la puissance totale qui sera

demandée aux batteries, donc la somme de la puissance demandée par les moteurs et celle demandée par

l’électronique de contrôle.

Pour évaluer la puissance des moteurs, il nous faut revenir au profil trapézoïdal défini en section 5.1.5.6 et à

l’évaluation des courants qui en a résultée en section 5.1.5.7. Pour évaluer le courant moyen demandé par les

moteurs, il est possible de faire une moyenne pondérée par le temps des courants demandés durant le profil. Il

est également nécessaire de considérer l’efficacité des hacheurs de courant que nous pouvons évaluer à 92%.

Nous obtenons donc:

Pour l’évaluation de la puissance demandée par l’électronique de contrôle, il suffit de reprendre les puissances

calculées en section 5.2.3.2 et de ramener cette puissance en courant sur 24V tout en considérant l’efficacité

des convertisseurs DC-DC, que nous pouvons approximer à 78%. Nous obtenons donc:

Donc, le courant total moyen que nous demandons aux batteries est le suivant:

Nous devons donc rechercher une batterie qui puisse supporter un tel courant pendant au moins 30 minutes

sans que la tension totale des batteries ne descende en bas de 20V puisqu’on considère qu’à ce point

l’ordinateur embarqué se réinitialisera1. La batterie qui a été retenue est le modèle LC-R127R2P de Panasonic,

qui est une batterie 12V à technologie acide-plomb. Il est ainsi nécessaire d’utiliser deux de ces batteries en

série. L’énergie de cette batterie est spécifiée à 7,2Ah pour une décharge d’une durée de 20h. Plusieurs

batteries ayant les mêmes caractéristiques électriques auraient pu être choisies, mais le modèle Panasonic

présentait une densité légèrement plus élevée (donc un poids et un volume légèrement plus faibles) que la

majorité des autres modèles. Nous obtenons un poids total pour les batteries de 4,94kg, ce qui correspond à

plus du tiers du poids du robot. Si nous observons la courbe de décharge de cette batterie, nous remarquons

1. Cette valeur a été établie suite à des essais. Ce phénomène devra cependant être revu puisque les convertisseurs devraientdonner une sortie acceptable pour une tension pouvant descendre jusqu’à 18V.

Imot2

0.92---------- 5.61 0.28⋅ 0.407 1.307⋅ 4.8 0.28⋅ 0.407 2.03⋅+ + +

0.28 1.307 0.28 2.03+ + +-------------------------------------------------------------------------------------------------------------------------------⋅ 2.384A= =

Ielec1

24 0.78⋅--------------------- 22.6 15.7+( )⋅ 2.046A= =

Imot Imot Ielec+ 4.423A= =



que nous pouvons demander un courant d’environ 7,5A durant 30 minutes pour que la tension descende à 10V.

De plus, pour un courant de 4,423A, nous observons que la décharge pourra durer près de 80 minutes avant

que la tension n’atteigne 10V. Nous obtenons donc une autonomie largement supérieure au critère établi et

nous aurions donc pû diminuer la taille et le poids de nos batteries. Toutefois, puisque nous obtenons des

performances satisfaisantes (en accélérations et en vitesses maximales) et que nous désirons obtenir une

autonomie qui soit évidemment la plus longue possible, ces batteries ont été conservées.

L’autonomie calculée précédemment considérait le profil de vitesse spécifique à la compétition. Lors de nos

essais et démonstrations, le robot utilise un profil de vitesse beaucoup moins sévère et nous pouvons donc

obtenir une autonomie assez élevée. Par exemple, si nous considérons que nous roulons toujours à vitesse

constante (les accélérations étant faibles et rares, nous les négligeons) et que nous n’utilisons pas le module de

suivi de ligne, nous obtenons un courant total aux batteries de 2,290A et une autonomie d’environ 3 heures.

5.3 Conception informatique

Les caractéristiques désirées de la structure logicielle du robot sont la modularité, les possibilités d’évolution,

l’efficacité et la robustesse. La structure présentée dans ce document correspond à celle utilisée pour répondre

aux besoins du Championnat mondial de robotique mobile. On y fait donc mention du module de ramassage

de boules (ramasse-boules) ainsi que du module de suivi de ligne.

5.3.1 Choix de l’architecture

L’ordinateur embarqué performant dont nous disposons nous permet dans un premier temps d’éliminer

plusieurs alternatives telles la programmation en assembleur ou autre langage de bas niveau. Il est évident que

l’utilisation d’un système d’exploitation évolué et de langages de programmation de haut niveau permettent

l’implantation d’un logiciel de contrôle complexe et modulaire.

Les éléments qui doivent donc être déterminés avant de pouvoir débuter l’implantation du logiciel de contrôle

sont le système d’exploitation ainsi que le/les langage(s) de programmation qui seront utilisés. Afin de choisir

notre système d’exploitation, deux critères principaux ont dû être considérés: la nécessité de boucles temps

réel, l’accessibilité (et le prix!) du système d’exploitation et le temps de développement des différents

modules. La nécessité de boucles temps réel vient éliminer plusieurs systèmes d’exploitation, en particulier la

gamme de produits Microsoft (mis à part Windows CE qui permet du temps réel). Pour ce qui est des systèmes

offrant des possibilités de temps réel, le système VxWorks n’était pas envisageable puisque ce dernier est

difficilement accessible dû à son prix élevé. Les trois options restantes étaient QNX et Linux utilisés



conjointement avec RT-Linux ou RTAI. Le système d’exploitation QNX constituait une solution inéressante

puisque ces capacités temps réel sont bien connues et éprouvées et la version la plus récente est disponible

gratuitement (http://get.qnx.com/) pour un usage non commercial. Par contre, l’équipe travaille depuis déjà

plusieurs années sous Linux tout en profitant des possibilités temps réel offertes par RT-Linux. Ainsi, notre

code de contrôle de bas niveau était déjà en grande partie développé pour cette plateforme. Il était donc clair

que le temps que nous économiserions en conservant cette plateforme constituait le critère décisif. Étant

donnée la préférence des développeurs de l’équipe, la version de Linux utilisée sur le robot SpinoS en ce

moment est Debian Linux (http://www.debian.org/) avec le noyau 2.2.19 et l’ajout RT-Linux version 2.2 (http:/

/www.rtlinux.org/).

Pour les langages de programmation utilisés, le choix s’est fait relativement facilement. Premièrement, notre

code de contrôle de bas niveau était déjà développé en langage C et nous le considérions suffisamment stable

pour ne pas vouloir le réécrire. De plus, pour utiliser les fonctionnalités temps réel offertes par RT-Linux, le

code temps réel se devait d’être écrit en langage C. Ensuite, pour notre programme de contrôle de haut niveau,

le langage C++ était particulièrement intéressant en ce sens que nous voulions une structure modulaire, ce qui

est une caractéristique inhérente à la programmation par objets, et nous voulions obtenir une vitesse

d’exécution intéressante. Il était également nécessaire d’utiliser ce langage pour une interface facile avec les

boucles temps réel. Finalement, il était le seul langage haut niveau bien connu des différents membres de

l’équipe.

5.3.2 Outils de développement

Les deux principaux outils de développement utilisés pour ce projet sont CVS (http://www.cvshome.org/), un

outil de contrôle de code source pour le travail en équipe, et doxygen (http://www.doxygen.org/), un outil pour

générer automatiquement la documentation du code source. On peut retrouver et naviguer dans le code source

du projet à l’adresse suivante: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/robosoft/sae/. Les répertoires

spinos et modules contiennent les parties du logiciel développé par l’équipe qui sont utilisées dans le projet

SpinoS. Le code source est également disponible dans le répertoire sae/ du CD fourni avec ce rapport. La

documentation du code source peut être retrouvée sur le CD en format html dans le répertoire sae/spinos/doc/

html et en format pdf dans le document sae/spinos/doc/spinos_manual.pdf.

5.3.3 Structure globale

La figure 5-21 présente la structure du logiciel de contrôle du robot SpinoS. On y retrouve principalement deux

sections, soit le module temps réel et le programme de contrôle. Les prochaines pages décrivent chacun des


http://get.qnx.com/

http://www.debian.org/

http://www.rtlinux.org/

http://www.rtlinux.org/

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/robosoft/sae/

http://www.cvshome.org/

src/doc

http://www.doxygen.org/


éléments de cette structure, ainsi que les entrées/sorties entre chaque élément.

Il est à noter que cette structure présente strictement ce qui est propre au robot SpinoS et ne donne aucun détail

sur les modules de bas niveau qui permettent de communiquer avec le matériel. En fait, deux modules

supplémentaires sont présentement utilisés, soit le module de communication avec la carte de contrôle (pmd.o)

et le module de communication avec la carte d’entrées/sorties numériques (pcm3724.o). Le module temps réel

doit évidemment utiliser les modules de communication avec le matériel. Les modules développés par l’équipe

se trouvent tous dans src/sae/modules.

Figure 5-21: Structure du logiciel de contrôle du robot SpinoS

5.3.4 Module temps réel

Le module temps réel s’assure d’acquisitionner périodiquement (avec une période fixe et prédéterminée) les

différents capteurs du robot. Les capteurs actuellement lus par le système sont les encodeurs optiques des

moteurs (lus à partir de la carte de contrôle des moteurs), les signaux du module de suivi de ligne ainsi que les

détecteurs catadioptriques. Ce module est aussi chargé d’initialiser le système (initialisation des cartes,

lancement des boucles) et de transmettre les commandes du programme de contrôle à la carte de contrôle des

moteurs. Le concept de file (FIFO) est essentiel à la compréhension de ce module, puisque la communication

entre le module temps réel et le programme de contrôle se fait strictement grâce à des FIFOs. Ce module

comporte deux boucles temps réel distinctes, leur description suit. Le code de ce module se retrouve dans sae/

spinos/rt.

thread de commandenom: pmd_thread

période: 10ms

thread d'acqu. des capteursnom: strip_thread

période: 5ms

Brain

Position

Trajectory

Strip

ControllerFIFO_CMD

FIFO_STRIP

FIFO_ENC

pmd_in

pmd_out

strip

Spinos

infostraj.

speed, omega, lacc, racc, pu_init

x, y, theta, vtan, w, dist

line_pos, catas

Programme de contrôle (spinosd):programmation orientée-objet, langage C++

Module temps réel (spinos.o):programmation de bas niveau, langage C



5.3.4.1 Fil de commande:

Ce fil ("thread" pmd_thread) effectue la liaison entre la carte de contrôle des moteurs et le programme de

contrôle. Pour ce faire, il utilise le module pmd.o. Ce fil utilise le FIFO d’entrée (FIFO_CMD) pour lire les

commandes provenant du programme de contrôle et les transmettre à la carte. Ensuite, il utilise le FIFO de

sortie (FIFO_ENC) pour y insérer les informations des encodeurs qu’il a obtenues de la carte. La prériode de

cette boucle est fixée à 10ms pusique c’est la période minimale permettant un fonctionnement correct de la

carte de contrôle des moteurs. Lorsque la période est plus petite, la carte peut montrer un comportement

erratique, la raison étant probablement le temps requis par la machine à états du FPGA pour effectuer les

différentes opérations (voir [4] pour plus de détails). Voici une description détaillée des deux FIFOs:

Tpmd: période d’échantillonnage de la boucle PID de la carte de contrôle des moteurs (400 us).

5.3.4.2 Fil d’acquisition des capteurs:

Ce fil ("thread" pmd_strip) effectue la liaison entre la carte d’entrées/sorties numériques et le programme de

Tableau 5-5 : Structure de FIFO_CMD

Paramètre Description

pmd_in.spds.left Vitesse désirée du moteur gauche (en tics/Tpmd)

pmd_in.spds.right Vitesse désirée du moteur droit (en tics/Tpmd)

pmd_in.spds.aleft Accélération désirée du moteur gauche (en tics/Tpmd2)

pmd_in.spds.aright Accélération désirée du moteur droit (en tics/Tpmd2)

pmd_in.pu_init Signal de déclenchement du ramasse-boules

Tableau 5-6 : Structure de FIFO_ENC


pmd_out.ticks.left Position du moteur gauche (en tics)

pmd_out.ticks.right Position du moteur droit (en tics)

pmd_out.ticks.ball Position du moteur no.3 (ramasse-boules) (en tics)

pmd_out.ticks.dt Intervalle de temps entre deux lectures consécutives des enco-deurs (en ns)

pmd_out.status3 État du moteur no.3 (ramasse-boules). Sera égal à 1 lorsque cemoteur est à l’arrêt (bit MOTION_COMPLETE vrai), 0 autrement.Ce signal permet de déterminer la fin de la séquence de mouve-ments du ramasse-boules.



contrôle. Pour ce faire, il utilise le module pcm3724.o. Grâce à la carte d’entrées/sorties, ce fil est en mesure

de lire les capteurs (autres que les encodeurs) et de transmettre l’information acquisitionnée au programme de

contrôle en utilisant le FIFO FIFO_STRIP. Les capteurs présentement acquisitionnés par le robot sont les

capteurs du module de suivi de ligne ainsi que les détecteurs catadioptriques. Il est à noter que l’acquisition

des capteurs du module de suivi de ligne est adaptée aux spécifications de ce dernier, puisqu’il y a multiplexage

des 32 capteurs. La période de cette boucle a été fixée à 5ms de façon à être suffisamment rapide pour

l’acquisition des détecteurs catadioptriques. Ces derniers doivent détecter une bande d’environ 3cm de large à

une vitesse maximale de 2,5m/s lors de la compétition. Ceci laisse une marge de 12ms pour la détection de la

bande. Afin de s’assurer de ne pas la rater, une période inférieure à 10ms a été fixée. Voici la description du

FIFO FIFO_STRIP:

5.3.5 Programme de contrôle

Le programme de contrôle utilise le langage C++ pour assurer une structure modulaire. Il est ainsi constitué

de modules (classes) ayant tous des fonctions nécessaires à l’obtention d’un progamme permettant des

opérations complexes que le robot peut accomplir de façon autonome. Les présentes sections décrivent les

différentes classes utilisées par le programme de contrôle. Le code de ce programme se retrouve dans sae/

spinos/controller. Le programme est compilé sous le nom de spinosd et le fichier sae/spinos/controller/

spinosd.h contient la majorité des paramètres du programme.

5.3.5.1 Classe Controller

Ce module sert principalement à envoyer les commandes à la carte de contrôle des moteurs DC. La fonction

send(float speed, float omega, float lacc = accel, float racc = accel, int pu_init = 0) permet de contrôler le

robot en vitesse tangentielle (speed) et en vitesse angulaire (omega) et elle permet également de modifier

l’accélération du profil trapézoïdal du contrôleur des deux moteurs (lacc et racc). De plus, le paramètre pu_init

permet de lancer la séquence de mouvement du moteur du ramasse-boules. Cette classe utilise le FIFO

FIFO_CMD pour transmettre ses valeurs au fil de commande. Elle se charge également d’effectuer les

conversions nécessaires pour respecter les formats de données de la carte contrôleur.

Tableau 5-7 : Structure de FIFO_STRIP


strip.leds Valeurs (en binaire) des 32 capteurs du module de suivi de ligne.

strip.catas Valeurs (en binaire) des 3 détecteurs catadioptriques



Le calcul des vitesses angulaires des moteurs utilise les équations suivantes:

• vitesse du moteur de gauche:

• vitesse du moteur de droite:

où Vud est la vitesse tangentielle désirée et la vitesse angulaire désirée du robot.

5.3.5.2 Classe Position

Le suivi de ligne ne nécessite pas de positionnement du robot par rapport à un référentiel fixe. Toutefois, un

module de positionnement est presque toujours nécessaire lorsque le cerveau doit accomplir d’autres tâches.

Par exemple, l’épreuve de ramassage de boules de la compétition nécessite le positionnement du robot dans le

plan.

Cette classe est donc responsable de positionner le robot dans un référentiel fixe. Elle est en mesure, grâce aux

informations des encodeurs reçues du FIFO FIFO_ENC, de déterminer et de transmettre au reste du

programme les informations sur la cinématique du robot: x, y, , Vu, ainsi que la distance parcourue par le

robot. Elle est également chargée de vérifier l’état du module de ramassage de boules, c’est-à-dire qu’elle est

en mesure de déterminer si la séquence de mouvement du module est complétée.

La classe Position utilise les équations du modèle cinématique du robot décrit en section 6.2.

NOTE: l’appel des fonctions read_f() et update() est nécessaire à chaque fois que des nouvelles données sont

disponibles dans FIFO_ENC

5.3.5.3 Classe Strip

La classe était initialement strictement dédiée à l’acquisition des capteurs du module de suivi de ligne, d’où

son nom de Strip. Toutefois, utilisant le FIFO FIFO_STR qui détient les valeurs lues de la carte d’entrées/

sorties numériques, il a été jugé plus simple, et surtout plus rapide, d’utiliser cette classe pour lire tous les

capteurs connectés à la carte d’entrées/sorties plutôt que de créer une classe par capteur. Par contre, pour

respecter les concepts de programmation orientée-objets et la volonté de conserver une structure modulaire, il

devrait normalement y avoir un FIFO et une classe par capteur. Quoiqu’il en soit, voyons brièvement comment

fonctionne cette classe.

ω1 Vud ωd l 2⁄⋅–( ) Ra⁄=

ω2 Vud ωd l 2⁄⋅+( ) Ra⁄=

ωd

θ ω



• Capteurs catadioptriques:

La valeur de ces capteurs est directement lue du paramètre st.catas provenant de FIFO_STR. Grâce à des

positions pré-établies sur la carte et à une énumération en conséquence (dans sae/spinos/rt/ctrl.h), le

programme est en mesure de savoir l’état de chacun des capteurs (avant-gauche, avant-droite et arrière). La

fonction get_cata() retourne l’état des capteurs.

• Module de suivi de ligne

La valeur des capteurs du module de suivi de ligne est obtenue dans un mot de 32 bits inscrit dans le paramètre

st.leds de FIFO_STR. Grâce à ces valeurs, la fonction update() est en mesure de déterminer si les données

recueillies sont acceptables pour positionner la ligne, et lorsque le résultat est positif, la position de la ligne est

calculée. Elle est également en mesure de déterminer le type de case sur laquelle le robot se trouve (ligne

blanche sur fond noir ou ligne noire sur fond blanc). Grâce à cette information, le robot est en mesure de savoir

sur quelle case il se trouve sur le terrain.

Les données des capteurs sont dans un premier temps remises en logique "positive" pour traiter les signaux

identiquement peu importe le type de case. Donc, la ligne est représentée par des ’1’ et le reste par des ’0’.

Ensuite, les bits repésentant la ligne sont filtrés de façon à éliminer les bits considérés comme du bruit (qui

sont différents de leurs deux bits voisins immédiats). La figure 5-22 illustre ce processus de filtrage. De plus,

une ligne sera considérée inacceptable si elle est composée de plus de 4 capteurs et de moins de 2.

Figure 5-22: Processus de filtrage des données du module de suivi de ligne: a) données brutes b)résultat après filtrage

Pour déterminer la position de la ligne, il suffit alors de calculer la moyenne des bits à ’1’. Nous obtenons alors

la position de la ligne dans le mot de 32 bits (POS). Afin de retourner la valeur en m par rapport au centre du

module, la conversion suivante est effectuée:

......a)

bit erronépos. de la ligne

......pos. de la ligne

b)

lineposls2---- POS

nbleds 1–-------------------------- 2⋅ 1– ⋅=



où ls correspond à la largeur du module de suivi de ligne (en m) et nbleds le nombre total de capteurs du

module.

La fonction get_lost_ctr() de la classe Strip retourne le nombre d’itérations consécutives sans ligne valide. Ce

compteur est utile pour déterminer si le robot a bel et bien perdu le tracé.

NOTE: l’appel des fonctions read_f() et update() est nécessaire à chaque fois que des nouvelles données sont

disponibles dans FIFO_STRIP

5.3.5.4 Classe Trajectory

Cette classe a pour but de permettre au robot de se déplacer dans le plan selon une trajectoire connue. Il est

important de mentionner tout d’abord que cette classe a été dévloppée rapidement pour permettre au robot de

compléter les épreuves de la compétition. Il existe deux modes de fonctionnement dans cette classe: un mode

permettant d’effectuer des éléments de trajectoire prédéterminés (ligne droite, rotation pure et arc de cercle) et

un mode permettant de spécifier une position à atteindre dans le plan.

• Mode éléments de trajectoire:

Ce mode permet de spécifier les paramètres d’éléments de trajectoire que le robot devra effectuer. Un élément

de trajectoire est défini par la structure TrajectoryElement. Cette structure est formée des paramètres v_tan, la

vitesse tangentielle désirée, v_ang, la vitesse angulaire désirée, et condition, la condition qui permet de

déterminer la fin de l’élément de trajectoire. Cette condition dépend du type de trajectoire qui est déterminé

grâce aux valeurs de v_tan et v_ang. Lorsque la vitesse angulaire désirée est nulle (et la vitesse tangentielle

non nulle!), le robot effectuera une ligne droite (à vitesse de translation positive ou négative) et la condition

d’arrêt sera spécifiée par une distance en m en valeur absolue. Si la vitesse angulaire désirée est non nulle, le

robot effectuera une rotation pure si la vitesse tangentielle est nulle et un arc de cercle dans le cas contraire.

Pour ces deux derniers types de mouvements, la condition d’arrêt est spécifiée en radians, soit l’angle de

rotation (positif ou négatif) que le robot doit accomplir. Il est également possible de spécifier un tableau

d’éléments de trajectoire grâce à la structure TrajectoryDescription qui est composée d’un tableau de

TrajectoryElement et du nombre d’éléments dans ce tableau. Conjointement à cette description de trajectoire,

il est nécessaire de spécifier une variable booléenne (loop) qui permet de répéter ou non la trajectoire. Il est

alors possible de spécifier quelques éléments de trajectoire et de les répéter indéfiniment. Les 3 différentes

méthodes load() permettent de charger un élement de trajectoire, une trajectoire complète, ou encore un fichier

contenant une description de trajectoire. La fonction execute() doit être appelée à chaque itération de la boucle

de contrôle (cette fonction est appelée d’un objet de type Brain) et elle retournera 1 lorsque la trajectoire sera



complétée, 0 autrement.

• Mode par positionnement dans le plan:

Ce mode permet au robot d’atteindre une position désirée dans le plan. Pour utiliser ce mode, il est nécessaire

premièrement d’appeler la méthode xyload(float X, float Y) pour spécifier le point à atteindre dans le plan.

Ensuite, l’appel de la fonction gotoxy() permettra au robot de se rendre au point préalablement spécifié. La

méthode execute() doit ensuite être appelée à chaque itération pour permettre aux mouvements de s’effectuer.

Cette méthode retournera 1 lorsque le point désiré sera atteint, 0 autrement. La génération de trajectoire

employée dans la méthode gotoxy() est très simple: elle décompose la trajectoire en une rotation et en une

translation pures. Dans un premier temps, le robot s’arrêtera et se positionnera vers le point à atteindre. Puis il

parcourera la distance nécessaire pour atteindre le point. Cette méthode est bien pratique, mais elle devra être

plus évoluée. Elle devra entre autre permettre d’ajuster la valeur des vitesses (transltation et rotation) désirées.

Les fichiers sae/spinos/controller/brain/TestXY.cc sae/spinos/controller/brain/Brain2.cc présentent des

exemples d’utilisation de la classe Trajectory.

NOTE: Les méthodes implantées dans la classe Trajectory ont été implantées rapidement dans le but de

répondre aux besoins des différentes épreuves de la compétition. Toutefois, le mode par positionnement dans

le plan décompose le mouvement en rotation et translations pures et le suivi des éléments de trajectoire est

assuré simplement par les contrôleurs de vitesse angulaire des deux moteurs. Ces méthodes répondent aux

besoins, mais elles sont peu précises et peu rapides. Des méthodes beaucoup plus précises et plus fluides

(idéalement continues) devront être implantées pour permettre au robot d’effectuer des séquences de

mouvement de façon répétitives avec précision.

5.3.5.5 Classe Brain

La classe Brain permet d’implanter au robot un certain comportement en fonction des informations des

différents capteurs et des informations sur la cinématique du robot. Nous considérons cette classe comme un

cerveau puisqu’en faisant une analogie avec le corps humain, elle est en mesure de prendre les informations

du système nerveux et sensoriel (les capteurs et le positionnement, classes Strip et Position), de prendre des

décisions sur le comportement à adopter et de demander au système moteur d’effectuer des mouvements

désirés (classes Trajectory et Controller).

En fait, cette classe ne contient que la fonction virtuelle step() qui est appelée à chaque itération par le

programme de contrôle. Il est nécessaire, afin d’implanter le comportement désiré au robot, de définir une



classe dérivée de la classe Brain() qui elle contiendra une méthode step() surchargée qui implantera le

comportement en question. Pour le programme de contrôle, l’objet utilisé est de type Brain, peu importe la

classe dérivée. Le programme utilisera donc toujours une classe dérivée de la classe Brain, mais ceci sera fait

de façon entièrement transparente. C’est-à-dire que la structure et le fonctionnement du programme de

contrôle, mis à part la classe dérivée, sera exactement le même pour tous les cerveaux. Évidemment, une seule

classe dérivée (un seul cerveau) est utilisée à la fois. Ce processus transparent est permis grâce à la classe

BrainCreator qui se charge d’initialiser correctement le cerveau désiré au moment de l’exécution. Le fichier

sae/spinos/controller/brain/README_Brain explique comment créer un nouveau cerveau. La référence [9]

contient des détails sur la technique employée.

La plupart des cerveaux développés par l’équipe (voir section 5.4) sont constitués d’au moins une machine à

états (ou MSA: machine séquentielle algorithmique), machine qui permet de définir le comportement du robot.

Le concept de machine à états est particulièrement bien approprié pour définir le comportement d’un robot

mobile devant accomplir des opérations connues et prédéfinies. Effectivement, l’utilisation de machines à états

facilite grandement la conception et l’implantation d’algorithmes séquentiels de complexité arbitraire. La

machine à états comporte les caractéristiques suivantes:

• permet de bien visualiser les algorithmes séquentiels

• permet une implantation rapide et robuste des algorithmes séquentiels

• facilité d’imbrication de plusieurs machines à états

• comportements indépendants pour chacun des états; facilité de modification de la machine à états

• facilité de documentation des algorithmes

Les lignes qui suivent illustrent une façon simple d’implanter une machine à états au sein d’un programme

C++. Cette méthode est employée dans plusieurs cerveaux développés jusqu’à présent. Pour imbriquer une

machine à état à l’intérieur d’un état spécifique, il suffit d’appeler une fonction (dans l’état spécifique) qui

correspond en fait à la machine à imbriquer. Par exemple, dans l’exemple qui suit, la fonction

swing_la_bacaisse() pourrait contenir une machine à états.

1-Définition des états (avant la définition de la classe):

// Definition des etats

#define ETAT_ARRET 0

#define ETAT_RECHERCHE 1

#define ETAT_DANSE_LE_TWIST 2



...

#define ETAT_PAUSE_CAFE n

2-Définition des variables d’états (dans la définition de la classe):

class Cerveau_dansant::public Brain

public :

int step();

void stop();

private:

...

// Variables d’etats

int etat_courant;

int etat_suivant;

int etat_precedent;

...

3-Description de la machine à états (dans la fonction appelée périodiquement):

int Cerveau_dansant::step()

...

etat_courant = etat_suivant;

switch (etat_courant)

case ETAT_DANSE_LE_TWIST:

if (etat_precedent != ETAT_DANSE_LE_TWIST)

swing_la_bacaisse();

...

else if (mauvaise_musique())

etat_suivant = ETAT_ARRET;

else

etat_suivant = etat_courant;

break;

...

default:

etat_suivant = ETAT_ARRET;

break;



etat_precedent = etat_courant;

...

5.3.5.6 Classe SpinoS

La classe SpinoS englobe tous les modules du progamme de contrôle et représente en quelque sorte le robot

dans son ensemble. Cette classe est donc principalement constituée d’un cerveau, d’un module de génération

de trajectoire, d’un module de traitement des entrées/sorties, d’un module de positionnement et d’un

contrôleur.

Le programme principal, spinosd, contient un objet de type SpinoS et il utilise la méthode think() à chaque

itération pour permettre au robot d’évoluer dans le temps. Cette méthode appelera la méthode step() du cerveau

lorsque de nouvelles données seront reçues des boucles temps réel, par l’entremise des FIFOs. Pour vérifier

qu’il y a des données nouvelles en arrivée et mettre à jour les modules de positionnement et de traitement des

entrées/sorties, la classe SpinoS utilise des objets de type PosThread et StripThread et leurs méthodes run(),

qui sont en fait des fils ("threads") sans contrainte temps réel. Les méthodes run() de ces deux classes

effectuent la lecture des FIFOs par l’entremise des méthodes Position::read_f() et Strip::read_f() et la mise à

jour des modules (Position::update() et Strip::update()) puis indique qu’il y a de nouvelles données

disponibles.

5.4 Module de prise de décision et de commande (cerveau)

Le cerveau est structuré en machine à états, ce qui assure un fonctionnement séquentiel robuste. Le module de

prise de décision et de commande permet au robot d’évoluer de façon complètement autonome. L’équipe a

déjà développé plusieurs cerveaux différents, dont un spécifique à la compétition et plusieurs autres qui

implantent des comportements variés. Dans les sections qui suivent, une description détaillée du cerveau de

compétition ainsi qu’une brève description des différents cerveaux développés jusqu’à présent sont présentées.

5.4.1 Cerveau de compétition

Ce cerveau est implanté dans la classe Brain2. Le cerveau de compétition est constitué de 6 machines à états

simples: une machine à état principale et 5 machines imbriquées dans la machine principale. Les sections

suivantes décrivent chacune des machines à états.



5.4.1.1 Machine à états principale

La machine à états principale du cerveau de compétition permet au robot d’évoluer sur la piste de compétition

en complétant les différentes épreuves. L’objectif de cette machine à états est d’obtenir un système qui répond

de façon fiable et rapide, pour espérer d’excellents résultats en compétition. Cette machine à états, implantée

dans la méthode step(), est constituée de 6 états correspondant aux opérations spécifiques aux différentes

exigences de la compétition: suivi de ligne, ramassage de boules de billard, évolution en zone libre et arrêt à

la fin du tracé. Le tableau 5-8 décrit les différents états de la MSA tandis que la figure 5-23 en présente le

diagramme d’états.

Nous remarquons que l’état initial de cette MSA est l’état ’Suivi de ligne’. Cet état correspond à l’algorithme

de suivi de ligne décrit à la section suivante. Le suivi de ligne se terminera lorsque la distance parcourue par

le robot sera plus grande que la distance du parcours. De plus, lorsqu’un détecteur catadioptrique est actif et

qu’il reste des boules de billard à ramasser (le robot connait le nombre de boules à ramasser), il pourra être

interrompu afin de ramasser les boules de billard disposées à 80 cm de la ligne. Une séquence d’opérations

permettant le ramassage et la reprise de la ligne est alors activée et le suivi de ligne reprendra à la fin de cette

séquence. Finalement, une séquence semblable sera activée lorsque le robot pénètrera dans la troisième case

du tracé (zone libre) pour permettre au robot de ramasser la boule de billard de la zone libre.

Tableau 5-8 : Description des états de la MSA principale

État No. Description

Suivi de ligne (S_LINE) 0 Contrôleur de suivi de ligne (méthode line())

Ramasse-boule (S_PICKUP) 1 Séquence de ramassage d’une boule de billard (méth-ode pickup())

Reprise ligne (S_GETLINE) 2 Séquence de repositionnement sur la ligne du tracé(méthode getline())

Ramasse-boule zône libre(S_PICKUP_FZ)

3 Séquence de ramassage d’une boule de billard en zônelibre (méthode pickup_fz())

Reprise ligne zône libre(S_GETLINE_FZ)

4 Séquence de repositionnement sur la ligne du tracé enzône libre (méthode getline_fz())

Arrêt (S_END) 1 Arrêt du robot à la fin de la piste



Figure 5-23: Diagramme d’états de la MSA principale

5.4.1.2 Machine à états de suivi de ligne

Puisque cette machine à états constitue en fait une proposition pour un contrôleur de suivi de ligne performant,

la description de cette machine à états se retrouve en section 7.3.4.

5.4.1.3 Machine à états de ramassage de boule

Cette machine à états (méthode pickup()) constitue une séquence d’opérations permettant au robot

d’interrompre momentanément le suivi de ligne pour récupérer une boule de billlard nouvellement détectée.

Cette MSA est composée de 6 états qui correspondent à la séquence d’opérations définie. Le tableau 5-9 décrit

les différents états de cette MSA et la figure 5-24 présente son diagramme d’états.

La figure 5-25 illustre la séquence utilisée pour positionner le robot en vue du lancement du ramassage comme

(0) Suivi de ligne

(1) Ramasse-boule (3) Zone libre

(5) Arret

(2) Reprise ligne(4) Reprise ligne

zone libre

Fin de piste ?

OUI

CATA avant ?NON

OUI

BouleRamassee ?

BouleRamassee ?

Ligne Reprise ? Ligne Reprise?

OUIOUI

Case no.3 ?NON

OUI

OUI OUI

NON NON

NON NON

BouleRamassee ?

NON

OUI

NON

nb_boules > 0 ?

OUI

NON

nb_boules -= 1 nb_boules -= 1



tel. La séquence de mouvements est donc assez simple et il est inutile de la décrire plus en détails. Il est

toutefois nécessaire de discuter de deux états particuliers, non illustrés, soit les états ’Correction’ et

’Rapprochement’. L’état ’Correction’ permet de corriger un possible dépassement lors de l’arrêt. Par exemple,

si le robot arrive trop rapidement, il se peut qu’il ne puisse arrêter sur la distance séparant les détecteurs des

roues motrices. Donc, il sera nécessaire de reculer par la suite. Finalement, l’état ’Rapprochement’ vient

combler l’écart entre la portée du ramasse-boules (70cm) et la distance de la boule à ramasser (80cm).

Tableau 5-9 : Description des états de la MSA de ramassage de boule


Arret (PU_STOP) 0 Arrêt du robot (axe des roues aligné avec boule)

Correction (PU_CORRECT) 1 Correction de la position si le robot est mal aligné

Rotation (PU_ROTATE) 2 Rotation du robot pour s’orienter vers la boule

Rapprochement (PU_REACH) 3 Rapprochement du robot vers la boule

Lancement (PU_LAUNCH) 4 Lancement du moteur du ramasse-boules

Attente (PU_WAIT) 5 Attente de l’arrêt du moteur du ramasse-boules



Figure 5-24: Diagramme d’états de la MSA de ramassage de boule

Figure 5-25: Séquence de positionnement pour ramassage de boule

(0) Arret

(1) Correction

(3) Rapprochement

Vu = 0 ?

OUI

position ok ?

Vu = 0 ?

(2) Rotation

NON

NON

CATA arriere ?

NON

NON

OUI OUI

OUI

Vu = 0 ?

NON

(4) Lancement

OUI

(5) Attente

arret moteur 3 ?

NON

OUI

Détection 0- Arrêt 2- Rotation (fin)



5.4.1.4 Machine à états de reprise de ligne

Cette machine à états (méthode getline()) permet au robot de reprendre la ligne après un ramassage de boule.

Elle est très simple, car il est simplement nécessaire de faire les mouvements inverses effectués lors des états

’Rapprochement’ et ’Rotation’ du ramassage de boule.

Figure 5-26: Diagramme d’états de la MSA de reprise de ligne

5.4.1.5 Machine à états de ramassage de boule en zone libre

Cette machine à états (méthode pickupfz()) permet au robot d’aller ramasser la boule de billard située à un

emplacement arbitraire en zone libre. Elle est presqu’identique à la machine à états de ramassage de boule.

Seul le premier état diffère, puisque le robot doit aller se positionner près de la boule pour pouvoir la ramasser.

Les états ’Correction’ et ’Rapprochement’ ne sont pas utilisés dans l’implantation actuelle. En fait, seul l’état

’Correction’ pourrait être utile lorsque le robot s’arrête trop loin du point désiré. L’état ’Rapprochement’ ne

devrait pas être nécessaire et pourrait être enlevé de la MSA.

NOTE: Dans l’implantation actuelle, la position de la balle doit être connue au préalable. Dans le cas où la

détection de la balle en zone libre devrait se faire de façon complètement automatique, il serait possible

d’utiliser le capteur catadioptrique pour la détecter et de reculer vers la boule. Un quatrième capteur pointant

Tableau 5-10 : Description des états de la MSA de reprise de ligne


Rapprochement (GL_REACH) 0 Rapprochement du robot vers la ligne

Rotation (GL_ROTATE) 1 Rotation du robot pour s’orienter vers la ligne

(0) Rapprochement

Vu = 0 ?

OUI

(1) Rotation

NON

w = 0 ?

NON

OUI



vers le bas pourrait alors être utilisé pour s’arrêter à une distance connue de la boule. Il serait aussi possible

d’utiliser la vision artificielle pour compléter cette détection.

Tableau 5-11 : Description des états de la MSA de ramassage de boule en zone libre


Cible (FZP_GOTOXY) 0 Déplacement du robot vers la cible (près de la boule)

Correction (FZP_CORRECT) 1 Correction de la position si le robot est mal aligné

Rotation (FZP_ROTATE) 2 Rotation du robot pour s’orienter vers la boule

Rapprochement (FZP_REACH) 3 Rapprochement du robot vers la boule

Lancement (FZP_LAUNCH) 4 Lancement du moteur du ramasse-boules

Attente (FZP_WAIT) 5 Attente de l’arrêt du moteur du ramasse-boules



Figure 5-27: Diagramme d’états de la MSA de ramassage de boule en zone libre

5.4.1.6 Machine à états de reprise de ligne en zone libre

Cette machine à états (méthode getlinefz()) permet au robot de reprendre la ligne après un ramassage de boule

en zone libre. Comme pour les méthodes de ramassage, elle est presqu’identique à la machine à états de reprise

de ligne. Seul le premier état diffère, puisque le robot doit aller se repositionner sur la ligne qui peut être très

loin de ce dernier.

NOTE: Dans l’implantation actuelle, la position et l’orientation de reprise de ligne sont spécifiées au robot

de façon à retrouver la ligne à une position qui minimise la distance parcourue par le robot et ainsi sauver du

temps. Dans le cas où la reprise de ligne en zone libre devrait se faire de façon complètement automatique, il

serait possible de revenir au point où le robot a quitté la ligne. Il serait également possible d’utiliser la balise

(0) Cible

(1) Correction

(3) Rapprochement

Vu = 0 ?

OUI

position ok ?

Vu = 0 ?

(2) Rotation

NON

NON

CATA arriere ?

NON

NON

OUI OUI

OUI

Vu = 0 ?

NON

(4) Lancement

OUI

(5) Attente

arret moteur 3 ?

NON

OUI



avec matériau réfléchissant qui indique une position possible pour la reprise de ligne (voir figure 2-1), mais

nous n’avons pas l’intention d’ajouter un capteur catadioptrique à 1m du sol sur le robot.

Figure 5-28: Diagramme d’états de la MSA de reprise de ligne en zone libre

5.4.2 Autres cerveaux

Voici la liste des cerveaux qui ont été développés jusqu’à présent ainsi qu’une brève description du

comportement qu’ils implantent au robot.

• Spin: Ce cerveau permet au robot de tourner sur son centre. Le départ et l’arrêt du robot est contrôlé parle capteur catadioptrique arrière. Le robot alterne le sens de rotation à chaque départ. La vitesse derotation est ajustable à l’exécution. Cerveau développé pour permettre une exposition dynamique durobot dans un espace restreint minimal.

• SquareChaos: Ce cerveau permet au robot d’atteindre des points aléatoires dans le plan à l’intérieur d’unespace rectangulaire. La dimension de l’espace rectangulaire est ajustable à l’exécution. Cerveaudéveloppé pour permettre une exposition dynamique du robot dans un espace plus ou moins restreint.

• TestXY: Ce cerveau demande au robot d’atteindre plusieurs points successivement pour finalementrevenir au point initial. Cerveau développé dans le but de tester les fonctionnalités de la classe Trajectoryet d’évaluer la précision et la répétabilité du robot.

Tableau 5-12 : Description des états de la MSA de reprise de ligne en zobe libre


Rapprochement (FZP_GOTOXY) 0 Rapprochement du robot vers la ligne

Rotation (GL_ROTATE) 1 Rotation du robot pour s’orienter vers la ligne

(0) Rapprochement

Vu = 0 ?

OUI

(1) Rotation

NON

w = 0 ?

NON

OUI



6. Modèle du robot

Le modèle de robot présenté dans cette section utilise les hypothèses suivantes

• Glissement latéral négligé: nous avons un robot à contrainte non-holonome1 et nous allons considérerque le glissement latéral est impossible. Cela permet de simplifier grandement le modèle puisque nousn’avons pas à considérer la force centrifuge et l’adhérence du robot face à des forces latérales.

• Roulis et tangage négligés: nous supposons que le centre de masse est suffisamment bas pour empêcherle roulis et le tangage du robot selon les accélérations que nous lui demandons.

• Centre de masse au milieu de l’axe des roues motrices: cette hypothèse qui est d’ailleurs valide vue laconfiguration du robot, permet de modéliser le robot comme un disque dont le centre est le centre del’axe et dont la masse est uniformément répartie sur la surface de ce disque. Cette hypothèse simplifiegrandement la modélisation de l’inertie de rotation du robot puisqu’elle devient simplement l’inertied’un disque.

• Régime transitoire des moteurs négligé: le circuit équivalent des moteurs DC possède une constante de

temps ( ) très faible comparativement à la constante de temps mécanique. Nous pouvons

donc négliger le régime transitoire électrique.

6.1 Géométrie du robot

La figure 6-1 présente le modèle géométrique du robot. Seuls 4 paramètres sont utiles, soit la distance entre

les deux roues motrices l, le rayon des roues motrices Ra, la distance entre l’axe des roues motrices et le module

de suivi de ligne ds et la largeur du module de suivi de ligne ls. Le tableau 6-1 en donne les valeurs numériques.

1. Contrainte indiquant que le glissement latéral est impossible, réduisant ainsi le domaine des vitesses de translation admis-sibles dans le plan.

τe L Re⁄=

l

2Ra

ls

ds

module desuivi de

ligne



Figure 6-1: Géométrie du robot SpinoS

6.2 Modèle cinématique du robot

La figure 6-2 illustre les paramètres cinématiques du robot selon un référentiel fixe. Ce robot est constitué de

trois degrés de liberté, soit x, y et

Figure 6-2: Modèle cinématique du robot SpinoS

Les informations que nous obtenons de la boucle temps réel sont les déplacements angulaires des deux moteurs

depuis la dernière itération. À partir de ces données, les équations suivantes sont utilisées pour retrouver les

différents paramètres cinématiques du robot:

Tableau 6-1 : Paramètres géométriques du robot SpinoS

Description Symbole Valeur

Distance entre les roues motrices l 0.40m

Rayon des roues motrices Ra 0.0525m

Distance entre le module de suivi de ligne et l’axe des roues ds 0.30m

Largeur du module de suivi de ligne ls 0.30m

θ

y

x

(x, y)

θ

ω

v1

v2

Vu

θ2 ω2,

θ1 ω1,

ω1 td

dθ1= ω2 td

dθ2=

v1 ω1 Ra⋅= v2 ω2 Ra⋅=



Par contre, le modèle dynamique du robot utilisé en simulation calcule directement les accélérations

tangentielle et angulaire. Nous désirons donc retrouver les vitesses, la position et l’orientation du robot, mais

également les vitesses angulaires des deux roues motrices (pour les contrôleurs de moteurs et la modélisation

de la friction). Ainsi, les équations suivantes sont également utiles:

6.3 Modèle dynamique du robot

Le modèle dynamique du robot est basé sur le développement fait dans [8] et il est utilisé dans le cadre du cours

ELE3100: Projets de génie électrique. Ce modèle permet de modéliser l’inertie en translation et l’inertie en

rotation du moteur, tout en considérant le modèle dynamique des moteurs DC. Le développement de ce modèle

étant bien détaillé dans [8], seules les équations résultantes sont présentées:

• Inertie de translation:

m (masse du robot)

Vu

v1 v2+

2----------------=

ωv2 v1–

l----------------=

θ ω td∫=

x Vu θcos⋅ td∫=

y Vu θsin⋅ td∫=

Vu V· u td∫=

ω ω· td∫=

ω1

Vuω l⋅

2----------+

Ra-----------------------=

ω2

Vuω l⋅

2----------–

Ra----------------------=



• Inertie de rotation:

NOTE: Ceci correspond à l’inertie d’un disque. Le rayon du disque est considéré comme étant la distance

entre les roues motrices du robot. Toutefois, cette valeur est approximative puisqu’il serait nécessaire de

prendre des mesure expérimentales pour déterminer cette inertie. Comme l’inertie d’un disque varie en

fonction du carré de son rayon, cette valeur a beaucoup d’influence sur le comportement du robot en rotation.

• Accélération en translation:

• Accélération en rotation:

où V1 et V2 sont respectivement les tensions du moteur de gauche et du moteur de droite. Les valeurs des forces

de friction Ff1 et Ff2 seront égales en valeur absolue ( ), mais leur signe sera

déterminé par les vitesses de rotation des roues ( et ).

Pour ce qui est des paramètres des moteurs, voici la correspondance avec la documentation de Pittman:

, ,

J12--- m

l2--- 2

⋅ ⋅=

Vu·

Kt V1 V2+( ) CtVu

Ff1 Ff2+

m--------------------- –+=

Kt

nKΦRaRem-----------------=

Ct2n

Ra2m

----------KΦKb

Re-------------- b+ =

ω· Ko V1 V2–( ) CoωFf1 Ff2–

2J--------------------- –+=

Ko

lnKΦ2RaReJ------------------=

Ctl2n

2

2Ra2J

------------KΦKb

Re-------------- b+ =

Ff1 Ff2 Ff µc N⋅= = =

ω1 ω2

Re RT= KΦ KT= Kb KE= b D=



7. Contrôleurs et simulation

Les sections qui suivent décrivent le fonctionnement des différents contrôleurs utilisés sur le robot. Elles

donnent également les principales utilités et quelques résultats sont présentés.

Tous les modèles de simulation ont été développés sous Simulink, l’environnement de simulation de Matlab.

Cet environnement permet assez rapidement de développer des modèles de simulation complets grâce à une

multitude de blocs entrées/sorties, des blocs utilitaires pour obtenir les résultats et le tout dans une interface

conviviale. Il est donc intéressant, une fois un modèle de simulation développé, d’utiliser cet outil pour valider

des concepts, valider et ajuster des contrôleurs, étudier l’effet de certains paramètres sur le système, etc. Mais

il est également bien utile de pouvoir simuler le système en utilisant le programe de contrôle utilisé sur le vrai

robot. Il est alors possible de valider l’implantation des algorithmes en simulation et de déterminer, si

nécessaire, sans courir le risque de générer des incidents fâcheux avec le système réel. Une ébauche d’outils

de simulation a été développée dans le cadre du projet SpinoS et il sera intéressant de la compléter dans un

avenir rapproché. Les modèles de simulation peuvent être trouvés dans le répertoire simulink du CD fourni

avec ce rapport.

7.1 Contrôleur en boucle ouverte

7.1.1 Description du contrôleur

Le contrôleur en boucle ouverte est de loin le contrôleur le plus simple. Puisqu’il n’y a aucun paramètre qui

est asservi, l’appellation de contrôleur n’est même pas justifiée, mais nous la conserverons tout de même. Par

contre, le contrôleur en boucle ouverte est d’une grande utilité dans le développement des différents

contrôleurs du robot. Il permet dans un premier temps de vérifier les hypothèses émises sur le comportement

du robot. Il permet en effet de caractériser le robot grâce à des mesures expérimentales appropriées et ainsi

obtenir des estimations précises de différents paramètres (vitesses maximales, friction, inertie, etc.). Il permet

dans un deuxième temps de valider le modèle dynamique du robot utilisé en simulation. Si des données

expérimentales ont été recueillies du robot, il est alors possible de fournir une bonne estimation des différents

paramètres du système et ainsi obtenir un modèle de simulation réaliste.

Comme le montre le schéma-blocs du contrôleur en figure 7-1, les entrées du système sont les tensions à

envoyer aux deux moteurs (V1, et V2) et nous cherchons ensuite à mesurer les paramètres cinématiques du

robot (x, y, , Vu et ). Les tensions appliquées vont donc générer une certaine rotation des moteurs et cette

rotation des moteurs sera obtenue grâce aux encodeurs, permettant ainsi de calculer les paramètres

θ ω



cinématiques.

En simulation (figure 7-2), les moteurs et les encodeurs sont remplacés par le modèle dynamique du robot

présenté en section 6.3. Ceci est en fait le seul élément distinctif et il apparaît donc évident que ce contrôleur

permet de valider le modèle dynamique du robot.

Figure 7-1: Schéma-blocs du contrôleur en boucle ouverte: situation réelle

Figure 7-2: Schéma-blocs du contrôleur en boucle ouverte: simulation

7.1.2 Modèle de simulation

Ce modèle est implanté dans le fichier spinos_BO.mdl et il correspond au schéma-blocs de la figure 7-2.

7.1.3 Résultats

Grâce à ce contrôleur et au simulateur, il a été possible de vérifier certaines caractéristiques du robot. Par

exemple, la courbe de la figure 7-3 présente la vitesse tangentielle du robot en fonction de la tension

d’alimentation des moteurs. Cette courbe permet de déterminer le gain statique du système en translation, qui

est en fait directement proportionnel à la constante de force contre-électromotrice des moteurs. Puisque cette

constante est spécifiée dans la fiche technique des moteurs, il est normal de voir une grande ressemblance entre

les valeurs expérimentales et les valeurs simulées. La zone morte du moteur n’est toutefois pas représentée sur

les courbes de la figure 35 puisqu’il a été impossible de soumettre des tensions de très faible amplitude aux

Moteurs +encodeurs

V1

V2

theta1

theta2

Modèlecinématique

x

y

theta

Vu

w

Modèledynamique du

robot

V1

V2

Vu

w

Modèlecinématique

du robot

x

y

theta



moteurs.

Figure 7-3: Vitesse tangentielle du robot en fonction de la tension appliquée aux moteurs

Il est également possible de mesurer des paramètres tels les vitesses maximales du robot en considérant la

tension d’alimentation maximale. Par exemple, les courbes de la figure 7-4 et de la figure 7-5 présentent les

vitesses tangentielle et angulaire maximales respectivement obenues du modèle de simulation. Nous obtenons

ainsi en simulation une vitesse tangentielle maximale de 4,50m/s et une vitesse angulaire maximale de

21,50rad/s. Ces valeurs sont légèrement inférieures à celles obtenues en considérant la vitesse maximale du

moteur sans charge puisque la friction des roues du robot avec le sol est modélisée. Ces valeurs ne sont pas

exactement les mêmes valeurs que nous pourrions mesurer sur le robot puisque la friction n’est pas modélisée

exactement, mais elles sont tout de même très près de la réalité.

0 2 4 6 8 1 0 1 2 1 4 1 6 1 8 2 00

0 . 5

1

1 . 5

2

2 . 5

3

3 . 5

4

T e n s i o n ( V )

Vite

sse

tang

entie

lle(m

/s)

s i m u l a t i o nr o b o t r é e l



Figure 7-4: Vitesse tangentielle maximale du robot (simulation)

Figure 7-5: Vitesse angulaire maximale du robot (simulation)

NOTE: La simulation en boucle ouverte permet donc de déterminer une multitude de paramètres propres au

robot. La caractérisation de ce système n’ayant pas été effectuée en profondeur, il serait important d’obtenir

les différentes mesures permettant de mieux connaître le système et de réviser certains paramètres du modèle

de simulation (en particulier la friction et l’inertie de rotation).

0 1 2 3 4 5 6 7 8 9 1 00

0 . 5

1

1 . 5

2

2 . 5

3

3 . 5

4

4 . 5

5

t e m p s ( s )

vite

sse

tang

entie

lle(m

/s)

0 1 2 3 4 5 6 7 8 9 1 00

2 . 5

5

7 . 5

1 0

1 2 . 5

1 5

1 7 . 5

2 0

2 2 . 5

2 5

t e m p s ( s )

vite

sse

angu

laire

(rad

/s)



7.2 Contrôleur en boucle fermée


Le contrôleur en boucle fermée permet de contrôler la vitesse tangentielle et la vitesse angulaire du robot. En

fait, la stratégie de commande ne contrôle pas directement ces vitesses mais bien les vitesses angulaires des

deux moteurs, puisque tel est le fonctionnement de la carte de contrôle des moteurs. Ce contrôleur est crucial

au fonctionnement du robot puisque des contrôleurs de plus haut niveau peuvent être insérés dans le système

et ils peuvent utiliser le contrôleur de vitesses. Tel est le cas par exemple pour le contrôleur de suivi de ligne

présenté en section 7.3. Il est donc important d’ajuster les gains de contrôleur correctement de façon à obtenir

un système rapide, précis et robuste sur lequel on pourra construire.

Le schéma-blocs de ce contrôleur, tel qu’implanté sur le robot, est présenté en figure 7-6. On y remarque

premièrement les deux entrées du système qui sont la vitesse tangentielle désirée et la vitesse angulaire désirée.

Grâce aux équations de cinématique inverse définies en section 6.2, il est alors possible de retrouver les

vitesses de rotation désirées de chacune des roues motrices. Ces valeurs sont alors envoyées aux contrôleurs

de moteur qui se chargent, grâce à un générateur de trajectoire et à une boucle PID de calculer la tension de

commande à transmettre aux moteurs. Grâce ensuite aux encodeurs optiques des moteurs, le contrôleur pourra

fermer les deux boucles de contrôle. Les deux derniers blocs de ce schéma correspondent en fait au contrôleur

en boucle ouverte présenté précédemment.

Le modèle de simulation dont le schéma-blocs est présenté en figure 7-7 fonctionne principalement de la même

façon que le système réel. Les mêmes équations sont utilisées pour déterminer les vitesses de rotation désirées

des deux moteurs et les contrôleurs de moteur sont idéalement les mêmes que ceux utilisés par la carte de

contrôle. La différence principale avec le modèle réel est encore une fois les moteurs qui sont remplacés par

le modèle dynamique du robot. De plus, les orientations des deux moteurs sont calculées dans le modèle

cinématique du robot. Pour les contrôleurs de moteur, un modèle a été développé permettant de simuler le

fonctionnement des contrôleurs de moteurs utilisés sur le robot1. Le schéma Simulink de ce modèle est présenté

à la figure 7-8. On y retrouve principalement le générateur de trajectoire qui est simplifié et représenté par une

saturation sur la variation de la vitesse, ce qui permet donc de respecter l’accélération désirée pour le profil

trapézoïdal. Ensuite la vitesse angulaire résultante est intégrée pour obtenir la position angulaire désirée qui

est comparée à la position réelle. L’erreur d’orientation est transformée pour représenter les valeurs réellement

mesurées par la carte de contrôle (selon le nombre de tics des encodeurs et le ratio de l’engrenage) et ensuite

passée dans un filtre PID. La sortie du filtre est additionnée du facteur anticipatif sur la vitesse angulaire

1. Seul le mode d’asservissement en vitesse est possible cependant.



désirée et nous obtenons la tension à appliquer au moteur en binaire sur 16bits signé, c’est pourquoi il est

nécessaire de diviser par 32767 pour retrouver la tension en V. En réalité, la tension de commande reçue de la

carte de contrôle ne pourra excéder la tension des batteries, ce qui correspond à un signal à MLI1 de 100%.

Ainsi, il serait souhaitable de limiter la tension de commande dans le modèle de simulation pour obtenir un

modèle qui soit le plus réaliste possible et qui permette d’observer l’effet des différentes non-linéarités du

système réel.

Figure 7-6: Schéma-blocs du contrôleur en boucle fermée: situation réelle

Figure 7-7: Schéma-blocs du contrôleur en boucle fermée en simulation

1. MLI est la traduction de PWM et signifie ’Modulation de la Largeur d’Impulsion’.

Modèlecinématique

x

y

theta

Vu

w

V1

V2

theta1

theta2

Controleursde

moteurs

Cinematiqueinverse

w1_des

w2_des

theta1, theta2

Vu_d

w_dMoteurs +encodeurs

Modèledynamique

du robot

V1

V2

Vu

w

Modèlecinématique

du robot

x

y

theta

Controleursde

moteurs

Cinematiqueinverse

w1_des

w2_des

w1, w21/stheta1, theta2

Vu_d

w_d



Figure 7-8: Modèle du contrôleur de moteur


Ce modèle est implanté dans le fichier spinos_BF.mdl et il correspond au schéma-blocs de la figure 7-7.

7.2.3 Résultats

Grâce au contrôleur en boucle fermée, nous sommes en mesure de mesurer la réponse du système à des

commandes en vitesse tangentielle et en vitesse angulaire. Avant de présenter les résultats, il est important de

préciser que les données recueillies du robot ont été filtrées afin de procurer plus de clarté dans les résultats.

En effet, les vitesses recueillies du programme de contrôle sont obtenues en dérivant directement les signaux

des encodeurs . Évidemment, ces signaux sont bruités dû entre autre à la discrétisation des encodeurs et aux

perturbations du terrain, mais le filtrage n’est pas nécessaire et surtout indésirable dans le programme de

contrôle dû au délai qu’il engendre. Pour la présentation des résultats, le filtrage est effectué grâce à un deux

filtres médians successifs de dimension 4. La figure 7-9 présente le résultat de ce filtrage pour un essai à basse

vitesse (bruit élevé relativement à la commande), soit une vitesse tangentielle désirée de 0,25m/s.



Figure 7-9: Résultat du filtrage des données recueillies du programme de contrôle

Les courbes de résultats sont regroupées en annexe 2 et elles présentent les résultats d’une série de tests sur le

robot pour différentes vitesses désirées. Les résultats sont jumelés aux résultats obtenus en simulation. Les

gains des contrôleurs de moteurs utilisés pour ces essais étaient les suivants: , ,

et . Ces gains ont été ajustés par essais et erreurs puisque l’utilisation de gains calculés de

façon analytique ne donnait les perfromances attendues. Cela s’explique principalement par les nombreuses

non-linéarités qui sont présentes qui tendent à déteriorer la réponse de ce dernier. D’ailleurs, il est assez

difficile d’observer une concordance évidente entre la réponse du modèle de simulation et la réponse du

système réel puisque de nombreuses caractéristiques non-linéaires ne sont pas présentes dans le modèle de

simulation (discrétisation des encodeurs, zone morte du moteur, imprécisions mécaniques, perturbations du

terrain, etc.). Les gains retenus permettent néanmoins d’obtenir une réponse qui soit précise et rapide et qui

comporte le moins de bruit possible.

En observant les différents essais, on peut observer que la réponse du système est plutôt mauvaise à basse

vitesse. Cela peut s’expliquer par le fait que les non-linéarités du système ont beaucoup plus d’influence à

basse vitesse qu’à haute vitesse. Par exemple, la zone morte des moteurs peut amplifier considérablement le

dépassement de la réponse à basse vitesse. Nous remarquons cependant que la réponse du système est bonne

et constante pour des demandes de vitesse suffisamment élevées. Le fait que la réponse soit constante est

particulièremnt intéressant puisque nous savons que nous obtenons, pour des mêmes gains, une r.ponse qui

soit satisfaisante sur une grande plage de commande. Évidemment, nous retrouvons le profil de vitesse

0 0.5 1 1.5 2 2.50

0.05

0.1

0.15

0.2

0.25

0.3

0.35

temps (s)0 0.5 1 1.5 2 2.5

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

temps (s)

KP 200= KD 400=

KI 0= Kvff 0=



trapézoïdal généré par les contrôleurs de moteurs. L’accélération demandée étant de 2m/s2, nous retrouvons

bel et bien une dérivée d’environ 2 durant les accélérations et décélérations des différents essais. Pour les

courbes d’asservissement en vitesse angulaire, nous retrouvons une dérivée d’environ , soit 10rad/s2.

Nous pouvons remarquer également sur les courbes qu’il y a un certain délai au départ avant que l’échelon de

comande soit envoyé et donc que le mouvement s’active. Ce délai est d’environ 0,15s et il correspond

probablement au temps mis par le programme de contrôle pour s’initialiser. Ce délai ne dérange aucunement

le comportement du robot puisqu’il est présent seulement au départ du programme. Par contre, sa valeur est

assez grande et il serait nécessaire de déterminer ce qui cause un tel délai. Finalement, nous remarquons que

la réponse du système réel est toujours légèrement en retard par rapport au modèle de simulation. Le temps de

réponse du système n’étant pas considéré dans le modèle de simulation, ceci est tout à fait normal. Ce temps

de réponse, pourrait éventuellement être évalué précisément et inclus dans le modèle de simulation.

7.3 Contrôleur de suivi de ligne


Le contrôleur de suivi de ligne permet d’asservir le robot sur le tracé qu’il doit parcourir. Les objectifs de ce

contrôleur sont d’obtenir un suivi qui soit rapide puisque la vitesse moyenne doit être la plus élevée possible,

mais également un suivi qui soit robuste puisqu’il est très difficile de reprendre le tracé lorsque le robot

décroche de la trajectoire désirée.

Pour illustrer le fonctionnement de ce contrôleur, nous pouvons observer le schéma-blocs du système présenté

en figure 7-10. Nous remarquons donc que ce contrôleur est construit par-dessus le contrôleur en boucle

fermée présenté dans la section précédente. En fait, la stratégie de commande consiste à asservir la vitesse

angulaire en fonction de la position de la ligne et à conserver une vitesse tangentielle désirée constante, mais

la plus élevée possible. Le contrôleur de suivi de ligne reçoit donc en entrée la position de la ligne mesurée par

le module de suivi de ligne. Cette position est reçue en mètres et la position 0 correspond au centre du module

de suivi de ligne. Grâce à la position de la ligne, le contrôleur est alors en mesure de déterminer la vitesse

angulaire désirée pour corriger l’erreur sur la position de la ligne. L’erreur est corrigée selon un compensateur

PID et l’équation de la vitesse angulaire désirée en fonction de la position de la ligne (lp) et de la position de

la ligne désirée (lpdes) est la suivante:

2 2 l⁄⋅

ωd KPS lpdes lp–( )⋅ KDSs lpdes lp–( )KIS

s-------- lpdes lp–( )⋅+⋅+=



Figure 7-10: Schéma-blocs du contrôleur de suivi de ligne: situation réelle

Le schéma-blocs du modèle de simulation est présenté à la figure 7-11. Nous remarquons que la principale

distinction, mis à part les distinctions préalablement énumérées pour les contrôleurs en boucles ouverte et

fermée, se situe au niveau du module de suivi de ligne. Effectivement, il est nécessaire de modéliser et de

simuler ce module pour obtenir un comportement qui soit idéalement identique au module réel. Nous

remarquons que les entrées de ce module sont des informations sur la cinématique (Vu et ) ainsi que le rayon

de courbure (Rc) du tracé.

Figure 7-11: Schéma-blocs du contrôleur de suivi de ligne: simulation

En utilisant donc les entrées de ce bloc et les paramètres géométriques du robot, nous cherchons à calculer la

Modèlecinématique

x

y

theta

Vu

w

V1

V2

theta1

theta2

Controleursde

moteurs

Cinematiqueinverse

w1_des

w2_des

theta1, theta2

Vu_d

w_dMoteurs +encodeurs

Module desuivi de ligne

Controleurde suivi de

lignelp

θ

Modèledynamique

du robot

V1

V2

Vu

w

Modèlecinématique

du robot

x

y

theta

Controleursde

moteurs

Cinematiqueinverse

w1_des

w2_des

w1, w21/s

Vu_d

w_d

theta1, theta2

Module desuivi de ligne

Controleurde suivi de

lignelp

Rc



position de la ligne lue du module de suivi de ligne. Pour déterminer cette position, il suffira de déterminer

dans un premier temps l’écart latéral de l’axe des roues du robot par rapport au tracé (los), puis de retrouver la

mesure du module de suivi de ligne grâce à la géométrie du robot. Il est important de mentionner que les

différentes équations présentées ici ont été développées en considérant les possibilités de simulation de

l’environnement Simulink. En effet, ces possibilités ne sont pas infinies en ce qui a trait à la manipulation de

variables et à la modélisation et elles imposent donc certaines contraintes. Il est ainsi nécessaire, dans le but

de faciliter l’implantation d’un modèle sous cet environnement, de développer des équations qui soit

facilement implantables.

Ceci étant dit, voyons comment nous pouvons calculer l’écart latéral. La figure 7-12 illustre le modèle utilisé

pour déterminer la position de la ligne. La distance los est déterminée par une droite reliant le centre du robot

au point sur le tracé qui permet d’obtenir une droite perpendiculaire à la tangente du tracé à ce point. Cette

distance est en fait la distance la plus courte séparant le centre du robot du tracé. Pour calculer los, nous

pouvons utiliser l’équation suivante:

où , ce qui correspond à l’écart d’orientation du robot par rapport à la tangente à la courbe. La

seule information que nous ne connaissons pas à ce moment est et nous chercherons donc à l’obtenir. Pour

calculer l’orientation du tracé, nous pouvons utiliser l’expression suivante:

où d correspond à la distance parcourue sur le tracé, qui n’est pas nécessairement égale à la distance parcourue

par le robot, puisque le suivi n’est pas parfait. Il est important de ramarquer que l’équation précédente n’est

pas utilisable pour un rayon de courbure nul (le robot doit tourner sur un point) ou encore un rayon infini (ligne

droite). Le cas particulier de la ligne droite est prévu et traité dans le modèle de simulation puisqu’un rayon de

courbure supérieur à 100m est considéré comme une ligne droite et l’orientation du tracé demeurera à ce

moment constante. Un rayon de courbure nul est toutefois impossible, cette situation n’étant pas pertinente à

notre modèle. Pour obtenir la distance parcourue, nous pouvons utiliser l’expression .

Nous remarquons cependant que nous obtenons une boucle algébrique, car nous tentons d’obtenir d’une

expression qui en dépend. Néanmoins, voilà une des caractéristiques de l’envrionnement Simulink: Il n’a

généralement aucune difficulté à traiter la majorité des boucles algébriques. Il lui suffit dans ce cas de prendre

la valeur initiale pour la variable en question ( ) dans notre cas. Sous certaines conditions, par exemple avec

(7.1)los Vu θossin⋅( ) td∫=

θos θl θ–=

θl

θldRc-----=

d Vu θoscos⋅( ) td∫=

θos

θos



l’utilisation de fonctions de transferts (discrétisées ou continues), la présence d’une boucle algébrique sera

signalée en erreur et il suffira d’ajouter un délai d’une itération (bloc ’Unit delay’) pour régler la situation.

Nous obtenons donc l’expression:

Figure 7-12: Modèle utilisé pour le calcul de la position de la ligne

Nous sommes donc en mesure d’évaluer l’équation 7.1 en utilisant la vitesse tangentielle et l’orientation du

robot ainsi que la seule information que nous possédons du tracé, soit son rayon de courbure. Les équations

utilisées pour déterminer los sont implantées dans le bloc ’Module de suivi de ligne’ du modèle de simulation.

Nous pouvons dès lors, par construction géométrique, retrouver la position de la ligne vue par le module de

suivi de ligne, la variable lp. Nous obtenons alors l’expression suivante:

Il est important de remarquer que l’expression que nous obtenons dépend non seulement de l’écart latéral et

de l’écart d’orientation. Le contrôleur utilisant la longueur lp devrait donc être en mesure de corriger l’écart

latéral, mais également l’écart d’orientation du robot, ce qui est appréciable. La valeur que nous obtenons de

θl1Rc----- Vu θoscos⋅( ) td∫=

ds

lp

los

θlθ

y

x

le

lplos θosdssin+

θoscos-----------------------------------=



lp est exacte lorsque le robot est sur une ligne droite, mais elle constitue toutefois une approximation lorsque

le robot se retrouve sur une courbe. En effet, comme le montre la figure 7-12, il serait nécessaire d’évaluer la

longueur le, afin d’obtenir la valeur exacte de la position de la ligne lue par le module. Toutefois, lorsque

l’écart d’orientation et l’écart latéral sont faibles, cette longueur est également faible. Par exemple, pour un

rayon de courbure d’1m et des écarts nuls, nous obtenons:

Voici donc une lacune importante du modèle puisque cette longueur n’est pas calculée. L’évaluation de cette

longueur serait désirée puisqu’elle permettrait entre autre d’obtenir le comportement réel du robot en entrée et

sortie de courbe. En effet, cette longueur représente la seule longueur qui sera mesurée en entrée et sortie de

courbe, lorsque le rayon de courbure sur le module de suivi de ligne est différent de celui se trouvant sur l’axe

des roues. Ainsi, en négligeant cette longueur, il sera impossible de simuler une caractéristique importante et

appréciable du module de suivi de ligne qui permet de combler le retard dû au temps de réponse du système.

Mis à part cette lacune, le modèle demeure fidèle au système réel (en considérant que le simulateur dynamique

du robot est fidèle) et il est possible d’obtenir des simulations pertinentes comme il sera présenté dans la

prochaine section. D’ailleurs, sa principale utilité étant de pouvoir régler les gains du contrôleur de suivi de

ligne de façon précise, son utilisation est pertinente.

Finalement, il serait important de mentionner les différentes non-linéarités qui ont été ajoutées au modèle pour

obtenir une représentation fidèle du système réel. Premièrement, la longueur du module de suivi de ligne (ls)

qui est de 30cm a été considérée. Donc, le module ne pourra pas mesurer une erreur (par rapport au centre du

module) de plus de 15cm. Cette caractéristique est importante puisqu’elle influence énormément la stabilité

du contrôleur. Ensuite, la longueur lp qui est calculée a été discrétisée pour représenter l’effet du nombre de

capteurs limité du module de suivi de ligne. Ainsi, nous obtenons une précision qui dépend du nombre de

capteurs et puisque nous faisons la moyenne des capteurs lus, nous obtenons une précision de:

NOTE: Il serait important de considérer une période de simulation semblable, sinon identique, à la période

utilisée dans le logiciel de contrôle. Puisque la réponse du système dépend de cette période, il sera ainsi

possible d’obtenir une réponse plus fidèle. Cette période correspond à la variable Ts enregistrée dans le fichier

simulink/spinos_init.m.

le RcdsRc----- asin

cos– 0.046m= =

lp∆ ls2 n 1–( )-------------------- 0.48cm= =




Ce modèle est implanté dans le fichier spinos_strip.mdl et il correspond au schéma-blocs de la figure 7-11.

7.3.3 Résultats

Cette section présente des résultats obtenus par simulation du contrôleur de suivi de ligne. Le module de suivi

de ligne n’étant pas fonctionnel au moment de l’écriture de ce rapport, il a été impossible de recueillir des

courbes du robot en mode suivi de ligne. Nous avons toutefois recueilli des données (mais pas de courbes!)

lors d’essais préliminaires effectués en févrirer dernier et nous verrons que le comportement obtenu en

simulation est similaire au comportement observé sur le robot.

Le premier essai que nous étudierons consiste à partir le robot sur une ligne droite (rayon de courbure infini)

et à le faire entrer dans une courbe (rayon de courbure de 1m) à une vitesse de 2m/s. Nous pouvons dans un

premier temps observer la réponse du système pour un module de suivi de ligne idéal, c’est-à-dire d’une

largeur infinie et donnant un signal non discrétisé. Pour l’ajustement des gains, nous devons procéder par

essais et erreurs puisque le modèle est non-linéaire et que nous ne linéariserons pas le modèle. La figure 7-13

montre la position de la ligne (la réponse du système à un changement de rayon de courbure qui est perçu

comme une perturbation) pour des gains KPS = 50, KDS = 6.5et KIS = 40. Nous obtenons alors une réponse

relativement rapide et qui demeure à l’intérieure de la limite de 15cm (limite du module de suivi de ligne). Le

changement brusque de rayon de courbure (l’entrée en courbe) à 2s engendre inévitablement une crête. Cette

crête serait moins prononcée sur le système réel puisque la correction débutera lorsque le module de suivi de

ligne entrera en courbe, et non l’axe des roues motrices. Nous obtenons néanmoins une réponse satisfaisante.

Il est important cependant de mentionner que le domaine de stabilité des gains est très limité. Pour mieux

étudier cette situation, il serait intéressant de linéariser le système et d’observer les pôles du système en boucle

fermée.

Figure 7-13: Position de la ligne pour essai non discrétisé (2m/s)

0 0 . 5 1 1 . 5 2 2 . 5 3 3 . 5 4 4 . 5 5- 0 . 0 2

0

0 . 0 2

0 . 0 4

0 . 0 6

0 . 0 8

0 . 1

0 . 1 2

0 . 1 4

t e m p s ( s )

posi

tion

dela

ligne

(m)



Nous allons maintenant effectuer le même essai, en utilisant les mêmes gains, pour le module à largeur finie

avec discrétisation de la position de la ligne. La figure 7-14 montre la réponse du système.

Figure 7-14: Position de la ligne pour essai discrétisé (2m/s)

Nous remarquons de façon évidente que le système est instable. En fait, la discrétisation engendre

d’importantes variations dans la dérivée de la position de la ligne. Nous remarquons alors que le gain dérivatif

n’influence à peu près plus le système. Puisqu’il permettait de diminuer les oscillations et ainsi stabiliser le

système pour un gain proportionnel élevé, le système devient inévitablement instable. Il est alors nécessaire

de choisir un gain KPS suffisamment faible pour conserver la stabilité du système. Pour régler ce problème, il

est nécessaire de filtrer le signal entrant dans le dérivateur. Par exemple, l’utilisation d’un filtre passe-bas du

premier ordre avec une fréquence de coupure de 1.6Hz ( ) sera suffisant pour laisser passer

une bonne partie du signal propre au mouvement du robot et atténuer de façon importante les effets de la

discrétisation. Nous obtenons alors une réponse semblable à la réponse obtenue sans discrétisation. La réponse

obtenue est illustrée à la figure 7-15. La réponse que nous obtenons alors est satisfaisante.

Figure 7-15: Position de la ligne pour essai discrétisé avec filtre pour la dérivée (2m/s)

Maintenant, nous allons tenter de faire suivre au robot deux courbes de suite comme il est possible de retrouver

en compétition. Nous savons, grâce aux essais effectués en févrirer dernier, que le contrôleur permet

difficilement l’ajustement pour deux courbes consécutives. Si nous tentons d’asservir le robot sur deux

0 0 . 5 1 1 . 5 2 2 . 5 3 3 . 5 4 4 . 5 5- 0 . 2

- 0 . 1 5

- 0 . 1

- 0 . 0 5

0

0 . 0 5

0 . 1

0 . 1 5

0 . 2

t e m p s ( s )

posi

tion

dela

ligne

(m)

FPB1

0.01s 1+----------------------=

0 0 . 5 1 1 . 5 2 2 . 5 3 3 . 5 4 4 . 5 5- 0 . 0 2

0

0 . 0 2

0 . 0 4

0 . 0 6

0 . 0 8

0 . 1

0 . 1 2

0 . 1 4

0 . 1 6

t e m p s ( s )

posi

tion

dela

ligne

(m)



courbes consécutives en utilisant le modèle de simulation et les gains trouvés précédemment, nous obtenons

la réponse qui est montrée à la figure 7-16. Il est clair que le système réagit trop lentement à la variation du

rayon de courbure et il est donc très difficile de prendre deux courbes inversées consécutives.

Figure 7-16: Position de la ligne pour essai discrétisé, deux courbes consécutives(2m/s)

Évidemment, nous pouvons jouer sur les gains et réussir à trouver une configuration qui fonctionne. Toutefois,

il est clair que le système est à la limite de la stabilité et qu’il sera très sensible à des perturbations. Il serait

également possible de réduire la vitesse tangentielle, par exemple à 1,8m/s, et arriver à stabiliser le système

comme il a été fait en février dernier. Par contre, le critère de performance de 2m/s de vitesse moyenne sur le

tracé de compétition doit absolument être surpassé si nous voulons atteindre la plus haute marche du podium.

Il est donc clair que le contrôleur présenté n’est pas suffisamment performant. La section 7.3.4 propose une

amélioration au contrôleur présenté qui permettrait possiblement une transition plus facile entre 2 courbes

consécutives et qui permettrait facilement d’ajuster la vitesse tangentielle en fonction du type de tracé.

7.3.4 Amélioration du contrôleur du suivi de ligne

La version initiale du contrôleur de suivi de ligne a permis d’atteindre des performances intéressantes très

rapidement, soit les mêmes performances ayant été atteintes par le robot précédent, un suivi de ligne à vitesse

moyenne de 1,8m/s. Toutefois, il a été observé que cet algorithme permet difficilement la variation de la

vitesse tangentielle en fonction du rayon de courbure (nous cherchons à accélérer en ligne droite) et comme il

est démontré en section 7.3.3, il s’ajuste difficilement à une transition d’une courbe à une autre. C’est pour

cette raison qu’un contrôleur utilisant le concept de machine à états devient une option intéressante à étudier.

Le but de ce contrôleur est de permettre l’identification du type de ligne sur laquelle le robot se trouve (ligne

droite, courbe gauche ou courbe droite). Le contrôleur présenté ici vise donc à apporter deux améliorations au

contrôleur initial: permettre la variation de la vitesse tangentielle en fonction du tracé et assurer une transition

rapide et stable entre deux courbes opposées. Dû au retard dans le développement du module de suivi de ligne,

l’algorithme présenté dans les prochaines lignes n’a jamais été essayé sur le robot, nous nous contentrons donc

0 0 . 5 1 1 . 5 2 2 . 5 3 3 . 5 4 4 . 5 5- 0 . 2

- 0 . 1 5

- 0 . 1

- 0 . 0 5

0

0 . 0 5

0 . 1

0 . 1 5

t e m p s ( s )

posi

tion

dela

ligne

(m)



d’étudier son fonctionnement sans en vérifier les performances. Pour en vérifier les performances, il serait

évidemment souhaitable d’en développer le modèle de simulation. Il suffirait de modifier l’implantation du

bloc ’Contrôleur de suivi de ligne’ du modèle spinos_strip.mdl.

Les états du contrôleur sont décrits dans le tableau 7-1 et la figure 7-17 présente le diagramme d’états.

Tableau 7-1 : Description des états de la MSA de suivi de ligne


Ligne droite (L_STRAIGHT) 0 La portion courante du tracé est une ligne droite

Courbe droite (L_RIGHTTURN) -1 La portion courante est une courbe à droite (Rc = 1m)

Courbe gauche (L_LEFTTURN) 1 La portion courante est une courbe à gauche (Rc = 1m)



Figure 7-17: Diagramme d’états de la MSA de suivi de ligne

Nous remarquons que les trois états ont des valeurs spécifiques qui permettent d’ajuster simplement la vitesse

angulaire désirée. En effet l’équation: permet d’ajuster la vitesse angulaire désirée en

considérant le type de courbe de la portion courante. La valeur de Rc, le rayon de courbure de la portion

courante, devrait normalement être mesurée en temps réel sur le tracé. Cette mesure pourrait mener à des

imprécisions importantes et donc un suivi beaucoup moins optimisé. Par contre, selon les spécifications de la

compétition, nous savons que ce rayon sera de 1m pour toutes les courbes. Nous pouvons donc utiliser

LIGNE DROITE:Vd = v_droite

wd = 0lpdes = 0

COURBE DROITE:Vd = v_courbe

wd = etat * Vu/Rclpdes = -etat * cos(asin(ds))

COURBE GAUCHE:Vd = v_courbe

wd = etat * Vu/Rclpdes = -etat * cos(asin(ds))

|d_lp| > seuil_d ?

d_lp > 0 ? NONOUI

d_lp < -seuil_d ? d_lp > seuil_d ?

NONNON

NON

Etats:LIGNE DROITE = 0COURBE DROITE = -1COURBE GAUCHE = 1

Variables:Vu: vitesse tangentielle du robot (m/s)Vd: vitesse tangentielle désirée (m/s)w: vitesse angulaire désirée (rad/s)lpdes: position de ligne désiréed_lp derivee de la position de la ligne par rapport au centre de la strip (m/s)seuil_d: valeur minimale (en valeur absolue) de d_lp pour changement d'etatetat: valeur de l'etat courantRc: rayon de courbure de la piste (1m)ds: distance entre le module de suivi de ligne et l'axe des roues motrices

OUI

OUI OUI

ωd etat Vu Rc⁄⋅=



. Pour contrer les perturbations qui seront inévitablement présentes et pour combler le retard

dû aux accélérations non infinies du robot, un compensateur, par exemple un PD, pour l’erreur de la position

de la ligne (valeur obtenue du module de suivi de ligne) devra être ajouté à la vitesse angulaire désirée. Pour

ce qui est de la vitesse tangentielle, elle peut également varier en fonction du type de courbe. Par exemple, une

vitesse de 2,5m/s pourrait être utilisée en ligne droite et une vitesse de 1,8m/s en courbe. Nous devrions ainsi

réussir à dépasser l’objectif de 2m/s de vitesse moyenne.

Nous considérons à priori qu’un seuil (seuil_d) sur la dérivée de l’erreur de position de la ligne (d_lp) devrait

être suffisant pour des changements d’états appropriés. En fait, il sera nécessaire de bien filtrer la valeur de

l’erreur sur la position de la ligne puisque la discrétisation sur 32bits de la position de la ligne engendre des

crêtes importantes sur sa dérivée. Il est également nécessaire d’ajuster la valeur désirée pour la position de la

ligne puisqu’elle n’est pas la même selon le rayon de courbure. En effet, lorsque le robot est sur une ligne

droite, nous chercherons à positionner la ligne au centre du module de suivi de ligne. Par contre, dans les

courbes, le fait que le module de suivi de ligne soit à l’avant du robot déplace la position de la ligne désirée

puisque nous désirons que l’axe des roues soit perpendiculaire à la tangente à la ligne. La figure 7-18 illustre

cette situation.

Figure 7-18: Position désirée de la ligne en courbe

Nous pouvons obtenir la position désirée pour la situation illustrée de la façon suivante (en considérant

l’équation d’un cercle):

ωd etat Vu⋅=

position de laligne désirée

ds Rc θsin⋅= lpdes Rc θcos⋅=

θ ds( )asin=



Nous pouvons alors utiliser la valeur de l’état courant pour évaluer la valeur désirée de la ligne. Ainsi:

Donc, la valeur désirée pour la position de la ligne variera avec les états et nous pourrons alors l’utiliser pour

le contrôleur PD qui ajuste la vitesse angulaire, mais également pour obtenir une dérivée qui tient compte du

type de courbe. Nous devrions ainsi obtenir des changements d’état fiables. Pour ce qui est du seuil permettant

de changer d’état, il devra être ajusté de façon rigoureuse et il pourrait être fonction de la vitesse tangentielle

puisque la dérivée de la position augmentera plus rapidement en entrée de courbe (vitesse tangentielle élevée)

et plus lentement en sortie de courbe (vitesse tangentielle plus faible).

Une attention particulière doit d’ailleurs être portée aux conditions permettant de changer d’état, puisque les

performances de cet algorithme de contrôle reposent en grande partie sur l’exactitude et la rapidité des

changements d’état. En plus d’être précis pour éviter de créer des mouvements brusques indésirables lors de

changements d’état erronés, l’algorithme doit être rapide en ce sens que la détection d’un changement de type

de tracé doit être fait suffisamment rapidement pour permettre de combler le temps de réponse du système, en

particulier dans le cas de deux courbes différentes successives. Il se pourrait donc que des conditions

supplémentaires soit nécessaires pour empêcher les changements d’état erronés, entre autre après les

transitions d’état (oscillations possibles). Il est également pertinent de remarquer qu’il est impossible, dans

l’algorithme présenté, de passer directement d’une courbe à une autre. Il est nécessaire de passer par l’état

’LIGNE DROITE’ avant de tomber dans une courbe. Pour accélérer le passage d’une courbe à une autre, il

pourrait être nécessaire de permettre un passage direct entre les deux états courbes, par exemple avec un seuil

plus élevé sur la dérivée de la ligne.

Nous pouvons donc espérer des performances assez impressionnantes d’un tel type de contrôleur. Par contre,

pour en avoir la preuve, il faudra dans un premier temps le simuler et l’ajuster, pour ensuite l’essayer sur le

robot.

8. Recommandations et améliorations possibles

Le projet SpinoS n’est évidemment pas terminé et il continuera d’évoluer au sein du groupe étudiant SAE

Robotique. D’ailleurs, l’équipe doit se présenter en compétition au mois de mai 2002 en France. Le projet est

presque mûr pour remporter la compétition, mais certains points restent tout de même à être complétés pour

lpdes ds( )asin( )cos=

lpdes etat– ds( )asin( )cos⋅=



espérer remporter cette dernière. Voici donc les principaux éléments qui devraient être complétés durant le

trimestre d’hiver 2002:

• Correction du circuit imprimé du module de suivi de ligne: évidemment, sans ce module, nous nepouvons compléter aucune épreuve.

• Implantation du contrôleur de suivi de ligne avec machine à états: il faut absolument atteindre l’objectifde 2m/s de vitesse moyenne, et ce, sur un tracé sévère (plusieurs courbes consécutives).

• Implantation de la vision artificielle: il est clair que la prévision des courbes grâce à des algorithmes devision pourraient améliorer les performances en suivi de ligne.

Dans un cadre plus général, de nombreuses améliorations peuvent être apportées au robot pour en faire un

robot mobile beaucoup plus évolué et ainsi permettre le développement de nombreux algorithmes de haut

niveau. Quelques recommandations sont également à formuler dans le but d’éviter les problèmes de fiabilité

du robot et d’éviter les bris de composantes. Voici donc la liste de ces détails importants:

• Écriture d’un rapport sur la conception mécanique: cette partie du présent rapport fut abrégée et il seraitimportant de mieux détailler les étapes de conception mécanique de ce robot mobile pour éventuellements’y référer lors d’un projet futur.

• Validation du modèle dynamique: il serait important de caractériser plus précisément le système pourvalider les paramètres utilisés dans le modèle dynamique, en particulier l’inertie de rotation du robot etla friction des roues au sol.

• Compléter la classe Trajectory: cette classe doit être en mesure de générer des trajectoires beaucoup plusprécises et continues.

• Vérification de la période minimale de pmd_thread: la période de cette boucle doit être relativementgrande et cette valeur minimale semble dépendre du nombre de moteurs asservis par la carte de contrôle.Cette limitation provient possiblement du temps que mettent les différentes séquences de la machine àétat du FPGA à être parcourues . Ce point est à démystifier.

• Vérification des performances temps-réel du système d’exploitation: il serait important de vérifier cesperformances pour éviter les sources d’imprécision. Dans le cas où les résultats seraient insatisfaisants,le passage à un système d’exploitation temps réel (à la base), par exemple QNX, serait souhaitable.

• Choix rigoureux des accélérations maximales: l’accélération maximale ne doit jamais dépasser cellespécifiée par le couple maximal des moteurs. Il est donc nécessaire de réviser les valeurs calculées dansce rapport s’il y a augmentation du poids du robot ou variation d’autres paramètres mécaniques, parexemple la friction.

• Module Ethernet RF: un module de communication réseau sans fil (RF) permettrait de contrôler le robotà distance (sans compromettre nécessairement l’autonomie du robot). Il serait alors possible dedévelopper des modes de contrôle hybrides (semi-autonomes) et des démonstrations impressionnantes(outil promotionnel).

• Anneau de sonars: il serait très utile d’intégrer au robot un anneau de 16 sonars ou plus (fabriqué ouacheté) pour lui permettre de découvrir la géométrie de l’environnement dans lequel il se trouve. Desalgorithmes de navigation pourraient alors être développés.



• Acquisition de la tension des batteries: il serait très utile d’acquisitionner la tension des batteries et detransmettre ce signal à l’ordinateur embarqué. Il serait alors possible de prévenir les pannes etéventuellement de permettre au robot de se recharger automatiquement.

• Utilisation de la librairie MICROB1: cette librairie C++ contient de nombreux outils qui facilitentl’implantation de contrôleurs et d’interfaces de contrôle. Il serait donc pertinent d’intégrer cette librairieau programme de contrôle et d’en utiliser les éléments jugés pertinents à notre projet.

• Utilisation du Stateflow toolbox: cette boîte à outils de Matlab devrait permettre d’inclure les différentesmachines à état du cerveau de SpinoS dans les modèles de simulation déjà développés. Il serait alorspossible d’obtenir des simulateurs complets du robot sous Simulink.

9. Conclusion

Nous avons donc vu dans ce rapport les différents éléments pertinents de la conception de ce robot. Les

principales caractéristiques de la configuration mécanique, du système électrique et du logiciel de contrôle ont

ainsi été présentées. Par la suite, un module de prise décision du programme de contrôle, module qui permet

l’autonomie du robot, développé spécialement pour la compétition a été détaillé Finalement, les différents

contrôleurs utilisés sur ce robot mobile ont été décrits et nous avons pu observer quelques résultats

Nous pouvons donc faire un bref retour sur lesprincipaux objectis de ce projet de robotique mobile. Nous avons

établi les objectifs suivants au début du projet:

• Remporter le Championnat Mondial de Robotique Mobile en y présentant un robot-rouleur autonomecapable de battre les records de performance établis en compétition.

• Créer un robot modulaire offrant des possibilités d’évolution intéressantes, ce qui nous permettra dedévelopper des méthodes de contrôle variées, une fois la compétition remportée, et de déterminer unnouvel objectif principal pour le projet.

Nous avons vu dans les pages de ce rapport que nous avons réussi en grande partie à réaliser ces objectifs. Nous

avons en fait presque tous les éléments nous permettant de remporter la compétition. Il reste à corriger une

légère erreur sur le module de suivi de ligne et à implanter un nouveau contrôleur de suivi de ligne. Cette

implantation pourrait s’avérer plus longue que prévue. Néanmoins, l’équipe a suffisamment de temps avant la

compétition pour développer ce contrôleur et rencontrer le critère de vitesse moyenne pour le suivi de ligne.

Pour ce qui est du second objectif, tout semble indiquer que ce robot est appelé à devenir une plateforme

d’essais et de développement très utile. En effet, étant donnée sa simplicité et ses bonnes performances, il

constitue une plateforme intéressante pour faire des tests et implanter des algorithmes de haut niveau.

Concernant les critères de performance établis également dès le départ, il a été démontré dans ce rapport que

1. MICROB (Modules Intégrés de Contrôle Robotique): librairie C++ servant au développement de contrôleurs de systèmesrobotisés. Cette librairie est développée à l’Institut de Recherche d’Hydro-Québec.



la presque totalité de ces critères sont respectés. En fait, seul le critère pour le suivi de ligne n’a pas été encore

atteint. Les résultats obtenus lors de tests préliminaires en utilisant un prototype et le modèle de simulation

nous portent à croire que la configuration mécanique du robot est excellente et permettra facilement d’atteindre

ce critère en utilisant un contrôleur plus rapide que celui qui a été essayé. Pour les autres critères, nous avons

vu que nous dépassons généralement largement les valeurs minimales demandées.

Ce rapport se voulait donc le résumé le plus complet possible du projet. Toutefois, cette volonté d’inclure la

totalité des détails importants du projet dans un même rapport était audacieuse. En effet, ce projet est vaste et

complexe et il a été impossible de documenter dans le détail toutes les facettesdu projet. Ainsi, certaines parties

ont été résumées brièvement et il serait alors nécessaire de les documenter plus en détails pour permettre un

meilleur suivi et une éventuelle révision du projet. Ainsi, des rapports plus détaillés concernant la conception

mécanique, la réingénierie du module de suivi de ligne et le contrôleur de suivi de ligne devraient être fournis

par l’équipe du projet dans les prochains mois.



Bibliographie

1. Richard Hurteau, Asservissements, notes du cours ELE3201. École Polytechnique de

Montréal, septembre 2000.

2. Pittman, Servo Motor Application Notes. Pittman, 2001. (http://www.pittmannet.com/

220000.html)

3. Pittman, Bulletin LCG. Pittman, 2001. (http://www.pittmannet.com/122100.html)

4. Rick Bélair, Réalisation d’un contrôleur de moteur c.c.. École Polytechnique de Montréal, avril

1997.

5. Jean-Pierre Lefebvre, Conception et réalisation d’un amplificateur d epuissance pour moteur

c.c.. École Polytechnique de Montréal, avril 1999.

6. Jean-Pierre Lefebvre et Antoine Sirois, Projet final du cours ELE4300: décodeur de ligne.

École Polytechnique de Montréal, avril 1998.

7. Performance Motion Devices, Advanced Multi-Axis Motion Control Chipset. Performance

Motion Devices, novembre 1997

8. Romano M. DeSantis, Modeling and path-tracking control of a mobile wheeled robot with a

differential drive. École Polytechnique de Montréal, automne 1995.

9. Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides, Design Patterns: Elements

of Reusable Object-Oriented Software. Addison-Wesley, 1994.

10.Richard C. Dorf, Robert H. Bishop. Modern Control Systems, 8th Edition. Addison-Wesley

Longman Inc., 1998.



Annexe 1: Contribution des membres

• Philippe Abdel-Malek (collaboration externe, génie mécanique, ÉTS): conception et fabricationmécanique: structure mécanique, suspension, roues-folles, choix des matériaux, dessin technique,usinage.

• Julien Beaudry (génie électrique, ÉPM): gestion du projet, conception mécanique: choix de laconfiguration, choix des moteurs, suspension, conception du ramasse-boules, conception etdéveloppement du système électrique et électronique: choix des batteries, conception du circuitd’alimentation, réingénierie du module de suivi de ligne, choix des capteurs, conception etdéveloppement du système informatique: contrôleur de suivi de ligne, conception et développement ducerveau de compétition et de cerveaux de tests.

• Jonathan Boisvert (génie informatique, ÉPM): conception et développement du contrôleur partéléguidage.

• Rémi Lefebvre (génie informatique, ÉPM): conception et développement du système informatique:choix de l’architecture, boucles temps réel, modélisation objet.

• Jean-Pierre Magalhaës-Grave (génie électrique, ÉPM): conception et fabrication mécanique:conception et fabrication du module de ramasse-boules, conception et fabrication de la coque,conception et développement du système électrique et électronique: conception du circuitd’alimentation, prototype du module de suivi de ligne, circuit imprimé du module de suivi de ligne.

• Francis Mailhot (génie informatique, ÉPM): conception et fabrication mécanique: prototype du robot,conception et fabrication du module de ramasse-boules, fabrication du plan incliné, conception etdéveloppement du système informatique: gestion des entrées/sorties, abstraction de la classe Brain,boucles temps réel.

• Pierre-Olivier Roy (génie mécanique, ÉPM): dessin technique: plans mécaniques du robot.



Annexe 2: Résultats des essais d’asservisssement en vitesse

Figure : Asservissement en vitesse tangentielle (0,25m/s)


0 0 . 5 1 1 .5 2 2 . 50

0 .0 5

0 . 1

0 .1 5

0 . 2

0 .2 5

te m p s (s )

vite

sse

tang

entie

lle(m

/s)

v. d e s ire es im u la t io nro b o t

0 0 .5 1 1 .5 2 2 . 5 3 3 . 5 4-0 . 1

0

0 . 1

0 . 2

0 . 3

0 . 4

0 . 5

0 . 6

t e m p s (s )

vite

sse

tang

entie

lle(m

/s)






0 0 .5 1 1 . 5 2 2 . 5 3 3 .5 4 4 . 5-0 . 2

0

0 . 2

0 . 4

0 . 6

0 . 8

1

1 . 2

te m p s (s )

vite

sse

tang

entie

lle(m

/s)


0 0 . 5 1 1 .5 2 2 .5 3 3 . 5 4 4 . 5 5-0 . 2

0

0 . 2

0 . 4

0 . 6

0 . 8

1

1 . 2

1 . 4

1 . 6

t e m p s (s )

vite

sse

tang

entie

lle(m

/s)




Figure : Asservissement en vitesse tangentielle (2m/s)


0 0 .5 1 1 . 5 2 2 . 5 3 3 .5 4 4 . 5-0 . 5

0

0 . 5

1

1 . 5

2

te m p s (s )

vite

sse

tang

entie

lle(m

/s)


0 0 .5 1 1 . 5 2 2 . 5 3 3 .5 4 4 . 5-0 . 5

0

0 . 5

1

1 . 5

2

2 . 5

te m p s (s )

vite

sse

tang

entie

lle(m

/s)




Figure : Asservissement en vitesse angulaire (2rad/s)


0 0 .5 1 1 . 5 2 2 .5 3 3 . 5 40

0 . 5

1

1 . 5

2

2 . 5

te m p s (s )

vite

sse

angu

laire

(rad

/s)


0 0 .5 1 1 . 5 2 2 .5 3 3 . 5 40

0 . 5

1

1 . 5

2

2 . 5

3

3 . 5

4

4 . 5

te m p s (s )

vite

sse

angu

laire

(rad

/s)






0 0 .5 1 1 . 5 2 2 .5 3 3 . 5 40

1

2

3

4

5

6

7

8

9

te m p s (s )

vite

sse

angu

laire

(rad

/s)


0 0 .5 1 1 . 5 2 2 .5 3 3 . 5 40

2

4

6

8

1 0

1 2

1 4

te m p s (s )

vite

sse

angu

laire

(rad

/s)




Annexe 3: Spécifications du robot SpinoS

Caractéristiques mécaniques :

• diamètre de la base : 380 mm

• distance entre les roues motrices : 400 mm

• poids : approx. 13,7 kg (8,7 kg sans batteries)

• 3 moteurs 24 VDC (1 pour le ramasse-boules), encodeurs à résolution de 11800 tics/tour

Performances :

• vitesse maximale en ligne droite : 4,58 m/s

• vitesse tangentielle maximale en courbes (rayon de courbure : 1 m ) : 3.26 m/s

• vitesse angulaire maximale : 22,90 rad/s

• accélération maximale en ligne droite : 3.57 m/s2

Asservissement et contrôle :

• robot entièrement autonome

• module de suivi de ligne

• 3 moteurs DC asservis par boucles PID numériques

• positionnement à l’aide d’encodeurs optiques

Ordinateur embarqué :

• Processeur Celeron 566MHz

• 128Mb de RAM

• Bus : PC/104+ (PCI), PC/104(ISA)

• Système d’exploitation Debian Linux avec RT-Linux

Autonomie électrique :

• Entre 80 minutes et 3 heures, dépendant des vitesses et des accélérations



Annexe 4: Coût de fabrication du robot SpinoS

Voici une approximation du coût de fabrication du robot SpinoS

Coût total de fabrication : 6710 $

Composantes mécaniques Prix ($)

Aluminium 300

Moteurs 700

Matériau composite 75

Roues motrices 75

Roulements a bille 40

Suspension 70

Joints universels 75

O-rings 5

Vis 10

TOTAL 1350$

Composantes électriques et électroniques Prix ($)

Ordinateur embarqué 2200

Disque dur miniature 750

Carte d’entrées/sorties numériques 150

Carte d’acquisition vidéo 400

Carte de contrôle des moteurs 500

Hacheurs de courant 220

Module de suivi de ligne 150

Caméra vidéo 300

Détecteurs catadioptriques 90

Convertisseurs DC-DC 400

Batteries (2 ensembles) 140

Interrupteurs, connecteurs et filage 60

TOTAL 5360$



Annexe 5: Code source

Le code source de ce projet se retrouve dans le répertoire sae du CD fourni avec ce rapport.



Annexe 6: Schémas électroniques

Les schémas électroniques du module de suivi de ligne se retrouvent dans le répertoire strip du CD fourni avec

ce rapport.



Annexe 7: Plans mécaniques

Les plans mécaniques de ce projet se retrouve dans le répertoire CAD du CD fourni avec ce rapport.



Annexe 8: Fiches techniques

Les fiches techniques de ce projet se retrouvent dans le répertoire fiches_techniques du CD fourni avec ce

rapport.


DÉPARTEMENT DE GÉNIE ÉLECTRIQUE - Robofoot...

Documents

Transcript of DÉPARTEMENT DE GÉNIE ÉLECTRIQUE - Robofoot...