82 réponses à ce sujet

[Mike118]

Bon perso je préfère les architectures du style : 

Haut niveau ( raspberry ou autre ) => Middleware ( arduino mega ou autre ) => Slaves / capteurs 

Haut niveau middleware via uart 
Middleware vers slaves ou capteur : I2C ou GPIO en direct. 



 

[levend]

C'est un peu ce que je pense aussi c'est surtout la communication entre le RPi et plusieurs Arduino qui me dérange.

[Mike118]

plusieurs UART . 

Si besoin tu mets un hub USB. 

[levend]

J'aimerais bien vous mettre un schéma, mais je n'arrive pas à trouvé les éléments nécessaires (arduino, RPi) en téléchargement pour le logiciel que j'utilise (QElectrotech), SI vous avez un logiciel sympa et surtout plus adapté ...

[Mike118]

il y a pas mal de choses qui sont faite avec "fritzing " pour des tuto et autre... tu peux avoir des rendu sympas. avec des rendus dessins " réaliste " mais en mode dessin simplifié.

[Leon]

Pour les communications depuis un processeur central (Raspberry-Pi) vers les périphériques, il faut vraiment étudier toutes les solutions.

Typiquement, multiplier les connexions USB, et les convertisseurs USB-Série, comme le propose Mike, ça me semble une assez mauvaise idée.

 

Pour un réseau partagé entre 1 maitre et des esclaves, tu peux utiliser:

* si tes périphériques se branchent en USB, un hub USB

* port série asyncrhone :

    - en liaison point à point, c'est, de loin, le plus simple à utiliser et à débugger

    - pour faire 1 maitre et plusieurs esclave, avec 1 seul port série côté maitre, il y a plusieurs solutions à bidouiller. Pour plus de détails, demande moi. Ca nécessite de bidouiller au niveau soft, et d'inventer / adapter le protocole de communication (rien d'infaisable).

        + en anneau type token ring

        + en étoile avec 1 canal maitre vers esclave, et un canal partagé de retour;

        + en étoile avec 1 seul canal partagé par tout le monde.

* I2C : très pratique, mais assez limité en nombre d'adresses. Attention aux niveaux de tension 3 ou 5V. Comme c'est un bus partagé, le débit est limité par le périphérique le plus lent.

