Posté 25 mai 2013 - 01:20
J'ai beaucoup de remarques.
Principe général:
Sans PWM, tu ne pourras pas moduler la puissance des moteurs. Or, c'est assez indispensable si tu veux gérer des déplacements finement. Du tout ou rien dans des moteurs de déplacement, c'est insuffisant, à mon avis. Rien que le fait d'orienter le robot précisément nécessite de moduler la puissance des moteurs. Et puis c'est indispensable pour ceux qui veulent expérimenter des asservissements (PID). Ne pas gérer le PWM, c'est limiter énormément le robot.
Les codeurs: comment comptes-tu décoder (=exploiter) les codeurs de roue? En général, ça se décode soit par interruptions, soit avec un compteur/décompteur. Mais là, si tu veux procéder par "polling" (=lectures périodiques des Entrées), à mon avis, ça ne fonctionnera pas. En tout cas, je n'ai jamais vu ça. Il faudrait que tu interroges très régulièrement, et à fréquence très élevée. Tout dépend de la résolution des codeurs et de la vitesse du robot; mais même avec une résolution raisonnable, on atteint vite 500 ou 1000 tops par seconde. Donc il faudrait que tu interroges 2 fois plus vite que ça (pour ne louper aucun top, théorème de Shanon). Et interroger via une RPi (qui aura d'autres choses à faire) 2000 fois par seconde, ça me semble très ambitieux.
Bref, si j'étais toi, je repartirai de zéro. Pourquoi ne pas mettre un microcontrôleur pour faire l'interface entre la RPI et le reste? C'est quand même beaucoup plus flexible. Un petit microcontroleur qui génèrerai le PWM, lirait les E/S analogiquest et numériques, et surtout lirait par interruption les codeurs.
La carte:
Pourquoi interfacer un MCPxx par I2C et l'autre par SPI? Il existe des versions qui s'interfacent de la même façon (SPI ou I2C). Et les 2 types de bus I2C ou SPI permettent de partager plusieurs périphériques. C'est plus facile en I2C.
Mettre des résistances "pull up" (sur les EN-A et EN-B du L298 est dangereux. Si problème de configuration, en cours de programmation, ou autre, ça va forcer la puissance dans les moteurs, et donc faire avancer le robot tout seul. Il faut privilégier des pull-down.
Tu as fait beaucoup d'erreurs pour interfacer le L298, relis calmement l'intégralité du Datasheet.
* La logique du L298 s'alimente en 5V impérativement, alors que tu l'alimentes en 3.3V. D'ailleurs, pourquoi ne pas mettre un régulateur sur la carte?
* Tu as inversé VS et VSS. VS c'est l'alim puissance, et VSS c'est l'alim logique.
* Les résistances de mesure de courant (sense) ne sont pas reliées à la masse. Et elles sont reliées avec des pistes fines, alors qu'elles voient de la puissance.
* Tu as relié les résistances de mesure de courant sur des entrées/sorties tout ou rien. Quel est l'intérêt? A la rigueur sur des entrées analogiques, mais via un amplificateur opérationnel. Honêtement, on peut très bien s'en passer! Et directement relier "sense A et B" à la masse. C'est ce que je faisais sur BOB3.
* Il faut impérativement rajouter au moins 1 condo de puissance (chimique ou tantale) à côté du L298.
Il faut impérativement rajouter des condos de découplage à côté de l'alim (logique et puissance) de chaque composant. En général, on mets des petits céramiques 100nF.
Pourquoi faire des pistes aussi étroites? C'est très risqué. Il faut privilégier les traces plus grosses.
Plan de masse : A priori, ça ne sera pas gênant, vu que ça reste un montage relativement basse fréquence. Ca deviendra gênant si tu mets un microcontroleur, par exemple. Un plan de masse ne doit pas aller partout. Il ne doit pas aller là où il n'est relié à rien, et où il ne boucle pas avec lui même. Sinon, les bouts de plan de masse qui ne sont reliés que d'un côté vont faire "antenne". Exemple : le "T" que fait le plan de masse sur le haut du MCP23017 doit être enlevé intégralement, la masse doit s'arrêter à connecter les broches 10 et 18 de ton MCP23017.
Leon.
/>/>
/>
