Aller au contenu


Photo
- - - - -

Programme REA : Rover d'Exploration Autonome


22 réponses à ce sujet

#21 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 08 décembre 2014 - 06:06

1.5 - le contrôle des moteurs

 

1.5.1 - problématique

 

Si nous nous appuyons sur des servomoteurs à rotation continue, alors il n'y a besoin de rien de plus pour les contrôler. En revanche, avec des moteurs DC ou des moteurs pas à pas, il faut pouvoir les commander. Laissons de coté le cas un peu spécifique des moteurs pas à pas pour le moment, et revenons sur les moteurs DC.

Quand le courant électrique passe dans un sens, le rotor se met à tourner dans le sens A. Quand on inverse le sens du courent électrique, le rotor tourne dans le sens B. Notre moteur peut donc tourner dans deux sens, ce qui nous permet d'avancer, reculer, et tourner en combinant deux moteurs tournant en sens contraires.

 

 

1.5.2 - Le pont en H

 

Le problème est le suivant : comment peut on commander ces moteurs? Il faut en effet pouvoir faire varier le sens du courant à la volée quand on le souhaite. Pour ce faire, nous utiliserons une structure électronique appelée le "pont en H".

 

Je cite Wikipedia : "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. Les commutateurs peuvent être des relais, des transistors, ou autres éléments de commutation en fonction de l'application visée.".

330px-Pont_En_H.png

Sur l'illustration ci dessus, on peut voir le schéma d'un tel montage. Le + du circuit se sépare en deux, et le coté gauche passe par un commutateur S1, tandis que le côté droit passe par un commutateur S2. Après S1 et S2, on trouve les deux cotés de la charge, qui forme la branche horizontale du H, tandis que S1 et S2 sont les branches hautes, respectivement gauche et droite.

Le e câble partant de S1 continue vers S3 après l'intersection avec la charge au milieu, et idem pour le câble partant de S2, qui arrive en S4 après avoir croisé la charge. Les deux autres pôles des commutateurs S3 et S4 se rejoignent alors à la masse du circuit.

 

Le principe est qu'on ouvrira les contacts en S1 et S4, et fermera en S2 et S3. Ainsi, le courant circulera à travers la charge : le coté droit sera connecté au +, et le coté gauche au -.

Si l'on veut inverser le sens du courant, on fermera les contacts S1 et S4, et on ouvrira les contacts S2 et S3. Cette fois, le côté gauche de la charge sera connecté au +, et le coté droit au -.

 

Pour les commutateurs, on pourra donc en théorie utiliser n'importe quoi, mais en pratique on utilisera plutôt des transistors, pour leur capacité rapide de commutation. Maintenant, pour de très gros moteurs, on pourrait utiliser de gros relais, et reproduire le montage. Pour nos robots, les transistors permettront une très grande réactivité du système, et également de contrôler la vitesse des moteurs via un signal PWM (nous reviendrons dessus plus tard).

 

Il faut donc 4 transistors pour faire un pont en H, et ainsi contrôler un moteur. Puisqu'il nous faut deux moteurs, il nous faudra deux ponts en H, et donc 8 transistors. On peut aisément construire un double pont en H. Toutefois, puisque cette construction électronique est assez classique, il existe de nombreux circuits intégrés. On trouvera donc des puces "tout en un", qu'on branchera simplement sur nos moteurs, à l'alimentation, et au circuit de commande.

 

1.5.3 - Exemples de composants

Il existe de très nombreux composants, mais je vais parler de trois modèles spécifiques :

  • le L293D;
  • le SN754410;
  • le DRV8835.

 

Le L293D

Le L293D est un circuit intégré très utilisé et connu pour commander de petits moteurs. Ce n'est pas la puce la plus efficace, mais elle est peu chère, facile à trouver, et de nombreuses ressources sont disponibles.

Cette puce contient l'équivalent d'un double pont en H, et peut donc commander deux moteurs, en gérant le sens, mais aussi la vitesse grâce à un signal PWM (nous détaillerons le principe plus bas). Voici le schéma d'un montage à base de L293D : 

L293D_connections.jpg

Source : article sur robotplatform sur le L293D.

