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
SuPeRBaLoO
PMI
Posts: 669
Joined: Tue 02 Jun 2009, 15:22
Location: TDS-Team

Re: Cartes électroniques

Post by SuPeRBaLoO » Tue 24 Sep 2013, 07:50

GARGAMEL wrote:
Image
Bonjour,

quel composant utilisez vous en compteur decompteur ?
Toutes les infos sur notre team et nos robots: http://tdsteam.wordpress.com

antoine_cvra
Posts: 444
Joined: Mon 27 Aug 2007, 18:05
Location: Suisse

Re: Cartes électroniques

Post by antoine_cvra » Tue 24 Sep 2013, 08:02

Pour le Raspberry Pi, je pense que ça risque d'être compliqué, non pas au niveau interfaçage avec la motorisation / les codeurs (le Pi possède un port SPI), mais plutot au niveau temps réel si tu veux faire de l'odométrie ou de l'asservissement, tu risques d'avoir de la peine à avoir une fréquence fixe, Linux n'étant pas prévu pour.

a+

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

Re: Cartes électroniques

Post by Nirgal » Tue 24 Sep 2013, 08:09

bULBot wrote: 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.

Je doute...
Ce qui est certain, c'est que sur le PIC18F46k22, il y a bien deux niveaux d'IT. Le niveau haut pouvant préempter le niveau bas.
Après, tu as peut-être raison sur d'autres modèles... (?)

