J’ai cherché a comprendre pourquoi il était impossible d’utiliser qu’un seul USB2AX sur poppy. Pour cela j’ai placé un petit espion sur le réseaux des dynamixel :
Sur le graphe on peut voire la boucle de synchro à 50hz de tous les moteurs du bas de Poppy. En gros j’ai évalué le taux d’occupation du bus à 16% environ.
Du coup je ne vois pas bien pourquoi il y a des problèmes lorsque tous les moteurs du robot sont placé sur le même bus…
Wow intéressant! mais l’erreur principale que j’avais avec un seul USB2AX était un checksum error. Je ne sais pas si tu peux investiguer ça avec cet outil.
Ca parait compliqué, je pourrais décoder les messages, mais il parrais difficile d’évaluer si le message est bien ou pas…
Le soucis pourrait peut être venir de l’impédance de la ligne, peut être que le fait de relier tous les moteurs influe sur les temps de transition et favorise les erreurs d’interprétation de bits!
Je vais tenter d’autres tests dans la journée.
##2 bus dans poppy
J’ai refait exactement la même configuration que mon premier graph, je l’ai juste mieux fait. J’ai activé le décodage du réseaux et l’outil repère un bon nombre de “framing error”.
Du coup j’ai cherché a observer la qualité des signaux.
C’est pas fou mais ça passe dans la plupart des cas.
##1 bus dans poppy
Ensuite j’ai placé tous les moteurs sur le même bus dans le robot, le taux d’occupation explose par la répétition des messages raté :
Les signaux sont largement dégradé :
Le problème viens donc probablement de la qualité des signaux plus que du débit!
Ah oui, ça éclaire énormément ! @Xevel pourrait expliquer ? l’“antenne” est plus longue ? J’ai remarqué aussi qu’entre les deux connecteurs Molex d’un servomoteur MX-28, ce n’était pas un fil qui était tiré (en tous cas pour le +12V) Plus tu enchaines les servomoteurs, plus il y a une perte de charge qui apparait (pour arriver en dessous de 10V dans certains cas)
En effet, c’est moche.
Le problème ici, c’est la capacitance totale et la protection contre le +12V sur Data.
Le bus augmente sa capacitance chaque fois qu’on ajoute un bout de fil dessus, donc avec un seul USB2AX tu va avoir toute la capacitance du bus en face (au lieu d’environ la moitié), ca va être plus difficile à faire bouger.
La facon dont l’USB2AX est protégé contre le +12V sur la ligne DATA apporte son lot de problèmes aussi.
La diode zener a une capacitance d’environ 130pF (ce qui est déja beaucoup!), et il y a des resistors (100ohm PTC entre la diode et le bus pour proteger du 12V sur un temps indéfini, et 150ohm de entre le MCU et la diode pour proteger les pattes du MCU quand le bus est bloqué à 12V, et que la diode est bloquée a 5V1).
Donc habituellement, sur un bus sans trop de capacitance, on arrive a un état un peu dégradé mais ca tourne encore.
Dans mes tests habituellement avec une 20aine de servos @ 1Mbps c’est pas aussi mauvais que sur ta seconde courbe…
A noter que c’est un probleme que je compte régler pour l’USB2AX v4, vu qu’il doit pouvoir parler a 3Mbps, et cette situtation ne passe juste pas à une telle vitesse.
Les tests ont ils été faits avec un vrai USB2AX ou avec votre carte de contrôle pour Poppy ?
Il existe des fix, du plus simple et moins satisfaisant au plus compliqué (et pas forcément tres satisfaisant non plus):
Ca, c’est un autre problème: c’est la baisse de tension créée par la résistance du bus. Cette résistance croit avec chaque centimeter de cable et avec chaque connecteur.
J’ai fait des mesures et calculs et j’arrive, avec les cables officiels de Robotis, à une résistance de:
R = 8.1 * N + 102 * L
R = résistance en mOhm
N = nombre de cable en série
L = longueur totale des cables en m
La partie qui dépend du nombre de cables compte pour les connecteurs (~3.6mOhm mesuré par connecteur)+ la résistance entre les connecteurs dans un servo (~0.9mOhm mesuré, à peu pres identique sur les AX et RX-28, pas testé sur les autres).
La partie qui dépend de la longueur est simplement due à la résistance des fils (environ 100mOhm/m).
Pour avoir une vrai idée de la baisse de voltage, il faudrait faire le calcul par partie : le premier segment voit passer tout le courant de la chaine, le second segment ne voit passer que pour ceux qui restent, et ainsi de suite jusqu’au dernier qui voit passer le courrant du dernier servo uniquement. Mais si on est motivé, ca pourrait etre mis dans une feuille Excel ou un script assez facilement pour avoir une idée de la baisse de voltage à un point donné du circuit, en supposant qu’il s’agit uniquement d’une chaine. S’il y a des branches, cela complexifie un peu…
Il faut aussi estimer l’intensité (50mA par servo en standby, mais beaucoup plus quand ils bougent…).
Par rapport à ta dernière remarque et dans l’optique de développer de nouveau servo. Est-ce que tu vois une utilité à avoir une alim plus forte (e.g. 24V) et de la réduire à la tension moteur (e.g. 12V) dans chaque servo ? Ainsi même le servo en bout de ligne conserve les mêmes caractéristiques. Ou aura t’on trop de perte?
Sur le principe, transporter l’énergie avec une tension plus haute que celle dont on a besoin et la réduire au point de consommation, c’est théoriquement alléchant.
Mais quand on met tout les autres facteurs en jeu, ca devient vite moins rose.
Oui, le convertisseur aura l’avantage d’immuniser le servo des baisses de tension du bus, et on aura moins de perte de puissance dans les fils (quand on regarde uniquement les fils, P=RI^2 et U=RI, donc en doublant U à résistance constante on a divisé l’intensité par 2 et la puissance perdu dans les fils par 4).
Mais en même temps, on aura ce convertisseur DC/DC à chaque servo. Ca coûte cher, et pour faire passer les quelques ampères que le servo nécessite, il sera gros et il chauffera.
De plus, selon le design, ce convertisseur n’aura pas forcément la meilleure réponse aux demandes instantanées de courant (quand on lance le moteur, il a tendance a demander beaucoup de courant), et c’est potentiellement electro-magnétiquement bruyant (peut rendre la lecture d’ADC plus bruitée, et si vous voulez vendre ça un jour, ça pourrait peu-être rajouter un point délicat vis a vis des certifications CE/FCC).
Quant à la consommation énergétique… il faut compter entre 5 et 15% de pertes en gros, ce qui vu la consommation d’un servo en charge, est fera une baisse non négligeable du temps d’activité d’un robot sur batterie.
Pour info, sur les device Dynamixel que j’ai créé, j’ai mis un convertisseur DC/DC, et je pense que les servos comme les AX / MX bénéficieraient d’en avoir un (chauffe moins que le LDO qu’ils ont actuellement), mais tout cela ne concerne que de petites puissances (quelques centaines de mW), pour la logique et les capteurs. Dès qu’il y a un moteur en jeu c’est plus du tout pareil (dizaines de W).
Pour moi la solution parfaite n’est pas très évidente… Il faudrait que pour la partie communication on ai toute liberté de connexion, mais que l’intégrité du signal soit préservée, et que niveau puissance on ai un circuit de distribution qui permettre à la fois une distribution aisée et peu de pertes… Pas si simple.
En organisant la partie puissance pour qu’elle commence en étoile près de l’alim puis passe en chaîne quand la somme des consommation des nœuds restant est suffisamment basse pour ne pas poser de problèmes au nœuds connectés, on peut déja réduire le problème des baisses de tension. Dans mes robots ca se manifeste par une connexion directe de chaque membre à la carte d’alimentation par de gros cables, avec gros borniers ou connecteurs de puissance sur la carte d’alim.
Les connecteurs Molex SPOX 2.50mm utilisés dans les Dynamixels sont pas du tout fait pour passer de grosses intensités, comme le dit la datasheet:
Current - Maximum per Contact 3.0A
Conserver l’intégrité du signal, c’est éviter ce qu’on voit dans les posts juste au dessus, qui est causé par un ensemble de problèmes d’impédance. Ca passe à la fois par ce qu’on connecte (éviter de mettre de la capacitance ou resistance sur la ligne de donnée) et par la façon dont les fils sont agencés (en particulier la relation physique entre le fil de signal et le chemin de retour, qui est la masse dans note cas. Il faut qu’ils soient proche l’un de l’autre.).
Petite apparté sur la baisse de tension vue au bout de la chaine: elle n’affecte pas que la tension vue par le moteur, ca a aussi un impacte sur la ligne DATA. Si au servo du bout le chaine, on mesur une baisse de 1V entre GND et VCC par rapport à l’alim, étant donné que les fils de VCC et GND sont les mêmes (section, longueur et chemin pris), et bien on a 0.5V de perdu sur le fil de masse.
Comme le fil DATA ne porte pas de courant important, lui est presque au même potentiel sur toute sa longueur (en régime établi uniquement, pas lors de la transition qui elle est affectée par d’autres problèmes)… donc le servo en bout de ligne, avec sa référence (son pin GND) qui est “remonté” de 0.5V, et bien il voit DATA 0.5V plus bas que ce que le premier servo de la chaine aura vu. Et quand il parlera sur le bus, ce qu’il dit sera vu par le contrôleur entre 0.5V et 5.5V. Encore un peu de dégradation du signal… 
Ta reflexion est très intéréssante, du coup pour toi quel est le meilleur compromis dans un réseaux type robotis?
Qu’est-ce que tu changerais dans leur système pour que ce soit mieux?
Merci de ton retour détaillé, il y a effectivement beaucoup de choses à prendre en compte.
Malheureusement pour nous, comme dit @Nicolas, on souhaite rester sur une architecture type robotis où tout les modules sont câblés pareil (pas forcer le début en étoile et gros câble au début etc…). On veut rester flexible en autorisant des enchainements du genre (Moteur-LED-Capteur-LED-LED-Moteur-Moteur…), effectivement pas optimaux pour la distribution de la puissance.
Est-ce que tu as un avis sur des connecteurs meilleurs que les Molex de robotis? On a commencé un thread ici:
Il y en a par exemple qui permettent une large surface de contact pour la puissance, en gardant des pins classiques pour la data.
Là tout de suite, je n’ai pas de réponse miracle. C’est toujours plus facile de pointer ce qui ne vas pas que d’offrir une bonne solution 
Il me faudrait au moins quelques jours pour étudier la question à fond et revenir avec des propositions, mais je n’aurai pas de temps dispo avant Septembre, au mieux… 
Le projet sur lequel je bosse en ce moment demande vraiment tout mon temps, désolé.
Pour revenir sur l’interprétation de ma réponse concernant le DC/DC : au final, si tout les inconvénients ne sont pas rédhibitoires, ça peut se tenter. Il faut juste savoir dans quoi on met le doigt pour ne pas avoir des attentes irréalistes.
Pour revenir à la question originale:
Les mesures faites dont on voit les captures dans le soft de Saleae Logic, c’était avec un USB2AX ou avec une carte de contrôle toute intégrée de Poppy?
Il y a quoi de connecté au bus à part des servos? Est ce que tu aurais une photo du setup de test ?
Ca reste quand même étonnant d’avoir un résultat aussi mauvais avec une seule connexion.
USB2AX
Rien d’autres sur le bus moteur. Après on a 2 cables customs peut être qu’ils sont tout pourris …
Si vous avez une photo desdits câbles, je serais intéressé.
Si vous utilisez un hub pour les servos ou une carte d’alim qui a le fil DATA de connecté a quelque chose, ca peut aussi jouer.
En fait la mesure a été faite au cul du poppy, donc on a en effet (sur la dernière) 2 cartes alim avec la data qui passe dessus, 2 hubs et 25 moteurs. Le câble en question est en fait constitué de 2 câble robotis branché l’un à l’autre avec de simple barrette de pins sécable
J’ai peur que la photo soit peu explicite, je vais juste photographier un Poppy…
OK, ca m’a pourtant pas l’air trop déraisonnable à vue de nez… vous torsadez ou gainez vos cables?
En tout ca vous fait quelles longueurs de cables, quand vous cumulez toutes les longueurs des fils DATA (donc tous les cables sauf ceux d’alim) ?
Aussi, une note vis a vis de l’outils utilisé pour regarder les waveforms : si tu as un Logic 4, sa bande passante à -3dB est de 600kHz… donc tu ne peux pas avoir une représentation fidèle du signal.
A 1Mbps sur du série (ou chaque bit est représenté par une moitié de la période minimum), la fréquence principale du signal est de 500kHz (pas très loin de 600kHz donc à cette valeur tu aura déja une atténuation significative), mais les harmoniques vont être très affaiblies, ce qui va arrondir artificiellement ce qui est représenté.
Si tu veux vraiment voir ce qu’il se passe, il faut un oscilloscope avec une bande passante plus importante (20Mhz ou plus serait pas mal).
++
Effectivement j’ai pu observer de belle perturbations dans le taux de réussite en utilisant ma sonde salae…
J’ai pas réussi a retrouver le modèle exacte mais j’ai la toute dernière salae logic8 (qui fait mini oscilo+analyseur).
Sur la pire des mesure je pense qu’on avais environs 5m20 de cable Data!
Bonjour ,
Vos chute de tension sont colossale plus d’un volt. Une solution simple, comme dit plus haut, c’est d’augmenter la section du cable. Sachant que l’impédance d un fil c’est ro X l sur s avec ro résistance du cuivre, pour passer le signal dans un environnement aussi dégrader il faut passer en différentielle. Évident il faut une glue pour repasser en TTL.
Il ne faut pas négliger non plus la qualité du câblage.
Qu’en au dc/dc c’est une très bonne idée un buck synchrone peu dépasser les 90% de rendement et être stable. C’est pas très compliqué à faire. par example :
http://www.linear.com/product/LT8640
jusqu’a 96% de rendement
5A en continu et 7A pic
boitier qfn18 3x4mm il faut juste ajouter des condensateur une seff et les résitrance de réglage de la tension.
cerise sur le gateau simulable avec LTspice qui fonctionne trés bien avec WINE pour les linuxiens!
Bonjour,
Pour @Xevel & @Thot: Je m’interroge moi-aussi depuis qq temps sur ce problème, qui explique sans doute les problèmes de coordination de mouvements. Plutôt qu’un convertisseur DC-DC ou un régulateur low-drop, peut-être qu’un simple condensateur monté à l la sortie du connecteur Molex pourrait résoudre, au moins partiellement, le problème. Par exemple un condensateur tantale (ils sont très petits pour leur capacité) de 220 µF / 24 V permettrait de lisser les chutes de tension. En effet, la consommation en courant d’un MX28 (par exemple dans un bras de Poppy) est très irrégulière : de 90 mA en standby à 1.5 A en pointe. Les appels de courant sont surtout au démarrage ou lorsque la gravité fait que le couple augmente dans un mouvement. Mais en regardant un ampèremètre en même temps (même s’il intègre dans le temps) les pointes de surintensité ne représentent qu’une petite partie d’un cycle de mouvement.