Projet Eurêka - Icofolio

Projet Eurêka

Par Ico, mercredi 27 mai 2009 à 09:58 :: Electronique :: #2 :: rss

J'ai décidé de refaire la section Eurêka, car il me semblait qu'elle méritait mieux qu'un simple descriptif. Il me paraît évident que la robotique n'est pas destinée à rester un simple joujou pour électronicien, ni même un objet désuet d'intérêt en effectuant des tâches préprogrammées.

Le but principal d'Eurêka est de réaliser un robot évolutif tant dans ses cartes de développements qu'au niveau de sa programmation en assembleur. Ce robot aura pour tâche de se déplacer sur un bureau ou une surface plane sans tomber et en évitant les obstacles. Il aura en charge de capter les événements extérieurs (ambiance lumineuse et sonore) et sera capable d'afficher sur un écran des informations. (Voir : Relation homme / machine)

Plan de l'article :
1. Le cahier des charges
2. Les choix technologiques
3. Le bus série
3.1. Principe
3.2. Le choix du protocole I2C
3.3. Les composants dédiées
3.3.1. Côté maître (Master)
3.3.2. Côté esclave (Slave)
4. Notre application
4.1. Présentation du concept
4.2. Synoptique du concept
4.3. Explications
4.3.1. Le bus
4.3.2. Carte capteur (adresse 01110001)
4.3.3. Carte puissance (adresse 01110010)
4.3.4. Principe de fonctionnement du bus à travers le concept
5. Photographies du projet

