Raspberry Pi : fabriquons des trucs!

[sky99]

Montage d'un robot Raspberry pi type R.Cerda.

Dans le précédent tutoriel, nous avons vu le schéma fonctionnel du robot, et le schéma électronique. Pour la partie électronique, il suffit donc de connecter les éléments comme indiqué sur le schéma. Nous allons voir maintenant une façon de monter le tout.

Matériel et matériaux nécessaire

Nous avons vu dans un précédant tutoriel la liste des pièces nécessaires, et des possibilités de variantes, ainsi que les raisons de ces choix. Nous partons aujourd'hui sur une configuration simple, avec deux roues motrices et une roulette.

Avant tout résumons le matériel :

• Un Raspberry Pi;
  
• Une grande breadboard ;
  
• Deux L293D;
  
• Un MCP23017;
  
• Un MCP3008;
  
• Un Maxbotix LV-EZ0, 1, 2, 3, ou 4 , ou bien un capteur infrarouge, ou tout autre capteur de distance (facultatif, si vous utilisez uniquement les capteurs de contact);
  
• Du fil électrique (pour électronique, pas du gros câble);
  
• Une trappe pour 6 batteries AA;
  
• Deux roues;
  
• Une roulette;
  
• Une carte SD;
  
• Du jumper wire;
  
• un convertisseur DC-DC fournissant du 5V
  
• Une planche de bois d'environ 20cm*15-20cm;
  
• Une petite planchette pour visser la roulette (récupérez une chute, par ex un bout de 5*5cm);
  
• Des vis à bois de 3mm de diametre, et de 12-20mm de long;
  
• Deux petites plaques de plexi, plastique, ou n'importe quel matériau que vous pourrez coller sur les moteurs;
  
• un câble micro-USB;
  
• Un adaptateur power jack-USB (on peut s'en passer si on couple le câble USB pour accéder directement aux fils +5v et à la masse);
  
• Un power Jack (on peut également s'en passer dans le même contexte);
  
• Deux switches pour les capteurs de contact (facultatif, si vous n'utilisez que le détecteur à distance).
  

Pour les outils, il nous faudra :

• Un tournevis;
  
• Des ciseaux ou une pince à dénuder/pince coupante;
  
• Potentiellement un fer à souder et de l'etain, mais on peut faire sans en torsadant les fils entre eux;
  
• De la colle adaptée pour coller les moteurs à leurs supports (j'ai utilisé de la super glu, pour coller le corps en plastique du moteur au plexi).
  
• Éventuellement une perceuse si vous prenez des plaquettes de plexi, en bois on peut visser sans percer.
  

Nous avons maintenant tout ce dont nous pouvons avoir besoin, on peut commencer le montage.

Installation des roues et de la roulette.

La première étape sera de coller les petites plaques sur le corps des moteurs, comme sur ces photos :

Vous pouvez voir que dans mon cas, j'ai utilisé du plexiglas, et il y a deux trous qui permettront de fixer le moteur sur le châssis.

Pour le châssis, j'ai simplement pris une planche de bois. On peut voir sur l'image ci dessous que j'ai tracé un trait permettant de

placer les deux moteurs au même niveau, et également un trait perpendiculaire au milieu pour centrer la roulette.

On peut alors visser les moteurs sur le châssis :

Pour la roulette, nous allons d'abord visser le support de la roulette sur une planchette, avant de mettre la bille de la roulette en place et de visser la planchette sur le châssis:

L'installation des roues sur les moteurs est très simple, car l'axe des moteurs à un profil en D, et il y a un trou de la forme correspondante au centre de la roue.

Il suffit donc d'enficher la roue sur l'axe. On peut donc facilement installer et changer les roues facilement:

Le moteur est soudé à des fils, avec au bout un connecteur femelle de "jumper wire". J'ai simplement pris deux câbles femelle-femelle, et je les

ai coupés en 2. Il suffit de dénuder le bout coupé, et de le fixer sur le moteur, idéalement, en le soudant.

Partie électronique

Passons maintenant à l'installation des divers éléments électroniques sur l'autre face du châssis.

La breadboard principale contient le régulateur de tension, avec les fils partant vers les batteries, et le jack de sortie,

le MCP23017, le MCP3008, et les deux L293D. Des câbles partent également vers les moteurs, les capteurs, et le Raspberry Pi.

Sur l'image de gauche, on voit l'ensemble de la breadboard, et sur celle de droite, on peut voir la méthode utilisée pour

mettre en parallèle les deux L293D : des fils rigides connectent les pattes d'une puce à celle de l'autre. J'ai utilisé une bobine

de fil de fer gaîné pour réaliser ces connections.

Pour fixer la plaque, j'ai utilisé 4 vis à bois, vissées directement dans le bois du châssis. Elles sont vissées de part et d'autre des ergots sur le haut

de la breadboard, de façon à la caler horizontalement. Deux vis en bas bloquent la breadboard dans le sens vertical, de sorte que maintenant celle ci

ne bouge plus :

On fixe maintenant le Raspberry Pi lui même sur le châssis, en vissant celui ci avec deux vis, en passant par les deux trous prévus à cet effet sur le Raspberry Pi:

On peut maintenant fixer le logement des batteries AA sur le châssis. On notera que sur les 6 emplacements, l'un d'entre eux ne contient pas de batterie,

mais un fil à la place, ce qui permet d'obtenir du 6V au lieu d'avoir du 7.2V. Le logement est vissé au châssis par deux vis, par les trous prévus à cet

effet:

Il nous faudra également un câble jack vers USB et un câble micro-USB:

Cependant, il est également possible de couper le câble USB, et d'accéder directement aux fils +5V et masse. Dans ce cas, l'adaptateur USB-PowerJack et le jack power mâle sont superflus.

Les capteurs

Passons maintenant à l'installation des capteurs.

Le capteur à ultrasons est simplement vissé sur la face avant du châssis, et les capteurs de contact sont vissés sous le châssis.

Les boutons poussoirs qui servent de détecteurs de contact possèdent des trous par lesquelles peuvent passer les vis servant à les fixer :

Le tout en place

On peut voir sur les images ci dessous la disposition des éléments lorsque l'ensemble est en place:

On note sur la photo de droite que les diodes d'état, et la diode de la clé wifi sont visibles depuis le dessus du robot.

Option Webcam

On peut également ajouter une webcam, sur l'un des ports USB. Pour cela j'utilise une petite équerre en acier, vissée sur

le châssis, sur laquelle la webcam s'accroche :

A ce moment, quand tout est installé, le robot est opérationnel, et il ne reste plus qu'à le programmer!

Nous verrons donc cela dans le prochain tutoriel, ou nous décrirons la façon de programmer le robot, ainsi que quelques algorithmes.

Des codes sources fonctionnels seront également fournis.

J'espère que ce tutoriel vous aura permis de voir que le montage d'un robot n'est pas si compliqué que ce à quoi on s'attend. De plus, celui ci n'est pas le "robot minimal" qu'on pourrait faire,

il est donc possible de faire plus simple.

A bientôt pour la suite :)

[syris]

Matinal le sky99 !

Très beau tuto. Décidément j'adore ce topic!

[pierrot421]

Super tuto sky merci pour le temps passé a bien détailler

[Yaug]

Salut Sky.

Bon, je me suis acheté de quoi commencer un robot :)

Je me suis pris :

- 1 Raspberry Pi pour ne pas jongler entre domotique et robotique (et il m'en faut un troisième pour faire un media center )

- 4 moteurs 120:1

- 2 kits de 2 roues de 70*8

- 1 ball caster de 1/2 pouce (ça peut servir)

J'ai pris tout ce qui est raspberry et connexion chez snootlab (je suis déjà passé par eux et j'en suis très content), et tout ce qui est robot chez alpha crucis.

J'en ai eut pour 43 euros chez crucis, alors que si j'étais passé par polulu, j'en aurais eut pour 10€ de plus (j'ai fais le calcul) à cause des frais de port.

Bouarf.

J'avais déjà commandé 3 step-up/step-down chez polulu la semaine dernière (arrivés aujourd'hui), et j'ai une poignée de L293D commandés sur ebay.