* SPI : c'est l'idéal. C'est très souple, et de plus en plus de périphériques utilisent ça. Je ne sais pas si l'Arduino est compatible SPI esclave (pour le PicBasic, c'est non). On peut monter à des débits élevés (10Mb/s ou plus pour certains périphériques). Mais c'est un peu plus complexe à mettre en oeuvre, il faut mettre les mains dans le cambouis. Même si c'est un bus partagé, le débit n'est pas limité par le périphérique le plus lent, et le maitre peut adapter son débit à chaque esclave.

* un mélange de tout ça selon les périphériques. C'est très souvent ce qu'on est obligé de faire.

 

Attention, beaucoup de ces réseaux ont des contraintes de distance. A toi de voir si tu veux regrouper toute ton électronique à un seul endroit de ton robot ou non.

 

Leon.

[Path]

Avant ton schéma, Levend, tu parles de combien d'Arduino ?

[levend]

Je pensais à 3 ou 4 Arduino, mais si tu regardes le dernier châssis que j'ai montré ça peut monter à 8 arduino (1 par module et 1 pour la base) et un RPi pour rassembler le tout, même si je doute de l'utilisation des 8 modules à la fois.

[Mike118]

En gros moi la solution que je " préfère " n'est valable que pour un nombre limité de port USB, genre 5 ou 6.  

Après on peut mettre plusieurs "ordinateurs " ( RPi odroid ou autre ) en parallèle , qui communiquent via l'ethernent. 

La combinaison dont leon parle je la fait au niveau du " middleware " 

On parle d'un middle  le avec des capteurs carte SD ou autre et de genre 6 arduino en dessous en slave avec chacun leur capteurs ou actionneurs ... 

Du coup si tu as déjà 2 middle dans ton architecture liée à un "ordianteur" ça te fait déjà une sacrée architecture en place ... 
 

Typiquement si tu prends le cas d'un bipède que tu veux très complexe. 
Chaque jambe serait compososé de plusieurs slave, pour gerer les capteurs, mettre les moteurs en positions etc ... 

Un middle serait capable de gérer les deux jambes. 

De la même façon, un bras serais composé de plusieurs slave,  et les deux bras seraient géré par un autre middle .

Un " ordinateur " est connecté aux deux middle , et gére les mouvements du robots grâces aux capteur. 

Sauf que si je veux que le robot soit aussi très intéligent avec une vision stéréoscopique, reconnaissance de personne etc ... En fait je vais mettre une architecture complète rien que pour la tête : qui elle contiendra du coup aussi un "ordinateur ",  dédié à la vision, avec son middle ses slaves pour faire bouger la tête et récupérer des données,  les deux ordinateurs dialoguant eux sur le réseau ethernet... 

après il est claire qu'il faut pas tomber dans le piège à avoir trop de noeuds et trop de branches ... 





 

[Leon]

@Levend:

8 arduino esclaves d'un seul Raspberry-Pi, ça ne pose aucun problème, c'est parfaitement faisable. Voir ce que j'écrivais un peu plus haut.

Tu as 3 solutions d'interconnexion, à toi de choisir.

*******************************

 

@Mike, je ne te comprends pas sur ce coup là.

Après on peut mettre plusieurs "ordinateurs " ( RPi odroid ou autre ) en parallèle , qui communiquent via l'ethernent. 

On parle d'un middle  le avec des capteurs carte SD ou autre et de genre 6 arduino en dessous en slave avec chacun leur capteurs ou actionneurs ... 

Du coup si tu as déjà 2 middle dans ton architecture liée à un "ordianteur" ça te fait déjà une sacrée architecture en place ...

 

Pourquoi parles-tu d'une telle usine à gaz? Ca n'est sans doute pas ce que recherche Levend, et ça n'est pas vraiment un bon conseil non plus.

Faire simple, c'est indispensable dans ce genre de projet complexes, c'est multiplier fortement les chances de réussite.

 

Pourquoi proposer plusieurs Raspberry-Pi?

 

*********************

Et pour finir, je ne comprends pas ce que tu dis. A un moment, tu parles de "middle" en désignant un Arduino, puis tu parles de "middle" en désignant un Raspberry-Pi. Bref, je suis complètement perdu.

Haut niveau ( raspberry ou autre ) => Middleware ( arduino mega ou autre ) => Slaves / capteurs

 

On parle d'un middle avec des capteurs carte SD ou autre et de genre 6 arduino en dessous en slave avec chacun leur capteurs ou actionneurs ...

 

 

Leon.

[Mike118]

Alors , en effet là je parle d'une usine à gaz mais pour décrire un système qui requiert une usine à gaz ... Exemple d'un bipède qu'on veut super complexe.  ( Et je ne parle que de comment moi je le ferais pas de comment cela est fait chez boston dynamics ou autre ... car eux je ne sais pas comment ils le gèrent ) 

Ce que je dis est un exemple, je précise bien que tout doit se faire en fonction du besoin, pas besoin de sortir la bombe atomique pour faire sont compte à une mouche , une tapette un piège à mouche ou une bombe insecticide suffit. 

Mais pour en revenir à ce que j'expose: 


En gros je distingue

 " High level " = " Ordinateur " = Represente un PC pour de l'embarqué un RPi , odroid ou autre 

" Middle "  = Microcontrôleur que tu mets directement en liaison avec un ordinateur  ex : arduino pic  etc...  qui lui est aussi en lien avec des slaves ou directement des capteurs ou autre actionneur

"Low level" ," Slave "   = Microcontroleur esclave du middle , en lien avec des capteurs ou des actionneurs, ça peut être d'autres arduino ou d'autre micro contrôleurs


En gros la partie qui intéresse levend est la partie " High level <=> Middle "   

Mais je parle aussi de slave car je me rappel que dans sont projet à un moment donné il a parlé d'un très grand nombre d'entrées sorties dont il avait besoin. 
Pour ce genre de chose personnellement je met en place des Slaves ... 

Bref la conclusion de mon discours est : Ceci n'est qu'une façon parmis d'autre de mettre en place une architecture ...  Le but est que chaque pertie de la branche soit elle simple ... Et qu'un assemblage de chose simple ( qui du coup certes devient complexe ) permette de faire quelque chose de complexe. 
Ce type d'architecture permet de faire du modulaire => Supresseion de branche , déplacement de slave ou de middle etc ... 

Pour ma part j'estime que plus de 3 niveau  après c'est vraiment beaucoup ...  (mais ça reste imaginable ... Exemple concret, on imagine un essaim de robot hyper complexe, afin qu'ils agissent ensemble j'ajouterais un niveau supérieur capable de dialoguer avec chacun des robots ...  )

Quoi qu'il en soit je pense que c'est un peu comme la mise en place d'un réseau de neurone, faut pas mettre trop de couches ni trop de liaisons et faut trouver un juste équilibre ...
En fonction du besoin tu ajoutes ou enlève des couches, parallélise des branches ou pas. 

Suis-je suffisamment claire Léon ? Ou trouve tu toujours que mon discours se contredit ? 

Un autre point à éclaircir ? 

Après si tu as des raisons à donner indiquant les points faible de l'architecture que je propose je suis tout ouïe Léon =) 

 

 

PS: Un middle peut avoir avec lui un module de carte SD et faire du log dessus ou autre ... Si jamais c'est cela qui perturbe 

[Leon]

3 niveaux de contrôleurs, c'est beaucoup trop pour un robot simple comme celui de Levend. Simple d'un point de vue électronique.

Le robot sera principalement télécommandé, donc nécessite très peu d'intelligence, de puissance de calcul, juste un nombre raisonnable d'entrées/sorties.

 

Je ne vois vraiment pas l'intérêt du niveau du milieu fait en microcontrôleurs, si en dessous tu mets d'autres microcontrôleurs.

 

Peux-tu m'expliquer l'intérêt? Pourquoi ne pas faire dialoguer directement le Raspberry-Pi avec les Arduino esclaves? Via un bus SPI par exemple.

On peut facilement mettre une dizaine d'esclaves.

 

Pourquoi donner des conseils issus de tes réflexions sur l'architecture électronique d'un bipède, pour Levend qui cherche des solutionspour un robot beaucoup plus simple?

 

Leon.

[Mike118]

En fait léon, quand j'ai détaillé, c'est par ce que tu as posé des questions, et cet exemple du bipède je te l'ai donné pour toi, pour donner l'exemple d'une machine à gaz pour une machine à gaz ... 

 

Pour levend : 

 

mon conseil : 

 

Haut niveau ( raspberry ou autre ) => Middleware  communication via Uart. ( après si toi tu veux conseiller le SPI : why not, mais côté " ordinateur " de manière plus générique ( aussi bien raspberry que PC portable ou autre )  tu trouveras plus facilement de quoi communiquer avec des ports séries voilà tout ... ) 

 

Et je propose ça tout simplement par ce que sans que je sache pourquoi : Il veut mettre une RPi et des arduino ... alors qu'il pourrait peut être par exemple uniquement utiliser une arduino ou deux pour tout piloter ( mais ça j'en sais rien du tout )

