Freescale Cup (Autonomous RC-scale Car competition) - Mini project rapport

FREESCALE RACING CUP

P r o j e t P F A F r e e s c a l e C u p 2 0 1 5

Remerciements

En préambule à ce mémoire, Nous adressons nos remerciements les plus sincères aux personnes

qui nous ont apporté leur aide et qui ont contribué à l’élaboration de ce projet ainsi qu’à la

réussite de cette formidable année universitaire.

C’est avec un grand plaisir que, nous adressons nos sincères remerciements à l’égard de

notre encadreur Monsieur Nouri Masmoudi qui n’a épargné aucun effort pour la bonne

réussite de ce

travail. Merci pour vos aides précieuses, vos conseils bienveillants, pour votre soutien et

encouragement.

Nous tenons également à présenter notre profonde gratitude à Monsieur Aymen Marzouki , qui

nous a rendu ce travail une expérience motivante et enrichissante, pour ses compétences, son

encadrement, et pour ses conseils précieux, nous nous permettons de lui témoigne ici l’expression de

notre haute considération et notre profonde gratitude.

Nos vifs remerciements vont également au Monsieur Mohamed Chaäben pour son soutien

considérable et ses conseils.

Nous adressons nos remerciements les plus sincères aux personnes et l’administration qui nous ont

apporté leur aide et qui ont contribué à l’élaboration de ce projet

Pour la même occasion, nous adressons nos remerciements à tous nos enseignants pour

leurs efforts déploré qui ont enrichi nos études universitaires.

Enfin, nous espérons que ce travail sera à la hauteur de la confiance qu’ils nous ont accordée



Table des matières

1 Introductions ....................................................................................................................................... 6

1.1 Freescale Cup ................................................................................................................................ 6

1.2 Voiture............................................................................................................................................7

2 Etude Electronique ............................................................................................................................... 9

Synoptique du système ......................................................................................................... 9 2.1.1

KL25Z128 : ............................................................................................................................. 10 2.1.2

Accéléromètre (MMA8451Q) ............................................................................................... 12 2.1.3

Carte FRDM-TFC [2] ............................................................................................................ 13 2.1.4

Moteurs à courant continu .................................................................................................. 14 2.1.5

Servomoteurs ....................................................................................................................... 14 2.1.6

Line scan camera [3] ............................................................................................................ 16 2.1.7

Caméra et positionnement .................................................................................................. 17 2.1.8

Bilan de puissance ................................................................................................................ 18 2.1.9

2.2 Solution optique et électronique................................................................................................ 22

3 Partie mécanique ................................................................................................................................ 26

3.1 Conclusion : ................................................................................................................................. 27

4 Côté Programmation .......................................................................................................................... 29

4.1 Introduction à la partie programmation ................................................................................... 29

Mode de programmation .................................................................................................... 29 4.1.1

Etape de compilation .......................................................................................................... 29 4.1.2

Debug .................................................................................................................................. 29 4.1.3

4.2 Structures et interfaces des périphériques .................................................................................30

ServoMoteur. ........................................................................................................................30 4.2.1

Motors ..................................................................................................................................30 4.2.2

Accéléromètre : .................................................................................................................... 31 4.2.3

Etat de la voiture : ................................................................................................................ 31 4.2.4

5 Programme MAIN ............................................................................................................................... 33

6 Unité de binarisation des images ....................................................................................................... 35

6.1 Algorithme Générale de Binarisation et filtrage .........................................................................36

Blur [4] .................................................................................................................................. 37 6.1.1

rgbize : .................................................................................................................................. 37 6.1.2

filter : .................................................................................................................................... 37 6.1.3

6.2 Méthodes de binarisation: ...........................................................................................................38

Méthode de Midgrey-modifié [5]E ......................................................................................38 6.2.1



Méthode de MaxMinusConst [5] .........................................................................................38 6.2.2

Méthode Mean (ou midAvg) [5] ..........................................................................................38 6.2.3

Méthode de Shafait-modifié: [6] .........................................................................................38 6.2.4

Méthode de Pic dérivée ...................................................................................................... 40 6.2.5

Méthode de weighted-Derviate-link .................................................................................. 42 6.2.6

6.3 Comparaison des méthodes ........................................................................................................ 43

6.4 Conclusion : .................................................................................................................................45

7 Intelligence de vision ..........................................................................................................................47

7.1 Signal (donnée) d’initialisation : .................................................................................................47

7.2 Correction du signal ....................................................................................................................47

7.3 Détection de la ligne de fin ........................................................................................................ 48

7.4 Perception ................................................................................................................................... 49

TrackDir (Direction de la piste) ......................................................................................... 49 7.4.1

PositionToTrack (position à la piste) ................................................................................. 49 7.4.2

Motion (mouvement) ......................................................................................................... 49 7.4.3

isOversteering [7] ................................................................................................................ 49 7.4.4

SteerRange ............................................................................................................................50 7.4.5

7.5 Implémentation: ..........................................................................................................................50

8 Intelligence Artificielle (AI) ................................................................................................................ 52

8.1 Introduction ................................................................................................................................. 52

8.2 Conception du contrôleur flou .................................................................................................... 52

Le principe de base de la commande floue ......................................................................... 52 8.2.1

Les exigences de base du contrôleur flou ............................................................................ 52 8.2.2

La conception du contrôleur flou ........................................................................................ 53 8.2.3

Fuzzification ......................................................................................................................... 53 8.2.4

8.3 Base de Règles ............................................................................................................................. 56

8.4 Mécanisme de l'inférence ............................................................................................................ 57

8.5 Défuzzification ............................................................................................................................ 59

9 Unité de contrôle et système à états .................................................................................................. 61

9.1 Unité de contrôle ......................................................................................................................... 61

9.2 Système à états ............................................................................................................................. 61

10 Programmes de support ..................................................................................................................63

10.1 Outil : Simulation des algorithmes de filtrage ...........................................................................63

10.2 Visualisation d’accéléromètre en temps réel ............................................................................. 64

11 Bibliographie ................................................................................................................................... 66



Page laissée intentionnellement vide



Chapitre 1



1 Introductions

1.1 Freescale Cup

Freescale Racing Cup est un évènement

international annuel organisé pour choisir l’équipe

qui construit, programme et fait une course avec un système contre-la-montre le plus rapide.

Chaque équipe est équipé d’un KIT dit de « Freescale Cup Kit » contenant des pièces, pièces de

rechanges, carte FRDM-KL25Z centré autour d’un microcontrôleur ARM, caméra linescan,

servomoteur, 2 moteurs et une carte Shield (d’adaptation), et doit obéir au cahier de charge proposé

par les organizateurs.

Le but est simple: un trajet, une voiture autonome à programmer, 3 essais.

Un seul essai sera pris: Le premier tour lorsque le véhicule traverse toute la piste

sans déraper.

Déraper: Avoir une 3ème roue au dehors de la piste.

La piste exigée est « Edge-lane »

60 cm de surface blanche matte, ayant aux bords 2 traits en noirs

d’épaisseur 2.54cm.



Vu le nombre des participants, Freescale Racing Cup est organisé par région. Par exemple, la Tunisie

appartient à la région « North Africa », « EMEA ». Cela veut dire que le lieu des quart-final sera dans

un endroit auprès d’Algérie, Maroc et Tunisie, tandis que la demi-finale en Europe.

TFC 2015 EMEA a été organisé au Maroc. Plus précisément à Mundiapolis University, Casablanca ; le 5

mars 2015

*

1.2 Voiture

Plus de détails seront expliqués tout le long de ce rapport



Chapitre 2



La bonne configuration des matériels, l’étude électronique et optique (distance focale) sont des étapes

primordiales dans le cycle de notre projet. Elles permettent d’apporter des solutions aux difficultés

soulevées par le cahier de charge du système.

Dans ce chapitre nous allons étudier la partie électronique telle que le bilan de puissance et

consommation, les différentes cartes et capteurs.., la partie optique et enfin la partie mécanique.

2 Etude Electronique

Synoptique du système 2.1.1

Figure 1:synoptique

La figure montre les différentes composants et cartes électroniques dans notre système et la

nature de liaison entre eux.

Carte FRDM-TFC