Mon projet (nom de code Pongo)

Dans un premier temps, je souhaiterais réaliser un robot à 4 roues motrices programmé à l'avance avec une séquence de déplacement.

Une fois que cela fonctionnera, j'ajouterais alors sans doute une détection des obstacles frontaux.

C'est avant tout un projet qui doit me permettre de découvrir la robotique, en me confrontant à des problèmes basiques et à apprendre à utiliser les moteurs et autres capteurs.

Mes questions

- Est ce qu'il me faut 2 puces L293D par moteur ?

- Est ce que tu identifies des trucs qui pourraient me poser problèmes ?

- Tu as des conseils ?

Bref, j'ai hâte de commencer à faire joujou !

[sky99]

J'ai déjà acheté 3-4 fois des trucs chez Snootlab. Pas de FDP si vous êtes sur Toulouse, s'ils ont en stock, tu vas chercher ton matos le lendemain chez eux, et c'est plutôt cool de parler avec eux de ce qu'ils font, même s'ils on une préférence pour l'Arduino. Du coup je vais me ruer sur le pack robot dès que vous arrivez à le sortir.

En tout cas Sky99, je te remercie pour tous tes tutos, je me suis mis à l'élec sur RPi grâce à toi, et j'adore, j'apprends plein de trucs Continue comme ça !

Maintenant que je commence à gérer les bases, je vais tenter de mettre tout ça ensemble pour voir comment je me démerde. Et une fois que j'aurai le pack robot, je vais tenter le mien

Je vais essayer de voir ça avec eux au plus vite!

Et dès que tu as un truc qui roule n'hésite pas à poster, car c'est la que le topic deviendra réellement intéressant, quand on pourra comparer des configurations/idées, etc...

Matinal le sky99 !

Très beau tuto. Décidément j'adore ce topic!

Super tuto sky merci pour le temps passé a bien détailler

Merci à tous les trois des encouragements, ça motive à continuer :)

Salut Sky.

Bon, je me suis acheté de quoi commencer un robot :)

Je me suis pris :

- 1 Raspberry Pi pour ne pas jongler entre domotique et robotique (et il m'en faut un troisième pour faire un media center )

- 4 moteurs 120:1

- 2 kits de 2 roues de 70*8

- 1 ball caster de 1/2 pouce (ça peut servir)

J'ai pris tout ce qui est raspberry et connexion chez snootlab (je suis déjà passé par eux et j'en suis très content), et tout ce qui est robot chez alpha crucis.

J'en ai eut pour 43 euros chez crucis, alors que si j'étais passé par polulu, j'en aurais eut pour 10€ de plus (j'ai fais le calcul) à cause des frais de port.

Bouarf.

J'avais déjà commandé 3 step-up/step-down chez polulu la semaine dernière (arrivés aujourd'hui), et j'ai une poignée de L293D commandés sur ebay.

Mon projet (nom de code Pongo)

Dans un premier temps, je souhaiterais réaliser un robot à 4 roues motrices programmé à l'avance avec une séquence de déplacement.

Une fois que cela fonctionnera, j'ajouterais alors sans doute une détection des obstacles frontaux.

C'est avant tout un projet qui doit me permettre de découvrir la robotique, en me confrontant à des problèmes basiques et à apprendre à utiliser les moteurs et autres capteurs.

Mes questions

- Est ce qu'il me faut 2 puces L293D par moteur ?

- Est ce que tu identifies des trucs qui pourraient me poser problèmes ?

- Tu as des conseils ?

Bref, j'ai hâte de commencer à faire joujou !

- Est ce qu'il me faut 2 puces L293D par moteur ?

Non, en fait le L293D gere deux caneaux, avec une puissance de 600mA chacun. Chaque canal sert à alimenter un moteur, ce qui veut dire que les spécifications officielles indiquent qu'on peut gerer deux moteurs de 600mA de conso maxi par L293D.

Si tu as pris des pololu plastic gearmotors 120:1, je lis sur les spécifications qu'ils ont un "stall current" de 800mA, c'est à dire qu'il pourront consommer au MAXIMUM

800mA, le stall current étant le courant que peut consommer le moteur quand la roue est bloquée, la situation ou il va demander le plus pour fournir tout son couple.

Donc en pratique, tes moteurs demandent 200mA de plus que ce que peut fournir le L293D. Toutefois, ça peut passer, si tu t'assures que les moteurs ne soient pas bloqués.

Une solution est de mettre un rad sur les puces,ce qui peut permettre de tirer plus de puissance, sans abimer la puce, mais on sort des spec, et je sais pas comment

évaluer la taille du rad et le gain à espérer. Toutefois pour des tests, tu peux largement te contenter d'un L293D pour deux moteurs, tant que les moteurs ne sont pas bloqués

