Cartes électroniques

Echangez ici sur vos idées ou vos problèmes concernant vos circuits électroniques et électriques.
Discuss here the problems concerning your electronic and electrical circuits.
Post Reply
Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Cartes électroniques

Post by Keuronde » Wed 18 Sep 2013, 22:30

Bonsoir à vous,

Après quelques participations à la coupe nous aimerions varier notre électronique - ras le bol des PIC18F2550 - (et aussi la rendre plus compact).
Nous cherchons à avoir une carte avec au moins :
2 sorties moteurs
2 entrées encodeur (voir 4)
1 gyroscope
1 microcontrôleur performant et programmable depuis un pc linux
diverse Entrées / sortie, lien de communication...

Nous n'avons pas trouvé cette carte chez le revendeur du coin...

Comment faites vous pour vos cartes électroniques ?
  • * Acheter-vous des cartes toutes faites ?
    * Faites vous faire vos cartes en sous-traitant la soudure des composants ?
    * Vous avec un four à CMS ?
    * Faites-vous une carte non CMS sur laquelle vous greffez des modules comme ceux de Pololu ?
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

arno
PMI
Posts: 693
Joined: Wed 23 Jun 2004, 21:51
Location: Un peu partout...

Re: Cartes électroniques

Post by arno » Wed 18 Sep 2013, 23:51

Salut Keuronde,

Pas sur qu'on soit le meilleur exemple en tant que club d'anciens, mais voilà ma réponse:
* Acheter-vous des cartes toutes faites ?
=> Non
* Faites vous faire vos cartes en sous-traitant la soudure des composants ?
=> On sous traite seulement la fabrication des cartes (on a un membre qui aime remplir au moins 4 couches de cuivre... :D )
* Vous avec un four à CMS ?
=> oui quand il y a des composants à la noix (style QFN, ou composants avec pad thermique) et au fer pour finir
* Faites-vous une carte non CMS sur laquelle vous greffez des modules comme ceux de Pololu ?
=> non

Après y'a des exceptions, cette année la carte permettant de faire tirer les cerises à été faite sur place à trou en composants traversants, mais cohabitais avec des cartes CMS maison.

Il y a quelques années, lorsqu'on était encore dans des structures d'écoles, on faisait déjà les circuit nous même, mais en double face à l'insoleuse et au perchlo. Mais le CMS ne nous faisait déjà pas peur (on descendait jusqu'à 0.8mm de pas de souvenir).

Maintenant, faire des circuit ne coûte pas très cher. Voir le sujet que j'avais lancé l'an dernier : viewtopic.php?f=1&t=16299. Je suis passé par Dipôle pour faire lesdits circuit à l'époque, et je n'ai pas eu de soucis, c'était rapide, juste deux pistes qui se touchaient, mais qui avaient été repéré (autocollant avec flèche pointant le défaut). Aucune action chez eux, mais puisque c'est une boite française et que ça marche, pourquoi ne pas le dire ;).

User avatar
totofweb
PMI
Posts: 3198
Joined: Sun 22 Jun 2003, 09:58
Contact:

Re: Cartes électroniques

Post by totofweb » Thu 19 Sep 2013, 00:13

Salut
Keuronde wrote:* Acheter-vous des cartes toutes faites ?
Jamais. En fait, c'est généralement moins cher d'acheter, mais j'aime trop concevoir les choses moi-même ; et puis ça me permet d'avoir une électronique en totale adéquation avec mes besoins précis, ce qui est rarement le cas avec des cartes du commerce pour lesquelles il faut bidouiller tout un tas d'adaptations autour.

La seule électronique que j'ai déjà achetée toute faite pour la coupe, ce sont des contrôleurs de moteur MCDC3006C de Faulhaber, qui intègrent une régulation PID sur bus CAN. J'aurais pu le faire moi-même, mais ces contrôleurs sont tellement bien, compacts, avec protections, contrôles soft, etc, que j'aurais passé trop de temps pour faire quelque chose d'équivalent. Le PID, les ponts en H, j'ai déjà donné dans pas mal de montages, au bout d'un moment c'est lassant à faire.
Keuronde wrote:* Faites vous faire vos cartes en sous-traitant la soudure des composants ?
Pour la fabrication des PCBs, ça fait des années que je ne passe plus que par des professionnels. La métallisation des trous, les pistes fines, les PCBs fiables, quand on s'y habitue on ne revient plus en arrière. Et puis maintenant je fais des choses un peu plus complexe avec un certain nombre de couches internes, des adaptations d'impédances et de longueur de lignes, etc, donc c'est un peu indispensable.