Bloc interfaçage avec les capteurs

Caméra (Line scan caméra)

Unité de commande KL25Z128

Alimentation

Accéléromètre

ARM® Cortex™-M0

Bloc de puissance (H-Bridge) Servo moteur Deux moteurs à

courant continu

I2C 2

4 SPI

PWM

PWM SPI 4

2 commandes

digitales

2 commandes digitales

https://www.google.tn/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CBsQFjAA&url=http%3A%2F%2Ffr.wikipedia.org%2Fwiki%2FAcc%25C3%25A9l%25C3%25A9rom%25C3%25A8tre&ei=GqUyVedzjJ89n_WAmAU&usg=AFQjCNGxYfzHATL-cPUIVOowwBikfL3afA&sig2=cz6FMDuqIwN155CzO1YSjw&bvm=bv.91071109,d.bGg



I2C1 est un bus série synchrone bidirectionnel half-duplex. La connexion est réalisée par

l'intermédiaire de 2 lignes :

SDA (Serial Data Line) : ligne de données bidirectionnelle,

SCL (Serial Clock Line) : ligne d'horloge de synchronisation bidirectionnelle.

SPI2 (pour Serial Peripheral Interface) est un bus de données série synchrone baptisé ainsi

par Motorola, qui opère en mode Full-duplex. Le bus SPI utilise 4 signaux logiques :

SCLK : Serial Clock, Horloge (généré par le maître)

MOSI : Master Output, Slave Input (généré par le maître)

MISO : Master Input, Slave Output (généré par l'esclave)

SS : Slave Select, Actif à l'état bas (généré par le maître)

KL25Z128 : 2.1.2

Le FRDM-KL25Z est une conception simple et complète comportant une série L microcontrôleur

Kinetis, premier microcontrôleur de l'industrie repose sur le processeur ARM ® Cortex ™-M0 + noyau.

KL25Z128VLK est un dispositif de famille KL2 bénéficiant d'une fréquence de fonctionnement

maximale de 48 MHz, 128 Ko de flash, un contrôleur USB pleine vitesse, et des charges de périphériques

analogiques et numériques.

Les interfaces de bord comprennent une LED RVB, un accéléromètre numérique trois axes, et un curseur

tactile

On peut alimenter la carte par différentes méthodes:

– OpenSDA USB (J7) :5V

– KL25Z USB (J5) :5V

– VIN Pin :4.3-9V

– 3.3V Pin : 1.71-3.6V

– Coin Cell Battery : 1.71-3.6V

1 1 Wikipedia

http://fr.wikipedia.org/wiki/Motorola

http://fr.wikipedia.org/wiki/Full-duplex



Les caractéristiques de microcontrôleur KZ25 : [1]

• processeur ARM ® Cortex ™-M0 32 bits

• Fréquence jusqu’à 48MHZ3

• Mémoires :

– 128 KB flash

– 16 KB SRAM

• Horloges (Clocks ):

– Module de génération d’horloge avec

l’Oscillateur PLL et FLL

– Horloge interne de 4MHz et 32KHz

– Oscillateur « external crystal or resonator »

– Oscillateur RC 1Khz

– Périphériques analogiques:

– Convertisseur ADC 16 bits avec un accès direct à la mémoire DMA

– Convertisseur DAC 12 bits avec un accès direct à la mémoire DMA

– Comparateur de haute vitesse

• Communication :

– 2 SPI à 8bits

– 2 I2C

– 1 UART (low power) et 2 modules standards UART

• Timers:

– Real time clock (RTC)

– Low-power Timer (LPT)

– 1 module à 6 voie PWM

– 2 modules à 2 voies PWM

3 Pour l’exécution des instructions de type CPU

Figure 2 KL25Z128



Figure 3:les pins I/O de KL25Z128

Accéléromètre (MMA8451Q) 2.1.3

L’Accéléromètre à 3 axes permet de mesurer les 3 accélérations linéaires de la selon les 3 axes

orthogonaux, il est connecté à travers I2C et 2 GPIO selon le tableau ci-dessous

Tableau 1 :connexion de l’accélérométre avec cortex



Carte FRDM-TFC [2] 2.1.4

C’est une carte intermédiaire entre le KL25Z128, les capteurs et les moteurs.

Elle peut contrôler :

Motor Driver ICs (MC33887APVW) 2 canaux

Sorties servo 2 canaux

Interfaces dual Linescan Camera

2 entrées pour accéléromètres

2 potentiomètres pour fonctions utilisateur

2 boutons poussoirs pour fonctions utilisateur

4 Positions DIP Switch pour fonctions utilisateur

4 LEDs (jaunes) pour indicateur de batteries ou

fonctions utilisateur

Cette carte contient un Pont en H pour contrôler les moteurs DC. Le pont en H est une

structure électronique servant à contrôler la polarité aux bornes d'un dipôle. Il est composé de quatre

éléments de commutation généralement disposés schématiquement en une forme de H d'où le nom.

Figure 5:Pont en H

On utilise le pont en activant les commutateurs de différentes combinaisons pour obtenir le

branchement voulu. Le tableau suivant résume les combinaisons permises. Toutes les combinaisons

Figure 4 shiled FRDM-TFC

http://fr.wikipedia.org/wiki/Dip%C3%B4le_%C3%A9lectrique



qui ne figurent pas dans le tableau sont interdites et créent un court-circuit de la source. Le courant

de référence pour la charge est considéré comme étant de gauche à droite.

Tableau 2:combinaisons d'états des commutateurs de pont H

Le pont en H permet de réaliser 2 fonctions qui sont d'inverser le sens de rotation du moteur,

en inversant la tension aux bornes du moteur et la variation de la vitesse du moteur en modulant la

tension aux bornes du moteur.

De plus, le pont en H permet d'effectuer un freinage magnétique s’il est capable d'en dissiper la

puissance générée. Cette opération s'effectue en actionnant soit les deux commutateurs supérieurs ou

inférieurs en même temps, ce qui court-circuite les bornes du moteur, et le fait par conséquent

freiner.

Moteurs à courant continu 2.1.5

Les moteurs à courant continu qu’on a utilisé ont les caractéristiques suivantes :

Tableau 3:Caractéristiques du moteur à courant continu

Servomoteurs 2.1.6

Les servomoteurs électriques sont prévus pour être commandés facilement en position. En

effet, ils sont équipés d’un système d’asservissement basé sur un potentiomètre rotatif qui sert de

capteur de rotation.



Ils sont faciles à utiliser car ils ne nécessitent que :

une source de tension continue

une sortie PWM (Pulse Width Modulation) du microcontrôleur de votre robot

Les servomoteurs classiques possèdent 3 fils de connexion de couleurs différentes :

- Le noir ou marron – La masse

- Le rouge – La tension d’alimentation continue (+)

- Le jaune, orange ou blanc – Le signal de commande

Il comprend :

Un moteur électrique de petite taille.

Un réducteur en sortie de ce moteur pour avoir moins de vitesse et plus de couple. • Un capteur : un

potentiomètre qui produit une tension variable en fonction de l'angle de l'axe de sortie.

Un asservissement électronique pour contrôler la position de cet axe de sortie. L'utilisateur envoie à

chaque instant un signal modulé représentatif d’un angle.

Le servo tourne vers cet angle et s'y maintient.

Le signal de commande n’est rien d’autre qu’un signal logique périodique. C’est pour ça qu’il

est facile à générer à partir d’un microcontrôleur. La largeur des créneaux va commander l’angle de

l’arbre du servomoteur. La durée du créneau doit être comprise entre 1 et 2ms pour la majorité des

servomoteurs y compris le nôtre. Une durée de 1ms correspond à l’angle 0° et 2ms correspond à l’angle

180°.

Figure 6:principe de commande de servo moteur par le signal PWM

La période entre deux créneaux doit être de 20ms maximum.

Nous utilisons les servomoteurs Futaba S 3010 qui ont les caractéristiques:4

4 Caractéristique du datasheet du servomoteur



Vitesse: 0.20 sec/60° @ 4.8V

0.16 sec/60° @ 6.0V

Couple: 72 oz-in (5.2 kg-cm) @ 4.8V and

90 oz-in (6.5 kg-cm) @ 6V

Dimensions: 1.6 x 0.8 x 1.5" (1-9/16 x 13/16 x 1-1/2") : (40 x 20 x 38mm)