Ensuite si jamais il veut beaucoup d'entrées sorties analogique et qu'un middle ne suffit pas, soit il met plus de middle soit il peut mettre des slaves.  ( Et je parle de beaucoup d'entrées sortie car à un moment il disait qu'il n'aurait pas assez d'entrée sortie sur une arduino méga ) 

En soit l'architecture que je conseil à levend est loin d'être complexe. Par contre il est claire qu'on peut la complexifier si on veut faire une usine à Gaz. 

 

Enfin il est à noté que le choix de la forme de l'architecture n'est pas directement lié à un choix de protocole de communication, on pourrais mettre des bus can ou autre aussi ... Et même d'autre truc que je ne connais pas forcément. 

Mais si tu as des conseils léon vas y je t'écoute. Je reconnais que je n'ai pas la science infuse que je ne peut parler que de ce que je connais. Et le but d'un forum comme celui ci est d'échanger afin de tous progresser. 
 

PS : En fait le but du middle c'est de faire la tambouille I2C SPI etc... à ce niveau plutôt que de la faire au niveau d'un ordinateur qui n'intègre pas forcément tout ces protocoles de communication vu que le met un PC portable dans la catégorie de Ordinateurs au même niveau qu'un RPi ...  Mais bon après tout se discute ... Et je ne pense pas qu'il y ai qu'une unique façon de faire ou une largement meilleur que toutes les autres ... 



 

[levend]