1. Le cahier des charges :
Ce prototype devra se déplacer sur une surface stable et lisse (Bureau, surface claire) et aura en charge de capturer les évènements extérieurs (Son et lumière). Les cartes, en extension, devront être interchangeables (principe d'une carte mère et des cartes dédiées à insérer dessus). De façon à pouvoir gérer toutes les possibilités d'inter changements de carte, un programme générique sera installé. Un bus série sera créée pour la gestion de l'ensemble.

2. Les choix technologiques :
Afin de se déplacer en toute liberté sur une surface stable, un châssis mécanique a été créé avec des cornières en aluminium. Pour permettre le déplacement le choix c'est porté sur des servos d'ont l'électronique a été retiré.
Les différentes captures seront effectuées à partir des CAN (Convertisseurs Analogiques Numériques), montées sur des cartes inters changeables et gérés entièrement par la carte mère à travers le bus série.
Pour assurer les déplacements, une série de capteurs infrarouges sont nécessaires. Tout sera centralisé sur une carte fille dédiée à cette tâche. Elle retournera à travers le bus, l'image à l'instant « T », des capteurs. Pour un capteur, seul, il s'agit de relier à une PLL (Phase Locked Loop. Traduction : Boucle à verrouillage de phase) une diode infrarouge émettrice et un photo-transistor pour la réception.

3. Le bus série

3.1. Principe :
Un bus série transmet les données en train d'impulsions (les unes derrières les autres), octet par octet. Pour rappel 1 octet correspond à 8 bits composés deux quartés de 4 bits. Chaque bit peut prendre l'état 0 ou 1 dit « logique ». Dans notre application, nous voulons que les données évoluent dans les deux sens. Du maître (Master) à l'esclave (Slave) et de l'esclave au maître.

3.2. Le choix du protocole I2C :
Le protocole I2C a été inventé dans les années 80 par Philips pour satisfaire l'intégration dans le matériel audio et vidéo grand public. Il est fiable et apporte au projet un gage de stabilité dans le temps.
Notre but, avec le choix de ce bus, est d'utiliser le plus possible de composants du commerce. NXP, filiale de Philips propose d'ailleurs des composants utilisant le protocole I2C au format standard.

3.3. Les composants dédiées :

3.3.1. Côté maître (Master) :
Le PIC 16F876 intègre le protocole I2C en utilisant son module MSSP. Sans entrée dans le détail, car expliqué sur le site de BIGONOFF à l'adresse suivante http://www.abcelectronique.com/bigonoff/ . Le module MSSP est un registre de travail du Pic qui a en charge le fonctionnement du bus en mode I2C sur les pins RC3 « SCL » et RC4 « SDA ».
Pour notre application, on retiendra qu'en utilisant ce registre, on peut placer le PIC en mode I2C, adressage sur 7 bits et une fréquence de 100KHz, afin d'être compatible avec les autres composants esclaves.

3.3.2. Côté esclave (Slave):
Le PCF 8574, composant dédiée à l'I2C pour servir de port d'entrée/sortie supplémentaire. Il intègre d'une part le protocole I2C avec un adressage sur 7 bits pour une fréquence de 100KHz. On voit déjà la compatibilité avec le maître, notre PIC 16F876. Pour entrée dans le détail, je vous invite à aller sur le site de NXP : http://www.nxp.com/pip/PCF8574_4.html, ou l'on trouvera le datasheet du composant.

4. Notre application :

4.1. Présentation du concept :
Vous l'aurez compris, le projet Eurêka repousse dans ses limites l'intégration de cartes interchangeables. Afin de s'y retrouver un peu, notamment au niveau de la lecture / écriture et de l'adresse donné à chaque carte, je vais vous proposer un schéma synoptique qui vous donnera des informations quant à la structure du projet. Il est à noter que le robot, en fonction des applications visées, se verra attribuer plusieurs synoptiques et qu'il serait, en outre, fastidieux de tous les données dans cet article. Nous retiendrons alors la synoptique générale de l'application.

4.2. Synoptique du concept:

Synoptique

4.3. Explications :

4.3.1. Le bus :
On remarque de suite que le bus est toujours alimenté par deux résistances au 5V. L’I2C impose un tel fonctionnement afin de se prémunir des entrées parasites.

4.3.2. Carte capteur (adresse 01110001) :
Cette carte utilise un PCF 8574 en mode Lecture, voir dans son adresse, le bit de poids faible mis à 1 et récupère ainsi des états logiques fournis par les capteurs à travers des PLL, composées de NE567.

4.3.3. Carte puissances (adresse 01110010) :
Cette carte utilise un PCF 8574 en mode Ecriture, voir dans son adresse, le bit de poids faible mis à 0 et sort les états distribués par le maître à travers le bus.

4.3.4. Principe de fonctionnement du bus à travers le concept :
Afin de mieux comprendre, il se passera la chose suivante :
Le master (PIC 16F876) démarre la séquence (S) ;
Le master appelle la carte capteur (01110001) ;
Le master attend la réponse de la carte capteur (A) ;
Le master attend l'image des entrées de la carte capteur (XXXXXXXX) ;
Le master attend la réponse de la carte capteur (A) ;
Le master Libère le bus (P) ;

Le master compare les données reçues de la carte capteur
(XXXXXXXX = 00011100 - par exemple) ;
Le master prend sa décision (on écrira alors 00001010 - par exemple) ;

Le master (PIC 16F876) démarre la séquence (S) ;
Le master appelle la carte puissance (01110010) ;
Le master attend la réponse de la carte puissance (A) ;
Le master écrit ce que la carte puissance doit faire (00001010) ;
Le master attend la réponse de la carte puissance (A) ;
Le master Libère le bus (P) ;

On boucle ce programme.


Ce qui correspond en bits :
S 01110001 A 00011100 A P ;
Prise de décision, on écrit 00001010 ;
S 01110010 A 00001010 A P ;
On boucle le programme pour un nouvel échange


Voyez comme ceci est en fait très simple. Nous avons à faire à un dialogue entre un composant maître et ses composants esclaves. Le programme boucle afin de tester à nouveau les entrées puis, après la prise de décision, en découler les sorties qui seront alors à appliquer.
J'ai volontairement simplifié à un seul test et une seule écriture pour ne pas surcharger le présent article. Tout décrire serais lourd à lire et fastidieux à écrire. Si vous prenez la peine de lire le cours de BIGONOFF section MSSP et les datasheets proposés, vous devriez n'avoir aucun problème pour comprendre le concept et le protocole I2C.

5. Photographies du projet:
Eurêka a enfin droit à une image, d'autres devrais venir plus tard.

Eurêka 01