Poids: 1.5oz (1-7/16oz) (41g)

Line scan camera [3] 2.1.7

Le capteur TSL1401CL est une caméra CMOS 1x128. Elle est constituée de 128 photodiodes qui sont

disposés l’un de coté de l’autre formant une ligne (tableau).

Chaque diode disposée à la lumière génère un courant électrique à l’aide des circuits associés à ce

pixel.

Pendant le temps d’intégration, un condensateur d'échantillonnage sera connecté à la sortie de

l'intégrateur par un interrupteur analogique. La quantité de charge accumulée au niveau de chaque

pixel est directement proportionnelle à l'intensité lumineuse et au temps d'intégration.

Le temps d’intégration sera calculé par la formule suivante

𝑇 = 1

𝑓𝑚𝑎𝑥 (𝑛 − 18)𝑝𝑖𝑥𝑒𝑙𝑠 + 20µ𝑠

Temps d'intégration minimum: 33.75µs

Temps d'intégration maximale: les condensateurs seront saturés s’ils dépassent 100ms

Fréquence : 5 kHz - 8 Mhz



Caractéristiques de la caméra :

128 pixels (capteur TSL1401CL)

5 pins

Temps d’exposition : 267µS to 68mS

Equipée par un amplificateur pour distinguer les niveaux de blanc et

noir

Il faut couvrir les circuits électroniques de la caméra pour éliminer les bruits et diminuer les erreurs de mesures.

Caméra et positionnement 2.1.8

L'appareil sera monté au-dessus de la voiture pour regarder en avant la distance. En changeant

l'angle de la caméra, la distance "look-ahead" peut être modifié afin d'assurer un pilotage plus efficace.

La distance focale doit être bien choisie pour éliminer la composante floue de l’image

Figure 9: influence de variation de la distance focale du camera

Figure 7 Line scan caméra

Figure 8. circuit électronique de la caméra



Bilan de puissance 2.1.9

Il est évident qu’une étude de puissance est nécessaire pour qu’on puisse ajouter des circuits à notre

système.

La première étape consiste à déterminer pratiquement les caractéristiques des composants électroniques

comme le montre les deux tableaux ci-dessous.

Pièce Etat Consommation minimal Consommation typique Consommation maximale

Carte & caméra - - 40mA -

Servomoteur Arrêt - 45mA -

Normal 200mA - 350mA

Bloqué 400mA - -

Les 2 moteur DC Arrêt - 340mA -

Normal 400mA - -

Normal avec frottement 700mA - -

Survitesse avec frott. - - >5A

LED - - 80mA *15 -

Pièce Consommation minimal Consommation typique Consommation maximale

Carte & caméra - 40mA -

Servomoteur 45mA 350mA >400mA

Les 2 moteur DC 400mA* 700mA >5A

LED - 80mA*15 -

Tableau 4:consommation des composants électroniques



2.1.9.1 . Batterie