J'ai lu vos réponses et cet après-midi j'ai fait quelques recherches sur le SPI, cela pourrait bien être la solution que je vais utiliser pour communiquer entre le RPi et les Arduino.

 

Mike > tout n'a pas tout à fait tort, apparemment tu a bien suivi mais c'est moi qui aurait du apporter de nouvelles infos, désolé :

• Au départ je prévoyais de commander les différents modules avec une seul Arduino, maintenant je me dit que chaque module aura son Arduino donc un nombre plus restreint d'E/S par Arduino
• Le choix du RPi au centre de tout, c'est d'une part parce que j'en ai à ne rien faire et d'autre part je le trouve plus adapté pour pour faire un robot modulaire,

Je pense aussi que deux niveaux suffisent, si je veux ajouter des capteurs (détection d'obstacle), soit je les connecte à l'arduino de la base, soit à une nouvelle arduino connecté au RPi.

[cocothebo]

Personellement, je partirai sur de l'i2c parce que franchement sauf besoin de débits importants, l'i2c c'est super pratique:

• facile à utiliser
• utilise peu d'I/O
• relativement rapide (jusque 100kbits/s voir 400 en mode fast qui est souvent disponible)

Bref en gros c'est un port série classique avec un adressage (en théorie sur 7bits mais @ par toujours modifiable sur des capteurs).

 

En SPI le gros prblème dans ton cas, va être la connexion à plusieurs arduino, le Pi n'a que 2 /CS de dispo (de mémoire) donc au max tu peux sélectionner 2 arduinos différents. Certes tu peut faire un SPI chainé, mais ça complexifie beaucoup le bouzin et surtout le côté arduino.

 

En i2c, tu veux rajouter un arduino, facile faut lui donner une @, et le rajouter celle ci dans le code du Pi, mais pas besoin de toucher au HW (a part brancher l'arduino sur SDA SCL commun). Si tu veux même faire une sorte de ségrégation, en utilisant des arduino due qui possédent 2 ports i2c tu peux faire des schémas du style:

 

         I2C1                       I2C2

 

         i2c                             ---> capteur 1

RPi -------> Arduino Due--| ... 

                                           ---> capteur n

 

Après le Due est un peu cher à mon goût, mais si ya un besoin d'un peu de puissance de calcul pour fusionner les données des différents capteurs dessous c'est parfait.

Et ça n'empêche pas non plus d'utiliser des capteurs sur UART, SPI ou autre depuis les arduino.

 

 

Après si tes capteurs (les potentiomètres motorisés?) ne sont pas i2c, alors la des simples arduino mini/nano/uno sont plus que suffisant vu que niveau arduino, tu mets l'@ que tu veux en tant que slave i2c; donc tu n'auras pas de problèmes au niveau @ (tant que tu ne dépasses pas les 128 arduinos différents)

[Leon]

Je confirme que l'I2C est vraiment simple à mettre en oeuvre. Plus simple que le SPI.

Si tu te contentes de quelques dizaines de kb/s de débit réel, c'est la bonne solution. Pour un robot radiocommandé semi-automatique, je pense que c'est le bon ordre de grandeur.

Au niveau des adresses I2C, j'ai déjà eu des problèmes. Les périphériques I2C ont souvent une adresse I2C configurables, mais je me suis déjà heurté à des problèmes d'adresses qui se chevauchent, et m'empêchaient de brancher 2 capteurs (non configurables) différents sur le même réseau.

 

Pour le SPI, on peut "facilement" dépasser la contrainte du fait qu'il y ait seulement 2 sorties CS sur le Raspbery-Pi. Il suffit d'utiliser des GPIO à côté comme sortie CS. Certes, c'est un peu plus complexe à programmer, mais rien d'infaisable. Le SPI est surtout utile pour les plus gros débits. J'ai déjà fait un montage avec un décodeur d'adresse 4bits donc 16 sorties, qui permet de piloter 15 CS de 15 périphériques SPI avec seulement 4 sorties GPIO sur le maitre. Pas 16, car il faut laisser un état "aucun périphérique sélectionné" en SPI, c'est impératif.

 

Leon.

[macerobotics]

Bonjour,

 

Le SPI peut aussi être utilisé en mode daisy chain, avec donc un seul CS.

[cocothebo]

Je suis d'accord avec vous, mais il me semble que Levend n'est pas (encore?) un pro de la programmation arduino/pi et qu'il cherche une solution simple.

Si on reste sur des capteurs/actionneurs type potentiomètres motorisés et des boutons en gros, le taux de rafraichissement n'est pas énorme.

 

Mettons qu'il faut commander des servomoteurs, la la fréquence "habituelle" (sur les servo de modélisme) de rafraichissement est d'environ 50hz.

    => il faut maxi 1 octet par servomoteur pour donner l'ordre, soit environ 50 octets par seconde,

          avec l'overhead (start condition + 1octet d'adresse + les ACK) on doit arriver a 250 octets par seconde

 

Les boutons on veut savoir s'ils sont appuyés un peu régulièrement mais pas non plus trop souvent (un humain n'appuyera pas 200 fois par secondes )

    => il faut pour simplifier 1 octet par bouton, 10 scan par secondes, soit 10 octets secondes

          avec l'overhead 50 octets par seconde

 

