Après quelques réunions de crise avec @Matthieu, @Pierre@JLaplace, @Manon, @Xevel, nous avons décidé de développer la solution “Carte mère compute module + Option IO module”. Ce topic a pour objectif de préciser un peu les features dont nous allons avoir besoin dans cette carte.
#Les connectiques
##Connecteur Robotis
2 x TTL (molex 3 pins)
2 x RS-485 (molex 4 pins)
2 x XL-320 (molex 3 pins XL-320)
Dans notre archi il y a 2 USB2AX optionnel (contenu par la carte IO Module SODIM), en cas d’absence de ces USB2AX il faut pouvoir utiliser le port UART de la RPI pour driver les moteurs (TTL et XL-320). On sélectionnera le chemin de la com avec un jumper.
Nous envisageons aussi la possibilité d’utiliser la communication en mode RS-485 (uniquement avec les USB2AX. De la même manière le chemin de la com sera configurable à l’aide d’un jumper.
##Connecteur Arduino
N x UART (5V, RX, TX, GND)
I2C (5V, SCL, SDA, GND) + lvl shifter liker sur la RPI
Sur la partie arrière, il y a un Ethernet, un double port USB, des leds et un micro usb pour flasher la raspberry.
Tous les autres ports sont assez libres dans leurs emplacement. Attention sur les portes hdmi et usb interne il faudrait des ports v verticaux pour éviter que le connecteur dépasse de la zone de 80x72.
Il faudrait rajouter 4 trous pour fixer la carte, je vais essayer de définir ça au plus vite.
Si jamais la surface disponible ne suffit pas, je vais pas pouvoir vraiment augmenter les dimensions du rectangle (enfin pas plus de 2mm). Il faudra passer sur une autre forme géométrique, comme un pentagone ou notre bien aimé hexagone ^^
J’ai commencé un modèle 3D (dispo publiquement ici) pour visualiser un peu mieux à quoi ça pourrait ressembler, sous les SO-DIMM il y a environ 3mm de hauteur pour placer des composants et il reste “pas mal” de place pour mettre la forêt d’IO sur le côté:
S’il faut plus de place pour les IO, on peut souder tous les traversants sur une face et tous les CMS sur l’autre, en mettant les 2 les 2 SODIMM du même côté et en laissant le dessus pour toutes les IO:
Pour la position des trous c’est un peu libre mais je pense qu’il faudrait des trous de 3mm situés aux 4 coins sauf si un connecteur doit prendre la place, auquel cas on peut déplacer le trou proche du connecteur pour assure la stabilité de la board (un peu comme dans les exemples de cartes que j’ai fait).
@Xevel, est ce que tu peux me dire ce qu’il te manque comme info importante concernant la méca ?
J’ajoute un fichier DXF de la board pour importation dans Eagle/CircuitMaker: Poppy Motherboard - PCB.dxf (162.3 KB)
Je suis pas sûr du rendu, c’est la première fois que je le tente avec OnShape
on pourrait peut être laisser la possibilité de connecter la board à du 5V via le port micro-usb de prog situé à l’arrière ?
et à coté avoir un port de puissance 12V sur lequel se brancher en interne avec un convertisseur 5V ?
Ensuite pour la partie 12V, le plus simple serait un header 2pin tout con mais y’a pas de détrompeur. Sinon on a tendance à utiliser du molex 4 pin (style dynamixel) mais là, vu la place disponible je ne sais pas si on ne devrait pas prendre quelque chose de plus petit ?
Après je ne sais pas ce qu’il se passe quand on alimente à la fois la board via le 5V du port micro et en 12V via le port de puissance…
Je mets plein de banalités rapidement que vous avez p-t déjà discuté/trié.
Ce serait bien d’avoir les trous “traversant”, cad que les 2 SO-DIMM ne soit pas dans l’axe des trous pour qu’on puisse toujours monter la board. (Sur les trois propositions seul la derniere rempli ce critère (en décalant le Ethernet et USB un peu pour mettre un trou dans le coin))
Aussi avoir toute les connectiques utiles sur le dessus: tous les molex robotis, les pins arduino/IO, …
en facade, meme face que USB et Ethernet (mais p-t en dessous), HDMI + sortie son standard.
garder le même layout de PIN de sortie pour la RPI. Si possible mais bcp plus compliqué/impossible de même pour l’arduino (même si ce serait méga cool pour profiter des shields arduino.)
Avoir des PINs qui donne acces au 12V, au 7.5V et au 5V, important pour develloper sur son bureau. Aussi la sortie son en PIN. Aussi why not de l’USB en PIN.
Est-ce qu’on connecte un USB du compute module à l’USB de l’arduino (pour avoir la comm entre les deux)? Si oui comment? Est-ce que ça ne va pas bloquer la programmation USB de la partie arduino? (ou alors est-ce qu’on connecte directement leurs UARTs?)
le port USB que l’on voit permet-il de programmer la partie Arduino?
Est-ce que cette carte alimente les moteurs Dynamixel? (Je dirai oui), mais attention il ne faut pas surdimensionner l’alim (i.e. pour les gros robots comme Poppy/fendi/poppyrate, il est p-t préférable d’avoir une alim dédié. Pour Poppy ça passerait pck 12V, pas de régu, juste dimensionnement de la largeur de piste (et encore…les distributeurs d’alim qu’on utilise sur Poppy ont une bonne capa pour les appels de courant), pour fendi/poppyrate c’est plus chiant, on peut pas dimensionner une alim 7.5V/5A sur la carte…) -> Laisser la possibilité de déconnecté l’alim sur les broches molex? ou juste bien prèvenir les gens de couper le brin du cable correspondant à l’alim quand bcp de moteurs… (mais typiquement pour un petit robot, genre ergojr, ce serait hyper chaint d’avoir une alim en plus)
Alimentation
Il faut penser que l’on peut aussi brancher des batteries sur le robot. Cela implique plusieurs choses :
Pouvoir brancher 2 batteries LiPo (11.4V) on peut faire un seul connecteur et faire la dérivation sur deux fils qui vont se connecter aux batteries
découpler l’alimentation des moteurs et celle du contrôleur. On le voit avec les MX, quand il y en a un qui plante pour “overload” il faut rebooter tout le robot avec le risque de perdre la connection WIFI. L’autre chose est que la perte de charge due à une sur-consommation des moteurs peut faire rebooter le contrôleur.
Si on met une série de ports analogiques, il peut être judicieux d’en mettre un sur l’alimentation, comme ça, on a le niveau des batteries.
Le câble de base pour alimenter, le SMPS2Dynamixel est bien pratique quand on ne veut pas utiliser les batteries (lors d’une séance d’écriture de mouvement par exemple)
penser à comment faire un arrêt d’urgence
Cosmetique
Je vois en travaillant sur d’autres robots, qu’il y a des moments où on ne sait pas où on en est sans brancher un écran sur le port HDMI. Des petites LED, c’est peut-être rien mais ça peut dire énormément :
1 LED témoin d’alimentation
1 LED témoin de “running” comme la LED bleu qui clignote sur l’ODROID
1 LED témoin de connection WIFI (ça peut prendre du temps, et ça permet de savoir quand on peut ouvrir un SSH)
1 LED pour faire joli ou utilisable par l’utilisateur
L’autre chose est l’ajout d’un ou deux boutons poussoirs équivalents au bouton de la poitrine de Nao, Ca permet notamment de connaitre l’adresse IP du robot directement, ou bien de faire la demande d’acquisition d’une pose
Les connecteurs USB sont aussi un gros problème (fragiles). Savez-vous s’il existe des connecteurs USB enfichables comme des Molex ?
La Razor
Normalement, la Razor peut se connecter en USB sur le contrôleur, mais au final, c’est du RS 232. S’il y a moyen de connecter par exemple directement la Razor sur l’Arduino (via port série virtuel par exemple) Ca peut être cool.
On ne peut mettre qu’un HDMI et sortie son standard il nous les faudra les deux a l’intérieur de la tête.
Les connecteur en façade sont des chose qui doive être accessible pour une utilisation normal de la machine. Utiliser un robot comme ordi est un hack!
On est pas large en terme de place mais a voir…
Pour moi l’USB est trop délicat pour être mis en pin, d’autant plus que les USB ne sont pas gratuit ça implique de placer des HUB supplémentaire sur la carte. Ajouter des USB sur pin au cas ou coute cher pour des cas d’utilisation extrêmement faible.
Sur le IO module il y a un hub usb qui est relié a l’arduino, les aux 2 USB2AX. Donc le lien entre la RPI et l’arduino est équivalent a la connexion classic qu’on pourrais avoir avec une vrais RPI et Arduino par USB… En plus les 2 carte sont relier par I2C. On peut utiliser l’usb pour uploader du code sur l’arduino mais aussi pour échanger des infos.
A priori la partie alim sera déporté, pas la place ici et l’emplacement physique des alim est trop importante. Une alim hybride XL-320 et MX est a l’étude actuellement.
On a prévu une mini batterie (grosse capa) pour maintenir la carte en route en cas de chute de tension du robot.
Pour le moment la gestion des batteries n’est pas pris en compte, il vas falloir continuer à bricoler @Thot!
L’arret d’urgence ne sera pas non plus traité dans ce système, pour rappel cette carte ne gère pas de puissance, son seul rôle est de limité l’encombrement dans la tête et simplifier le montage…
Dans la version 1.1 il y aura un écran utilisant le port HDMI au niveau des yen, tu pourra l’utiliser a des fin de débug. Une led visible de l’extérieur a été envisagé mais les autre seront probablement dans la tête et ne seront pas facile a observer.
L’idée d’ajouter une Arduino dans la tête est justement de vous laisser libre d’ajouter toutes les features dont vous rêvez (bouton, led, razor, capteur capacitif…)
Déjà aujourd’hui le ventilateur dans la tête n’est pas obligatoire, il est utile pour refroidir la odroid (puissance = chauffe) la RPI ne nécessitera aucune ventilation.
Ca rajoute encore de la complexité de gérer la puissance sur cette carte, mais je pense que ce serait un énorme point positif pour la fiabilité des robots si on pouvait redémarrer les moteurs de façon logicielle.
Il y a un certain nombre de cas où les moteurs se mettent en erreur, et que la seule façon de s’en sortir est de le débrancher/rebrancher.
@nicolas Je trouve qu’il y a un certain nombre de ces idées qui sont intéressantes en particulier dans des cas d’utilisations hors Poppy Humanoid.
Le problème qu’on a pour le moment c’est qu’il n’y a pas d’écran pour raspberry compatible DSI de 4 pouces. Un premier écran compatible DSI vient de sortir mais il est en 7".
Du coup:
soit on fait le pari que raspberry pi sorte un adaptateur ou un écran 4" dans les 2 mois et on peut mettre le port HDMI à l’exterieur (en façade), hyper utile pour brancher un écran externe.
soit on doit mettre un micro HDMI en interne pour au moins avoir une solution fonctionnelle.
Peut être qu’on peut mettre un ensemble de pin sur lesquels tu peux mettre un shield, qui permet dans ce cas de rajouter une alim 7V@5A ?
@Thot
Effectivement, il faudrait trouver un moyen de pouvoir rebooter les moteurs sans rebooter la carte. J’avais pas pensé à ça. Quand on a qu’une alim comme c’est le cas maintenant c’est pas direct.
Pour le moment c’est pas mal tendu niveau place.
En fait, il faudrait presque considerer qu’on a une alim 5V propre qui arrive sur la carte mère et que toutes les gestions d’alim soit déportées sur une carte dédiée.
Oui bonne idée
Pour ça t’auras la arduino embarquée et tu pourras animer un sapin de noel si tu veux
Tout a fait c’est prévu
Pour ça, on va faire sortir 1 ou 2 GPIO de la raspberry pi et t’auras les pins digitals de l’arduino. Après tu peux mettre un bouton dessus et faire ton code qui gère ce que tu veux avec.
Les dynamixels qui ne bougent plus après un overload peuvent être relancés en remettant Torque Limit (celui dans la partie RAM) à une valeur non nulle. Je ne crois pas qu’il existe de cas qui nécessite vraiment un cycle puissance (à part si on considère les cas d’update firmware).
Notes: If the function of Alarm Shutdown is triggered, the motor loses its torque because the value becomes 0. At this moment, if the value is changed to the value other than 0, the motor can be used again.
Le cycle d’alim va aussi avoir l’intéret de remettre tout les servos dans leur état de démarrage, mais c’est faisable avec des commandes aussi (en réécrivant les registres en RAM a leur valeur au pire).
Des discussions qu’il y a eu, j’ai l’impression qu’il ressort 2 besoins qui sont peut être un peu opposés:
Avoir la carte la plus minimaliste et la plus petite possible,
Avoir la carte la plus pratique pour faire du dev robotique,
Les 2 sont de bonnes idées selon moi. L’une est plus orientée techno-geek qui sait ce qu’il fait, l’autre plus orientée utilisateur.
Dans le cas où l’on fait une solution plus orienté utilisateur, je vois ça comme un petit pc de dev avec une partie optimisée pour l’utilisateur et une partie optimisée pour le robot.
Pour la partie utilisateur, j’aimerais retrouver les connecteurs suivants accessibles depuis l’extérieur du robot:
port ethernet
USB x2
micro HDMI (permet de brancher un écran externe pour le dev et le debug)
port jack audio, stereo + micro (pour brancher sur des enceintes et micro externes)
micro USB de prog (pour changer l’image de la raspberry pi)
un port micro SD (extension de mémoire et fichiers utilisateurs, permet un accès facile à la mémoire et d’uploader de nouvelles images sans perdre les fichiers utilisateurs)
En interne, je ne mettrais que des connecteurs low profile, qui minimisent l’encombrement pris par les cables.
Ports moteurs (molex)
Ports à nappes (DSI, CAM)
Port USB sans le port usb (petits connecteurs à définir on s’en fout si on ne respecte pas les normes)
header (pair de pin) pour venir connecter des boutons à déporter
ports COM standards (UART, I2C,…)
header d’extension pour mettre des shields (par exemple l’alim sur des ergo ou des PWM)
Dans le cas, où l’on veut plus une carte minimaliste et très petite, pour moi, il ne faudrait quasiment aucun port dédié à l’utilisateur. Si ça doit être hyper integré sur un robot autonome, c’est bizarre d’avoir un gros port ethernet par ex.
Je verrais donc plus une sorte de port spécifique de prog sur lequel l’utilisateur vient brancher un cable et qui lui donne accès au réseau ethernet, des USB, etc… Une fois configuré, il débranche et c’est uniquement de la com sans fil.
Quelques autres points:
@xevel s’il n’y a pas l’audio sur la raspeberry pi compute module, est ce qu’on devrait pas l’ajouter sur l’io-module que tu as fait ? Il reste de la place en dessous et des pins libres. Genre stereo + micro en I2S ?
@xevel, on a oublié la question du Xbee, comment on pourrait integrer ça sur le carte mère ?
Si on fait ça signifie que ces pins seront utilisé que par des gens en mesure de faire des cartes électronique suffisamment avancé pour avoir de l’USB. Aucune autre carte ne propose des pins USB…
Un genre de port comme la mac… Le soucis avec ça c’est qu’on vas se retrouvé dans le même cas que mac il vas nous falloir des connecteurs pas standard, ce qui est chiant pour l’utilisateur et pour nous.
Avoir une carte qui fait des robot et le café est un grand défi que peut de gens savent relever. En regardant le specs que tu décrit je me demande pourquoi un utilisateur achèterais notre carte autrement que pour la placer dans un robot a base de robotis…
Pour revenir au prôblème de design un peut plus concret, j’ai regarder comment fonctionnais l’ethernet de la RPI et il utilise un Hub USB qui fourni 2 USB et une sortie ethernet, le LAN9512.
Il existe également une version qui permet d’avoir 4 USB et 1 ethernet, le LAN9514. C’est celui de la pi2 mais leur sch ne le représente pas…
L’audio quand à lui semble être géré directement par PWM par les GPIO40 et GPIO45, le hard est constitué d’une simple paire de passe bande.
Aujourd’hui nous avons fait une réunion avec @jgrizou, @Nicolas et moi-même pour refaire le point sur les différentes caractéristiques et priorités suites aux discussions qu’il y a eu ici.
Ainsi nous nous sommes mis d’accord sur le fait de commencer avec la solution suivante:
utiliser une raspberry pi compute module
utiliser l’IO-module contenant une Arduino Mega, 2 USB2AX, 1 IMU.
developper une carte mère ayant les connecteurs
Façade
1x Ethernet
2x USB (pour le wifi et une clé usb contenant les fichiers utilisateurs)
1x microUSB pour uploader les images raspbian
3 Leds: PWR (rouge), Activity (vert) et User (bleu)
J’ai regardé plus en détail le raspberry pi compute module et en effet, ça semble une bonne solution, surtout si la 2 va bientôt arriver. Super compromis avec cette solution.
Reliée par I2C ? Tu parles de quoi relié à quoi exactement ?
Il est nécessaire de déporter la carte alim - et il pourrait etre intéressant d’en developper au moins 2, une pour les gros robots et une pour les plus petits… La partie puissance dépend beaucoup de la taille du robot, la partie contrôle moins.
Une bonne carte puissance intégrerrai aussi les questions de protections et de séparation de l’alim de l’élec vs alim des servos, avec un moyen d’allumer/éteindre l’alim des chaines de servo (via un relais). Un arret d’urgence (toujours très utile!) serait alors uniquement sur les lignes d’alim servo.
Si on avait de la place et qu’on était certain de l’utilité de la possibilité d’avoir un écran interne OU externe, on pourrait mettre un chip multiplexeur pour pouvoir choisir logiciellement lequel est utilisé. Mais là, on a pas du tout de place, et pas l’impression que ce soit primordial…
Le XBee, je vois pas trop où on aura de la place là…
Ma carte mère a de l’usb sur un header 2.54, pour le cable qui alimente les deux ports de facade… donc ca peut se faire dans le principe. Et ce n’est même pas une hérésie, la norme USB ne donne pas de restriction sur les connecteurs internes à un produit, donc tant qu’on a les bonnes impédances on fait ce qu’on veut.
A quoi tu pense quand tu dis “connecteur nappe” pour du HDMI? tu as une ref de ce que tu veux?
Je ne connais pas la ref du connecteur mais il fait 19 pins, 14mm de large, 4mm de profondeur et 2,1mm de haut.
Après on fait un bout de PCB avec le connecteur qu’on voit, soit un HDMI male pour mettre dans l’écran, soit un HDMI femelle que l’on placerait en façade.