Une batterie NiMH (de l'anglais nickel metal hybride) est un accumulateur rechargeable

électrique fonctionnant avec de l'hydrure métallique et du nickel.

Les avantages sont :

30 à 40 pour cent de capacité en plus par rapport à des piles et batteries standards NiCd,

faible sensibilité à l'effet mémoire,

les conditions de transport sont simples et non soumises à une réglementation particulière,

respectueux de l'environnement, contient seulement des toxines douces ; recyclage facilité,

absence de cadmium et de plombs,

Les inconvénients sont :

Durées d'utilisation limitées, si plusieurs cycles à fortes décharges, particulièrement avec un

courant élevé (se détériore après 200 à 300 cycles).

Processus de mise en charge de la batterie plus complexe.

Les performances des piles NiMH se dégradent si elles sont stockées à haute température

Environ 20% plus cher que les batteries NiCd.

Les batteries NiMH supportant les courants élevés (pour l'automobile) sont plus chères que la

version normale.

Notre batterie a les caractéristiques suivantes :

Tableau 5:caractéristiques de la batterie



Pour le calcul de décharge et le calcul du temps restant, on a utilisé les formules suivantes selon l’état la batterie et

l’environnement:

Dès la recharge, après un jour, la batterie perd de 5% à 20% de sa capacité.

A chaque jour après ce premier jour, la batterie peut perdre de 10% à 40% de sa capacité.

Pour faire l’étude d’une manière convenable, on a développé à l’aide du logiciel Excel, un petit

programme de calcul permettant d’estimer la consommation et le temps restant selon les données

suivantes.

Consommation en mA

Carte 40

Servomoteur 700

2*moteur DC 1400

LED 1200

Shield 0

Tableau 6:consommations des composants électronique en courant

On obtient le résultat suivant :

Tableau 7:durée de consommation de la batterie



Etat de la batterie après un jour du jour de recharge

Capacité Temps restant C_rate

Décharge après 1 jr 1710 mAh 0h:30m 1.953216374

Pire des cas 1440 mAh 0h:25m 2.319444444

Etat de la batterie après 2 jours du jour de recharge


Décharge après 2 jr 1539 mAh 0h:27m 2.170240416

Pire des cas 1026 mAh 0h:18m 3.255360624

Pire des pires des cas 864 mAh 0h:15m 3.865740741

Etat de la batterie après 3 jours du jour de recharge


Décharge après 3 jr 1385.1 mAh 0h:24m 2.41137824

Pire des cas 615.6 mAh 0h:11m 5.42560104

Pire des pires des cas 518.4 mAh 0h:9m 6.442901235

Tableau 8: états de la batterie



2.2 Solution optique et électronique

Dans le cadre d’étude optique, nous avons cherché une solution matérielle pour réduire l’effet

de bruit.

Tout d’abord on a relève le signal de la caméra dans des conditions différentes, on a remarqué

que la lumière du milieu est insuffisante, en fait l’intensité de la lumière est variable sur le trajet

comme le montre la figure ci-dessous.

Figure 10: cas indésirable

Donc notre solution consiste à ajouter une autre solution de lumière qui couvre la largeur de piste.

Figure 11: Cas souhaitée

Après plusieurs expériences nous avons choisi d’utiliser une source de lumière constituée par

des LEDs rouge de puissance. Ce choix est justifié par l’efficacité de ce composant et sa vivoté.

Pour choisir une intensité de lumière convenable, nous avons recours une autre fois aux outils

pratique. Nous avons mesuré la tension et le courant du LEDs qui vaut respectivement 2V et 80 mA.

La détermination des nombres des LEDs, longueur de panneau, distance entre deux LEDs consécutif et

les résistances utilisé sont déterminer à partir du programme LED Calc qu’on a réalisé à l’aide de logicielle Visual

basic.



On a deux choix pour alimenter le panneau LEDs soit par l’intermédiaire du régulateur de tension 5V,

soit liée directement à la batterie. Les LEDs sont liées en parallèles.

Figure 12: alimentation en utilisant régulateur de tension

Figure 13: alimentation par batterie (directement)



Le choix de nature de la source (sans ou avec régulateur) est justifiée par le bilan de puissance que on a fait.

Puisque l’utilisation des diodes liée en parallèles impose l’utilisation de plusieurs résistances d’où l’augmentation

de pertes joule, les LEDs seront couplés en séries.

Nous avons réalisé carte d’alimentation contenant un bouton et des résistances et quatre cartes contenant

chacune trois LEDs, ces dernières cartes seront reliée en cascade.

Figure 14: schématique de la carte d’alimentation

Figure 15: typons des cartes électroniques



Chapitre 3



3 Partie mécanique

La première étape est d’assembler le châssis mécanique du kit Freescale.

La deuxième étape est de déterminer la hauteur de la tige de caméra, sa position et faire la conception

de leur support. Donc on a recours à l’essai pratique, En variant la hauteur de caméra, on visualise son

signal à l’aide d’un programme similaire à LabVIEW programmé par nous-mêmes et on vérifie s’il y a

une détection des deux extrémités noires du trajet.

Figure 16:détermination de la hauteur de la caméra

La hauteur du support caméra ne doit pas dépasser le 30 cm selon le cahier de charge.

D’après les essais expérimentaux, la hauteur de tige est égale à 28cm.

Nous avons réalisé le support ci-dessous, en utilisant ce support on peut varier

la hauteur de caméra et son angle de vision.

Figure 17 support caméra



La troisième étape était la conception et la réalisation support réfléchissant de cartes LEDs.

Figure 18:support cartes LEDs

3.1 Conclusion :

Dans ce chapitre nous avons illustré les rôles des systèmes électroniques et mécanique, leurs architectures et leurs

principes de fonctionnement. Dès que cette étape est achevée avec succès, il reste encore une étape très

importante, c’est l’étape de traitement de signal et programmation sujet de chapitre suivant.



Chapitre 4



4 Côté Programmation

4.1 Introduction à la partie programmation On avait le choix de choisir entre C et C++. De ce fait, on a choisi le langage le plus familier C.

Le cahier de charge a imposé CodeWarrior d’être l’IDE de développement. Cet IDE contient déjà

les bibliothèques de FRDM-KL25Z depuis quelques versions, y inclus 10.6 celle que nous avons

utilisé.

Figure 19 CodeWarrior

Mode de programmation 4.1.1

Pour tout acte de flashage, de supervision, on n’a utilisé que le mode openSDA.

Etape de compilation 4.1.2

La compilation du projet se fait à partir de Run --> Run As --> Codewarrior.

Ceci permet une double opération : compilation et link du projet, aussi bien que flasher la carte

(au cas où la première opération s’est terminée avec succès).

Debug 4.1.3

CodeWarrior offre aussi la possibilité de débugger son code avec Run --> Debug As --> Codewarrior.

Encore ayant une double opération : compilation en mode debug, aussi bien que flashage de la

carte (encore en cas où la 1ère opération est achevée)



Figure 20. CodeWarrior en mode debug

Le mode debug dans Codewarrior permet de visualiser la mémoire, la modifier en temps réel,

aussi que les différents registres et variables aussi que le ASM (disassembly) du code tapé.

4.2 Structures et interfaces des périphériques

ServoMoteur. 4.2.1

Le servomoteur est caractérisé par 2 grandeurs : offset et command :

- 𝑠𝑒𝑟𝑣𝑜. 𝑜𝑓𝑓𝑠𝑒𝑡 + (𝑠𝑒𝑟𝑣𝑜. 𝑐𝑜𝑚𝑚𝑎𝑛𝑑 = 0) : La voiture doit marcher en rectiligne

- 𝑠𝑒𝑟𝑣𝑜. 𝑜𝑓𝑓𝑠𝑒𝑡 + 𝑠𝑒𝑟𝑣𝑜. 𝑐𝑜𝑚𝑚𝑎𝑛𝑑 est la grandeur enfin reçu par le servomoteur

- 𝑠𝑒𝑟𝑣𝑜. 𝑐𝑜𝑚𝑚𝑎𝑛𝑑 doit être entre [-1,1]

typedef struct {

float offset; //l'offset+command=0 <=> marche rectiligne

float command; //commande du servo

} SERVO ;

Motors 4.2.2

Les moteurs sont programmés comme-ci :

- motors.rightSpeed : vitesse du moteur à droit, doit être entre [-1,1]

- motors.leftSpeed : vitesse du moteur à gauche, doit être entre [-1,1]

- motors.maxSpeed : vitesse maximal (relié avec un relai à saturation)

- motors.speedMultiplier : sera utilisé pour multiplier les vitesses préprogrammées

Les moteurs reçoivent à la fin :

𝑟𝑖𝑔ℎ𝑡𝑀𝑜𝑡𝑜𝑟 ← min (𝑚𝑜𝑡𝑜𝑟𝑠. 𝑟𝑖𝑔ℎ𝑡𝑆𝑝𝑒𝑒𝑑 ∗ 𝑚𝑜𝑡𝑜𝑟𝑠. 𝑠𝑝𝑒𝑒𝑑𝑀𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑒𝑟, 𝑚𝑜𝑡𝑜𝑟𝑠. 𝑚𝑎𝑥𝑆𝑝𝑒𝑒𝑑)

𝑙𝑒𝑓𝑡𝑀𝑜𝑡𝑜𝑟 ← min (𝑚𝑜𝑡𝑜𝑟𝑠. 𝑙𝑒𝑓𝑡𝑆𝑝𝑒𝑒𝑑 ∗ 𝑚𝑜𝑡𝑜𝑟𝑠. 𝑠𝑝𝑒𝑒𝑑𝑀𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑒𝑟, 𝑚𝑜𝑡𝑜𝑟𝑠. 𝑚𝑎𝑥𝑆𝑝𝑒𝑒𝑑)



typedef struct {

float rightSpeed;

float leftSpeed;

float maxSpeed;

float speedMultiplier;

} MOTORS;

Accéléromètre : 4.2.3

L’accéléromètre (module sans gyroscope) ne permet que

savoir l’accélération au tour de l’axe Y (Yaw), mais

permet de savoir le « Pitch » et le « roll »

Par ça, l’accéléromètre ne sera utilisé que pour calculer

le Pitch (ponte et descente)

On tire depuis l’accéléromètre 3 valeurs (après filtrage) : Xout_g, Yout_g, Zout_g (Roll, Pitch et

Yaw)

(*) L’image est tirée à partir de http://www.formula1-dictionary.net/

Etat de la voiture : 4.2.4

On a choisi un système d’état minimal de la voiture mais pertinent qui indique l’état de la voiture

- car.motion : mouvement actuel de la voiture

- car.steerRange : Steer Range (pour sauver son équilibre)

- car.positionToTrack : position de la voiture par rapport au circuit

- car.trackDir : vecteur devant (forward)

- car.isOversteering : La voiture est en “oversteering” ou “understeering”

typedef struct {

float motion;

float steerRange;

float positionToTrack;

float trackDir;

bool isOverSteering;

} CARINFO;

http://www.formula1-dictionary.net/



Chapitre 5



5 Programme MAIN



Chapitre 6



6 Unité de binarisation des images

Le but ultime de cette unité est de laisser le microcontrôleur distinguer entre le noir et le blanc.

Cependant, la limite de la technologie utilisée (Caméra linescan à base de photodiodes-

condensateurs) impose des problèmes énormes surtout les faux alertes (fausses détection des traits

noirs dans notre cas ou fausses détection de blanc).

Dans cette partie, on va se contenter d’expliquer la démarche de « binarisation » (seuillage noir-blanc)

ainsi que les différentes parties du filtrage.



6.1 Algorithme Générale de Binarisation et filtrage

Les données:

Data/pixel : vecteur de 128 entiers prenant valeurs entre 0 et 4096 (CAN).

avgLight : Valeur moyenne des pixels (avgLight = ∑ 𝑝𝑖𝑥𝑒𝑙[𝑖] 127

0

128)

Threshold : Valeur maximale pour démarrer la phase de “blur”

Les fonctions :

blur : Algorithme de flou gaussien (pour lisser le signal)

rgbize : Convertir en valeurs RGB (entre 0 et 255) pour minimiser davantage les bruits.

filter : utilise une méthode prédéfinie pour binariser l’image.



Blur [4] 6.1.1

Comme le signal est très bruité, on applique un filtre passe-bas (flou) pour le lisser le maximum.

On a choisi le noyau de Gauss pour extraire un nouveau noyau à application unidimensionnelle.

Le filtre de Gauss, étant discrétisé à application 2D à temps réduit, peut être exprimé sous la forme

d’une matrice de convolution suivante.

1

16[1 2 12 4 21 2 1

]

Ceci est équivalent à [1 2 1]*0.25 dans l’espace 1-D.

Le résultat final est donc la convolution suivante :

𝑝𝑖𝑥𝑒𝑙[] =𝑝𝑖𝑥𝑒𝑙[] ∗ [1 2 1]

4

Cependant, cette application (lorsqu’on travaille auprès de la valeur saturante) peut causer une perte

énorme dans le signal, c’est pourquoi on le désactive dans ce cas).

rgbize : 6.1.2

La fonction rgbize permet de convertir les valeurs de l’intervalle [0, 4095] à [0, 255]. Ceci permet de

faire une résolution plus large et donc de stabiliser l’image.

filter : 6.1.3

Cette fonction prend la méthode désirée et l’exécute afin de convertir les valeurs en nuances de gris en

des valeurs binaires (noir ou blanc).



6.2 Méthodes de binarisation: On notera pixel[] le vecteur à 128 éléments contenant des valeurs en nuances de gris

B[] sera le vecteur final à 128 éléments prenant valeur NOIR = 0 ou bien BLANC = 1 (image binarisée)

Méthode de Midgrey-modifié [5]E 6.2.1

Cette méthode est non adaptable, elle compare le pixel courant par rapport à midGrey (128)

La valeur finale sera alors

B[i] = pixel[i] < 128

O(n)

3*n

Méthode de MaxMinusConst [5] 6.2.2

Cette méthode n’est pas tout à fait « adaptable », mais plus allégée que Midgrey. On cherche

un nouveau max à chaque itération.


B[i] = pixel[i] < (max − constant)

O(n)

Best

4*n+1

Worst

5*n

Méthode Mean (ou midAvg) [5] 6.2.3

La méthode moyenne (Mean) permet de comparer les pixels par rapport à la moyenne globale

des pixels. (Rappelons que avgLight =∑ 𝑝𝑖𝑥𝑒𝑙[𝑗]𝑖127

𝑗=0

128 )


B[i] = pixel[i] < avgLight

O(n)

Best

3*n+2

Worst

3*n (*) avgLight est calculé au début, alors son temps ne sera pas compris

En pratique, avgLight = ∑ 𝑝𝑖𝑥𝑒𝑙[𝑗]

𝑓𝑖𝑛𝑖𝑠ℎ_𝑖𝑛𝑑𝑒𝑥𝑗=𝑠𝑡𝑎𝑟𝑡_𝑖𝑛𝑑𝑥

𝑓𝑖𝑛𝑖𝑠ℎ_𝑖𝑛𝑑𝑒𝑥−𝑠𝑡𝑎𝑟𝑡_𝑖𝑛𝑑𝑒𝑥 +1 tenant alors compte des pixels ignorés.

Méthode de Shafait-modifié: [6] 6.2.4

La méthode de Shafait (ou la méthode de binarisation par Image Intégrale) est une méthode de

binarisation adaptative qui permet de différencier à l’aide de la variance locale la valeur de noir

du blanc.

globale

globale

globale

adaptative



Sauf que la méthode de Shafait est une méthode pour utilisation à 2-dimensions, on a alors

adopté cette méthode pour utilisation unidimensionnelle.

La méthode est comme suit :

intI, m, σ : vecteurs de +128 entiers long.

w : Entier, taille de la fenêtre de vision (lookup Window)

L’image intégrale

𝑖𝑛𝑡𝐼[𝑖] = ∑ 𝑝𝑖𝑥𝑒𝑙[𝑗]

𝑖−1

𝑗=0

Moyenne locale (sur lookup window)

𝑚[𝑖] =𝑖𝑛𝑡𝐼 [𝑖 +

𝑤2

] − 𝑖𝑛𝑡𝐼 [𝑖 −𝑤2

]

𝑤

Calcul de la variance locale (sur lookup window):

𝜎[𝑖] = √1

𝑤∑ 𝑝𝑖𝑥𝑒𝑙[𝑗]2 − 𝑚[𝑖]²

𝑖+𝑤2

𝑗=𝑖−𝑤2

Le résultat sera donc :

B[i] = pixel[i] < 𝜎[𝑖]

Cependant, cette méthode toute-seule n’est pas parfaitement adéquate (par son critère

dynamique mais pouvant causer des fausses alertes c-à-d détection de faux noirs).

Pour cela on utilise un relai à seuil en cascades pour forcer le programme à ne pas détecter

de faux « noirs » au-delà d’une valeur threshold. ( B[i] = (pixel[i] < 𝜎[𝑖]) &&( 𝐵[𝑖] <

𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑𝑉𝑎𝑙𝑢𝑒)

(*) à noter que la méthode de Shafait originale prend O(n²)

O(n*w)

6 ∗ 𝑛 + (4𝑤 + 2) ∗ 𝑛



Méthode de Pic dérivée 6.2.5

C’est la méthode proposée par Marzouki Aymen et se repose sur la recherche de pique de dérivation,

puis déterminer la position de l’autre pic (par estimation).

Ce pique confond avec la position de la ligne en noir.

L’idée se repose sur le fait que la courbe ait son dérivé positif maximal à droite et à un dérivé

maximal négatif à gauche lors de la vision de la trajectoire. Si une faute de luminosité a peu eu

lieu, on déterminera l’autre position (en utilisant un paramètre predefDist = predefined

Distance).

On notera maxInd (resp. minIndx) l’indice de l’élément contenant la plus grande valeur (resp.

la plus faible)

globale



(*) 1st derivative : est un tableau de 128 éléments entiers signés.

O(n)

Best

6*n+6

Worst

10*n +4 (*) Le calcul de la dérivée est inclus



Calculate 1st derivative (array)

Calculate the weighted average

define bounds of "object" (from

background) through local thresholding

link bounds

Méthode de weighted-Derviate-link 6.2.6

Cette méthode tire son concept de la dérivation et la

programmation dynamique, synthétisé par les membres de notre

équipe.

C’est la méthode qui a donné le meilleur rendement.

6.2.6.1 Eligibilité d’approximation de modèle affine

Comme la performance est en péril pour des algorithmes avancés,

on cherche toujours à simplifier le modèle du signal.

En effet, pour une salle ayant diffusion de lumière uniforme (soleil

ou lumière artificielle : tubes néons), les données issues de la

caméra pouvant être représentées d’une manière parabolique

(ax²+bx+c) comme suit :

𝑐 = 𝑝𝑖𝑥𝑒𝑙[0]

𝑏 = (𝑚𝑎𝑥(𝑝𝑖𝑥𝑒𝑙[]) – 𝑐) ∗2

64

𝑎 = −𝑏

128

Exemple Pratique: ayant converti les pixels en système RGB auparavant, pour un max = 227, c=40

𝑎 = −

((𝑚𝑎𝑥(𝑝𝑖𝑥𝑒𝑙[])– 𝑐) ∗2

64 )

128= −0.045

Pour simplifier davantage ce modèle, on pourra estimer qu’il s’agit d’une fonction triangle avec un

offset de 𝑚𝑖𝑛(𝑝𝑖𝑥𝑒𝑙[]) ~ 𝑝𝑖𝑥𝑒𝑙[0], le pic étant juste au pixel #64 + 2px

6.2.6.2 Calcul de Weighted average. (Moyenne pondérée)

On cherche le produit scalaire de la dérivée du signal avec le signal triangle défini comme-suit.

(Les valeurs sont empiriques)

adaptative



6.2.6.3 . Différencier entre l’objet (trait noir) du background (matte blanc de la piste).

On compare chaque élément de la dérivée du signal avec son homologue du signal triangle

multiplié par la moyenne pondérée calculée suivant 1.2.6.2.

On associe de plus un « flag » comprenant le signe de l’élément traité.

Par exemple, pour un tableau de 30 éléments ayant 2 traits noirs, on obtient

0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0

- + - +

6.2.6.4 . Liaison des « bornes » (linking bounds)

On repend le tableau calculé en 1.2.6.4, on relie les bits négatifs avec les bits positifs.

0 0 0 -1

0 0 0 +1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -1

0 0 0 +1

0

O(n)

~1ms

6.3 Comparaison des méthodes

On a testé plusieurs méthodes (de seuillage par Otsu, Sauvola…. / de filtrage tel que Emboss, sharpen, edge

detection…) qui sont pourvu comme incompatibles ou bien ayant une complexité exagérée (à

utilisation non-temps-réel).

Méthode Rapidité Δ remarques Avantages

Average (1.2.3)

Très rapide -Fausses détections aux bords - Incompatible avec un environnement trop illuminé ou ayant une diffusion lumineuse/éclairage lumineuse non uniforme

- Rapidité

Max-const (1.2.2)

Très rapide - Fausses détections aux bords - incompatible avec un environnement faiblement illuminé ou ayant un éclairage/diffusion lumineuse non uniforme

- Rapidité

midGrey (1.2.1)

Très rapide - Fausses détections aux bords - incompatible avec les environnements ayant un éclairage non uniforme - le taux d’erreur est très grand.

- Rapidité

Pic dérivé (1.2.5)

Très Rapide - détection non stabilisée (sensible au bruit*) - insensible à la distribution lumineuse (jusqu’à une valeur raisonnable)

-Elimination des problèmes de détections aux bords - Rapidité

Shafait (1.2.4)

Rapide - n’est pas compatibles avec tous les environnements (bruits non gaussiens)

-Elimination des problèmes de



- Incompatible avec les environnements à un seul couleur (blanc dans notre cas, c’est-à-dire l’intersection ne sera pas détectée) - très dépendante de la valeur « w » (taille de la fenêtre) utilisée

détections aux bords

- rapidité raisonnable - adaptative

Weighted derivate

link (1.2.6)

Moyennement rapide

- compatible avec plusieurs environnement - insensible aux bruits - erreur détection aux bords contrôlable - imprécision : erreur de mesure (quelques pixels)

- efficacité

(*) Bruit : même après filtrage, quelques bruits persistent

Pour un signal « parasité » aléatoire, voici ce que les méthodes retournent :

Méthode 1.2.4 [Integral Image aka de Shafait]

Existent quelques parasites aux bords (fausse détection)

méthode 1.2.6 [weighted-derivate-link]

(*) on a préféré de donner des courbes qu’une capture de Processing Méthode 1.2.3 (voir la courbe verte) [avg] Méthode 1.2.1 (voir la courbe rouge) [midGrey] Vous pouvez voir les problèmes de détection aux bords Et aussi le retard engendré

Méthode 1.2.5 (dérivé pic)

Détection parfaite après lissage

Méthode 1.2.2

Détection catastrophique (méthode n’opère que si l’environnement est trop illuminé)



6.4 Conclusion :

En énumérant ces méthodes, on peut se questionner « mais enfin, quelle méthode avez-vous choisi ? ».

Si on parcourt les méthodes, on trouvera 4 méthodes qui peuvent être utilisé selon le cas :

Environnement trop illuminé : Méthode de max – const

Environnement faiblement illuminé : Méthode d’Average

Environnement non-bruité : Méthode de Pic de dérivé

Ignorant les imprécisions : Méthode de Weighted derviate and link

Ceci, avec les 2 premières méthodes ayant des problèmes sur les bords (fausse détection suite à

la forme de signal.

C’est pourquoi, il ne faut pas se contenter seulement d’avoir binarisé le signal mais tout

d’abord détecter quelle méthode à utiliser et aussi corriger les erreurs de chaque méthode.

Autrement dit, on a besoin d’une intelligence de vision.



Chapitre 7



7 Intelligence de vision Jusqu’à maintenant, on n’a parlé que de la détection de l’objet « noir » du background « blanc »,

sauf que cette détection peut être erronée et même peut induire des problèmes impardonnables.

De plus, en cas la voiture est en train de viser une intersection (rappelons qu’il s’agit d’une surface

blanche supposé matte) il faut se questionner si laisser la voiture faire un « wilderness » (action

imprévisible ou décision quasi-aléatoire) peut causer des problèmes.

7.1 Signal (donnée) d’initialisation :

Le signal d’initialisation sera toutefois fini une entrée pour l’algorithme de supervision de la

« qualité du signal ».

Un bon signal peut être représenté sous la forme suivante :

- 2 bandes ayant une largeur entre 3 et 12 pixels

- Bandes se trouvant dans zones [0,32] et [96, 127]

Pour mettre en concret ceci, on associe une fonction d’évaluation qui donne un score entre (-1)

[rejet total] et 3 (bon signal) testant les critères un par un.

Une fois cet algorithme finit sa tâche, on trouvera la méthode la plus convenable mais aussi un

signal pertinent utilisable lors de traitement du signal suivant.

On a implémenté cette méthode en utilisant une lecture pixel par pixel en utilisant un système à

états.

Note : Pic-Dérivé n’était pas permise pour ce test.

7.2 Correction du signal

La correction du signal était indispensable pour notre projet. Elle permet de retrouver des

informations perdus aussi bien que fixer les problèmes des méthodes utilisés

La correction du signal est une notion abstraite qui s’étend sur plusieurs fonctions. Par exemple,

parmi les méthodes citées, quelques méthodes sont munies d’un correcteur qui permet de filtrer

les résultats sur place.



Exemple de corrections :

NOM de l’erreur Diagramme Correction

Valeur bruitée Flou + seuil: Si (B[i]+B[i+1]+B[i-1])>2 alors B[i] = 1

sinon B[i] = 0

Fausse détection aux bords Si (détection à la fin ou au début) alors supprimer cette détection Ignorer n bits à gauche et à droite

Lorsque le nombre des bandes se réduit à 1 (en cas d’un emplacement trop à gauche ou à droite

de la voiture), le programme estime alors la position de la ligne en calculant l’écart

(mouvement) de l’autre ligne et l’ajouter à la position antérieure de la ligne courante.

La correction comprend aussi l’évasion de la perplexité lors de la rencontre d’une position

erronée (par exemple différente de celle calculé ou mesuré auparavant). En utilisant un

correcteur PI pour alléger la transition et éviter tout « acte » de réflexion.

7.3 Détection de la ligne de fin

La détection de la ligne de fin peut être fait à plusieurs manière tel que

1. Détection de 2 bandes d’épaisseur large

2. Détection d’au moins 3 bandes (utilisé)

3. Détection d’une distance de quelques pixels entre 2 bandes consécutifs



Pour faciliter la tâche, on a utilisé la 3ème méthode, qui déclanchera un événement FINISHED une fois

le pattern est détecté

7.4 Perception

Une fois le signal est corrigé, on obtient la plupart des cas la position de 2 lignes. Ainsi, on peut

calculer l’état de la voiture.

Pour alléger l’écriture et simplifier le code, on notera

* LeftLine, RightLine la position de la ligne à gauche et à droite (resp.)

* current, previous : l’indice courant et l’indice précédent

TrackDir (Direction de la piste) 7.4.1

𝑐𝑎𝑟. 𝑡𝑟𝑎𝑐𝑘𝐷𝑖𝑟 =𝐿𝑒𝑓𝑡𝐿𝑖𝑛𝑒[𝑐𝑢𝑟𝑟𝑒𝑛𝑡] − 𝐿𝑒𝑓𝑡𝐿𝑖𝑛𝑒[𝑝𝑟𝑒𝑣𝑖𝑜𝑢𝑠]

2

PositionToTrack (position à la piste) 7.4.2

𝑐𝑎𝑟. 𝑝𝑜𝑠𝑖𝑡𝑖𝑜𝑛𝑇𝑜𝑇𝑟𝑎𝑐𝑘 =𝐿𝑒𝑓𝑡𝐿𝑖𝑛𝑒[𝑐𝑢𝑟𝑟𝑒𝑛𝑡] + 𝑟𝑖𝑔ℎ𝑡𝐿𝑖𝑛𝑒[𝑐𝑢𝑟𝑟𝑒𝑛𝑡]

2

Motion (mouvement) 7.4.3

𝑐𝑎𝑟. 𝑚𝑜𝑡𝑖𝑜𝑛 = 𝑐𝑎𝑟. 𝑝𝑜𝑠𝑖𝑡𝑖𝑜𝑛𝑇𝑜𝑇𝑟𝑎𝑐𝑘 − 𝑙𝑒𝑓𝑡𝐿𝑖𝑛𝑒[𝑝𝑟𝑒𝑣𝑖𝑜𝑢𝑠]+𝑟𝑖𝑔ℎ𝑡𝐿𝑖𝑛𝑒[𝑝𝑟𝑒𝑣𝑖𝑜𝑢𝑠]

2

isOversteering [7] 7.4.4

Un véhicule est dit « under steering » lorsqu’elle prend un long virage.

Le cas contraire, « over steering », c’est lorsque la voiture prend un virage

court.

La notion d’oversteering est nécessaire pour la stabilité de la voiture.

𝑐𝑎𝑟. 𝑖𝑠𝑂𝑣𝑒𝑟𝑠𝑡𝑒𝑒𝑟𝑖𝑛𝑔 = 𝑐𝑎𝑟. 𝑡𝑟𝑎𝑐𝑘𝐷𝑖𝑟 ∗ 𝑐𝑎𝑟. 𝑚𝑜𝑡𝑖𝑜𝑛 > 0



SteerRange 7.4.5

If 𝑐𝑎𝑟. 𝑖𝑠𝑂𝑣𝑒𝑟𝑠𝑡𝑒𝑒𝑟𝑖𝑛𝑔 Then 𝑐𝑎𝑟. 𝑠𝑡𝑒𝑒𝑟𝑅𝑎𝑛𝑔𝑒 = 𝑐𝑎𝑟. 𝑡𝑟𝑎𝑐𝑘𝐷𝑖𝑟 − 𝑐𝑎𝑟. 𝑚𝑜𝑡𝑖𝑜𝑛

Else 𝑐𝑎𝑟. 𝑠𝑡𝑒𝑒𝑟𝑅𝑎𝑛𝑔𝑒 = 𝑐𝑎𝑟. 𝑡𝑟𝑎𝑐𝑘𝐷𝑖𝑟 + 𝑐𝑎𝑟. 𝑚𝑜𝑡𝑖𝑜𝑛

7.5 Implémentation:

Pour réaliser ceci en pratique, on a converti le tableau de l’image binarisée vers un tableau utile

qui contient la position des bandes ainsi que le nombre (pouvant être 0, 2, 3 ou 4 puisqu’on a

fixé le problème d’avoir une seule bande).

On a choisi d’avoir 2 matrices 10x10 tokens (token start) et tokene (token end) : utilisé pour

signaler le début d’une bande (respectivement sa fin) et aussi un tableau cnt (count) pour le

nombre des bandes.

int tokens[10][10]; //token start array

int tokene[10][10]; //token end array

int cnt[10]; //count of a state

On recorde à chaque itération l’état courante et 9 états précédents. Pour gérer l’indice de l’état

courant et celle de états précédents on a établi 3 fonctions « prevIdx() », « nextIdx() » et

une variable curSigIdx . Ainsi avec ces fonctions on ne soucie plus d’être en dehors du tableau

ou bien de la performance.

En pratique, l’état « previous » décrit en 2.3 n’est d’autre que la 10ème capture. Ceci est

raisonnable car le temps entre la 10ème capture et la capture courante ne dépasse pas 1s.



Chapitre 8



8 Intelligence Artificielle (AI)

8.1 Introduction

Intelligents concours de voitures 'Freescale Cup » ont été organisées avec succès dans de

nombreux pays. Beaucoup de connaissances spécialisées sont impliqués dans le concours tels que la

science de contrôle, la reconnaissance des formes de la science, la technologie des capteurs,

électronique automobile, l'électricité, l'informatique, la mécanique, et ainsi de suite, comme dans

[8].Une bonne impulsion à long terme d'intégrer les connaissances et les pratiques des capacités des

étudiants de premier cycle a été mise en évidence. Et le concours peut stimuler le développement de la

technologie électronique automobile. Toutes les équipes sont tenues d'utiliser les mêmes modèles

SmartCar fournies par le comité d'organisation. Le MC9S12DG128 microcontrôleur est affecté comme

l'unité de commande centrale, qui est réalisée en Freescale semiconductors . Les participants sont

tenus de choisir et de concevoir le système de contrôle, y compris l'acquisition et le traitement des

signaux des capteurs, contrôler la conception d'algorithmes et de mise en œuvre, DC conception de

commande de moteur, la direction d'asservissement, et ainsi de suite. À la fin de la conception du

système de contrôle de smartcar et le débogage, le résultat du concours dépend largement de la

vitesse de la voiture à la route désignée. La vitesse de la smartcar est largement influencée par le temps

de suivi de l'itinéraire de la smartcar.

8.2 Conception du contrôleur flou

Le principe de base de la commande floue 8.2.1

Un système de commande floue est composé de l'entrée affectée, contrôleur flou, objet commandé

et le signal de rétroaction. Un contrôleur flou est divisé en quatre parties, comme dans [3, 4, 12 et 13]:

fuzzification, base de règles, l'inférence de règle et défuzzification. Voir figure ci-dessous.

Les exigences de base du contrôleur flou 8.2.2

Les exigences de base de la commande floue sont :

1) Lorsque la voiture est sur une voie

rectiligne, servo moteur de direction

devrait orienter au milieu.

2) La voiture ne devrait pas manquer la piste.

3) Lorsque la voiture est sur la piste de