Par contre, pour l'assemblage des PCB, je ne le fais que quand j'ai des BGA à souder, mais ça reste assez rare (pour mon usage amateur, car en pro ou semi-pro je fais sous-traiter).

Tout ce qui est CMS avec des TQFP fine pitch et des passifs jusqu'au 0603, ça se soude sans trop de problèmes avec un peu de technique. Je soude tout ça avec mon vieux JBC 30ST que j'ai eu à Noël il y a plus de 15 ans, donc ça n'impose pas d'investir dans du matériel hors de prix. Il faut juste une panne bien propre et pas trop grossière ni trop bourrine, un peu de tresse à dessouder (pour la soudure des circuits intégrés), une brucelle, et de l'étain pas trop grossier (0.5mm est préférable, 0.8mm éventuellement).

Quand des CMS ont des pads thermiques en dessous, une technique est de prévoir de très gros vias sur ce pad, pour faire passer de l'étain depuis l'autre côté du PCB.

Par contre, j'évite toujours d'utiliser des composants QFN. Ça se soude très mal au fer, et même quand c'est soudé les soudures ne sont jamais fiables.
Keuronde wrote:* Vous avec un four à CMS ?
J'ai un petit four à CMS (type four Elektor), mais je ne m'en sers presque jamais. On se dit que ça gagne du temps, mais mine de rien le placement manuel des composants ça prend un temps fou, et le moindre tremblement a vite fait de tout saccager.

Ça permet quand même de souder des QFN et des CMS avec pads thermiques. Je n'ai jamais tenté de BGA avec.
Pour les QFN, avec le recul je reste sur l'idée qu'il vaut mieux les éviter. Dans un cadre semi-professionnel j'ai fait fabriquer des centaines de cartes par une usine spécialisée, au bout de deux ans d'utilisation les principaux problèmes viennent des QFN, dont les soudures ont toujours tendance à casser : aucune flexibilité mécanique, donc les soudures craquent au gré des vibrations de PCB, dilatations thermiques, etc.
Keuronde wrote:* Faites-vous une carte non CMS sur laquelle vous greffez des modules comme ceux de Pololu ?
Non, il est très rare que j'utilise le moindre module tout fait. Par contre j'ai déjà utilisé les modules TI d'alimentation à découpage, ils sont assez pratiques quand on veut gagner du temps.



En ce qui concerne le choix d'une nouvelle architecture, j'ai passé pas mal d'années sur des AtMega, programmés avec gcc sous linux. C'était le bonheur. Maintenant, je suis passé aux AVR XMega, la nouvelle série, et c'est grandiose au niveau de la programmation et des possibilités internes (pour des contrôleurs 8 bits).

Point de PC embarqué pour moi, je préfère des solutions plus basiques ; après chacun son truc, un softeux éprouvera bien plus de plaisir à acheter le plus possible de modules du commerce tout en développant des choses super complexes sur PC. J'aime l'élec et la programmation bas niveau, donc j'oriente mes choix architecturaux en conséquence.

Si je devais faire un choix d'architecture pour une prochaine participation à la coupe, j'opterais pour un couple AVR XMega256A1 pour la gestion stratégiques, la planification des déplacements, et toutes les tâches dont la complexité décisionnelle oriente plutôt vers de la programmation en C et qui n'ont pas de grande criticité timing ; et FPGA Xilinx Spartan3 ou Spartan6 (programmable depuis linux aussi) en TQFP (tout soudable à la main) pour la gestion des périphériques, les asservissements, et tous les traitements rapides qui se font en tâche de fond. Le µc et le FPGA seraient interconnectés par le port EBI de l'AVR, de manière à ce que le FPGA soit mappé dans la map mémoire de l'AVR, pour pouvoir faire des lectures/écritures de registres comme s'il s'agissait de périphériques internes de l'AVR (donc aucun protocole de communication à gérer en soft). Ce type d'architecture a pas mal d'avantages, et permet de bien partitionner les tâches entre ce qui a besoin de traitement temps réel permanent en tâche de fond, et ce qui est purement décisionnel de haut niveau.

Bon courage pour la prochaine coupe !

kabriolin
Posts: 202
Joined: Tue 31 Aug 2010, 21:54

Re: Cartes électroniques

Post by kabriolin » Thu 19 Sep 2013, 12:32