(le robot essaie d'avancer face à un mur, par ex).

Donc en pratique, ça veut dire qu'il te faudra au moins 2 L293D, un pour les roues avant, l'autre pour les roues arrière. (ou ça doit etre possible de faire les roues de droite et celles de gauche).

Une autre solution est de faire du "piggyback", c'est à dire d'empiler deux puces l'une sur l'autre et de les souder ensemble, cela permet d'économiser l'espace, en doublant presque la puissance disponible. EN réalité les deux puces chaufferont ensemble, donc on ira un peu moins loin que la somme des deux puces séparées, mais c'est une solution que les gens adoptent.

Bref, pour être parfaitement dans les spécifications, pour toi je dirais donc qu'il faut 4 puces pour avoir assez de puissance, mais rien n’empêche de commencer avec 2 pour les tests. Mais en configuration autonome, ou tu laisse le robot se balader sans surveillance, 4 puces seront préférables, car tu sais que dans cette config, les puces ne risquent pas de griller, même si le robot vide sa batterie à essayer d'avancer contre un mur.

Comme trucs à problèmes, pas grand chose non. L'approche 4x4 est très intéressante, et tu as pris les mêmes moteurs, et les mêmes roues, donc normalement pas de souci d'équilibrage. L'intérêt c'est principalement d'éviter la roulette, qui pose des problèmes pour le franchissement. Avec ta configuration tu pourra à mon avis faire rouler le robot sur du bitume, ou du sol irrégulier sans trop de soucis.

En pratique, le couple de traction/propulsion disponible est doublé, ce qui veut dire que tu peux porter une charge doublée/pousser des obstacles deux fois plus gros, mais par contre pas aller deux fois plus vite.

EN revanche, il y a deux inconvénients : les moteurs ne sont pas parfaitement identiques, donc il y a de légères différences de vitesse. Dans mon cas, ça fait un robot qui a tendance à tourner un peu sur la gauche. Dans ton cas, ce sera intéressant de faire des essais pour essayer d'avoir un truc équilibré, du genre les deux plus "lents" devant, et les deux plus "rapides" derrière", ce qui évitera au robot de tourner légèrement quand il va en ligne droite.Par contre du coup, c'est de la puissance qui sera perdue, gaspillée, sur les différences de rythme. Dans mon cas, je perds de l'energie car mon robot ne fait pas une ligne droite, donc potentiellement un chemin plus long. Dans le tien, ça veut dire que la différence de vitesse entre les roues avant et arrière sera perdue en frottements par exemple.

Deuxième point, pour les rotations. Avec des roues fixes, pendant les rotations, les roues restent parallèles, donc on perd un peu de puissance.

Dans tous les cas, ce n'est pas nécessairement critique, mais c'est des paramètres qui sont intéressants à considérer si tu essaie de calculer l'autonomie du robot.

Par contre du coup il est important que chaque train de roues reçoive les mêmes instructions, je dirais donc que tu peux même te contenter d'avoir simplement 2 GPIO pour commander les roues de droite, et deux GPIO pour les roues de gauche (plus un ou deux GPIO pour les commandes "enable"), de façon à être certain d'envoyer les mêmes commandes aux roues avant et arrière de chaque coté.

Sur l'autonomie de ton robot :

On pourrait se dire de prime abord :deux fois plus de moteurs, donc conso doublée, et donc autonomie divisée par deux. Mais pas nécessairement. Chaque moteur a une conso en "free run" de 80mA, donc si les moteurs n'ont pas de charge, oui tu double la conso, en passant de 160mA au repos à 320. Maintenant en charge, ça peut être different.

Mon robot à deux roues motrices, s'il a la même masse que le tien, demandera une énergie donnée pour bouger. Donc disons qu'il me faut 300mA par moteur pour avancer, soit 600mA au total. Dans ton cas, chaque moteur pourrait consommer deux fois moins, puisque la charge est répartie. Ce qui fait que tu pourrais te retrouver à 150mA par moteur, soit 600mA au total, comme pour moi.

Si on ajoute 10% de conso pour les pertes dues au frottement par ex, tu te retrouverait à une conso environ 10% plus élevée (exemple à la louche).

Du coup tu n'as pas nécéssairement moins d'autonomie, tant que nos moteurs fournissent plus que la puissance minimale, et tant qu'ils ne sont pas bloqués.

Dans les cas "moteur en roue libre" et "roues bloquées", tu consommes en effet deux fois plus. La différence étant que ton 4x4 continuera à avancer pour des obstacles presque deux fois plus lourds que les miens.

AU passage, mon ball caster génère également de la friction, dans les lignes droites et sur sol irregulier. SI ça se trouve, tu rattrapes la puissance perdue sur ça!

Comme conseils, je te dirais d'y aller par étapes. Tu fais le câblage d'une puce, tu branches les moteurs, et sans mettre les roues (ou avec les roues, mais sur un support pour qu'il ne se barre pas), tu teste la marche avant et arrière de chaque moteur.

Deuxième point : si tu as la possibilité de mettre des connecteurs genre "jumper wire" pour connecter les moteurs aux pattes du L293D, je te le conseille, car ça évite d'avoir a faire des bidouilles quand on se rend compte que le sens d'alimentation n'est pas bon. Avec un système facile à débrancher, il suffit d'inverser le sens de branchement des fils, et zou, pas de code à modifier ou autre.

A partir de la, bah "yapuka", il suffit de câbler tous les moteurs, d'écrire 5 fonctions:

• avancer;

• reculer;

• tourner à gauche;

• tourner à droite;

• arrêter les moteurs.

vérifier que les roues tournent bien dans le bon sens, et il devient possible de tester la bestiole :)

A savoir une chose : comme les GPIO changent d'état pour l'état X jusqu'à ce qu'on les change à nouveau, la programmation se fait souvent sur les timings.

En gros on ne fera pas une boucle du genre while(...){avancer();}, mais plutôt avancer(); delay(x); stop(); si on veut avancer d'un petit bout. Une fois qu'on fait avancer(); le robot avance jusqu'à nouvel ordre. Si le programme plante ou est quitté il continue à faire ce qu'il faisait.

Sur la construction même, à mon avis il y a deux choses importantes.

Pour le châssis, il faut s'assurer qu'on à des cotés bien parallèles, pour les cotés gauche et droit. ça permet de se caler sur les bords pour bien aligner les moteurs.

De même, n'hésite pas à tracer sur ton châssis des lignes perpendiculaires aux bords pour avoir la même position pour les roues de avant, idem pour les roues arrières.

Logiquement, plus tes roues avant et arrière seront proches, plus leurs trajectoires seront proches quand tu tournes. Donc moins de pertes pour les rotations. D'un autre coté, ça veut dire moins de stabilité si le chassis est plus grand en longueur que l'écart entre les roues. D'autre part, ça n'intervient que quand tu tournes, donc ce n'est peut être pas très important. Mais si tu as un système qui te permet de dévisser les moteurs, ça peut être chouette à tester :)

Pourquoi pas une plaquette intermédiaire pour chaque train de roues, comme ça tu es sur de déplacer les deux au même niveau si tu fais des tests ^^

Le second point, c'est d'essayer d'équilibrer les masses. L'élement le plus lourd, c'est le bloc de batteries. Idéalement il devrait être centré, de sorte que la masse soit équitablement répartie sur les 4 moteurs. Sur la seconde version de mon robot R.Cerda, le bloc batteries est à gauche. Et le robot tourne un peu à gauche. Ce n'est peut être pas un hasard!

Maintenant c'est assez léger, donc bon!

Malgré tout ce que j'ai dit plus haut, je trouve qu'on s'en sort bien en prenant les pièces, et en les montant "comme on le sent", je l'ai fait pour certains prototypes, et ça marchait à peu près. Voyez sur ma chaine youtube le

, dont les moteurs n'étaient sans doute pas équilibré, et dont l'ajustement des pièces était très aproximatif. Pourtant il se débrouillait... Et je n'avais même pas de ball caster, c'était un boulon arrondi. Les moteurs étaient deux moteurs de chariot de lecteur CD, bidouillés, ils n'étaient pas bien alignés horizontalement et verticalement, mais le robot fonctionne :)

A mon sens, les points importants, c'est de:

• vérifier que les roues font bien ce qu'on attend d'elles, surtout si tu teste avec moins de puces que nécessaire,

• avoir les cotés du châssis bien parallèle pour bien placer les moteurs

• prévoir un chassis un peu grand, car au début on ne sait pas toujours ou on va mettre des trucs, et c'est chiant de devoir faire un bidule à étage quand il faut tripatouiller les connections. Sur le second chassis de R.Cerda, j'ai pris une plus grande plaque, et tout est sur un étage, ce qui me permet également de changer les batteries AA facilement.

• Vérifier le sens des connections sur la partie électrique (pour les GPIO s'ils sont pas au bon endroit c'est pas bien grave. Pour l'alim, c'est plus gênant :) )

Et juste une petite remarque :

comme capteurs de contact, tu peux voir que pour ma part j'ai des switchs spéciaux, avec un levier. Mais rien n'interdit d'utiliser des boutons poussoirs normaux! à partir du moment ou il y en a deux sur l'avant qui permettent la détection gauche droite, ça permet d'éviter les obstacles, et permet un mode autonome, sans nécessiter de convertisseur analogique, avec seulement deux GPIO, et pour moins de 2€ de matériel (deux boutons poussoirs, deux résistances, et c'est bon!)