Cette puce disponible au format DIP16 comporte 2 rangées de 8 broches.

A gauche, en partant du haut, la broche 1 est appelée enable 1, et permet de contrôler l'activation du premier moteur. Si on envoie un signal logique bas sur cette broche, le moteur 1 sera éteint. C'est via cette broche qu'on contrôlera la vitesse du moteur avec un signal PWM. Les broches 2 et 7 sont les entrées qui permettent de contrôler le sens de rotation du moteur. Si on envoie un signal haut sur la broche 2, et un signal bas sur la broche 7, le moteur tournera dans un sens, et si on envoie un signal bas sur la broche 2 et haut sur la broche 7, le moteur tournera dans l'autre sens. Toutes les autres combinaisons entraîneront l'arrêt du moteur. Bien sur, le moteur ne tournera que si la broche 1 reçoit un signal logique haut.

Les broches 3 et 6 seront connectées au moteur, tandis que les broches 4 et 5 seront connectée à la masse. Enfin la broche 8 sera connectée au Vmotor, à savoir le + de l'alimentation électrique des moteurs (généralement directement le + de la batterie)

 

Sur le côté droit, on retrouvera quelque chose de similaire, à quelques différences près.

Nous partirons cette fois ci du bas, pour la broche 9, vers le haut pour la broche 16. La broche 9 sera la broche enable2, qui contrôle l'activation du second moteur. Les broches 10 et 14 commandent le sens de rotation du moteur exactement comme les broches 2 et 7 commandent le moteur 1. Les broches 11 et 14 sont connectées au second moteur, et les broches 12 et 13 sont connectées à la masse. La broche 16 est connectée à l'alimentation logique (5V).

Il faut donc 6 signaux logiques pour commander nos deux moteurs avec cette puce. L'alimentation électrique des moteurs peut varier de 5V à 36V. L'alimentation logique peut accepter jusqu'à 7V.

La puce peut délivrer jusqu'à 600mA par moteur selon les spécifications. On peut toutefois aller un peu plus loin en refroidissement efficacement la puce, ou en mettant plusieurs puces en parallèle.

Voici un article détaillé en français sur le L293D, à lire pour aller plus loin.

Voici également la documentation (datasheet) du L293/L293D sur le site de TI, et la fiche produit du L293/L293D sur le site de TI.

 

 

Le SN754410