déviation, l'angle de direction devrait

augmenter avec l'augmentation de l'angle

de déviation de la voiture. La sortie d'angle

de direction devrait être un peu plus

grande que d'habitude lorsque la vitesse

est élevée.



La conception du contrôleur flou 8.2.3

Fuzzification 8.2.4

Le processus de fuzzification comprend la détermination des variables d'entrée et de sortie de tous

les systèmes et leurs domaines, le nombre et les valeurs de chaque variable linguistique, les fonctions

d'appartenance de chaque linguistique qui décident la position de chaque variable linguistique [9].La

définition des variables du système, leurs domaines et les fonctions d'appartenance sont décrits

comme suit :

a) L'entrée du système sont deux variables: la première est l'information acquise à partir des

informations de la route, qui est nommé "Cam». La seconde est la vitesse en temps réel acquis de

module d'acquisition de la vitesse, qui est nommé "Speed".

b) La sortie variable système est nommé "ServoAng". L'angle de sortie du moteur de direction

assistée varie de -40 degrés à 40 degrés. Le domaine de "ServoAng" est quantifiée à 0 ~ 150, et sa valeur

est affectée comme: Négatif Large (NL), Négatif Petit (NS), Moyen (Med), Positive Petit (PS), Grand positive

(PL).

c) L'univers du discours de "Cam" est -45 degrés à +45 degrés. Le 0 degré est censé que la position