Après tu peux aussi mettre une clé wifi, une webcam, et faire une interface de contrôle à distance :) Ou même décider de faire du pathfinding en utilisant la webcam, avec OpenCV par ex :)

D'ailleurs, je ferai un post sur le "robot minimum", celui que j'ai présenté ayant quelques éléments de plus qui sont utiles, sans trop en rajouter, mais n'étant pas le plus simple possible.

Bref, amuses toi bien, et n'hésite pas à nous présenter Pongo quand il sera né :)

PS : j'appelle mes robots R.quelquechose à chaque fois, c'est une référence à Asimov. Dans son univers, il y a plein de robots, et les hommes ont la particule M., les femmes, Mme, et les robots R. pour Robot. Je n'en dis pas plus sur l'univers d'Asimov, lisez les bouquins du cycle des robots, et du cycle de fondation pour en apprendre plus :)

[Yaug]

Déjà lu quasi tout Asimov, ne t'en fais pas :)

Merci pour tes retours en tout cas.

J'ai hâte de recevoir tout ça pour commencer à tester si je trouve suffisamment de temps libre.

Petite question au passage, sur mon topic sur le forum Robot maker, on me dit ceci :

Et bien tout faux!

Un pour les deux moteur sera suffisant =)

Dans un L293D tu as deux pont en H qui permettent chacun de délivrer environ 600mA en continu mais qui peuvent monter à 1200mA en pointe

en prenant 4 L293D tu aurais de quoi piloter 8 moteur

Après si tu veux jouer la sécurité tu peux prendre 2 L293D que tu soude l'un au dessus de l'autre.

Je n'arrive pas à saisir si vous me dites la même chose tous les deux.

Concernant le châssis, pour le moment je ne me suis pas trop posé la question, même si j'ai envie d'un truc assez compacte et donc plus à étages. Mais dans la pratique, on verra :)

[sky99]

Déjà lu quasi tout Asimov, ne t'en fais pas :)

Merci pour tes retours en tout cas.

J'ai hâte de recevoir tout ça pour commencer à tester si je trouve suffisamment de temps libre.

Petite question au passage, sur mon topic sur le forum Robot maker, on me dit ceci :

Et bien tout faux!

Un pour les deux moteur sera suffisant =)

Dans un L293D tu as deux pont en H qui permettent chacun de délivrer environ 600mA en continu mais qui peuvent monter à 1200mA en pointe

en prenant 4 L293D tu aurais de quoi piloter 8 moteur

Après si tu veux jouer la sécurité tu peux prendre 2 L293D que tu soude l'un au dessus de l'autre.

Je n'arrive pas à saisir si vous me dites la même chose tous les deux.

Concernant le châssis, pour le moment je ne me suis pas trop posé la question, même si j'ai envie d'un truc assez compacte et donc plus à étages. Mais dans la pratique, on verra :)

Eh bien techniquement, il a raison, le L293D peut fournir 1200mA PAR CANAL , mais uniquement EN POINTE. Cela signifie qu'il est conçu pour fournir 600mA par moteur en régime continu au maximum, mais qu'il peut fournir 1200mA en pointe pendant un court instant. L'intérêt principal, c'est que si tu as un obstacle à franchir qui utilise le moteur à fond, le L293D peut fournir de quoi alimenter un moteur consommant 1200mA par canal, donc deux moteurs pour un total de 2400mA, pour un temps court.

Maintenant pourquoi je parle de mettre deux puces pour deux moteurs?

SI le robot avance, et se coince face à un mur, il n'a aucun moyen de savoir qu'il n'avance pas. Dans ce cas la, tes moteurs pompent au maximum sur chaque canal, et prendront 800mA, soit plus que les 600mA par canal. Donc oui, le L293D les fournira. Mais si ça dure, il surchauffera, et va griller.

Les spécifications parlent bien de 600mA en régime continu. Les 1200mA doivent être vus comme un "boost" temporaire disponible, un peu comme l'overclocking des CPU modernes. Cette puissance est disponible temporairement, par exemple pour franchir un obstacle, ou au démarrage.

Maintenant le régime de croisière c'est 600mA par canal. Donc si le robot se bloque, et ne se rend pas compte qu'il n'avance pas, les moteurs tireront 800mA au lieu de 600mA. La puce va surchauffer, et peut bruler au bout d'un moment. Sur quelques secondes ça devrait tenir, mais comment savoir au bout de combien de temps ça n'ira plus?

Ta question était "faut il deux L293D par moteur", et en effet non. Chaque L293D peut piloter deux moteurs, de 600mA chacun soit 1200mA au total en croisière. Du coup on peut imaginer mettre les deux canaux en parallèle pour faire une sortie de 1200mA, et ainsi contrôler un moteur avec un L293D. ça revient à faire ce que j'indique : utiliser deux L293D pour deux moteurs :)

L'autre solution c'est de refroidir les puces, et se limiter à 2 puces (avant, arrière). Un rad sur les puces, ou pourquoi pas un petit ventilo 4cm qui souffle directement dessus (sans rad) pour dissiper les 200mA excédentaires consommés.

Bref, en pratique si ton robot est sous ta surveillance, tu peux t'en sortir avec deux puces au total, mais si il risque de se coincer sur des obstacles pour des durées non négligeables, il vaut mieux assurer en doublant les puces, ou alors en refroidissant celles ci.

Dans mes vidéos tu peux voir que je laisse parfois mon robot se coincer dans les obstacles, car je sais que les puces ne vont pas griller.

Sinon pour la compacité, tu en as déjà pour au moins 15cm de long, vu que tu dois aligner deux roues de 7cm ^^

Mon premier proto était plus compact (environ 15*18 au lieu de 20*20) et du coup je devais enlever l'étage supérieur pour accéder aux batteries à chaque fois...

Remarque rien n’empêche de mettre les batteries en haut, mais je préfère mette les éléments lourds en bas, pour abaisser le centre de gravité ^^

Une solution c'est de mettre les batteries sous le robot, à la manière d'une voiture téléguidée... Dans mon cas, j'avais la flemme de faire des découpes pour ça ^^

Mais certainement, pour une version ultérieure, j'y penserai!

Au passage, si tu as moyen d'avoir des "pare chocs" devant les roues, c'est aussi bien, pour le mien, il arrive que les roues se coincentn sur un obstacle alors que le robot est passé... Je pense rajouter des structures triangulaires sur le coté, de sorte qu'au lieu de tomber sur une surface perpendiculaire, l'obstacle glisse le long d'une pente qui dévierait un peu le robot. D'ailleurs avec un avant triangulaire tu peux t'éviter bien des problemes ^^

[titou190]

Je vais bientôt pouvoir venir jouer avec vous : mon Raspberry Pi vient d'être expédié

Par contre je vais avoir beaucoup de lecture et de boulot avant de fabriquer C3PO xD

Topic très intéressant en tout cas, je suis impatient de pouvoir suivre les tutos

[sky99]

Je vais bientôt pouvoir venir jouer avec vous : mon Raspberry Pi vient d'être expédié

Par contre je vais avoir beaucoup de lecture et de boulot avant de fabriquer C3PO xD