Même si on avait en plus des capteurs plus gourmand style accéléromètres ou gyroscope, idem le rafraichissement sera a maxi 100hz (en étant gentil)

   => 2 octets par valeur, si 6 axes acc+gyro => 12 octets, 100 fois par secondes soit 1200 octects

        avec l'overhead, 1600 octets par seconde

 

Bref on prend 10 servos moteurs, 20 boutons, 1 centralle inertielle, ca nous donne 10*250 + 20*50 + 1600 = 5100 octets par seconde

SI on veut être tranquille (je dis pas que j'ai pas oublié qqc niveau overhead ou autre), on double la valeur obtenue, soit 10 ko/s.

Ca passe très très bien en i2c.

 

 

Et ça c'est dans le cas ou on contrôle tout 1 par 1, dans le mode proposé je dirai qu'on peut avoir raisonablement une architecture du style:

le Pi qui communique avec 3 arduinos (1 pour les servos, 1 pour les boutons, 1 pour la centrale) ce qui réduit fortement l'overhead et donc le débit nécessaire (800 octets par seconde pour 10 servos, 150 octets pour les boutons, tjs 1600 pour la centrale)

La on passe a 4ko/s ce qui est encore beaucoup plus simple.

 

 

Bref tout est une question de dimensionnement, et le pseudo calcul fait au dessus est nécessaire. Une fois le débit maximum nécessaire, on peut alors regarder la techno à utiliser. Bien sur d'autres paramètre entrent en compte comme la distance sur l'interface, l'i2c par exemple n'est pas sensé faire de grandes distances, mais aussi la spécificité du protocole, Ethernet ne sert pas à la même chose qu'i2c, idem pour un bus CAN.

 

Mais je reste sur ma position dans le cas présent, i2c me semble vraiment très indiqué vu le bas débit demandé et le besoin de simplicité.

 

 

Le SPI serait nécessaire dans le cas de fort débits demandés (par exemple caméra).

[levend]

Bonjour,

 

Le SPI peut aussi être utilisé en mode daisy chain, avec donc un seul CS.

J'ai pas vraiment trouvé ce qu'était le mode daisy chain .

 

 

Mon choix de départ était l'I2C, mais je voyais l'adressage sur trois bit, donc beaucoup trop limité, d'où on orientation vers le SPI, mais j'ai vu de l'I2C pouvait avoir plus de 8 adresses, alors, pour le robot je pense communiquer avec l'I2C, j'ajouterai un "convertisseur" pour le RPI qui est en 3,3V si je ne me trompe pas.

 

 

Pour le moment, on laisse de côté tout ce qui est boutons potentiomètres (motorisés ou non), sur le robot ce sera plutôt des moteurs, des vérins ou des relais pour les actionneurs, pour les capteurs, je vois des capteurs de courant ou tension, peut-être des fin de courses dans un premier temps, des capteur US ou IR si je lui donne un peu d'autonomie.

il y aura du Ethernet plus tard, mais pour la communication extérieure...

[Leon]

Pour le convertisseur 3.3V du bus I2C, ça n'est pas forcément indispensable, il faut regarder les datasheets des différents composants.

Si tes composants 5V acceptent en entrée une tension de 3.3V, alors il suffit de mettre les résistances pull-up sur un 3.3V, et c'est tout!

 

Leon.