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.
User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Cartes électroniques

Post by sikularobotik » Wed 02 Oct 2013, 17:12

Chbi wrote:
Nirgal wrote:
antoine_cvra wrote: A noter qu'il existe d'autres cartes du même acabit que la RPi, par exemple la BeagleBone Black qui présente plus d'entrées sortie, et certains types de bus directement. Une RPi est plus axée sur du traitement multimedia (pour faire un petit serveur à la maison par exemple), alors que la BeagleBone Black est plus pour faire du traitement de données, plus adaptée pour les robots je pense. Par contre, intégrer un RTOS sur une BBBlack, jamais entendu parler (jamais cherché, non plus, remarque)
Bonjour,

Nous utilisons une Beaglebone (blanche) et nous allons la remplacer à très court terme par la Beaglebone Black (on peut en acheter une chacun comme on travaille à distance). On a conçu une carte d'interface que l'on enfiche sur la Beagle et cela fonctionne très bien et c'est très sympathique. L'utilisation des PWM, des IOs et de l'I2C pour piloter (via une carte puissance) des moteurs et récupérer des infos capteurs fonctionne très bien sans trop de prise de tête. On a une nette préférence pour la Beagle sur la Rapsberry pour cette application à cause des IOs disponibles, en plus le Cortex A8 est quand même plus costaud que le pauvre armV6a de l'autre. On travaillera plus tard à confier le décodage de quadrature au module Hardware présent dans le SoC.

Je vous invites à suivre le lien Design Spark / Sikula dans la signature, un de nos membre a déjà posté 3 articles sur la Beaglebone Black. Il s'agit de la prise en main mais je penses que d'autres vont suivre, dont certainement un sur les aspect temps réel.

En attenant, pour le temps réel, il y a déjà moyen de faire un asservissement en montant la priorité du programme, si si ça tourne, après nous pensons appliquer un patch linux-rt ce qui suffira en terme de performances, enfin Xenomaï c'est faisable mais ça nous semble "overkill".

En théorie il y a deux "co-processeurs" temps réel dans le SoC mais pour le coup cela semble effroyablement complexe à utiliser, bien que cela soit fait pour gérer des IOs à haute vitesse... mais bon assembleur et les librairies de communications fournies par Texas sont... à explorer surtout qu'on peut facilement faire autrement.

EDIT : Cela ne doit pas être si dur les co-processeurs.... quelqu'un en a déjà parlé.

Valère
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

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

Re: Cartes électroniques

Post by Keuronde » Thu 17 Oct 2013, 22:30

Bonsoir à tous,

Même si je n'ai pas encore réalisé la carte, je crois que mes choix sont faits. Coté architecture, ce sera un Raspberry Pi en lien avec deux microcontrôleurs : un dsPIC33FJ128MC802 (qui existe au format SPDIP) et un PIC18F4550.

Le dsPIC33FJ128MC802 devrait gérer tout l'aspect positionnement hors recalages :
* 2 moteurs propulsion
* 2 roues codeuses
* le SPI pour le gyroscope
* 1 port I2C pour la communication avec le PIC18F4550
* 1 port I2C pour la communication avec le RPi (plutôt pour du débug)

Le pic18F4550 gérera la stratégie et les servomoteurs, si le temps le permet il recevra les info de reconnaissance d'image du RPi (le module caméra est arrivé hier, j'espère pouvoir faire tourner un code semblable à ceux que nous utilisions sur la CMUcam).

Je vais investir dans un PicKit, ça fait trop longtemps que j'aurai du le faire.

Enfin je vais tenter les CMS pour les ponts en H avec les A4950. Si la carte est trop grosse, je passerai aussi les µC en CMS, (au format TQFP)

Voila l'essentiel, une bonne partie des ces choix ont été fait grâce à vos retours d'expérience ! Merci beaucoup !