Topic très intéressant en tout cas, je suis impatient de pouvoir suivre les tutos

C3PO certes, ça prendra du temps. Mais une sorte de R2D2 sans les lasers, ça peut aller très vite :)

N'hésite pas à me contacter si tu as des questions spécifiques :)

[Yaug]

Bonjour,

Un double tuto aujourd'hui : la lecture d'une sonde DHT22 avec un arduino et avec un raspberry pi.

Comme d'habitude, ces 2 articles se trouvent sur mon site. Article pour l'arduino, article pour le Raspberry pi.

Montage avec un Arduino

Bonjour à tous,

Aujourd’hui nous allons attaquer un grand classique : Lire une sonde DHT22 / AM2303 (qui permet de relever la température et l’humidité), avec une carte Arduino Uno.

Ingrédients

Pour réaliser cette recette il vous faudra :

• Une carte arduino
  
• Une sonde DHT22
  
• Une plaque de prototypage
  
• Quelques câbles mâles / mâles
  

Et c’est tout

Présentation de la sonde

La sonde DHT22 est une des sondes les plus classiques lorsque l’on souhaite mesurer une température avec un minimum de fiabilité. Évitez d’utiliser la DHT11 qui ne vaut pas le coup même si elle est moins chère. Elle est moins précise, et ne prend pas les températures négative. A éviter donc !

Notre sonde DHT22 a elle les spécifications suivantes :

• Entre 3 et 5V en entrée
  
• Lecture de l’humidité entre 0 et 100% avec une précision allant de 2% à 5%
  
• Lecture de la température de -40°C à 80°C avec une précision d’environ 0.5°C
  

Vous trouverez dans la datasheet l’ensemble des spécifications techniques.

Montage

Passons maintenant à la partie marrante : brancher des fils et se planter Pour lire cette sonde, il faut faut effectuer les branchements suivant :

Montage Arduino et DHT22

La sonde possède 4 pattes, mais la 3 ème ne nous sert pas. On relie donc les pattes de la manière suivante :

1. Vers l’alimentation 3,3 Volts
   
2. Vers un pin de donnée
   
3. On laisse vide
   
4. Vers un pin GRD
   

Et il faut bien évidemment mettre une résistance de 4700 Ohm à la broche 2 et la relier ensuite à l’alimentation (référez vous à mon schéma pour l’exemple). Voila, montage terminé, c’est on ne peut plus simple.

Le code

Maintenant que notre montage est complet, on va désormais s’occuper de la partie code pour récupérer les informations que l’on recherche : la température et l’humidité.

Heureusement pour nous, il existe sur le net plusieurs bibliothèques pour exploiter les données récoltées, nous allons ici exploiter celle d’Adafruit pour utiliser notre sonde. Téléchargez le code sur le github dédié.

Pensez à modifier cette ligne pour renseigner le pin que vous avez utilisé.

#define DHTPIN 2

Vérifiez le code, puis compilez le et téléversez le sur votre carte arduino. Et hop, cela fonctionne.

Ouvrez le serial monitor et vous obtenez un affichage dans ce genre :

Affichage serial de la lecture du DHT22

Et voila, le tour est joué !

Je vous invite à faire un tour dans la bibliothèque fournie par Adafruit, notamment dans le fichier DHT.cpp pour comprendre comment fonctionne la lecture de la sonde.

N’hésitez pas non plus à poser vos questions.

Montage avec le Raspberry Pi

Bonjour,

Nous allons maintenant lire une sonde DHT22 à l’aide du Raspberry Pi afin de relever la température et l’humidité. Vous allez voir, c’est on ne peut plus simple. Nous allons utiliser pour cela nous allons utiliser le matériel suivant :

• Un Raspberry Pi
  
• Une sonde DHT22
  
• Une résistance de 4700 Ohms
  
• Quelques câbles de connexion (mâle/mâle et mâle/femelle)
  

Et c’est tout. C’est tout aussi simple que le montage pour l’arduino.

Pourquoi choisir une sonde DHT22 par rapport à une DS18B20 ? Certe la DS28B20 ne coute quasi rien, mais du coup, elle est moins complète puisqu’elle ne permet de pas de relever l’humidité.

Le montage

Avec aussi peu de composants, c’est on ne peut plus facile. Voici le schéma du montage :

Montage Raspberry Pi et DHT22

Facile encore une fois ! Quand je vous disais que c’est le même montage que pour l’arduino…

Les branchements sont les suivants :

• Le Pin 1 de la sonde va vers l’alim 3,3V du Raspberry
  
• Le Pin 2 va vers un pin du Raspberry Pi (le pin 4 dans mon exemple).
  
• Le Pin 3 … ne sert à rien
  
• Le Pin 4 va vers le Ground du Raspberry Pi
  
• Une resistance (de 4700 ohm à 10K Ohm) se branche entre le pin 2 et l’alim (à connecter en premier, avant la sortie vers le pin 4 du raspberry pi).
  

Voila, le montage est complet. Si vous il ne fonctionne pas, pensez à vérifier votre résistance. Il m’est arrivé d’en griller.

Attention : Ne pas connecter au 5V ! Cette sonde est adaptée au 3,3V donc soit vous grillez votre sonde, soit vous grillez votre résistance, mais dans tout les cas, ça ne va pas le faire …

Le code

Encore une fois, on va exploiter les librairies mises à disposition par adafruit.

Commencez par vous créer un répertoire de travail pour les sondes adafruit :

mkdir adafruitcd adafruit

Voila, maintenant, on télécharger les librairies adafruit :

wget https://github.com/a...hive/master.zipunzip master.zip

Et hop, vous avez récupéré l’ensemble des librairies utiles d’adafruit. Allez dans le dossier spécifique au DHT :

cd Adafruit-Raspberry-Pi-Python-Code-master/Adafruit_DHT_Driver/

voila, vous êtes maintenant au bon endroit pour lire votre capteur. Si votre branchement est correct, exécuter alors la commande suivante :

sudo ./Adafruit_DHT 22 4

Le premier paramètre désigne le type de capteur (ici un 22), le second désigne le pin utilisé sur votre Raspberry Pi. Vous obtenez normalement cet affichage :

Using pin #4Data (40): 0x0 0xfa 0x0 0xee 0xe8Temp =  23.8 *C, Hum = 25.0 %

Et voila !

Ça c’est si tout se passe bien ! Ce n’est pas ce que j’ai rencontré. Moi, à la place j’ai eut ça :

sudo: unable to execute ./Adafruit_DHT: No such file or directory

Ettttt ouiiiii…. c’est la loose !

Heureusement voici une solution fiable (encore une fois donnée par Adafruit). Pour nous en sortir on doit recompiler la source d’adafruit en ajoutant une autre bibliothèque : bcm2835, une bibliothèque C de bas niveau permettant d’interagir correctement avec la sonde DHT22.

Dans un premier temps on récupère la bibliothèque et on l’ajoute à notre système :

$ wget http://www.open.com....2835-1.8.tar.gz$ tar -zxvf bcm2835-1.8.tar.gz$ cd bcm2835-1.8$ ./configure$ make$ sudo make install

Ensuite, on revient dans le répertoire Adafruit_DHT_Driver, puis on recompile la source d’adafruit en ajoutant la librairie :

[b]gcc Adafruit_DHT.c -l bcm2835 -std=gnu99 -o Adafruit_DHT[/b]