Je partage bien sur le reste de ton point de vue : un PIC18, c'est limite... pour l'application visant odométrie + trajectoires + déplacements + ...
Et effectivement, l'USB ne me semble pas vraiment indispensable pour développer sur PIC...
antoine_cvra wrote:Pour le Raspberry Pi, je pense que ça risque d'être compliqué, non pas au niveau interfaçage avec la motorisation / les codeurs (le Pi possède un port SPI), mais plutot au niveau temps réel si tu veux faire de l'odométrie ou de l'asservissement, tu risques d'avoir de la peine à avoir une fréquence fixe, Linux n'étant pas prévu pour.
+1
Le raspberry Pi est souvent plus séduisant qu'efficace pour faire du temps réel...
A moins de chercher à y grimper un OS temps réel (et préemptif tant qu'à faire)... et là, on tombe sur un autre problème : on manque d'interfaces et de broches d'entrées/sorties...

Si vous voulez profiter de cette carte... intuitivement je dirais qu'elle se prête bien aux algos 'haut niveaux'.. à condition d'y adjoindre une carte micro très temps réel à coté... (moteurs, codeurs, acquisitions...)
Nirgal
Robot-ESEO

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

Re: Cartes électroniques

Post by Bidouill » Tue 24 Sep 2013, 08:16

antoine_cvra wrote:Pour le Raspberry Pi, ... plutot au niveau temps réel ...Linux n'étant pas prévu pour.
Effectivement c'est le dilemme de Raspberrry. Il y a des portages d'OS temps réel tel que FreeRTOS et là tu as la maitrise de ta clock. Le problème c'est que pour le moment, du fait de l’architecture (électronique bas cout pondu par des softeux) de la Raspberry tu perds tout l'intérêt de la board en terme de périphérique. Pour exemple le LAN est monté sur un chip extension USB, donc il faut développer une stack USB et communiquer avec ce chip pour avoir du LAN. Bref Raspberry=temps réel c'est pas encore tout ça tout ça pour le moment.
Président de l'association de robotique I-Grebot de Grenoble
http://www.igrebot.fr | Wiki | Forum| Vidéos

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

Re: Cartes électroniques

Post by Keuronde » Tue 24 Sep 2013, 08:44

Nirgal wrote:
antoine_cvra l wrote: Pour le Raspberry Pi, ... plutot au niveau temps réel ...Linux n'étant pas prévu pour.
Effectivement c'est le dilemme de Raspberrry. Il y a des portages d'OS temps réel tel que FreeRTOS et là tu as la maitrise de ta clock. Le problème c'est que pour le moment, du fait de l’architecture (électronique bas cout pondu par des softeux) de la Raspberry tu perds tout l'intérêt de la board en terme de périphérique. Pour exemple le LAN est monté sur un chip extension USB, donc il faut développer une stack USB et communiquer avec ce chip pour avoir du LAN. Bref Raspberry=temps réel c'est pas encore tout ça tout ça pour le moment.
Je suis entièrement d'accord avec vous, l'utilisation du RaspberryPi ne servirai qu'a remplacer la partie CMUcam et ajouter une partie débug (par liaison série probablement). J'ai créé ce fil de discution car je cherche à concevoir notre nouvelle carte à microcontrôleur (et vous m'avez déjà donné des bonnes piste la dessus !). Je suis plutôt persuadé qu'un OS sur un processeur n'est pas adapté :
* Au pilotage des servomoteurs (précision requise de l'ordre de 0,1 ms)
* A la lecture d'un gyroscope (toutes les quelques ms)
* A la gestion de l'odometrie
* Au contrôle moteur

Comme SuPerBaLoO, je serai curieux de connaître les composants utilisés par RCVA pour la lecture des capteurs incrémentaux !
(J'ai déjà l'intention d'acquérir le gyroscope présenté par RCVA, alors pourquoi ne pas continuer avec un autre composant :) )
É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
GARGAMEL
PMI
Posts: 1183
Joined: Tue 14 Jun 2005, 17:16
Location: Ville d'Avray
Contact:

Re: Cartes électroniques

Post by GARGAMEL » Tue 24 Sep 2013, 11:01

Keuronde wrote: Comme SuPerBaLoO, je serai curieux de connaître les composants utilisés par RCVA pour la lecture des capteurs incrémentaux !
(J'ai déjà l'intention d'acquérir le gyroscope présenté par RCVA, alors pourquoi ne pas continuer avec un autre composant :) )
La demande de SuPerBaLoO m'a échappé, il s'agit du ls7366.
7366 R version DIP
7366 R-S version SOIC
RCVA: Robot Concept Ville d'Avray
http://www.rcva.fr

User avatar
SuPeRBaLoO
PMI
Posts: 669
Joined: Tue 02 Jun 2009, 15:22
Location: TDS-Team

Re: Cartes électroniques

Post by SuPeRBaLoO » Tue 24 Sep 2013, 17:45

GARGAMEL wrote:
Keuronde wrote: Comme SuPerBaLoO, je serai curieux de connaître les composants utilisés par RCVA pour la lecture des capteurs incrémentaux !
(J'ai déjà l'intention d'acquérir le gyroscope présenté par RCVA, alors pourquoi ne pas continuer avec un autre composant :) )
La demande de SuPerBaLoO m'a échappé, il s'agit du ls7366.
7366 R version DIP
7366 R-S version SOIC

Merci bien on va regarder ca de prés.

Pour nous on peut pas trop présenter notre système de carte électronique, puisque nous sommes en reconception globale.

Nous partons sur une architecture avec plusieurs carte dedié a une tache précise, et une carte maître. (technologie arduino nano)

Nous utilisons des cartes du commerce, que nous implantons sur nos pcb (ex carte adafruit motor control, carte de control AX 12)

Pour la réalisation nous faisons realiser nos pcb a des spécialistes, et nous soudons nous même.

On est en train de regarder si nous evoluons vers du cms pour gagner de la place
Toutes les infos sur notre team et nos robots: http://tdsteam.wordpress.com

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

Re: Cartes électroniques

Post by totofweb » Tue 24 Sep 2013, 21:45

Nirgal wrote:
antoine_cvra wrote:Pour le Raspberry Pi, je pense que ça risque d'être compliqué, non pas au niveau interfaçage avec la motorisation / les codeurs (le Pi possède un port SPI), mais plutot au niveau temps réel si tu veux faire de l'odométrie ou de l'asservissement, tu risques d'avoir de la peine à avoir une fréquence fixe, Linux n'étant pas prévu pour.
+1
Le raspberry Pi est souvent plus séduisant qu'efficace pour faire du temps réel...
A moins de chercher à y grimper un OS temps réel (et préemptif tant qu'à faire)... et là, on tombe sur un autre problème : on manque d'interfaces et de broches d'entrées/sorties...

Si vous voulez profiter de cette carte... intuitivement je dirais qu'elle se prête bien aux algos 'haut niveaux'.. à condition d'y adjoindre une carte micro très temps réel à coté... (moteurs, codeurs, acquisitions...)
Quelles que soient les préférences de chacun, on retombe toujours sur ce genre de problématique. On s'aperçoit toujours qu'il est préférable de répartir les différentes tâches de l'électronique numérique en deux ensembles :
- les tâches de gestion bas niveau, relativement simples et sans grand aspect décisionnel, qui tournent en permanence en tâche de fond, avec de grandes contraintes temporelles. Typiquement : interrogation de capteurs, comptage de pas, pilotage de servomoteurs, asservissement de moteur, monitoring température/courant/etc, etc...
- les tâches de haut niveau, avec de l'algorithmie complexe, mais qui peuvent se permettre une plus grande souplesse temporelle. Typiquement : stratégie de haut niveau, planification de trajectoires, logging/recording de débug, etc.

Une fois qu'on a identifié quelles étaient les contraintes de chaque tâche, on peut décider d'une méthode d'implémentation :
- On peut tout intégrer dans des microcontrôleurs, en jouant avec des interruptions pour gérer les tâches bas niveau.
- On peut s'aider de composants externes intégrant déjà des fonctionnalités utiles (exemple : composant de comptage de pas d'encodeur en quadrature, servomoteur dynamixel à interface série, etc) lorsque le microcontrôleur ne dispose pas de ces périphériques en interne, et que l'on ne peut pas se permettre un codage manuel pour des raisons de performances.
- On peut éventuellement répartir la tâche entre plusieurs microcontrôleurs si un seul a du mal à tout faire avec des performances suffisantes.
- Si les tâches bas niveau sont très critiques niveau timing et/ou que l'on souhaite de très bonnes performances dans leur gestion, il est possible de les intégrer dans un FPGA, esclave du contrôleur gérant les tâches de haut niveau (c'est l'architecture que je proposais).
- Si le FPGA est suffisamment performant, on peut aussi intégrer le microcontrôleur dedans (softcore) et ne plus rien avoir d'autre.
- Si les tâches haut niveau sont très complexes et/ou que l'on souhaite un environnement de développement type pc/linux, il est possible de les intégrer dans une carte PC embarquée et de se faire plaisir.

User avatar
Chbi
Posts: 132
Joined: Tue 20 Oct 2009, 15:53

Re: Cartes électroniques

Post by Chbi » Wed 25 Sep 2013, 10:23

Nirgal wrote:
antoine_cvra wrote:Pour le Raspberry Pi, je pense que ça risque d'être compliqué, non pas au niveau interfaçage avec la motorisation / les codeurs (le Pi possède un port SPI), mais plutot au niveau temps réel si tu veux faire de l'odométrie ou de l'asservissement, tu risques d'avoir de la peine à avoir une fréquence fixe, Linux n'étant pas prévu pour.
+1
Le raspberry Pi est souvent plus séduisant qu'efficace pour faire du temps réel...
A moins de chercher à y grimper un OS temps réel (et préemptif tant qu'à faire)... et là, on tombe sur un autre problème : on manque d'interfaces et de broches d'entrées/sorties...
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)

my 2 cents (de mécano, je précise, donc ça vaut pas grand chose =D)
Chbi
Plus ça marche pas, plus on a de chances que ça marche !

Supaero 2003-6, NoWheel Team 2007-17

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

Re: Cartes électroniques

Post by arno » Wed 25 Sep 2013, 19:53

Chbi 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.
Christophe Blaess en à fait une bonne analyse ici, avec tous les avantages/inconvénients de chacune de ces 2 cartes : http://www.blaess.fr/christophe/2013/05 ... -a-ronger/
Chbi wrote:Par contre, intégrer un RTOS sur une BBBlack, jamais entendu parler (jamais cherché, non plus, remarque)
Tu peux même mettre Xenomai sur RaspberryPi (patch temps réel pour linux), ce qui te permet de garder la souplesse de Linux et d'avoir des tâches temps réel dur (il mesure des latences inférieurs à 50 µs pendant ses tests): http://www.blaess.fr/christophe/2012/08 ... pberry-pi/

Tout son blog regorge d'articles liés aux OS temps réel et l'utilisation des périphériques des Raspi et BBB (dont les PWM et entrée Analogiques). Un must !

User avatar
Archi'Tech
Posts: 266
Joined: Mon 11 Aug 2008, 02:26
Location: Ouest

Re: Cartes électroniques

Post by Archi'Tech » Wed 25 Sep 2013, 20:31

Attention, il l'a dit lui même, les charges appliquées lors des tests de latence n'étaient peut être pas bonne. Il n'a d'ailleurs apparemment pas relevé les taux de cache miss, TLB miss, etc... déterminer le worst case est assez compliqué. Le mieux à faire à mon sens, si on veut être sur, c'est de déterminer un majorant en faisant des changements de contextes en invalidant tous les caches et le TLB. Ca donne un majorant du worst case, qui n'est pas non plus représentatif du cas nominal, mais, au moins, on sait à quoi s'attendre. Paradoxalement, un Cortex-M3 va assurer de meilleures latences qu'un Cortex-A15 (pour ce qui est du temps de réaction à une IT. Pour ce qui est du traitement, ça n'a plus rien à voir).
Jacen - Christian

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

Re: Cartes électroniques

Post by arno » Wed 25 Sep 2013, 21:16

Archi'Tech wrote:Attention, il l'a dit lui même, les charges appliquées lors des tests de latence n'étaient peut être pas bonne. Il n'a d'ailleurs apparemment pas relevé les taux de cache miss, TLB miss, etc... déterminer le worst case est assez compliqué.
Effectivement, faut pas prendre le résultat au pied de la lettre. L'objectif était de dire que ça existait, que c'était pas forcement trop dur à faire, et que ça reste assez performant.
Ensuite si on veux une précision à la milliseconde pour une tâche simple, un pauvre micro 8 bits d'il y a 10 ans le fera bien mieux. Un pic 16F84 de début 2000 à 4MHz pour piloter 10 servos moteurs ne bouge pas d'un iota sur les timings.
Mais pour ce qui est d’exécuter une tâche à une période de 1ms (voir un peu moins) de façon précise, ça peut se faire sur une raspi en gardant le noyau linux à côté et donc accès facile aux système de fichier, connexion réseau, affichage...

Perso je reste sur du combo STM32/BeagleBoard pour un projet perso, et on avait un dsPIC33/Raspi sur le petit robot de l'an passé (jusqu'à ce qu'on fume la raspi, après on a remis la strateg dans le pic ;) ).
C'est beaucoup plus simple et efficace. Chaque circuit est utilisé pour ce qu'il fait le mieux.

Enfin, la BeagleBoard est un peu particulière. A côté du proc principal se situent 2 CPU RISC nommé PRU pour "Programmable Realtime Unit" (Ok, ca reste un nom marketing). Ils sont extremement limités en instructions, n'ont pas d'OS, mais ça dépote (200MHz!). Ils communiquent avec le proc par une zone mémoire partagée, et ils ont accès aux I/O. C'est un peu violent (prog assembleur et compagnie), mais ça permet de faire un contrôleur de moteur pas à pas ou de servos super précis, et qui prends ses ordres du proc tournant sous linux. Un exemple ici avec un programme python décodant des trajectoires d'imprimante 3D et la PRU qui dépile les pas avec précision : http://hipstercircuits.com/accelerated- ... eaglebone/ (voir les articles de la catégorie "PRU" pour plein d'autre infos et exemple).

Bref, on voit bien que c'est les archi hybrides les plus performantes, que ça soit avec en mixant un gros proc avec OS avec un FPGA ou un microcontrôleur. Mais pour des besoins pas trop critiques, il y a moyen de faire déjà un peu de temps réel avec un noyau xenomai, si on est prêt à y passer un peu de temps.
Pour un robot, la BeagleBone reste quand même plus adapté que la raspi concernant les entrées/sorties (dont PWM et ana), les bus de communication plus nombreux (dont USB OTG, la raspi n'a que du maître), la flash interne en plus de la sd et un poil plus de puissance. Sauf dans le cas de l'usage d'une caméra, qu'il est beaucoup plus simple d'intégrer sur la raspi si on utilise le module produit par la fondation.

User avatar
la poutre
Posts: 79
Joined: Mon 10 Oct 2005, 21:53

Re: Cartes électroniques

Post by la poutre » Thu 26 Sep 2013, 10:20

Bonjour à tous,
De notre coté nous avons basé notre architecture élec sur des DsPIC 33E.
Sur le robot principal de 2013 nous avions 2 cartes polyvalentes et 1 carte moteur reliées par un bus I²C. La strat et l'asserv étaient sur une des cartes polyvalentes qui était elle même maître I²C.

La carte polyvalente (80x90mm) comprend:
2 LMD18200 + limitation de courant
1 chaine AX12 (6A)
1 RS232
2 I²C
12 Capteurs (Analogique/Numérique)
2 codeurs incrémentaux
Image

La carte moteurs (80x90mm) comprend :
8 LMD18200 + limitation de courant
2 RS232
1 I²C
2 codeurs incrémentaux
1 gros dissipateur absent sur la photo
Image

Plus de détails sur notre site et ici: http://www.usinages.com/robotique/sussu ... 47021.html

Vincent

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

Re: Cartes électroniques

Post by Nirgal » Thu 26 Sep 2013, 10:33

Salut "la poutre"...

Une petite question à propos de ton retour d'expérience sur ces connecteurs 'rouges'...

Qu'en penses-tu ?
Fiable ? Solide ? Maintenu ?...
Avez-vous eu des soucis avec... ?


Merci ! ;)
Nirgal
Robot-ESEO

User avatar
PEB
Posts: 13
Joined: Mon 07 Jul 2008, 14:25
Location: PARIS

Re: Cartes électroniques

Post by PEB » Thu 26 Sep 2013, 11:16

Nirgal wrote:Salut "la poutre"...

Une petite question à propos de ton retour d'expérience sur ces connecteurs 'rouges'...

Qu'en penses-tu ?
Fiable ? Solide ? Maintenu ?...
Avez-vous eu des soucis avec... ?

Merci ! ;)
Salut Nirgal,

les points forts de ces connecteurs :
+ suffisamment petit pour ne pas prendre trop de place, mais suffisamment gros pour ne pas galérer à les connecter.
+ ils vieillissent bien : même après plusieurs années, de nombreuse reconnexion, le connecteur tient toujours aussi bien.

les points négatifs :
- pour les sertir : ils sont vraiment fait pour être utilisé avec de la nappe fine. Je sertie souvent directement le câble des capteurs sur le connecteur, c'est possible mais demande de s'occuper des files un à un car la gaine est plus grosse que celle des nappes...
- le détrompeur : même si je les trouve assez résistant (il en reste sur la majorité de nos connecteurs^^), si vous avez des mécano un peu bourrin un peu comme chez nous (je ne vise personne... bon même s'il n'y a qu'un seul mécano dans notre équipe :D ), le détrompeur de certain connecteur y passera obligatoirement... un câble qui pend et assez long pour passer sous le robot ... un robot assez lourd... on pose le robot avec toute la délicatesse qu'un mécano peut avoir... et voila comme supprimer un appendisse de plastique sur un connecteur fraichement sertie!

Au final j'en suis assez content, je leur trouve un bon rapport taille/résistance.
SUSSUS INVADERS (http://sussusinvaders.fr/)

Post Reply