(Il est cependant probable qu'à la coupe, j'enlève le RPi si nous n'avons pas eu le temps de le programmer)
É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 » Fri 18 Oct 2013, 10:40

Le pic18F4550 gérera la stratégie et les servomoteurs,
C'est cool que tu sois arrivé à un résultat. Juste deux questions/remarques

Quitte à utiliser un dsPIC, pourquoi ne pas en mettre un second ? Il sera nettement plus puissant qu'un pic18. A ta place je remettrais un MC802, ce qui te permettra éventuellement de contrôler deux moteurs CC supplémentaires, de faire du pin swapping, d'implémenter des algos plus puissants...sans compter que tu n'as plus besoin de faire attention à la compatibilité des niveaux de tension (5V vs 3.3V).
A moins que tu ne comptes utiliser de l'USB, ce qui pourrait justifier le 4550. Mais tu peux aussi mettre un FTDI pour convertir un port série en USB.

Pourquoi deux I2C ? Je suis un peu rouillé à ce niveau là, mais normalement tu peux n'utiliser qu'un seul bus I2C et faire la sélection du noeud d'arrivée sur base de l'adresse.

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

Re: Cartes électroniques

Post by Nirgal » Fri 18 Oct 2013, 10:42

+1...

Intuitivement, j'aurais aussi visé deux micros identiques, pour ne pas multiplier les développements des couches basses (qui sont très différentes entre un 18F et un 33F)...
Mais, je ne connais pas bien sur la liste des contraintes qui induisent ce choix...

Bon développement en tout cas !
Nirgal
Robot-ESEO

User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Cartes électroniques

Post by sikularobotik » Sun 20 Oct 2013, 19:25

Je suis assez d'accord pour 2 uC identiques, cela évite d'éparpiller les efforts et puis si tu veux développer un algo de pathfinding par exemple tu ne crachera pas sur le gain de puissance de calcul.

Par contre j'utiliserais aussi 2 bus I2C distincts, cela laisse plus de capacités d'extensions et en plus en cas de problème sur le bus avec la Rpi l'autre plus critique ne sera pas en danger.

D'ailleurs tant qu'à utiliser deux DSPiC identiques pourquoi ne pas mettre les deux bus I2C "maitre" sur le uC "de commande" et considérer deux esclaves : le uC de déplacement et la Rpi/moteur de vision ? Ce n'est que ma vision des choses qui a certainement plein d'inconvénients... en tout cas bonne chance cela me paraît globalement un ensemble de choix judicieux !
-
Valère
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

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

Re: Cartes électroniques

Post by arno » Sun 20 Oct 2013, 19:57

Keuronde wrote:Même si je n'ai pas encore réalisé la carte, je crois que mes choix sont faits. Coté architecture, ce sera un Raspberry Pi en lien avec deux microcontrôleurs : un dsPIC33FJ128MC802 (qui existe au format SPDIP) et un PIC18F4550.
Je pense que tu t'embêtes un peu là vu le peu que le 18F a à faire. Le dsPIC doit pouvoir aussi gérer les servo-moteurs (à moins que tu ne sois limité par le nombre de broches, vu que c'est un petit boitier ?), ce qui t'éviterais d'avoir une seconde carte+programme et une liaison I2C supplémentaire à débugger.

C'est ce qu'on avait fait l'an passé :
- carte à base de dsPIC qui gères toutes les entrées (télémètres, capteur couleur, roues codeuses, tirette, couleur) et les sorties (servo moteurs, pas à pas, électro-aimant)
- RaspberryPi pour la stratégie et éventuellement caméra si on avait pris le temps
Les 2 étaient reliés par un simple port série, pas d'I2C.

L'intérêt est que c'est assez souple à débugger. Pour le dsPIC il suffit de lui envoyer des commandes par port série, donc ça le fait de n'importe quel PC avec un FTDI sur USB. Pour la stratégie, on branchais un petit écran 7" sur la raspi et on avait tout le détail des trajectoires demandées par le pathfinding, de la pondération des objectifs, du temps restant... On avait aussi une appli de test graphique qui permettait de tester toutes les commandes du dsPIC, très utile pour valider le bon fonctionnement des roues codeuses ou regler les positions des servo-moteur.
Mais bon, pendant la coupe mon alim à découpage est partie en fumée entrainant la raspi avec, donc on a recodé une partie de la stratégie dans le dsPIC pendant la nuit... :roll:

Mais comme l'a dis Nirgal, je ne connais pas toutes tes contraintes, donc cela ne s'applique peut être pas chez toi.
Bon courage !

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

Re: Cartes électroniques

Post by Keuronde » Sun 20 Oct 2013, 22:19

Alors effectivement, mettre deux microcontrôleurs différents, ce serait chercher les problèmes mais ça fait longtemps que je développe sur pic18F2550 (le petit frère du 18F4550), j'ai les codes qui vont bien pour l'I2C, le pilotage des servomoteurs, la liaison série, le pilotage des moteurs...
Donc par rapport à mes connaissance, c'est plus le dsPIC qui est rajouté. Le 18F constitue un module qu'on est à peu près sur de savoir faire marcher rapidement.
bULBot wrote:sans compter que tu n'as plus besoin de faire attention à la compatibilité des niveaux de tension (5V vs 3.3V).
Effectivement, lorsque j'ai attribué les fonctions à chaque broche, j'ai cru que ça n'aller pas bien se passer. Mais le bus I2C n°1 du dsPIC est sur des broches supportant le 5V.
arno wrote:(à moins que tu ne sois limité par le nombre de broches, vu que c'est un petit boitier ?)
De base, c'est ça qui nous a fait passer du 18F2550 (28 broches) au 18F4550 (40 broches)
arno wrote:Pour le dsPIC il suffit de lui envoyer des commandes par port série, donc ça le fait de n'importe quel PC avec un FTDI sur USB
Pour moi, FTDI était synonyme de CMS, donc de pas soudable à la main. C'est une position qu'on est en train de revoir notamment pour les ponts en H A4950, puis peut-être aussi pour les microcontrôleurs si on a un problème de place...


Voici l'historique qui explique toutes ces liaisons :
Nous avions un PIC18F maitre I2C qui communiquait avec une caméra (CMUcam) par le port série. Parmi les esclave I2C on avait d'autres cartes à base de 18F (dont des cartes moteurs) et un gyroscope I2C (Wii MotionPlus). Sur la nouvelle carte on garde la même architecture, d'où la liaison série PIC18F4550 <=> RaspberryPi et la liaison I2C PIC18F4550 maitre <=> {dsPIC33 + ancien gyroscope si ça se passe mal avec le nouveau (genre un problème de temps)}
Nous avons repéré un nouveau gyroscope (grâce à Gargamel ! Merci à lui !) qui communique en SPI. Malheureusement le PIC18F4550 utilise les même broches pour l'I2C et le SPI, c'est en partie pour cela que le gyroscope est rattaché au dsPIC33.

Je voulais une liaison pour du debug/log entre le dsPIC et le RaspberryPi, le SPI est en mode maitre pour le (nouveau) gyroscope et je suppose qu'on a la même blague que pour l'I2C, pas de mode esclave pour le Raspberry (mais je peux me tromper). La liaison série du RaspberryPi (la seule dispo sur le connecteur GPIO) est pour le PIC18F4550. Il reste donc l'I2C en mode maitre pour le RaspberryPi, esclave pour le dsPIC.
Je ne tiens pas à avoir un bus I2C avec plusieurs maîtres dessus, j'ai assez d'innovations comme ça pour me planter cette année !

sikularobotik wrote:D'ailleurs tant qu'à utiliser deux DSPiC identiques pourquoi ne pas mettre les deux bus I2C "maitre" sur le uC "de commande" et considérer deux esclaves : le uC de déplacement et la Rpi/moteur de vision ?
Côté I2C, le Raspberry Pi ne propose pas de mode esclave et je crois que ce n'est pas un simple problème de pilote, c'est le matériel qui n'a pas le module adéquate. Or il me semble important, pour des raison de temps que le bus I2C principal soit piloté par un microcontrôleur.

Enfin la cerise sur le gâteau (ce qu'on fera une fois qu'on aura finalisé la reconnaissance d'image - donc pas tout de suite), j'espère pouvoir reprogrammer à distance la stratégie via le RaspberryPi en Wifi et la liaison USB RaspberryPi <=> PIC18F4550

C'est un peu abstrait comme ça sous forme de texte si j'ai le temps, je ferai un schéma avec les deux architectures, l'ancienne et la nouvelle...

Merci encore pour tous vos retours et vos conseils !
É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 » Sun 20 Oct 2013, 22:41

Ok ca explique les choix.

Pour les FTDI, il existe des petites plaques (chez Sparkfun, Adafruit ou autre ex http://www.robotshop.com/search/search. ... words=ftdi) avec toutes les bornes accessibles;
Ceci dit les circuits SOIC comme le FTDI ne sont pas très compliqués à souder à la main: il faut juste en sacrifier un ou deux pour s'entrainer, mais c'est à ça que servent les échantillons gratuits de Microchip et de TI :lol:

Sinon, en ce qui concerne la RPI, tu peux toujours utiliser un canal UART plutot que de l'I2C. Du coup, il n'y a ni maitre ni esclave ( de l'amour et du pain...ok j'arrête) et ça te libère l'I2C et/ou l'USB. On avait fait un truc semblable avec une Panda Board, avec un MCU qui servait d'interface avec le bus CAN du robot

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

Re: Cartes électroniques

Post by arno » Sun 20 Oct 2013, 23:03

Keuronde wrote:Alors effectivement, mettre deux microcontrôleurs différents, ce serait chercher les problèmes mais ça fait longtemps que je développe sur pic18F2550 (le petit frère du 18F4550), j'ai les codes qui vont bien pour l'I2C, le pilotage des servomoteurs, la liaison série, le pilotage des moteurs...
Effectivement, quand on a toutes les infos, ca se justifie !
Keuronde wrote:
arno wrote:Pour le dsPIC il suffit de lui envoyer des commandes par port série, donc ça le fait de n'importe quel PC avec un FTDI sur USB
Pour moi, FTDI était synonyme de CMS, donc de pas soudable à la main.
Pour moi, c'est un abus de langage... Je voulais juste dire un convertisseur USB/Série, qui existe avec des niveaux de tension 3.3V en tout fait, genre ça : http://www.adafruit.com/products/70 ou https://www.adafruit.com/products/954 (qui est à base de PL2303 donc pas FTDI...).
Le fait de voir des FTDI partout sur des cartes elec fait que je mélange le nom du produit et la fonction ;)

Bonne continuation sur ce projet !

User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Cartes électroniques

Post by sikularobotik » Mon 21 Oct 2013, 00:21

bULBot wrote:Ok ca explique les choix.
Ceci dit les circuits SOIC comme le FTDI ne sont pas très compliqués à souder à la main: il faut juste en sacrifier un ou deux pour s'entrainer, mais c'est à ça que servent les échantillons gratuits de Microchip et de TI :lol:
Oui du coup les choix sont très logiques :D .

Si je ne m'abuse le FTDI est en SSOP, bien qu'avec un peu d'habitude il n'y ait guère de différence quand on commence autant le SOIC est vraiment facile à souder autant le SSOP peut faire un peu plus peur :wink: . C'est surtout quand le tirage des cartes est artisanal que le SSOP n'est pas très pratique.... Mais bon avec les 10 exemplaires 10cm 10cm double face, vias, vernis, sérigraphie, à 25€ frais de port compris sur des sites comme Seeedstudio (ou autre DF Robot ou ... à compléter) on voit les choses très différemment.

D'ailleurs pour ceux qui n'auraient pas encore franchis le pas du CMS partout, notre bon amis Dave (eevblog) explique ça très bien avec son accent australien :http://youtu.be/b9FC9fAlfQE

Personnellement je ne soude que rarement les pins une par une, j'aurais donc pratiquement une préférence pour le SSOP, mais je cherches les ennuis :evil:
- je fixe le composant avec de l'étain sur les deux coins opposés
- ensuite je traine plein d'étain, si j'ai assez de flux il n'y a pas de cc
- s'il y a des court-circuits la tresse à dessouder permet de l'enlever, et paradoxalement ça chauffe moins le composant que patte par patte
Keuronde wrote:Enfin je vais tenter les CMS pour les ponts en H avec les A4950. Si la carte est trop grosse, je passerai aussi les µC en CMS, (au format TQFP)
Sympathique petite bête, je l'avais pas trouvé, on a adopté les DRV8801 (en échantillon chez Texas ;-)) et j'ai eu très peur de ne pas arriver à les souder en... Power SSOP on avait prévu de pouvoir rater 8 cartes sur 10 à cause de ça l'an dernier finalement on en a raté aucune et sacrifié aucun composant.
Si tu n'as pas de station à air chaud pour souder le pad thermique de l'A4950, il y a quand même moyen on l'a fait (à 4 mains) avant que j'achètes la station à air chaud. Dans tous les cas on a apprit qu'il valait mieux prévoir le coup en faisant dépasser l'emprunter de connexion du pad thermique de chaque côté et sur chaque face et... sans vernis pour pouvoir chauffer (on saura pour la prochaine fois :lol: ).
--
Valère
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

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

Re: Cartes électroniques

Post by bULBot » Mon 21 Oct 2013, 00:40

sikularobotik wrote: Si je ne m'abuse le FTDI est en SSOP
De fait, je me suis trompé.
Et vive les PCB à 10€ de SeeedStudio, j'ai déjà fait faire quantité de PCB pour des projets en tout genre chez eux, et je n'ai jamais été déçu.
Sympathique petite bête, je l'avais pas trouvé, on a adopté les DRV8801 (en échantillon chez Texas ;-))
Très sympas ce chip. On utilise son grand frère à trois demi-ponts (DRV8312) pour alimenter nos BLDC, mais on va passer sur du L6234 de ST qui est plus simple d'utilisation et qui demande moins de composants. Je viens de finir de router la carte d'alim' des moteurs, reste à l'envoyer chez Eurocircuits.

Bidouill
PMI
Posts: 846
Joined: Wed 07 Jun 2006, 10:48
Location: Grenoble
Contact:

Re: Cartes électroniques

Post by Bidouill » Mon 21 Oct 2013, 08:43

bULBot wrote:Et vive les PCB à 10€ de SeeedStudio, j'ai déjà fait faire quantité de PCB pour des projets en tout genre chez eux, et je n'ai jamais été déçu.
Plutôt d'accord, c'est de la bonne came.
Sympathique petite bête, je l'avais pas trouvé, on a adopté les DRV8801 (en échantillon chez Texas ;-))
Adopté également chez nous avec sont grand frère le DRV8843.
Je viens de finir de router la carte d'alim' des moteurs, reste à l'envoyer chez Eurocircuits.
J'imagine que c'est un sponsor parce qu'ils sont pas donnés!!
Président de l'association de robotique I-Grebot de Grenoble
http://www.igrebot.fr | Wiki | Forum| Vidéos

User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Cartes électroniques

Post by sikularobotik » Mon 21 Oct 2013, 16:58

bULBot wrote: Et vive les PCB à 10€ de SeeedStudio, j'ai déjà fait faire quantité de PCB pour des projets en tout genre chez eux, et je n'ai jamais été déçu.
On commence à avoir fait le tour aussi, 5x5cm à 10€, 10x10cm à 25€, panélisation autorisé de plusieurs cartes sur une 10x10 sans surcoût, découpe de la carte à une forme spécifique (inclus), livraison normale, production / livraison rapide.... et les PCB sont nickels y compris en 0.2 mm pour les pistes.
J'ai chauffé de bon coeur aussi mais pas de décollement pour l'instant mais peut être qu'en y allant méchamment plusieurs dizaines de fois il y a moyen de faire lâcher le PCB... quoiqu'avec 10 exemplaire pour un besoin habituel limité à 2/3.

La seule chose qui est moins bien que le reste c'est que parfois la sérigraphie n'est pas parfaitement parfaitement alignée mais bon.... tout le reste est nickel aligné donc on ne se plaindra pas à ce prix.
Mais bon il vaut mieux le savoir suivant les applications, parce que chez nous ils y en a qui aime faire de la déco sur PCB....

Ah et la production n'est pas RoHs... mais pour du prototype c'est pas délirant vu la différence de prix.
Si cela vous intéresse je peux envoyer des photos de nos PCB sur demande (j'ai la flemme de les héberger pour les intégrer au message...).

Avant de découvrir ça on se torturait l'esprit pour les cartes avec notre budget limité... même si fondamentalement je préférerais faire produire les PCB en Europe voir en France ce n'est juste pas réaliste !
bULBot wrote: Très sympas ce chip. On utilise son grand frère à trois demi-ponts (DRV8312) pour alimenter nos BLDC, mais on va passer sur du L6234 de ST qui est plus simple d'utilisation et qui demande moins de composants. Je viens de finir de router la carte d'alim' des moteurs, reste à l'envoyer chez Eurocircuits.
Vous utilisez des moteurs Brushless pour la propulsion ? Avec retour par capteur Hall ? Cela m'intéresse on y avait pensé mais on a renoncé par manque de temps pour construire un custom contrôleur...
--
Valère
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

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

Re: Cartes électroniques

Post by bULBot » Mon 21 Oct 2013, 18:18

sikularobotik wrote: Vous utilisez des moteurs Brushless pour la propulsion ? Avec retour par capteur Hall ? Cela m'intéresse on y avait pensé mais on a renoncé par manque de temps pour construire un custom contrôleur...
Oui, et oui.
Ca prend un peu de temps à développer, autant du point de vue software que hardware, mais on y gagne vraiment en encombrement et aussi au niveau du prix des moteurs (on devait de toutes façons en racheter l'an passé, on en a profité pour franchir le pas).
Enfin, ça nous a surtout pris du temps parce qu'on a décidé de recoder la régulation en même temps. Au niveau des BLDC le soft se résume à regarder l'état actuel des effet Hall et à activer les bonnes phases en conséquence. En gros, une phase est laissée flottante, et la PWM est appliquée entre les deux phases de manière à faire tourner le moteur dans le sens voulu. Au fur et à mesure que le moteur tourne, la valeur des capteurs à effet Hall change et on assigne des valeurs différentes aux trois phases. Tout ça est bien expliqué dans une AppNote de Microchip.

Niveau hardware, il faut un driver avec trois demi-ponts qui peuvent être activés/désactivés individuellement de manière à pouvoir effectivement choisir la phase flottante. TI et ST en ont plusieurs. Le DRV8313 (le petit frère du surpuissant DRV8312) de Texas est vraiment sympa et a le bon goût de ne pas nécessiter trop de composants externes, mais on avait des problèmes avec la limitation de courant qui s'enclenchait alors qu'on était en moyenne très loin de la valeur d'enclenchement. La cause était que le ripple de courant dû à la PWM était trop important. Mais ça dépend fort de l'inductance du moteur, de la fréquence de la PWM donc il faut voir si ça ne convient pas pour vous.

Je suis en train de (lentement) écrire un article à ce sujet sur notre site. J'espère le publier bientôt. Les plans de notre carte de propulsion seront également disponibles.

User avatar
sikularobotik
Posts: 64
Joined: Wed 02 Oct 2013, 00:30
Location: Grand Ouest
Contact:

Re: Cartes électroniques

Post by sikularobotik » Mon 21 Oct 2013, 22:54

bULBot wrote: Je suis en train de (lentement) écrire un article à ce sujet sur notre site. J'espère le publier bientôt. Les plans de notre carte de propulsion seront également disponibles.
Génial, si tu peux je veux bien que tu nous prévienne quand l'article sera prêt, j'en connais un qui sera très intéressé (en plus de moi).

Nous on prépare aussi des articles mais plus orientés BeagleBone Black (utilisation des E/S bref dans le thème Cartes électroniques / temps réel) et imprimante 3d (Printrbot).
--
Valère
--
Association Šikula Robotik
2016 Axolotl & Harvé
2015 Aventurier
2014 Australopithèque,Zinjanthrope
2013 Brownie&CrèmeA., Zlabia
2012 Albator, Zabulbo
http://sikula-robotik.desbwa.org
Twitter : @SikulaRobotik
Youtube : SikulaRobotik

Post Reply