Salut,
* Acheter-vous des cartes toutes faites ?
Au mieux pour tester, mais sinon, je m'amuse trop à les faire moi même, et au moins, je les adapte à ce dont j'ai besoin.
* Faites vous faire vos cartes en sous-traitant la soudure des composants ?
Oui et non, tout dépend de la qualité demandé, mais vu ce que ça donne quand c'est sous-traité, c'est quand même mieux.
* Vous avec un four à CMS ?
J'ai commencé à en faire un, mais jamais trop eu le temps de finaliser les réglages.
* Faites-vous une carte non CMS sur laquelle vous greffez des modules comme ceux de Pololu ?
Ha non, moins j’achète de tout fait, mieux je me porte, c'est quand même plus satisfaisant de voir le robot fonctionner avec des trucs fais sois même, que de l'assemblage de cartes du commerce non?

Pour ce qui est des technologies, point de PC embarqué, tout au uC.
Cette année, je développe une carte compacte (tout est relatif) multi-fonction:
2 moteurs DC
2 codeurs
6 servo type modelisme, avec alim à découpage à tension réglable
4 AX-12 avec alim à découpage à tension réglable
4 entrées analogiques
4 Entrée/Sorties
Le tout dans 80x100mm
3 uC, bus IIC interne
Plusieurs cartes peuvent êtres mises sur un bus RS485, chacune ayant une adresse unique.
Le bus RS485 permettant d'y interfacer facilement un adaptateur RS485->USB afin d'espionner les trames et de faire du debug de ce qui se dit sur le bus et donc de récupérer toutes les consignes, les positions...
Communication par trames type "GCODE"

Le proto est sorti, le soft en cours de dev, la partie AX-12 est OK, les servos, les mesures analogiques aussi.
L'asserv en lui même est OK, mais j'ai un petit soucis de compatibilité entre le code d'asserv et FreeRTOS tournant sur tous les uC du robot. Mais rien de méchant.
2015: Robotic System: finaliste Belgique et Suisse, 42ème en France (Merci Murphy)
2014: Robotic System: 4ème des Qualifs de Belgique, 2ème en Coupe de France
2013: Robotic System: 3ème en Belgique, 14ème en Coupe de France
2012: Robotic System: 38ème

User avatar
romain_cvra
PMI
Posts: 1105
Joined: Sat 30 Jun 2007, 16:17
Location: suisse
Contact:

Re: Cartes électroniques

Post by romain_cvra » Thu 19 Sep 2013, 13:05