centrale. Le "Cam" est quantifiée au domaine [0,1,2,3,4,5,6,7,8,9,10], et sa valeur est affectée comme

suit: Très Gauche (VL), gauche (L), Moyen (M), droite (R), très droit (VR).

d) Le domaine de la vitesse réelle de temps est de 0 ~ 2500mm / s, et sa valeur est affectée que dans

trois classes selon la situation réelle: Slow, Rapide, Fast.

(*) Les valeurs sont peu empiriques

e) Les fonctions d'appartenance des variables linguistiques sont généralement déterminées par la loi

de triangle. La formule est présentée comme l'équation 1. La détermination de la fonction

d'appartenance est représentée sur la Fig. suivante.



Selon l'expérience de la pratique, la définition des fonctions d'appartenance des variables linguistiques

est représentée dans Fig.5.



f) La fonction d'appartenance de la fonction de sortie est utilisé comme fonction d'appartenance de

ServoAng. Alors que lors de l'écriture programme de microcontrôleur, fonction à valeur unique est

utilisé, [9] La définition de la fonction est représentée sur la Fig. suivante.



8.3 Base de Règles

Etablissement des règles

La règle de base de l'inférence est: si X est un ET Y est B, alors Z est C, comme dans [4]. Où, 'X est A' est antécédent 1, 'Y est B' est antécédent 2, et «Z est C 'est conséquente. Antécédents est relié par Symbole 'ET'.