Le SN754410, de TI est une puce au même format que le L293D, et compatible broche à broche (c'est à dire que dans un circuit, on peut enlever un L293D et mettre un SN754410 sans rien changer). Cette puce plus efficace fait tout ce que fait le L293D, mais peut délivrer plus de puissance. Ainsi, on peut atteindre 1A par moteur, et il est possible de recourir aux mêmes astuces qu'avec le L293D pour augmenter la puissance disponible. Ces puces intègrent de plus des diodes de protection pour protéger les transistors contre les retours de courant. Bref, une puce plus puissante, plus résistante, et compatible broche à broche avec les L293D. Si on a le choix, autant prendre celle ci à la place d'une L293D. Les deux inconvéniants de cette puce sont qu'elle est moins courante et donc moins facile à trouver que le L293D, et qu'elle à un nom difficile à retenir!

Voici la fiche du SN754410 chez Pololu, la documentation du SN754410 (datasheet), la fiche produit du 754410 chez TI.

 

Le DRV8835

Le DRV8835, encore de TI, est une puce plus moderne, capable de délivrer davantage de courant (1.5A max par moteur), et de contrôler deux moteurs. Par rapport aux deux puces précédentes, celle ci peut donc commuter plus de courant, mais également une tension plus faible pour les moteurs. Les deux précédentes sont prévues pour une tension de moteurs d'au moins 4.5V, contre 2V pour le DRV8835. En revanche, le DRV8835 ne permet pas ce commander des moteurs nécessitant une tension de plus de 11V.

L'intérêt de cette puce sera donc de pouvoir commander des moteurs à une faible tension (par exemple, si on utilise une batterie une cellule lipo, la tension variera entre 3 et 4.2V, ce qui est trop faible pour un L293D ou un SN754410), et/ou avec des courants plus forts. Il est à noter que le DRV8833 permet de monter jusqu'à 2A en pointe par moteur, au dépens de la plage de tension, puisqu'il faut au moins 2.7V, et au plus 10.8V.

Ces puces sont fabriquées dans un format peu pratique pour ceux qui ne peuvent pas souder des composants de surface, mais heureusement, on trouve des cartes permettant d'utiliser ces puces sur une breadboard ou simplement en soudant des câbles.

Avec la carte de pololu, on contrôlera donc différemment la puce par rapport à un L293D/SN754410:

0J4058.600.png?9eff351b63a93064f7eaeb6b7

En pratique, du côté gauche de la carte, tout en haut, nous aurons la masse, puis le VCC (alimentation logique).

En dessous, la broche enable du moteur B (même principe que la broche enable des deux précédentes puces).

Encore en dessous (4 ème broche en partant du haut), nous aurons l'entrée "BPHASE", qui permet de contrôler le sens du moteur : si cette entrée reçoit un signal logique bas, le moteur tournera dans un sens, et si elle reçoit un signal logique haut, le moteur tournera dans l'autre sens (toujours si la broche enable est active).

En dessous, en 5 et 6, nous aurons la broche enable du moteur A, et la broche phase du moteur B, qui auront le même rôle que pour le moteur B. Enfin, la broche tout en bas est la broche permettant de régler le mode de contrôle. Pour que l'on puisse utiliser le moteur comme décrit plus haut, il faut que cette broche reçoive un signal logique haut (il suffit de la connecter à VCC). Dans le cas contraire, on contrôlera les moteurs de façon différente, avec davantage de possibilités (voir la documentation pour cela).

Du coté droit, en partant du haut, nous aurons d'abord la masse des moteurs, puis le VIN, ou le + des moteurs. En dessous, en 3 et 4, les broches de sortie du moteur B, puis en 5 et 6 les broches de sortie du moteur A. Enfin, la dernière broche, VMM, permet de récupérer le + de l'alimentation des moteurs, après le circuit de protection contre l'inversion de tension.

 

On notera donc ici qu'il suffira de 2 broches par moteur pour contrôler la vitesse et le sens, par rapport à 3 pour les deux précédentes puces.

 

Encore une fois, on peut multiplier les puces pour augmenter le courant de sortie, ou refroidir la puce. En pratique, d'après les tests de pololu, dans une pièce à température ambiante, la puce peut délivrer 1.2A par canal en continu, et  1.5A pendant 15s avant que la protection thermique intégrée ne coupe l'alimentation.

Dans tous les cas, il est à noter que cette protection thermique existe, et donc vous ne grillerez pas votre puce, elle s'arrêtera avant.

 

Voici quelques documents:

La fiche produit chez TI du DRV3385, la documentation (datasheet) du DRV3385 sur le site de TI, la fiche produit du DRV3385 sur Pololu.

La fiche produit chez TI du DRV3383, la documentation (datasheet) du DRV3383 sur le site de TI, la fiche produit du DRV3383 sur Pololu.

 

Il existe de nombreuses autres puces, comme par exemple le L298, le L298N, etc...

Certaines solutions sont plus complexes à utiliser que d'autres, et les plages de tension, les courants disponibles ainsi que d'autres paramètres varieront grandement.

 

1.5.4 - Utilisation de signaux PWM pour contrôler la vitesse

Pour contrôler la vitesse des moteurs, on utilisera bien souvent des signaux PWM. En effet, on pourrait faire varier la tension délivrée aux moteurs, mais cela nécessite un circuit capable de fournir un signal de sortie analogique. Une autre solution consiste en gros à allumer et éteindre très rapidement le moteur, ce qui fait qu'il tournera en moyenne moins vite. C'est le principe de la PWM, ou Pulse Witdth Modulation, soit Modulation de la Largeur d'Impulsion.

 

500px-Delta_PWM.svg.png

Le principe est, comme sur le graphique ci dessus, d'envoyer un signal en créneau, c'est à dire que par moment on enverra alternativement un signal bas, et alternativement un signal haut. Si on fait très rapidement cette alternance, cela permet d'activer/désactiver très rapidement le moteur, donc qu'il tournera moins vite. 

En pratique, si 500 fois par seconde, on envoie du courant à la tension du moteur pendant 1ms, avant de couper le courant pour 1ms, le moteur recevra du courant 50% du temps. Il tournera donc moins vite, on dira qu'il a un cycle de charge de 50%. En faisant varier la durée pendant laquelle on envoie du courant par rapport à la durée pendant laquelle le courant ne passe pas, on pourra ainsi faire varier la vitesse de rotation du moteur.

En pratique, si l'on envoie un signal PWM sur la broche enable du moteur, on pourra ainsi contrôler la vitesse du moteur, car le signal en sortie du pont en H aura le même cycle PWM.

 

1.5.5 - Conclusions

Avec ce dernier composant, nous avons enfin le dernier composant nécessaire pour assurer la propulsion d'un robot roulant. Il est à noter que ces contrôleurs de moteurs permettent également (au moins les deux premiers) de commander des moteurs pas à pas, et qu'il existe des contrôleurs spécifiques pour les moteurs pas à pas.

On prendra bien soin d'ajuster le composant utilisé à la puissance des moteurs : si les moteurs atteignent X ampères au maximum, alors le contrôleur devrait pouvoir gérer au moins X ampères en continu pour le ou les canaux assignés à ce moteur. Il est préférable en outre de ne pas pousser les composants au maximum, donc il vaut mieux surdimensionner le contrôleur de moteur pour être sur de ne pas avoir de problème de surchauffe.

 

Certains composants apportent en outre diverses fonctionnalités supplémentaires, par exemple une protection anti-surchauffe, une mesure du courant consommé, etc. Il conviendra de considérer ces fonctionnalités selon les besoins, bien qu'on puisse ajouter certaines avec des composants externes.


Mon site principal : http://www.nagashur.com/ (format blog, un wiki y est aussi)

Mon profil sur hackaday.io : https://hackaday.io/sky99 (hackerspace en anglais, j'y ai plein de projets)

Mon Github : https://github.com/sarinkhan/


#22 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 18 février 2015 - 05:49

Etape 2 :  l'électronique de commande

2.1 - Choix de l'électronique de commande

Suite aux choix posés aux étapes précédentes, nous disposons d'un système autonome, capable de déplacements contrôlables.

Toutefois, il faut orchestrer l'ensemble, activer les composants au bon moment, etc. Il nous faut donc un composant,

ou un ensemble de composant qui nous permettra de commander l'ensemble des organes du robot. Pour cela, nous nous

tournerons vers des circuits d'électronique programmable, afin de pouvoir programmer le comportement du rover à notre guise.

 

En effet, il ne s'agit pas d'une machine télé-opérée, mais autonome, il faut donc qu'elle puisse seule exécuter un algorithme,

et répondre à des problèmes rencontrés. Il existe de très nombreux systèmes répondant à nos attentes, dont beaucoup proposant

des fonctionnalités équivalentes.  Nous poserons donc des choix davantage basés sur la commodité que sur des raisons techniques; les choix 

faits ici pourront aisément se voir modifiés selon les besoins et/ou le matériel disponible.

 

2.1.1 - Architecture générale du système de commande

Nous avons besoin d'un système capable à la fois de gérer des signaux précis pour interagir avec le matériel, mais également d'exécuter des algorithmes potentiellement lourds en ressources et complexes.

Pour répondre à ces deux problématiques, notre approche sera un système à deux niveaux : 

  1. une première carte programmable intégrant un microcontrôleur se chargera des tâches dites de "bas niveau", à savoir le contrôle précis des moteurs, l'analyse des capteurs pour ajuster automatiquement certains paramètres, la mesure des tensions, etc;
  2. une seconde carte embarquant un processeur plus puissant pour une programmation des algorithmes dits de "haut niveau", qui enverra des instructions générales à la première carte en fonction d'un algorithme à plus grande échelle.

En pratique, on pourra dire que la première carte s'occupera des détails, des ajustements fins, et du contrôle moteur précis, tandis que la seconde s'occupera du plan d'ensemble, de la stratégie globale. Ainsi, si l'on veut se rendre d'un point A à un point B, la seconde carte déterminera un itinéraire, ou même si c'est simplement possible. Elle enverra alors une suite d'instructions à la seconde carte, qui se chargera de traduire ces instructions générales (avancer tout droit sur 50cm, tourner à gauche de 60°, etc) en instructions précises (allumage des deux moteurs dans le sens avant, ajustement de la vitesse de ceux ci pour corriger la trajectoire, etc) qui permettront le déplacement effectif du robot.

 

Ainsi, dans un premier temps, on se bornera à programmer les organes du robot à travers la carte de bas niveau, en créant un ensemble de fonctions. Une fois ceci fait, nous disposerons d'un "langage" nous permettant de programmer le robot depuis la seconde carte pour lui permettre de réaliser des tâches concrètes.

 

Voyons maintenant le matériel.

 

2.1.2 - La carte de contrôle "bas niveau" : Arduino

Pour le contrôle de bas niveau, nous avons besoin d'un système capable d'envoyer des instructions précises parfois à la milliseconde, voire microseconde près. Nous aurons besoin de pouvoir envoyer des signaux carrés (PWM), et d'analyser à haute fréquence certains signaux, voire lire des signaux analogiques. De nombreux microcontrôleurs permettent la réalisation de ces tâches, avec par exemple les Picaxe, ou encore les ATMega et les ATTiny. Ces deux derniers sont des puces de chez Atmel. Les ATmega sont présents au cœur de nombreux modèles de Arduino, avec notamment le ATMega328p pour le Arduino Uno. De nombreuses solutions sont disponibles sur le marché, et énormément sont très valables. Le choix du Arduino dans ce contexte vient du fait que ces cartes sont très rependues, avec une vaste communauté (et donc de documentation), faciles à programmer et utiliser. Nous n'avons pas de raisons techniques particulières pour privilégier le Arduino face aux picaxe, simplement les raisons présentées ci dessus, et le fait que je dispose déjà de tel matériel.

 

En pratique, les cartes Arduino embarquent une puce, le microcontrôleur, que nous programmerons, et qui interagira avec les organes du robot. Il dispose d'un nombre variable d'entrées-sorties, selon le modèle. Généralement les Arduino disposent également d'un port USB connecté à un convertisseur série, qui permet à la fois de communiquer avec le microcontrôleur et de le programmer.

En pratique, un bon choix sera celui du Arduino Uno R3, avec la puce au format DIP. En effet, c'est un modèle courant, et la puce amovible peut être changée en cas de problème.

 

Toutefois, les codes développés resteront valables pour la majorité des Arduino du marché. Il en existe en effet d'autres (Léonardo, mega, etc), mais également des versions dans des formats variés (Arduino mini, par ex). Enfin, en achetant la puce et un convertisseur série-USB, on peut fabriquer son propre Arduino, et l'adapter précisément à nos besoins.

 

Nous partirons ici d'un Arduino Uno R3 pour les premiers tests, mais nous passerons très certainement à un Arduino spécifique pour coller à nos besoins. 

Toutefois, le code restera compatible, et les branchements seront équivalents, sauf mention contraire, dans ce cas les modifications seront précisées.

D'autre part, un Arduino classique fera très bien l'affaire, les modèles que nous ferons serviront principalement à réduire l'encombrement et la consommation.

 

2.1.3 - La carte de contrôle de haut niveau : le Raspberry pi

Pour le contrôle de haut niveau, il existe également de nombreuses solutions. Nous cherchons cette fois ci un système capable d’exécuter des programmes importants, dans divers langages si possible, et pouvant traiter des informations plus lourdes. Dans ce contexte, un micro-ordinateur compact sera souhaitable, pour nous offrir un maximum de flexibilité. Un processeur x86 semble exclu, car ceux ci imposent une consommation électrique conséquente, au détriment de l'autonomie. Nous nous tournerons donc vers les processeurs ARM, qu'on retrouve dans les téléphones, les GPS, ou tout simplement la plupart des systèmes embarqués, mobiles. 

Un bon exemple serait un téléphone Android. En effet, il s'agit d'une micro-ordinateur complet, avec une grande connectivité, et avec sa propre batterie. Ce pourrait être une solution intéressante. Une autre solution pourrait être le beaglebone black, carte tout en un très efficace, embarquant de nombreux GPIO. Elle est toutefois un peu difficile à trouver, mais c'est une très bonne solution.

Toutefois, nous nous tournerons vers le Raspberry Pi, un micro-ordinateur ARM mono-carte tout en un, économique, assez ouvert, bien assez performant pour nos besoins, très rependu, et avec une énorme communauté. De plus, le Raspberry Pi dispose d'une gigantesque communauté, et de très nombreux accessoires, tel le module camera, qui pourra nous permettre de traiter des images de l'environnement du robot, en full HD en video, et en 5Mpixels en photo, pour un coût équivalent à une webcam basique. Enfin, le Raspberry pi dispose également de nombreuses entrées-sorties numériques (GPIO) qui pourront nous servir à interfacer divers systèmes, capteurs, effecteurs, etc.

 

Puisque le Raspberry pi dispose de GPIO, pourquoi utiliser en plus un Arduino? 

Nous conservons le Arduino pour ses capacités d'exécution précises de commandes en temps réel. En effet, bien que le Raspberry pi sont excessivement plus puissant en capacité de calcul, et dispose de bien plus de mémoire, il utilise un système d'exploitation qui ne permet pas d’exécuter des instructions "en temps réel", c'est à dire à un moment donné précis, prédictible, et pour une durée précise et prédictible. En pratique, il faudra un certain temps (faible certes, mais variable, et non prédictible de façon précise) pour exécuter une instruction, qui prendra un temps encore une fois non prédictible de façon précise pour s'exécuter.

 

Concrètement, quand on voudra contrôler les moteurs très précisément, à la milliseconde près, cela posera problème. Le Arduino en revanche est pensé pour ces tâches, et exécutera la même instruction en un temps constant. En contrepartie, le Raspberry pi pourra exécuter plusieurs tâches en parallèle, faire des calculs plus lourds, traiter des données volumineuses, etc.

Enfin, le Raspberry pi ne dispose ni d'entrées analogiques, ni d'assez de sorties PWM. Le Arduino se chargera donc de ces aspects.

 

Le Raspberry pi tourne sous Linux, ce qui nous permettra d'installer de nombreux programmes, mais aussi de programmer le robot dans le langage de notre choix. Par exemple Python, qui est très complet et puissant, tout en restant accessible.

 

Il existe de nombreux modèles de Raspberry Pi, mais ici seuls deux nous intéresseront :

 

Le modèle A+ est le plus compact, le moins cher (20$), et consomme moins que les autres (100mA au repos 200 en prenant des photos avec le module camera). Il ne dispose que d'un port USB, et pas de port réseau, mais ce n'est pas gênant pour un robot. Le port USB pourra servir à l'ajout d'une clé wifi par exemple. Ce modèle ne dispose que de 256Mo de ram, contre 512 pour les autres, mais cela ne devrait pas poser de problème. La faible consommation nous permettra d’accroître l'autonomie du robot.

 

Le Raspberry Pi 2 modèle B est un peu plus gros, plus cher (35$) et consomme un peu plus (250-350mA), mais dispose en contrepartie d'un processeur beaucoup plus puissant (quatre coeurs A7 à 900Mhz, contre un coeur A6 à 700Mhz), et de 1Go de RAM. Si la puissance du A+ venait à être insuffisante, alors ce modèle pourra remédier à ce problème.

 

Il est à noter que le Raspberry Pi modèle B+ (première version) coûte le même prix que le 2, et à le même format, mais embarque le même processeur que le modèle A+, et 512Mo de ram. Celui ci consomme légerement moins que le Raspberry pi 2, mais plus que le A+. Il peut donc s'avérer une solution intéressante dans certains cas, mais généralement on acceptera une légere perte d'autonomie en contrepartie d'une massive augmentation de puissance de calcul et de mémoire.

 

Les modèles A et B ne présentent pas d'intérêt par rapport aux modèles A+ et B+, qui les surclassent à tous points de vue. Le Raspi 2 B consomme même moins que le Raspi 1 modèle B.

Donc en cas d'achat, il n'y a aucun intérêt à prendre un modèle A ou B à la place d'un A+ ou B+, et le Raspi 2 B semble préférable généralement au Raspi 1 B+.

 

Toutefois, si on dispose déjà de matériel, il n'est pas nécessaire d'en racheter pour prendre les nouveaux modèles. En effet, en terme de puissance de calcul, hormis le Raspi 2, les autres modèles sont tous comparables. En revanche, les A et B consomment plus que les A+ et B+, ce qui nuira à l'autonomie du robot. Le A consomme environ autant qu'un B+ (environ 50mA de moins) et le B consomme plus que tous les autres (350mA au repos, jusqu'à 500 en vidéo). Bref, les anciens modèles ne sont pas les plus optimisés, mais fonctionneront très bien au détriment d'un peu d'autonomie.

 

Le code restera le même pour tous les modèles.

On peut en outre développer sur un modèle, puis transférer la carte sur un autre. Attention toutefois, les A et B utilisent une carte SD, tandis que les autres utilisent une microSD. Mais on peut facilement cloner la carte.

 

2.1.4 - Conclusions

 

Nous avons donc défini l'architecture générale de l’électronique de commande, avec une architecture à deux niveaux, le premier pour les opérations de bas niveau, et le second pour les opérations plus complexes et à plus grande échelle. Cette architecture n'est toutefois pas obligatoire, nous pourrions en effet nous contenter de l'électronique programmable de bas niveau, ou alors du Raspberry Pi. Nous étudierons par la suite les limitations de chacune des solution, afin de déterminer dans quel contexte celles ci sont souhaitables, avant de nous intéresser à une implémentation de cette architecture à deux niveaux.


Mon site principal : http://www.nagashur.com/ (format blog, un wiki y est aussi)

Mon profil sur hackaday.io : https://hackaday.io/sky99 (hackerspace en anglais, j'y ai plein de projets)

Mon Github : https://github.com/sarinkhan/


#23 sky99

sky99

    Habitué

  • Membres
  • PipPip
  • 271 messages
  • Gender:Male

Posté 15 avril 2016 - 11:00

Sur la partie électronique de commande, j'ajouterai deux cartes notables.

La première est le Raspberry Pi Zero. Bien que dépourvu du connecteur caméra (si celui ci est nécessaire, on préférera le A+), ce modèle est extrêmement compact,

et coûte 5€. A mon sens il est extrêmement intéressant dans de nombreux cas. Sa consommation en veille tombe à 80mA, soit 20% de moins qu'un A+.

Donc très bien dans de nombreux cas, et en plus les GPIO ne sont pas soudés, donc on peut souder directement dessus et avoir un ensemble très compact.

 

Si le poids et l'encombrement sont des paramètres critiques, et qu'on peut se passer du module caméra, c'est la meilleure option.

 

A l'autre bout du spectre, le Raspberry pi 3 est au format B+ et également le même que le pi2, mais fournit un CPU plus puissant (+50-60%), et surtout un module wifi et bluetooth embarqué.

Donc ce pourra être une bonne solution pour un robot capable de fournir l'alimentation électrique requise à ce pi (c'est celui qui peut consommer le plus, si l'on fait travailler les quatre cœurs à fond).

 

A noter que d'après ce que j'ai compris, un Raspberry pi 3 A+ sortira à un moment ou un autre, donc à voir si ce sera un Raspi A+ avec le wifi et le BT intégré en, gardant l'ancien CPU économe, ou un Raspi 3 avec le nouveau CPU gourmand, mais en format compact et toujours avec le wifi et BT.

 

Dans tous les cas, le choix s'élargit, et on a de plus en plus d'options très adaptées à des cas bien précis, plutôt qu'une seule bonne option utile un peu partout!


Mon site principal : http://www.nagashur.com/ (format blog, un wiki y est aussi)

Mon profil sur hackaday.io : https://hackaday.io/sky99 (hackerspace en anglais, j'y ai plein de projets)

Mon Github : https://github.com/sarinkhan/




Répondre à ce sujet



  


0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users