Notre électronique à comme base une carte FPGA de dév, la DE0-Nano de chez Terasic (http://www.altera.com/education/univ/ma ... board.html).
Dimension 75x50mm, munie d'une FPGA Cyclone 4 et de connecteurs d'extensions (2x40pins et 1x26pins).
Elle offre une grande flexibilité en associant une programmation hardware VHDL spécifique à nos besoins (PWM, compteurs de puls, etc...) ainsi qu’une programmation rapide et souple en langage C via le softcore Nios II (régulation, odométrie, stratégie, etc...).

Cette année nous avons développé des nouvelles cartes d'interface nettement plus compactes.

La carte "IO FPGA" (en haut de la photo) est une carte d'entrée-sortie. Elle vient se pluger directement sous la carte FPGA via le connecteur 26pins. Dimension identique à la carte FPGA 75x50mm, lorsque les deux cartes sont mises ensemble, l'épaisseur de l'ensemble est de 28mm. Munie de 8 entrées analogiques, 16 entrées digitales, 16 sorties digitales et 4 ports séries (Rx,Tx 3.3V).

La carte "Hex Motor Driver" (milieux de la photos) est une carte d'interface moteur pour 6 moteurs DC brushed ou 4 moteurs brushless (max 20A continu). Elle incorpore aussi 6 entrées codeurs A-B, 3 entrées index ainsi que 6 mesure de courant. Dimension 70x50x8mm. Elle se connecte à un des connecteurs 40pins de la carte FPGA. On en a 2 dans le robot.

La petit carte en bas de la photos permet de passé d'un gros connecteur 40pins à une petite nappe 40fils au pas de 0.5mm.

Nous avons encore une carte de gestion de l'alim. Dimension 40x60mm. Elle coupe l'alim du robot si la tension de l'accu est trop basse (sauvegarde de l'accu en cas d'oubli...). Émet des bips si l'accu doit être changé. Réparti les tensions d'alim et de commande, génère le 5V commande et gère le stop d'urgence ainsi que le switch de l'alim commande.

Pour le robot à bras, nous avons donc la carte "FPGA" et en dessous la carte "IO FPGA", deux cartes "Hex Motor Driver" l'une sur l'autre. Et la carte de gestion de l'alim. Le tout est dans le tronc centrale du robot dans un espace de 220x60x30! :-D
Keuronde wrote:* Acheter-vous des cartes toutes faites ?
Oui pour la carte FPGA. Toutes les autres sont fait maison.
Keuronde wrote:* Faites vous faire vos cartes en sous-traitant la soudure des composants ?
On commande le PCB mais c'est soudé à la main.
Keuronde wrote:* Vous avec un four à CMS ?
Pas encore mais c'est pour bientôt

Image

A+
Site web : http://www.cvra.ch.
Le code source : GitHub
Visualisation CAO 3D de nos robots : GrabCAD

User avatar
nadar breicq
Posts: 292
Joined: Fri 07 Mar 2008, 09:49
Location: Amiens
Contact:

Re: Cartes électroniques

Post by nadar breicq » Thu 19 Sep 2013, 14:05

* Acheter-vous des cartes toutes faites ?

De temps en temps pour tester des solutions nouvelles ou pour faire des protos. Généralement, on intègre la solution choisie dans une électronique maison.

* Faites vous faire vos cartes en sous-traitant la soudure des composants ?

On a toujours soudé nos cartes par nos propres moyens. Côté carte, ça dépend : si on peut, on les fait nous même, sinon on a déjà sous-traité dans les cas ou on était un peu à la bourre ...

* Vous avec un four à CMS ?

Non. Tous nos composants sont traversants. C'est un choix que l'on s'oblige à faire pour que les cartes soient facilement repérable et dépannable sans problème à 3h du mat pendant la coupe avec un bête fer a souder ^^

* Faites-vous une carte non CMS sur laquelle vous greffez des modules comme ceux de Pololu ?

Oui, on l'a déjà fait pour intégrer des modules type boussole ou accéléromètre par exemple.
Participez aux Joutes de robotique 2018 ! :wink:
Membre de l'équipe Les Karibous [2013][2014][2015][2016][2017][2018]
FabManager du FabLab La Machinerie d'Amiens
Membre du club Valrobotik de Valenciennes [2009 - 2012]

User avatar
GARGAMEL
PMI
Posts: 1174
Joined: Tue 14 Jun 2005, 17:16
Location: Ville d'Avray
Contact:

Re: Cartes électroniques

Post by GARGAMEL » Thu 19 Sep 2013, 17:39

La partie commande du robot s'articule autour d'un bus SPI, un simple ATMEGA étant le maître.
(Solution désuète mais qui suffit à notre bonheur)
Propriétés maximum de l'ensemble:
8 commandes PWM moteurs et pompes
16 commandes PWM servo-moteurs
12 entrées analogiques
52 entrées numériques
2 entrée/sortie série
1 liaison JTAG pour chargement et débugging de l'ATMEGA

Le nombre de cartes dépend de la structure mécanique du robot.
Au minimum 1 seule carte qui contient tout l'ensemble fonctionnel.
Au maximum 6 cartes (Comme le représente l'exemple ci-dessous).
Quelques composants cms sont passés au four.

Les cartes sont conçues, routées et câblées par les étudiants (Toutes les cartes sont refaites chaque année).
La fabrication est confiée à des professionnels ( EURO-CIRCUIT), car le département ne dispose que d'une machine à graver sans possibilité fiable de réaliser trous métallisés et vernis épargne.

Image
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

User avatar
syoctax
Posts: 67
Joined: Mon 05 Oct 2009, 18:07
Location: Grenoble

Re: Cartes électroniques

Post by syoctax » Thu 19 Sep 2013, 18:12

GARGAMEL wrote:La partie commande du robot s'articule autour d'un bus SPI, un simple ATMEGA étant le maître.
(Solution désuète mais qui suffit à notre bonheur)
Propriétés maximum de l'ensemble:
8 commandes PWM moteurs et pompes
16 commandes PWM servo-moteurs
12 entrées analogiques
52 entrées numériques
2 entrée/sortie série
1 liaison JTAG pour chargement et débugging de l'ATMEGA
...
Est-ce que tu peux nous donner plus d'info sur comment vous interfacez vos capteur "industriels" (disons fonctionnant sous 12V) avec le 5V logique de votre carte? Simples optocoupleurs? Est-ce que vous gérez le fait qu'ils peuvent avoir une sortie NPN ou PNP?

J'essaie de penser justement en ce moment à une carte d'interface "propre" (i.e. pas de pont diviseur de tension) compatible avec le plus grand nombre de capteurs dit "industriels"
Seb
2012, 2013, 2014, 2015, 2016 I-Grebot - Wiki
2010 Elder Project
2008, 2009 Robotnik INSA Rennes

User avatar
cho934
Posts: 115
Joined: Tue 05 Jun 2012, 18:57
Location: VILLERUPT
Contact:

Re: Cartes électroniques

Post by cho934 » Thu 19 Sep 2013, 18:14

Bonjour,

* Acheter-vous des cartes toutes faites ?
Ça dépend, effectivement entre l'amusement, le délais, et l'intégration.

* Faites vous faire vos cartes en sous-traitant la soudure des composants ?
Ça fait 10 ans qu'on les fait nous même, en simple face (pas de CMS), pour les mêmes raisons de debug au fer à souder, mais bon ça reste fiable une fois que c'est bien pensé ;)
En revanche, cette année on va se demander si cela vaut le coup de les faire faire pour miniaturisation...

On utilise une petite carte linux APF9328 de chez http://www.armadeus.com (On a tout le support en français). C'est la carte maitre, elle intègre même un FPGA directement, mais on a pas encore les compétences pour l'utiliser.
Et après on ajoute d'autres cartes, suivant le besoin, qui communiquent par SPI ou I2C ou GPIO.

Du coup on travaille sur machine virtuelle sous linux, on compile, et on envoie le programme par ssh dans le robot par RJ45.

++

User avatar
GARGAMEL
PMI
Posts: 1174
Joined: Tue 14 Jun 2005, 17:16
Location: Ville d'Avray
Contact:

Re: Cartes électroniques

Post by GARGAMEL » Thu 19 Sep 2013, 18:35

syoctax wrote: Est-ce que tu peux nous donner plus d'info sur comment vous interfacez vos capteur "industriels" (disons fonctionnant sous 12V) avec le 5V logique de votre carte? Simples optocoupleurs? Est-ce que vous gérez le fait qu'ils peuvent avoir une sortie NPN ou PNP?

J'essaie de penser justement en ce moment à une carte d'interface "propre" (i.e. pas de pont diviseur de tension) compatible avec le plus grand nombre de capteurs dit "industriels"
Tous nos capteurs (Opto, US, laser) sont alimentés sous 15v.
On n'utilise pas d'opto-coupleur mais on fait attention aux problèmes de masse:
On prévoit des masses séparées pour le 5V des micros, le 15v des capteurs et le 6v des servos.
Ces masse sont réunies sur la carte puissance et sont distribuées en étoile vers leurs destinataires respectifs. (Flèches en rouge sur le schéma fonctionnel ci-dessus).

Pour les sorties des capteurs, on prévoit les 3 types suivants:
Sorties NPN avec résistance de pull-up reliée au 5v num.
Sorties PNP avec diviseur de tension R-2R.
Sorties universelles (NPN ou PNP avec possibilité de passer de l'une à l'autre par strappe).
Toutes les sorties capteurs sont filtrées par capacités de 10 à 100nF.
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

User avatar
Nirgal
Posts: 201
Joined: Mon 25 Oct 2010, 20:05
Contact:

Re: Cartes électroniques

Post by Nirgal » Thu 19 Sep 2013, 21:57

GARGAMEL wrote: Tous nos capteurs (Opto, US, laser) sont alimentés sous 15v.
On n'utilise pas d'opto-coupleur mais on fait attention aux problèmes de masse:
On prévoit des masses séparées pour le 5V des micros, le 15v des capteurs et le 6v des servos.
Ces masse sont réunies sur la carte puissance et sont distribuées en étoile vers leurs destinataires respectifs. (Flèches en rouge sur le schéma fonctionnel ci-dessus).

Pour les sorties des capteurs, on prévoit les 3 types suivants:
Sorties NPN avec résistance de pull-up reliée au 5v num.
Sorties PNP avec diviseur de tension R-2R.
Sorties universelles (NPN ou PNP avec possibilité de passer de l'une à l'autre par strappe).
Toutes les sorties capteurs sont filtrées par capacités de 10 à 100nF.
+1 ---> Tout pareil...
les optocoupleurs sont super contraignants à mon gout...
Avec de bons filtres RC on limite déjà pas mal le risque de courants gênants.

Pour répondre à la question initiale sur l'utilisation ou non de cartes du commerce :
les deux...
Depuis 2005, nous tournons sur des cartes faites maison (et améliorées chaque année),à base de dsPIC30F...
Cette année, nous nous lançons sur une évolution technologique, avec l'utilisation de STM32F4DISCOVERY, un très bon compromis pour un budget 'minable'... (tu ajoutes un gyro, et tu as tout ce que tu cites).

En fait, je crois que tout dépend de vos compétences et de ce qui vous plait de développer..
Si vous êtes comme totofweb (c'est à dire amoureux des montages super personnalisés, tout petits, bourrés de CMS, de BGA, de QFN) : vous pouvez opter pour une solution home-made.
Si vous êtes plutôt des 'utilisateurs softeux' de l'électronique, cherchez sans doute à vous orienter vers une solution 'carte' en main... où il est facile d'ajouter quelques connecteurs, des modules tout faits (parce qu'on gagne du temps) et des composants externes spécifiques.

Pour les autres questions, on fait nous aussi fabriquer nos PCBs, et on soude à la main... On choisit des CMS en 1206 ou 0805. (bien souvent, en dessous on gagne pas en taille à cause des gros composants).

A+
Nirgal
Robot-ESEO

Réré - CrazyBot
Posts: 1
Joined: Tue 22 May 2012, 09:24

Re: Cartes électroniques

Post by Réré - CrazyBot » Mon 23 Sep 2013, 13:54

Salut Keuronde,

il y a quelques années, après mon départ de RCVA, je suis passé sur un PIC 18F6722 avec adressage externe pour le microcontoleur maitre.

Maintenant, on est passé sur un dspic33fj128mc802. C'est un 16 bits qui a la particularité d'avoir un module QEI (Quadrature encoder interface). En gros, tu peux brancher jusqu'à 2 codeurs incrémentaux et ils te codent le tout sur 16 bits. Il a 8x PWM, 2x SPI, 2x UART, 1x I2C et 1x CAN. De plus, on les a en gratuit gràce au sample de microchip. Tu le programme comme tous les PICs via usb et le module ICD2 ou pickit (1, 2 ou 3).

Voici la fiche technique: http://www.microchip.com/wwwproducts/De ... e=en532302

Concernant l'architecture, les capteurs/servomoteurs sont déportés sur des cartes filles munies de PIC18F14K22 (1 port 8xE/S analogique) qui communiquent avec le maitre en I2C. Le tout marche très bien.

On a fait sous-traiter toutes les cartes à partir des Typons. Comme ca était dit avant, c'est un vrai confort d'avoir une carte bien propre avec des trous métalisés, vernis prêtes à être souder. On fait la soudure nous même. Le seul composant en CMS est le dspic33F. Pour les cartes filles, se sont les connecteurs qui prennent le plus de place donc on est resté sur du trou transversant. C'est tout de même plus maintenable.

Il ne manques que le gyro. Mais je suis sur qu'il en existe en I2C. Sur une archi comme la notre, il serait facile de faire une carte fille pour gérer ce type de composant.

Robotiquement.

Réré.

User avatar
bULBot
Posts: 28
Joined: Sat 20 Apr 2013, 01:09

Re: Cartes électroniques

Post by bULBot » Mon 23 Sep 2013, 14:52

Histoire de nous joindre aussi à la discussion ...
Keuronde wrote: * Acheter-vous des cartes toutes faites ?
Non, jamais. Le club étant géré par des électroniciens, nous concevons les circuits nous-mêmes.
* Faites vous faire vos cartes en sous-traitant la soudure des composants ?
Nous avons une graveuse de circuits, mais la qualité des PCB n'est pas toujours au rendez-vous. Nous passons généralement par Eurocircuits, chez qui nous avons un contrat de sponsoring. Pour les petits circuits, nous passons parfois par SeeedStudio qui réalisent des PCB à des prix imbattables (10€ pour 10 circuits 5cm x 5cm fdp compris!)
Nous réalisons la soudure nous-mêmes.
* Vous avec un four à CMS ?
Oui, mais on ne s'en sert généralement que pour les circuits possédant un PowerPad ou pour ceux sans borne apparente. Pour les CMS du type SOIC ou pour les passifs, ça va plus vite de le faire à la main que de s'amuser à déposer de la pâte à braser sur les bornes. Dans de rares cas, nous avons demandé à Eurocircuits de nous fabriquer un stencil pour pouvoir déposer la pâte au racloir.
* Faites-vous une carte non CMS sur laquelle vous greffez des modules comme ceux de Pololu ?
Hormis les modules à découpage de TI déjà mentionnés, jamais.

Au vu des demandes, il ne devrait pas être difficile de réaliser une carte avec tout ce qu'il faut. C'est plus ou moins ce que l'on avait les années précédentes.
Pour la prop, on utilise une carte avec un dsPIC33FJ128MC804, qui possède deux modules encodeurs et de nombreuses IO en tous genre. Les deux encodeurs sur roue libre sont gérés dans le soft; ça ajoute pas mal d'interruptions, mais vu que ce processeur ne sert qu'à faire l'odo et la régulation, on a beaucoup de marge même en utilisant des variables en nombre flottants partout.
Dans ton cas, son petit frère le MC802 devrait suffire. Il possède également le module Peripheral Pin Config, qui permet de choisir les bornes utilisées par les périphériques.
Si tu veux plus de bornes pour encodeurs, je te conseille de regarder du coté des STM32 , qui en possèdent 4.

Keuronde
PMI
Posts: 500
Joined: Mon 25 Jan 2010, 22:48

Re: Cartes électroniques

Post by Keuronde » Mon 23 Sep 2013, 21:58

Je suis impressionné par le nombre de réponses et par la précision de vos réponses !
Je n'ai pas encore fini de dépouiller tout ça, mais ça ne saurait tarder.
Alors au lieu de vous présenter la solution que nous avons retenue, voici celle que nous utilisions :

En électronique, j'ai repris presque tout ce qui se faisait dans le club de mon école (malgré l'absence total de résultat à cette époque). Il s'agit d'une école plutôt orientée en mécanique, l'électronique n'était pas notre fort, ni la programmation des microcontrôleurs. Nous utilisions des microcontrôleurs PIC parce qu'on pouvait avoir des échantillons gratos. nous étions aussi en mode radins, l'association utilisait l'argent obtenu auprès de l'école pour financer le voyage (essence, camping et - au moins - un repas). Nous n'avions qu'un programmateur de PIC série. C'est lent est pas vraiment pratique puisqu'il faut enlever le microcontrôleur de son circuit pour le programmer.

La révolution a du avoir lieux l'année avant que j'arrive (disons 2003 ou 2004). Ils ont découvert les PIC USB et les Bootloader USB. Ils sont passé des PIC 16F à un PIC18F4550 uniquement pour le bootloader. Sans vraiment réalisé que le truc serait plus complexe à programmer (je pense notamment aux configurations de l'horloge pour que l'USB marche, chose qui ne se modifie pas avec le bootloader).

Nous nous autorisions à faire réaliser nos circuits (simple couche généralement) pour les souder nous même. Nos composants étaient exclusivement traversant. Nous ne disposions que d'un fer à souder bas de gamme que nous changions tous les 6 mois parce qu'il prenait un mauvais coup (ou une mauvaise chute).

Nous ne réutilisions aucune carte électronique d'une année sur l'autre. En partie parce que comme nous ne nous homologuions pas, nous ne pouvions pas vraiment valider quoique ce soit sur les robots.

Nos cartes devenaient de plus en plus complexes. Une année, alors que nous étions presque en avance sur le planning, la carte s'est révélée impossible à débogguer électriquement, impossible de trouver le faux contact. Nous avons re-conçu deux cartes, la deuxième étant une extensions sans microcontrôleur. L'année d'après nous nous sommes lancé dans l'I2C, ce fut un fiasco, mais les échecs sont riches en enseignement !

Après l'école, j'ai continué pareil à quelques détails. Voici les points importants :
* J'utilise toujours le programmateur série et le bootloader USB. J'ai bien pensé à changer de PIC, mais je n'ai pas trouvé grand chose de satisfaisant avec de l'USB et en traversant (nécessaire pour la programmation).
* Conception des cartes avec Eagle de CadSoft. J'ai essayé Kicad, mais il n'y avait pas beaucoup de composant à l'époque dans les bibliothèque. Je n'exclue pas de repasser à Kicad
* Achat d'une station Weller d'occasion. J'en étais très content, mais ces derniers temps, j'ai l'impression qu'elle ne chauffe pas assez.
* J'ai utilisé une seule (et nouvelle) carte avec un gyroscope I2C en 2010.
* Réutilisation d'une carte d'une année sur l'autre, toujours liées en I2C. Quasiment une carte de plus par an. En 2013 j'avais 4 cartes sur le robot. J'avais tellement peu de place que j'ai disposé mes cartes autour du moteur pas-à-pas de mon robot... Oui, CEM et toussa...
* Utilisation d'une CMUcam en liaison série.
* Coté puissance, c'est du L298

Ça a marché, mais je veux changer :
* Le debug est quasi-impossible à réaliser. Je pense au RaspberryPi qui pourrait m'aider pour le débug, notamment avec une connexion Wifi.
* J'ai des phénomènes vraiment bizarres lorsque j'utilise les interruptions hautes et les interruptions basses. J'avais le pilotage des servomoteur en interruption haute, les communications séries et I2C en interruptions basses. Mais les communications faisaient trembler les servomoteurs... D'autres tests (notamment un chenillard - Merci Gargamel) ont montré que le problème était lié aux interruptions.
* J'utilise MCC18 avec wine. Microchip (le fabriquant des PICs) a sortit un autre IDE (MPLABx)et je ne suis pas sur d'avoir un compilateur supporté très longtemps. Si possible je passerai bien sur un compilateur libre.
* J'ai essayé de gérer une roue codeuse avec un PIC18F2550 et le résultat n'a pas été concluant (mais le montage mécanique est peut-être en cause). Je pense quand même que je risque de perdre en précision lors des changements de sens...
* La CMUCam : j'ai trouvé la reconnaissance des couleurs très fiable sur le terrain de la Ferté Bernard, seulement lors des tests chez moi, j'ai passé plus de temps à recalibrer la CMUCam pour avoir un truc qui marche qu'à développer mon code. La aussi je pense que le RaspberryPi avec son module caméra peut grandement aider.

Voila un peu plus de contexte, merci encore pour vos réponses !

Si vous voulez encore détailler votre partie électronique, allez y !

Je vous tiendrais au courant de nos choix !
Équipe Poivron
Coupe 2014 : Équipe Poivron (67e)
Coupe 2012 : Équipe Poivron (73e)
Coupe 2011 : Équipe Poivron (122e) - Prix des équipes !
Coupe 2010 : Équipe Poivron (78e)


Passez voir le Portail des équipes

User avatar
bULBot
Posts: 28
Joined: Sat 20 Apr 2013, 01:09

Re: Cartes électroniques

Post by bULBot » Mon 23 Sep 2013, 23:15

Quelques réactions à chaud :

J'ai du mal à défendre le choix des pic18f2550 + bootloader USB, surtout connaissant l'état désastreux des librairies USB de Microchip.
Un picKit3 coûte une quarantaine d'euros et peut programmer OU débugger tous les pics 8/16/32 bits existants à ce jour. Il ne nécessite qu'un pin-header 5 broches et une résistance de pull-up sur la carte.

La nouvelle IDE, MPLABX, est multi-plateforme et support les mêmes compilateurs que MPLAB. A noter par contre que MCC18 à changé de nom pour devenir le compilateur XC8 (et les autres XC16 et XC32, ce qui est plus logique). Porter son projet en XC8 revient normalement à changer l'include principal en <xc.h> au lieu de <pic18f2550.h>. Dans tous les cas, il vaut mieux passer su MPLABX étant donné que MPLAB ne sera plus mis à jour, tout comme MCC18/30/32.

Si je me souviens bien, le PIC18 ne permet pas à une interruption de se faire réinterrompre même si la nouvelle est d'un niveau supérieur : il ne fera l'appel que lorsque l'interruption en cours se termine, et choisira la plus prioritaire. C'est possible sous dsPIC/PIC24 en revanche, sous le nom de Nested Interrupts. Si malgré tout tu veux rester en PIC18, cherche parmi ceux qui possèdent un module QEI permettant de décoder les signaux de l'encodeur en quadrature.

Maintenant, il est vrai qu'une carte comme la RPI permet de simplifier une bonne partie du design, mais j'ai des doutes en ce qui concerne la motorisation et la lecture des encodeurs. Je dois par contre avouer ne m’être jamais penché sur les capacités temps-réel de la carte, et il est facile d'ajouter une carte d'interface par dessus pour ajouter des composants mieux ajustés.

Pour la CMUCAM, je te souhaite plus de chance que ce que nous avons eu. On n'est jamais arrivé à obtenir une méthode fiable de calibration permettant de l'utiliser sur la table, et l'idée a été abandonnée (on retente avec une Kinect et un couple ARM+FPGA cette année)



Bonne chance en tous cas!

Post Reply