La base de règles du système de contrôle de la voiture intelligente est :



8.4 Mécanisme de l'inférence

Le processus d'inférence implique généralement deux étapes:

1- Les locaux de toutes les règles sont comparés aux entrées du contrôleur pour déterminer quelles

règles sont applicables à la situation actuelle. Ce processus de «matching» consiste à déterminer

la certitude que chaque règle applique, et généralement nous allons prendre en compte les

recommandations de règles que nous sommes plus certains appliquent à la situation actuelle.

2- Les conclusions (quelles actions à prendre le contrôle) sont déterminées en utilisant les règles

qui ont été déterminés à appliquer à l'heure actuelle. Les conclusions sont caractérisé par un

ensemble flou qui représente la certitude.

Détermination des règles de notre situation :

Déterminer l'applicabilité de chaque règle est appelée "matching." Nous disons qu'une règle est "à

l'instant t" si son μpremise de fonction d'appartenance de prémisse (c(t), s (t))> 0. Ainsi, le mécanisme

d'inférence cherche à déterminer quelles sont les règles à savoir quelles sont les règles applicables à la

situation actuelle. Dans l'étape suivante, l'inférence visera à combiner les recommandations de toutes

les règles à venir avec une seule conclusion. Considérons, par exemple :

c(t) = 3