On reprend ensuite là où on avait ajouté :

sudo ./Adafruit_DHT 22 4

Et hop ! ça fonctionne

Using pin #4Data (40): 0x0 0xf7 0x0 0xed 0xe4Temp =  23.7 *C, Hum = 24.7 %

Si votre montage ne fonctionne toujours pas, là…. vous avez un problème. Tester votre DHT22 avec l’arduino si vous en avez un, essayer de changer de résistance.

N’hésitez pas à poser vos questions si ce n’est pas assez clair.

Amusez vous bien.

[sky99]

Salut! Super tuto, et en plus avec la version Arduino, ce qui m'arrange car c'est typiquement le genre de capteurs que je collerais sur une puce d'Arduino (ou un Attiny) pour faire les mesures, en relayant le tout au pi par un moyen quelconque!

Je rajoute le lien à l'index.

Pour ma part, j'ai le DHT11 (que je n'ai pas encore testé), et les températures négatives ne me concernent pas, il fait toujours entre 15 et 35 en Guadeloupe (et encore 15°... ça doit être exceptionnel, de nuit, avec du vent, et en hauteur ). par contre la plage d'humidité mesurée est également plus importante sur le DHT22 d 'après les specs, puisque celui ci mesure tous les taux, alors que le DHT11 mesure de 20 à 80%.

Mais bon j'ai pris ce capteur pour tester, si jamais je me monte une autre station météo (j'ai déjà une station météo commerciale... Par contre rien ne dit que je n'en ferai pas

une moi même pour avoir du open Hardware et de l'open source dedans :) ), je prendrai le 22 ^^

Il faut vite que je choppe des émetteurs/récepteurs radio pour pouvoir faire des modules de mesure indépendants!

[Yaug]

En parlant de station météo...

Voici l'état de la mienne :

Je suis en train de bosser sur le prototype.

Une fois que j'aurais terminé, je programme tout sur une puce atmega, j'ajoute une alim externe, et je crée un boitier.

Par contre.

J'ai un problème, tu pourras peut être m'aider Sky.

J'arrive à lire sans problème ma sonde BMP085 quand je ne fais que ça. Mais une fois au milieu de tout le montage, là... impossible d'avoir quelque chose de correct.

J'ai l'impression que j'ai un "décalage temporel" du fait de tout les traitements à gérer et je n'arrive plus à lire la sonde.

ça te dit quelque chose ?

[sky99]

...

Non, je n'ai jamais eu ce problème jusqu'ici. Ceci dit sur l'Arduino je n'ai jamais essayé d'utiliser un protocole genre I²C. Peut être que le problème vient des

communications, si le protocole demande beaucoup de transferts?

Pour ma part je n'ai jamais rencontré ce problème, mais ça me semble plausible, vu que l'Arduino n'est pas multithreadé.

Jusqu'ici sur l'Arduino je n'ai testé que des sondes analogiques...

Si tu trouves la solution dis le moi, c'est bon à savoir :)

[sky99]

Programmation d'un robot Raspberry Pi R.Cerda

Aujourd'hui, vient la conclusion des tutoriels sur la construction d'un robot de type Cerda, avec la partie programmation. Nous avons déja vu comment choisir les composants du robot, les schémas fonctionnels et électroniques de R.Cerda, et les instructions pour assmembler les pièces et monter un R.Cerda fonctionnel. Nous verrons trois algorithmes, du plus simple au plus avancé. Cela devrait vous permettre d'avoir une base pour programmer votre robot comme vous le souhaitez, et pourquoi pas quelques idées :)

Commençons tout de suite, en rentrant dans le vif du sujet. Ce robot utilise le MCP23017 pour commander les L293D qui à leur tour commandent les moteurs. J'ai donc choisi python pour écrire le programme des robots, puisque c'est sur cette base que nous avons vu l'utilisation du MCP23017.

En premier lieu, voici le lien vers le GitHub ou je met les divers fichiers relatifs au code du robot Cerda.

Dans ce dépot, vous trouverez divers fichiers, donc la classe I2C d'Adafruit, et la classe permettant de gérer le MCP23017.

Assurez vous d'avoir ces deux fichiers dans le répertoire contenant les fichiers de votre robot, ils sont nécéssaires pour son fonctionnement,

et doivent être importés dans le script du programme de votre robot.

Vous noterez également un script robotStop.py, qui sert simplement à arrêter les moteurs du robot. Sur mon raspberry pi, j'ai fait un alias de ce script vers la commande stop, ce qui fait que je peux arrêter le déplacement du robot en tapant stop dans un terminal, n'importe ou.

Divers scripts sont présents, pour tester divers éléments :

• Un script pour tester le capteur à ultrasons;
  
• Un script pour tester les détecteurs de contact;
  
• Un script pour tester le balayage d'un servomoteur non inclus dans la version actuelle de R.Cerda (et utilisant un ATTiny85).
  

N'hésitez pas à tester vos capteurs avant de lancer le robot, pour vérifier si tout va bien. J'intégrerai également ultérieurement des scripts pour tester les moteurs.

Passons maintenant au programme principal du robot lui même. Voyons d'abord vite fait l'algorithme :

dans une boucle infinie, on répète les instructions suivantes :

Lire la distance mesurée devant le robot par le capteur à ultrasons.

Si cette distance est inférieure à 8 pouces, on recule.

Sinon, si cette distance est inférieure à 16 pouces, on tourne,

Sinon, on avance.

Et c'est tout! Ce simple algorithme suffit déjà à permettre au robot d'éviter des obstacles!

Cet algorithme est

implémenté dans le programme r1.py, dont la source se trouve sur le GitHub.

Je vais détailler un peu le code. Au début, vous verrez tous les "import", qui récupèrent les fonctions nécéssaires.

En dessous, vous retrouverez notre fonction "readadc", que nous avons vue avec le

MCP3008 (le tuto sur cette puce est disponible ici), qui nous permet de lire une entrée analogique (ici le capteur à ultrasons) sur les 8 que propose le MCP3008. Voyez donc ces deux liens pour plus de détails sur le sujet. En dessous viennent les variables définissant les broches utilisées pour le SPI; je vous renvoie encore aux précédents tutoriels pour plus d'explications. SI vous avez suivi les schémas de montage de R.Cerda, il n'y a rien à changer ici.

Vient ensuite le corps du programme à proprement parler. Vous verrez alors une série de fonctions, dont la fonction "readDistanceInch", qui permet de récupérer la distance en pouces plutot que la valeur brute. SI vous utilisez un autre capteur, il faudra adapter (ou bien utiliser la valeur brute, en faisant des essais). Les fonctions suivantes servent à commander directement le robot :

def moveForward(m1a,m1b,m1e,m2a,m2b,m2e):
mcp.output(m1a, 1)
mcp.output(m1b, 0)
mcp.output(m1e, 1)[/left]

mcp.output(m2a, 1)
mcp.output(m2b, 0)
mcp.output(m2e, 1)

Cette fonction par exemple permet mettre les broches de commande du moteur 1 à 1 et 0, la broche enable à 1 pour activer ce moteur, et idem pour le moteur 2. J'ai fait ces fonctions, car si le câblage change, il suffira de modifier les valeurs dans ces fonctions plutot que dans le main. De la même manière, on a une fonction pour reculer, arrêter les moteurs, tourner à gauche, et à droite.

