Cartes électroniques

[SuPeRBaLoO]

Bonjour,

quel composant utilisez vous en compteur decompteur ?

[antoine_cvra]

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+

[Nirgal]

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...

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...)

[Bidouill]

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.

[Keuronde]

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 )

[GARGAMEL]

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

[SuPeRBaLoO]

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

[totofweb]

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.

[Chbi]

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)

[arno]

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/

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 !

[Archi'Tech]

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).

[arno]

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.

[la poutre]

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


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


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

Vincent

[Nirgal]

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 !

[PEB]

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 ), 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.