et s(t) = 220 :

Il est utile de imager quelles sont les règles de la situation actuelle . Notez que, depuis c (t) = 3 ( e

(t) est directement dans le milieu entre les fonctions d'appartenance pour "Very Left" et "Medium")

ces deux fonctions d'appartenance sont éteints. Avec cela, vous devriez imaginer dans votre esprit la

région de règles de notre situation. De même pour s(t) .Ceci complète notre description de la

"matching" phase du mécanisme de déduction.

D’après les fonctions d'appartenance des entrés et les lignes verticales rouges donnent :

μLeft(c(t))=1 et pour s(t) on a μFast(s(t))=0,2 et μRapid(s(t))=0,8



Par suite :

"Cam is Left"

"Speed is Fast"

"Speed is Rapid"

donc les deux règles sont :

1

Détermination de la conclusion

Considérons la conclusion tirée par la règle (1) :

Utilisation du minimum représente le "premise" de la règle (1) donc on a :

μpremise(1)= min{ μLeft(c(t)) , μFast(s(t)) } = min { 1 ; 0,2 } = 0,2

Nous sommes 0,2 certain que cette règle vaut pour la situation actuelle.

ensuite, considérons la conclusion tirée par la règle (2) :

Utilisation du minimum pour représenter le "premise" de la règle (2) donc on a :

μpremise(2)= min{ μLeft(c(t)) , μRapid(s(t)) }= min { 1 ; 0,8 } = 0,8

nous sommes 0,8 certain que cette règle vaut pour la situation actuelle.

Ainsi, nous sommes beaucoup plus certains que la règle (2) applique à la situation actuelle de règle (1).



8.5 Défuzzification

Les résultats de l'inférence floue sont sorties floues. La sortie nette peut être obtenu par

défuzzification. Pour cette étape, les fonctions d'appartenance des sorties sont nécessaires. La

méthode du centre de gravité est généralement utilisé pour réaliser défuzzication, comme dans [4, 5].

La méthode de calcule du centre de gravité ( COG ) revient a calculer ucrisp (ServoAng) :

Pour notre situation, la défuzzification c'est comme «décodage» de l'information d'ensemble flou

produit par le mécanisme de l'inférence. Cette étape est revient à ceci :

et par suite :



Chapitre 9



9 Unité de contrôle et système à états

9.1 Unité de contrôle

L’unité de contrôle permet de superviser le système en général, détectant

l’état de la véhicule et surcharge ‘overloads’ le système en cas de risque

(c’est équivalent à une interruption software). En effet, on charge le système

à ignorer tout autre programme et fait obéir à un nombre de règles

prédéfinis.

Les ordres de ce système sont définitifs.

Ce système est appelé/codenamed LEAF-0.

N° Nom Description Fix Etat d’activation

1 Offset mal choisi Servo.offset, servo.command sont nuls mais car.motion n’est pas nul

Calibrer l’offset Inactif *

(programmé manuellement)

2 Détection erroné

de finish line Détection de finish line dans les 10 premier secondes

Ignorer Inactif **

(impossible)

3 Grand écart par

rapport au centre La position de la voiture est trop à gauche ou à droite

Equilibrer les vitesses de moteurs

pour revenir au centre

Actif

4 Understeer La voiture est en train de se déraper (manière critique)

Ralentir la vitesse et viser le centre

Actif

(*) Pour l’offset, on a programmé servo.offset en avance (résultats des expériences)

(**)Au démarrage, la caméra vise ce qui après la ligne (ne sera donc pas vu)

9.2 Système à états

Le système à états finis traite les différents cas du système.

N° Nom Description Action

1 PITCH_UP** Détection d’une ponte Accélérer

2 PITCH_DOWN** Détection d’une descente (du ponte) Ralentir

3 FINISHED* Détection de la fin de course Stopper les moteurs (*) Transmis à partir de l’unité d’intelligence de vision

(**) PITCH_UP et PITCH_DOWN sont convoqués à partir de traitement des valeurs d’accéléromètre



Chapitre 10



10 Programmes de support

10.1 Outil : Simulation des algorithmes de filtrage

Pour assurer la qualité des algorithmes de filtrage du signal de la caméra, on a utilisé un réseau de

programmes permettant un affichage rapide et stable des donnés.

Ce réseau se base sur 2 applications : Serveur et afficheur/filtrage (Application Processing).

Serveur (Multiplexage): C’est une application, programmé en Visual Basic, qui permet

l’acquisition des données d’après la caméra et de transférer ces données vers l’application de

filtrage (Processing).

Cette application permet aussi de charger des records de la caméra (sauvegardés auparavant)

de manière d’émuler la caméra et aussi générer de nouvelles valeurs en ajoutant du bruit

uniforme pour tester la stabilité des algorithmes.

Un seul mode d’opération (direct, de fichier avec/sans bruit) doit être activé.

Afficheur/filtrage (Processing) : C’est une application programmé en Processing (Java pour

les applications graphiques) qui permet un affichage et traitement des données en « pixels ».

Cette application a un double rôle : Affichage directe des résultats ainsi que la simulation,

comparaison des algorithmes (en affichant les résultats finaux sur l’écran).

Ci-dessous est un diagramme simplifié du laboratoire virtuel qu’on a utilisé



Aperçu de l’IDE

Avec le même moteur de programmation (code), on a programmé un « recorder » permettant de

sauvegarder des captures de caméra visualisable par le programme-père au temps voulu, sur le PC

voulu.

A noter que nous avons sorti d’une application basique :

10.2 Visualisation d’accéléromètre en temps réel

Basant sur le même moteur (engine), on a conçu de plus un visualiser qui permet de prendre les

coordonnées d’accélération et translater ceci en coordonnées géométriques affichable sur l’écran.

Cette application nous a beaucoup expliqué sur les fonctions d’accéléromètre.



A noter que pour utiliser l’accéléromètre, il faut utiliser un algorithme de filtrage passe-bas ou bien

Moving-Average (moyenne glissante) et ce que nous avons déjà fait (implicitement)

Courbe en bleu : données de

l’accéléromètre

Courbe en vert : moyenne glissante



11 Bibliographie

[1] F. semiconductors, FRDM-KL25Z User's Manual.

[2] F. s. Eli Hughes, «Freescale Cup Shield for the Freedom KL25Z,» [En ligne]. Available:

https://community.freescale.com/docs/DOC-93914.

[3] F. semiconductors, «Line Scan Camera Use,» Freescale, [En ligne]. Available:

https://community.freescale.com/docs/DOC-1030.

[4] G. BLT, «Computer Graphics : 2D Gaussian Blur,» Avril 2013. [En ligne]. Available:

http://ablogaboutshaders.blogspot.com/2013/04/2d-gaussian-blur.html . [Accès le 2015].

[5] o. Gabriel Landini, «Auto Local Threshold,» 2013. [En ligne]. Available:

http://fiji.sc/Auto_Local_Threshold . [Accès le 2015].

[6] D. K. T. M. B. F. Shafait, «Efficient Implementation of Local Adaptive Thresholding Techniques

Using Integral Images».

[7] G. Biasillo, «Racing AI Logic,» chez AI Game Wisdom, Charles River Media, 2000, 2002, pp. 444-

454.

[8] J. H. J. D. Kaisheng Huang, «Overview of Design for Korea Intelligent Model Car Design Contest,»

2004.

[9] B. Shao, «the Online Development of the Embedded Application of Microcontroller,» Beijing,

2004.

Freescale Cup (Autonomous RC-scale Car competition) - Mini project rapport

Engineering

Transcript of Freescale Cup (Autonomous RC-scale Car competition) - Mini project rapport