Cette fonction ne définit pas la durée pendant laquelle vous voulez faire une action. Une fois que vous appelerez l'une de ces fonctions, le robot continuera à exécuter cet ordre jusqu'à ce que vous l'arrêtiez. Ce qui veut dire que si vous souhaitez avancer d'une petite distance, vous devrez faire:

moveforward(...)
time.sleep(X)
stopMotors(...)

Plus bas, je définis les broches sur lesquelles sont connectés les détecteurs de contact, et deux fonctions pour lire leur valeur. En pratique, ces fonctions retournent 0 si le contact n'est pas pressé, et 1 si il est pressé, au lieu de 0 si le contact est pressé, et une valeur non nulle dans le cas contraire.

Les broches du MCP23017 qui commandent les deux moteurs sont définies juste en dessous, et on peut alors mettre les broches en sortie pour les moteurs, ou en entrée pour les détecteurs de contact.

Passons maintenant au corps du programme en lui même :

try:
#boucle principale et infinie du moteur
while (True):
#lecture de la distance de l'obstacle le plus proche
d=readDistanceInch(0, SPICLK, SPIMOSI, SPIMISO, SPICS)
#en dessous de 8 pouces, le robot recule pendant au moins 0.2s
if(d<:
moveBackward(m1a,m1b,m1e,m2a,m2b,m2e)
#time.sleep(0.2)
#entre 8 et 16 pouces, le robot tourne pendant au moins 0.2s
elif(d<16) :
turnLeft(m1a,m1b,m1e,m2a,m2b,m2e)
time.sleep(0.2)
#le reste du temps le robot avance pendant 0.05s
else :
moveForward(m1a,m1b,m1e,m2a,m2b,m2e)
time.sleep(0.05)
except KeyboardInterrupt:
print ""
print "stopping motors"
stopMotors(m1a,m1b,m1e,m2a,m2b,m2e)
print "motors stopped, exiting."
sys.exit(0)

Vous noterez un bloc try et un bloc except.

La partie dans "try" est le code du robot à proprement parler.

Il s'agit de l'implémentation de l'algorithme décrit plus haut. On notera toutefois que j'ai introduit un délai quand le robot tourne, pour

l'obliger à tourner au moins d'un certain angle. Comme mon robot est large et avec des angles proéminents, ça lui évite de coincer ses coins sur les bords de l'obstacle. La durée d'attente dépend de votre robot, à vous de tester!

Dans tous les cas, avant de recommencer, j'ai mis un temps d'attente de 50ms, à vous de voir si ça vous convient également.

C'est une attente que j'ai mise qui correspond à la fréquence de rafraîchissement du capteur de distance que j'utilise.

Le bloc "except KeyboardInterrupt" sert à gérer le CTRL+C qu'on utilise pour quitter le programme. Dans la précédente version, il n'y avait

pas ce bloc, et du coup, quand on faisait CTRL+C pour arrêter l'exécution de l'algorithme, le robot restait bloqué sur la denrière instruction, par exemple, avancer, jusqu'à ce qu'on lance la commande robotStop.py.

Ici, il arrêtera les moteurs avant de quitter le programme.

.

La seconde version de ce code, r2.py, cette fois, tient compte des capteurs de contact, qui sont prioritaires sur le capteur à ultrasons (si un contact est détecté, alors le robot recule, puis tourne dans la direction opposée, quoi que dise le capteur à ultrasons).

Le reste du code est le même qu'avant.

.

Nous avons également

une troisième version, r3.py, qui introduit le fait qu'au lieu de toujours tourner à droite, le robot tourne un certain nombre de fois du même coté, puis commence à tourner dans l'autre sens pour éviter les obstacles. Il compte comme "tourner d'un coté" comme l'action continue entre le moment ou il commence à tourner et le moment ou il arrête de tourner. Cela évite qu'il fasse des allers retours de gauche à droite.

Mais également la version qui change de coté au bout d'un moment :

[media]

[/media]

Enfin, la dernière version du robot, r4.py est la plus évoluée. On intègre tout ce qui a été fait avant, mais cette fois ci, quand le robot détecte un obstacle avec le capteur à ultrasons entre 8 et 16 pouces, il tourne à gauche, mesure la distance de ce coté, tourne à droite, mesure la distance de ce coté égalment, et choisit de tourner du coté ou la distance est la plus grande. Pour éviter face à des obstacles équidistants de tourner à gauche puis à droite en boucle, le robot tourne dans la direction qu'il à choisie jusqu'à ce que l'obstacle soit au delà de la distance de 16 pouces. Encore une fois, cela donne de bons résultats, car sur un obstacle rectiligne, le robot tournera du coté ou le mur "s'éloigne", donc choisira le coté ou il a le moins à tourner. Pour certains obstacles, il peut ne pas prendre la décision optimale (obstacle semi circulaire par exemple), mais ne se retrouvera pas bloqué.

Voici une vidéo illustrant le fonctionnement de cet algorithme :

[media]

[/media]

Je ne l'ai pas encore uploadée, manifestement, mais ça sera bientôt fait.

Dans une prochaine mise à jour, j'intégrerai le code.

Si des versions plus avancées sont développées, je ne les décrirai pas forcément, mais je les enverrai sur le GitHub. en général j'essaie de faire du code commenté, et clair.

Je rappelle les précédentes étapes :

1. présentation du robot Raspberry Pi R.Cerda;
   
2. Détail du choix des composants pour un Robot type Cerda;
   
3. Schéma fonctionnel et schéma de montage électronique de R.Cerda;
   
4. Instructions d’assemblage/création du châssis de R.Cerda.
   

[Yaug]

Salut Sky, je me permet de revenir sur le montage utilisé pour R.Cerda (Montage d'un robot Raspberry Pi de type R.Cerda).

Tu utilises à la foi un MCP23017 pour contrôler les L293D et un MCP3008 pour le sensor.

Quelle est la raison de ce choix ?

- C'est parce que cela te permet ensuite d'étendre les fonctionnalités ?

- Ou c'est parce qu'il n'y avait plus de place dispo pour faire tout seulement sur le MCP23017 ?

Etant donné que j'en suis à la phase de montage de mon robot Pongo, je me pose ce genre de questions :)

D'avance merci pour ta réponse.

[titou190]

Il me semble que le 3008 sert à convertir des sorties analogiques en numérique (depuis une capteur) tandis que le 23017 (ou le 23008) sert à ajouter des GPIO. Je vais pouvoir commencer à jouer un peu, j'ai reçu aujourd'hui ma commande de puces/moteurs/capteurs/roues/etc

[sky99]

Salut Sky, je me permet de revenir sur le montage utilisé pour R.Cerda (Montage d'un robot Raspberry Pi de type R.Cerda).

Tu utilises à la foi un MCP23017 pour contrôler les L293D et un MCP3008 pour le sensor.

Quelle est la raison de ce choix ?

- C'est parce que cela te permet ensuite d'étendre les fonctionnalités ?

- Ou c'est parce qu'il n'y avait plus de place dispo pour faire tout seulement sur le MCP23017 ?

Etant donné que j'en suis à la phase de montage de mon robot Pongo, je me pose ce genre de questions :)

D'avance merci pour ta réponse.

Precisement ce que dit titou dans son message :)

Le MCP3008 est un convertisseur analogique-digital. Le capteur ultrasonique, de même qu'un capteur IR, et autres, renvoie une valeur analogique, en pratique, une tension entre 0 et VCC selon la distance. Le Pi n'est pas capable d'analyser des valeurs analogiques, uniquement des valeurs logiques (3.3V=1 , 0v = 0).

Le MCP3008 lira les valeurs analogiques, et renverra celles ci sous forme numérique. Vu qu'il s'agit d'un ADC 10 bits, on aura donc des valeurs de 0 à 1023.

Le MCP3008 me permet donc d'avoir 8 entrées analogiques, et donc de lire 8 capteurs de ce type.

Le MCP23017, quand à lui, rajoute 16 GPIO numeriques, en entrée-sorties. Le MCP3008 ajoute des entrées analogiques, et ne peux pas être utilisé en sortie.

Avec le MCP23017, je peux configurer chaque broche GPIO de la puce en entrée ou sortie, mais uniquement en numérique. Donc par exemple, pour les boutons poussoirs, vu que c'est du binaire (le contact est enfoncé = 1, il ne l'est pas=0), ça convient. De même, les broches du L293D sont commandées par des impulsions numériques, donc je peux utiliser 6 broches du MCP23017. Cette seconde puce est donc facultative, car on pourrait simplement utiliser les GPIO du PI pour ça. L'intérêt c'est que ces GPIO sont plus "solides"' que ceux du PI, en ceci que la puce résiste mieux à diverses bêtises qu'on pourrait faire (mauvais branchements). Donc j'aime bien cette puce. Quand il y a un problème, la puce ne fonctionne pas, mais le Pi continue à tourner. Un mauvais branchement sur les GPIO et celui ci s’éteint.

De plus, les GPIO du MCP23017 peuvent chacun fournir 25mA, alors que c'est 16mA par GPIO sur le PI, avec un total qui doit être inférieur à 53 ou 56mA (je ne me rappelle plus exactement la valeur, mais c'est dans ces eaux là). Donc simplement 3 LED de 20mA et on dépasse les spécifications...

Dans les deux cas, je peux aussi étendre les fonctionalités, car j'utilise 6 GPIO du MCP23017 pour les motor drivers, et 2 pour les détecteurs de contact. Il me reste donc 8 GPIO sur cette puce, sachant que je peux ajouter jusqu'à 6 autres MCP23017 au montage très facilement, pour jusqu'à 96GPIO supplémentaires si nécessaire.

Le MCP3008 permet de lire jusqu'à 8 capteurs analogiques en même temps, j'en utilise 1. Sans ce capteur analogique, on peut se passer du MCP3008, mais on renonce à la capacité de lire de telles sondes. Dans mon cas, je peux ajouter jusqu'à 7 autres capteurs analogiques (je mettrai sans doute un capteur de distance à courte portée, vers l'avant, pour détecter les trous et éviter au robot de tomber dans les escaliers ou autres, mais on peut rajouter tout plein de capteurs différents!)

Donc à l'heure actuelle, cette version du robot dispose de 7 entrées analogiques libres, et de 8 entrées-sorties numériques libres.

Pour le MCP23017, je m'en sers pour chacun de mes Raspberry pi, pour les raisons énoncées plus haut :)

Et comme il est en I²C, il ne consomme que deux GPIO, qui sont de toutes façons utilisables par d'autres puces I²C en définissant l'adresse correctement. Donc plus ou moins "gratuit" en GPIO ^^

Pour le SPI, malheureusement je n'ai rien trouvé qui indique qu'on puisse chaîner ce bus, donc on peut rajouter un autre MCP3008 pour avoir 16 entrées analogiques au total, mais il faut prendre 4 autres GPIO pour ça. Il y a peut être moyen toutefois de brancher le MCP3008 sur un MCP23017, mais je ne m'y suis pas attaché :)

[Yaug]

Niquel, merci pour toutes ces précisions !

je vais donc partir sur 1 puce de chaque en effet.

Histoire de pouvoir partir sur un robot extensible.

Dans tous les cas, super réponse, merci encore Sky

[syris]

Pour ceux qui ont quelques problèmes de température sur leur pi overclocké et qui souhaite y raccorder un mini ventilo avec déclenchement sur seuil de température :

http://www.syris.fr/index.php/declencher-un-ventilateur-avec-seuil-de-temperature-sur-raspberry-pi-via-python-et-gpio/

A bientôt !

[Simplearetenir]

Super topic

C'est vraiment intéressant ! J'ai hâte de découvrir de nouveaux tutoriels.

J’aimerais monitorer ma plaque de cuisson. Je m’explique : j’ai de une à quatre casserole sur ma plaque de cuisson électrique, je voudrais :

• allumer ou éteindre chaque bruleur électrique à partir de scénario ou de mon interface tactile à ça je sais faire !
• récupérer la température des contenants de chaque casserole à ça je ne sais pas comment faire.

J’avais pensé à un montage avec un capteur de température sans contact (type infrarouge), pouvez-vous m’aiguiller sur une techno ? une référence, et bien sure il faudrait que ce soit abordable (que le capteur ne coute pas un bras).

Est-ce quelqu’un a déjà fait ou saurait faire ?

[sky99]

Salut!

Si les contenants sont composés de liquides, ou au moins d'un truc avec de la sauce, la solution la plus simple est d'utiliser ce genre de composants :

http://www.adafruit.com/products/270

Avec, on peut monter jusqu'à 500°C.

Sinon, s'il s'agit de mesurer la température pour une poêle qui doit faire cuire un steak, donc sans trop de liquides ou immerger la sonde, en effet, il faudra peut être penser à une solution sans fil. Toutefois, il est peut être possible d'établir une relation entre la température au dessus de la poêle a une distance donnée et celle ci. Du coup en faisant des tests, avec la sonde en contact avec le métal et une seconde sonde 1cm au dessus, et en enlevant la sonde en contact si on s'approche de 500°C, il doit être possible d'établir une fonction de la température en fonction de celle de la sonde.

Ou pourquoi pas, une pince métallique d'une certaine longueur, qui viendrait se fixer sur la poêle, d'une certaine longueur, et dissipant assez de chaleur pour être en dessous des 500°C à un bout. Ainsi, avec la même méthode, on peut établir une fonction de la température, et avec cet instrument qui se clipperait sur la poêle.

Sinon pour les capteurs sans contact, j'avais trouvé un capteur de température infrarouge, dont je crois me souvenir qu'il coutait pas trop cher, dans les 30€. je vais chercher la référence, et si je la retrouve, je la posterai. Ceci dit, s'il faut surveiller plusieurs casseroles ça devient vite plus cher :)

[Simplearetenir]

Merci pour ta réponse !

Oui je pense que la meilleure solution serait le sans contact infrarouge. 30€ c'est dans le budget ! J'espère que tu va retrouver cette référence.

Encore bravo pour ce topic ! Good job !

[Yaug]

simple à retenir, c'est toi qui a voté pour venir à l'aPIro à Metz ? :)

[Simplearetenir]

simple à retenir, c'est toi qui a voté pour venir à l'aPIro à Metz ? :)

Oui, et c'est simplearetenir en un seul mot ! Simple à retenir, non ?

[kikeklaus]

Hello, j'aimerais uniquement te remercier "Sky99" car c'est vraiment un super travail que tu as fait. J'ai rarement vu des explications aussi claires et des tutos aussi simple se balader sur les Forums...

Si tu veux, je te ferais part de mes projets lorsqu'ils seront terminés :)