search

xenomorphales / xenomorphales

Équipe participant à la Coupe de France de Robotique
3 stars 0 forks source link

Idée électronique/mécanique modulaire pour Céres 3.0 #67

Open astralien3000 opened 7 years ago

astralien3000 commented 7 years ago

J'aimerai expérimenter une électronique/méca modulaire.

On part de là :

Objectifs :

Idées :

Voilà, c'est assez ambitieux, mais ça peut être intéressant ?

EDIT :

Voila un schéma : ceres3_elec

Le seul gros problème est l'arret d'urgence... Il faut pouvoir atteindre les batteries qui sont en bas alors qu'il doit être sur le toit...

Elioty commented 7 years ago

Wow, super boulot, ça a l'air cool 😍

Alors première remarque, sur ton schéma, on voit bien les gateways et mécaniquement, ça serait représenter par un plaque sandwich-alu (ou autre matériau) j'imagine. L'idée de la carte qui se positionnerait dans un orifice percé quelque part sur cette plaque de séparation d'étage avec des connecteurs des deux côtés (à mon avis, il faut bien au minimum deux connecteurs par face, un pour la logique avec alim, masse et le bus de com, et l'autre pour passer l'arrivée de la batterie à l'arrêt d'urgence mais c'est à discuter en fonction de ce que l'on veut que l'arrêt d'urgence arrête, ou peut-être on peut juste l'utiliser pour commander un relais en passant par le connecteur logique). Bref, la où je voulais en venir sur ce principe de gateway est que, je pense, ça pourrait/devrait être une réflexion plus large englobant la méca. Tu y fais déjà allusion dans ton message mais je pense qu'il faut bien y réfléchir genre chaque bloc (pris indépendamment, lorsque démonté des autres blocs par exemple) ne dispose que de quatre colonnes et de la plaque du haut avec la carte/interface gateway. Mais les quatre colonnes seraient sur le même axe vertical pour tous les blocs mécaniques du robot donc faut bien réfléchir comment on vient stacker tout ça. On pourrait aussi imaginer que les plaques supérieurs proposent plusieurs "bases de fixation" pour les colonnes du bloc supérieur afin de laisser plus de liberté pour designer (l'occupation de l'espace de) chacun des blocs. Bref, faut y réfléchir aussi si tu veux que les blocs soient aussi facilement interchangeables mécaniquement (et pas juste électrique/électroniquement) et déplaçable au sein du robot. Désolé, première remarque plus longue que prévue 😋

Deuxième, bien plus courte, est-ce qu'on veut vraiment que les servos d'Hydra soient sur le même bus que la com entre nos microcontrôleurs et notre rasp ? Ça me choque un peu comme cela. Et puis on va en discuter/y réfléchir mais on peut peut-être (certainement ?) trouver un bus plus efficace pour la com entre les microcontrôleurs que du TTL/UART half-duplex.

Justement sur la communication inter-microcontrôleur, ça risque être le noeud de la guerre dans toute cette archi. Faut voir quels seront les flux de données qui passeront sur le bus, qui communique avec qui, "peer-to-peer" ou uniquement "master/slaves" voir "masterS/slaves" ou encore en mode "data-centric" (je "broadcast" une information que j'ai acquise par un senseur ou calculée sur le bus et je me fiche de savoir qui consomme l'information). Voir aussi mon avant-dernière remarque un peu plus bas.

Troisièmement, c'est juste d'ordre lexical 😅

Avoir le moins possible de câbles entre 2 étages (l'idéal est d'avoir un seul câble à débrancher)

Avant-dernière remarque, faut peut-être aussi réfléchir à comment tu va mettre en place la boucle d'asservissement là-dessus, bref genre faire un diagramme de séquence pour savoir quelle carte fait quoi et ordonne quoi aux autres.

Dernièrement remarque, concernant le schéma, ne fait pas de boucle sur le bus de communication autour d'Hydra et de la board de détection, connecte-les une seul fois sur le bus, ça serait plus correct.

Bref, je vais m'arrêter là pour maintenant, c'est déjà pas mal je pense mais en tout cas, si on part sur quelque chose comme ça, je suis déjà enthousiasmé pour la coupe 2018 😄😍 et ça peut franchement être un bon projet à défendre/évoquer lors d'entretien d'embauche, sur LinkedIn ou même sur son CV, aussi bien la partie élec qu'informatique.

Elioty commented 7 years ago

Oh et j'oubliais mais on va devoir chercher plein de petits noms pour toutes ces cartes 😋 rappel des noms existants :

Pour le nom Cérès, c'est la "déesse romaine de l'agriculture, des moissons et de la fécondité" mais je pense que l'inspiration originale vient plutôt de la planète naine de notre système solaire du même nom (pour faire suite au thème spatial évoqué par le nom de l'équipe). Dis moi si je me trompe @astralien3000.

darwikey commented 7 years ago

Pour la carte IHM: Janus (dieu des portes et des choix) Pour la carte alim: Atlas (parce qu'il porte toutes les autres cartes "sur ses épaules") Pour la carte detection: Heimdall (le gardien du Bifrost dans Thor) Juste des suggestions..

Mais certain module, comme la carte detection, sont-il vraiment obligatoire ? Y a deja pas mal d'IO sur la carte hermès.

astralien3000 commented 7 years ago

Longue remarque j'espère que je vais rien oublier ! ^^

Pour le premier point sur la méca. Je suis en train de concevoir un système plsu simple à démonter qu'actuellement (enfin j'espère). En gros, à la place d'avoir des "barres" en plein milieu du robot (où il faut que le tournevis slalome entre les actionneurs/cartes pour atteindre la structure porteuse), je voulais faire un système plus proche des bords à base d'équerres (la vis serait directement atteignable sur la paroi du robot). Mais je sais pas si ça peut s'appliquer dans tout les cas.

Autre point que tu soulève dans la première remarque : l'interchangeabilité des modules. Déjà tout les modules ne sont pas interchangeables, ça va de soi. Le module "base roulante" sera forcément en bas. L'IHM forcément en haut (quoique, ça se discute...). Et par exemple, pour un module contenant des bras comme cette année, le changer de hauteur pourrait le rendre inutilisable (comme une grande partie des modules actionneurs, je pense). Les seuls modules qui pourraient être déplacés dans mon schéma sont la détection, la comm sans fil et la rasp. Donc je sais pas à quel point c'est important d'avoir une méca ultra modulaire, mais en effet, il faut essayer des trouver des constantes dans la fixation entre les modules. Pas comme actuellement, où l'étage le plus bas prend des vis M6 de 10cm, sur un carré de 10cm de côté, le suivant des M6 de 5cm sur un rectangle dont je me rapelles plus des dimentions pour finir sur des plots qui supportent des barres à base carrée ! XD

Pour ton 2e point sur le bus des servo. Je pense que vu nos demandes, il va être difficile d'avoir les même connecteurs de toute façon (on aura vraisemblablement besoin de plus de 3 pins). Par contre pour l'histoire du TTL/UART, il y a un gros avantage : c'est facile à coder, relativement facile à faire niveau élec (quoique ?), et presque tout les MCU gèrent l'UART, mêmes les plus simples. Pour l'I2C et le SPI c'est déjà pas la même (mais on va considèrérer que tout ce qui est plus gros qu'un ATMega328p les aura quand même donc c'est pas une vraie contrainte). Pour l'I2C, les anciens m'ont toujours dis que c'était une mauvaise idée, mais bon ils ont dit la même avec la tirette-jumper, et j'ai pas eu de problème depuis 4 ans... Si tu a une autre proposition (CAN ? Ethernet ? Autre bus bourrin ?), il faut en discuter. Il y a aussi la possibilitée de faire plusieurs bus en parallèles (genre 2 TTL/UART sur 2 lignes différentes, pour doubler le débit potentiel ?)

J'aimerai vraiment que la comm soit data-centric, ça serait pile dans ma thèse ^^ ! Et en plus ça serait cool ! J'essaie de faire une étude des flux de donnée rapidement... (tient ça vaudrait une petit issue, ça !) Pour la diagramme de séquence, je pense qu'une certaine partie du travail est fait ici, mais il faut continuer, en effet.

Pour la dernière remarque je voulais juste représenter que les fils qui se croisent sont le même bus (donc il n'y a pas de composants qui les séparent, si ce n'est des connecteurs sur les boards), en oppositions aux fils qui ne sont pas croisés avec d'autres et qui ne sont donc pas dans le bus.

(ça commence à faire baucoup ! vaste sujet !)

astralien3000 commented 7 years ago

Bon, on vas pas s'étendre trop sur les noms (on verra au fur et à mesure que les cartes sont créées)

@Elioty tout juste ! ^^

@darwikey J'aurai plus mis Janus pour la Gateway, vu qu'il a deux faces Mais ça va bien à l'IHM aussi, en effet !

Pour la carte Alim, j'aurai aussi pensé à Prométhée (son frère en fait), qui donne le feu (= une source d'énergie) aux hommes. En plus Prométhé, même si ça me fait pas plaisir ça fait parti de la saga alien maintenant.

Pour détection = Heimdall 👍 j'ai direct pensé à ça aussi et je pense qu'on peut difficilement trouver mieux. Mais comme tu dis, son utilitée finale peut être discutée. Il y a plein de façon de régler le même problème :

astralien3000 commented 7 years ago

J'ai une meilleur proposition pour les boards que les Teensy : Des Nucleo (format 32 pins) ! Spécialement la NUCLEO-F042K6, qui possède 2 Timers avec lecture d'encodeurs (Ctrl-F quadrature). Elle est pas cher, comparée aux Teensy. Et en plus elle est supportée par des vrais framework (mbed, RIOT), pas Arduino-like, en somme ^^. Elle est peut être un peu limite niveau RAM(6K)/Flash(32K), mais ça sera suffisant pour contrôler les moteurs, et lire les encodeurs tout en gérant le bus de communication. Et au pire il y a des NUCLEO du même format qui sont plus fournie niveau mémoire (par contre c'est la seule avec 2 lecteurs de quadrature, les autres que j'ai vu n'en ont qu'un...).

Elioty commented 7 years ago

Pour l'aspect méca, je n'ai pas précisé effectivement mais j'avais bien à l'esprit que le bloc base roulante est forcément en bas et que le bloc tout en haut n'est pas forcément IHM mais doit être capable de supporter au minimum l'arrêt d'urgence et le mat de balise. En tout cas, amuse toi bien avec la méco alors 👍

Pour le bus des servos, c'est aussi surtout que s'ils sont sur le bus avec tout le monde, pourquoi avoir Hydra (si ce n'est pour aligner des connecteurs et des capas de découplage) ? Et si au final on utilise autre chose que de l'UART half-duplex, on n'aura pas le choix de les séparer sur un bus séparé. Car si tu veux faire du data-centric ("je partage l'information que je viens de récupérer ou de calculer"), il faut un truc qui :

Du coups pour le premier point, ce qui vient évidemment direct en tête est l’Ethernet mais c'est quand même lourd pour notre besoin. En faisant quelques recherches, le RS232/UART, l'I2C, le SPI ou le RS485, aucun d'eux ne semblent adapter pour gérer les collisions, ils fonctionnent soit en full-duplex (1-to-1), soit en master/slave et pour ceux en 1-to-1 qu'on bidouille en mode bus, on retombe dans un mode master/slave. Par contre, eurêka, le CAN gère les collisions !! Tout le monde peut prendre la parole librement sans qu'il n'y ait de master qui donne la parole. Les contrôleurs CAN sont par contre quand même bien présents dans la plupart des microcontrôleurs ARM mais côté atmega, ce n'est pas ça. Contrairement à l'UART qui est absolument partout. Pour le bus où le droit de parole tourne et qu'il soit robuste à la panne logiciel d'un des nœuds, je ne vois qu'une solution, une horloge commune que tout le monde reçoit (avec un top départ) et chaque nœud est programmé pour parler pendant une fenêtre de temps distincte des autres (ce n'est quand même pas très modulaire si tu veux ajouter un nœud, si tu n'as pas de spare dans ton partitionnement temporel du droit de parole...). Et je ne pense pas qu'il existe des trucs comme ça implémenté en hardware donc ça risque d'être chiant 😅 mais ça devrait poser problème quand même si un nœud rate le top départ ou reboot après coups. Bref, je vais continuer mes recherches sur le sujet mais si le master/slave te convient (ce que je ne pense pas si tu préfère du data-centric), ça peut se faire avec de l'UART half-duplex même si je préférais qu'on utilise un truc adapté comme le SPI (quand même lourd, il faut un fil slave-select par slave) ou l'I2C (mieux, le slave est adressé par le protocole de la couche liaison). Sinon, il n'y a à mon avis pas de secret si le CAN a réussi à s'imposer dans plusieurs industries, c'est que ça marche 😋 et dans les liens externes sur sa page wikipedia on trouve... un cours sur le CAN d'un prof de l'ENSEIRB (bon ça date un peu, l'ancien logo avant la fusion avec matmeca).

Vaste sujet comme tu l'as dit. Autres liens que j'ai lu jusqu'à maintenant pendant mes recherches, je les met là. http://community.silabs.com/t5/8-bit-MCU/One-master-multiple-slaves-over-UART/td-p/57005 http://www.edaboard.com/thread302747.html https://www.maximintegrated.com/en/app-notes/index.mvp/id/214

Pour les noms des boards, on a le temps effectivement mais je vois que vous avez plein d'idées 😃

On peut mettre une board par GP2 pour les brancher directement au bus comme des servomoteurs (overkill !!)

Tu veux faire des GP2 numériques ?! hahaha 😆

Pour les nucleo, pourquoi pas, elles sont minces en plus (format Arduino nano de ce que j'ai compris). Et si on découpe toute l'archi comme ça, je pense que 6K de ram et 32K de flash seront largement suffisant pour Hermes. Puis ce petit STM32F042K6 dispose quand même niveau com d'UART, de SPI, d'I2C, d'I2S, d'USB et de CAN donc a n'a que l'embarras du choix.

Et d'ailleurs, une question qui m'est venu en tête (et je m'arrête là pour ce soir), tu comptes flasher les cartes comment ? Que ce soit de l'Arduino, du Teensy ou du Nucleo, faut passer par l'USB (et pour les Teensy faut en plus appuyer sur son bouton de flashage, pour les Nucleo, je ne sais pas). Tu veux flasher depuis la raspberry embarqué ou depuis un PC portable à côté du robot ? Mais dans ce dernier cas là il faut que les USB de programmation soient accessibles ou tirés vers les bords du robots avec une rallonge quelconque installée proprement dans le robot.

astralien3000 commented 7 years ago

Ouai, j'avais parlé avec @Titwin des différents bus.

Le dernier point m'amène à une autre problèmatique : On tire quoi comme cable d'alim en plus des bus de communication ?

Il y a plusieurs possibilités :

Voilà, ce sont trois proposition auxquelles j'ai pensé, on peut en trouver d'autres ou faire des mélanges.

Pour le flashage des cartes : Déjà j'aimerai arriver au point où on arrive à la coupe et on a pas besoin de flasher les boards qui ne gèrent pas la stratégie (comme sur Buggybot). Mais à part ça, oui, sortir l'USB sur les bords de la méca serait une bonne solution. De toute façon faire passer les USB par le bus commun pour atteindre la rasp n'est pas envisageable ? Je sais que RIOT expérimente des façons de flasher, principalement sans fil, mais on pourrait aussi bien flasher à travers un bus CAN. Ca reste pas très stable encore, donc l'USB reste le plus sûr. Et puis c'est pas un choix définitif, si un jour on arrive à flasher via le bus commun, ça sera pas un problème. D'ailleurs c'est encore un point pour les Nucleo, pas besoin d'appuyer sur un bouton !

darwikey commented 7 years ago

Pour la teensy, normalement y a pas besoin d appuyer sur un bouton pour programmer ( en début d année j'étais obligé à cause d un problème de driver je pense)

Elioty commented 7 years ago

Pour le bus, on a l'air de tendre vers le CAN. Pour les Arduino, il existe certainement des shields pour avoir du CAN. Et pour la Raspberry, un adaptateur USB/CAN doit pouvoir se trouver sans trop de problème non plus. Pour l'idée à la con, oui on pourrait tirer deux bus mais est-ce vraiment nécessaire ? Ça alourdit le tout juste pour pouvoir gérer les atmega au final (car même si on câblait les servos directement sur le bus, il faudrait une carte (sans µP) pour tous les brancher proprement et leur mettre des capa de découplage). Les nucleo ne sont vraiment pas chères il semblerait donc pourquoi pas avoir de l'ARM partout ? (et puis on peu toujours acheter une ou deux cartes/shield CAN pour les atmega).

Pour l'alimentation, c'est peut-être plus cher comme tu l'as dit mais plus modulaire de n'envoyer qu'une seule tension à côté du bus et chaque module se débrouille pour réguler la/les tension(s) qu'il lui faut avec des régulateurs supportant l'ampérage nécessaire par le bloc en question, et moins de fils aussi qui traverse tout le robot. Et libre à eux d'avoir leurs propres batteries également. Et avec cette solution, pour l'arrêt d'urgence on peut tirer entre les étages : le bus de données (juste deux fils pour le CAN), le + et le - des batteries avec un XT60 et en plus, un autre file puissance qui est au même potentiel que le + des batteries mais derrière l'arrêt d'urgence, avec un XT60 aussi soit avec un seul fil soit on remet la masse. Il faudra quand même penser à mettre un interrupteur genre comme ceux sur les alimentations ATX (pour PC de bureau) quelque part à côté des batteries pour couper toute alimentation.

L'autre solution que tu as évoqué est d'avoir une carte alim qui regroupe tous les régulateurs puis distribue, à l'aide de plusieurs fils, les différents niveaux de tensions dans le robot, et tire un fil jusqu'en haut pour récupérer l'arrêt d'urgence.

Bref je vais récapituler avec un tableau les deux solutions, ça sera plus clair :

Alim décentralisée Carte alim
Bus de données Bus de données
+15V +15V
GND GND
+15V (derrière l'arrêt d'urgence) +15V (derrière l'arrêt d'urgence)
N/A +3.3V
N/A +5V
N/A +7.4V (derrière l'arrêt d'urgence)

Si je n'ai rien oublié, on gagne donc trois fils. Sachant que le 7.4V alimente des servos, il faudrait donc mieux que ça soit un fil épais. Et pour le 3.3V et le 5V, pas forcément aussi épais que des fils puissance mais faut pas prendre un diamètre trop petit non plus car on alimente toute la logique du robot avec. Personnellement, je penche plus pour l'alim décentralisée.

Dernier point, pour le flashage des cartes effectivement j'espère qu'on peut pondre des programmes qui fonctionnent bien sans trop de bug et qui ont leurs constantes paramétrables à travers le protocole applicatif qu'on utilise sur notre bus de données. Pour les USB, vaut mieux les rendre accessibles depuis l'extérieur du robot. Parce que oui, remonter les USB par nos gateways n'est pas envisageable : soit pas modulaire en ne provisionnant que n USB ; soit un seul USB de câblé mais faut installer un hub à chaque étage 😱. Et pour flasher par le bus, faut faire notre bootloader (et potentiellement notre loader côté Linux), ça peut se faire mais c'est pas mal de boulot et il faut très certainement investir dans une sonde de debug hardware (genre JTAG) pour faire ça. A moins que les nucleo ont du debug embarqué (comme la stm32f4-discovery il me semble) ? Dans tous les cas, ça c'est du plus qui n'apporte pas réellement de fonctionnel si ce n'est pouvoir flasher nos cartes depuis la raspberry sans rien brancher de plus. Tu veux faire le genre d'algo d'IA qui se modifie lui-même ?! (je crois que des gars font ça avec une IA sur un FPGA, c'est fou 😆)

astralien3000 commented 7 years ago

Petite remarque rapide (mais importante !) 32Ko de Flash sur ARM c'est vraiment hardcore en fait. Je viens de faire une petite étude de la taille de mon code actuel : ~10Ko avec un main vide ! (bon, l'OS fait du travail derrière, et surtout appel du printf sans notre consentement...) Rien que les drivers moteurs ça nou ajoute du ~8Ko ! moteurs+gyro+asserv angle, ça dépasse déjà les 32Ko... Et juste pour info mon code complet (drivers gyro,moteurs,bras,... + strat + cli) ça fait ~56Ko (pour 8Ko de RAM, mais là on peut facilement diminuer)

Ça monte beaucoup plus vite que sur AVR.

EDIT : Bon, sans les printf, ça passe à ~4Ko avec un main vide (un peu plus acceptable) Je pense aussi que les float sans FPU ça doit faire mal.

Elioty commented 7 years ago

Mouais, ça va être tendu avec cette nucleo. Il n'y en a aucune avec un plus gros µP qui a quand même deux lecteurs de quadrature ? Sinon beh Teensy ? Elles gèrent bien le CAN normalement.

Sinon remarque pour comparer ARM et AVR, le premier a des instructions de taille fixe, 32 bits, sur AVR c'est variable, 16 ou 32 bits. Par contre selon la taille des valeurs manipulées, vu que l'APU de l'AVR n'est que 8 bits, une opération simple (genre une somme) peut prendre plusieurs instructions. Pour les floats, c'est fait en soft dans les deux cas mais ce n'est peut-être (certainement) pas la même implémentation avec les mêmes optims. Et tu as aussi peut-être le float64 (aka le double en C/C++) de gérer dans l'implémentation des flottants sur ton ARM. Seul le float32 est géré avec avr-gcc.

astralien3000 commented 7 years ago

Edit: J'ai pas du tout confiance dans le site (jamais testé), mais après il y a pas de raison. C'est juste pour trouver des boards moins cher, mais si c'est pour avoir un truc dur à programmer, autant rester sur Teensy, si on peut en effet la programmer sans appuyer sur reset.

kazord commented 7 years ago

Question qui peut paraît bête mais qui mérite réflexion (de mon point de vue au moins)

Comment sont connecté les gateways entre elle et aux carte : Carte = gw = carte = gw....

Ou

Carte = gw = gw = gw = gw II. II. II. II Carte. Carte Carte

La différence devrait se voir dans deux cas : Test sans un module Fonctionnement/cablage des bus de données

astralien3000 commented 7 years ago

En effet. Je pense que de toute façon toutes les boards devraient avoir au moins 2 connecteurs pour le bus pour pouvoir les chainer. La gateway pourait en avoir plus pour permettre les deux cas que tu a donné.

Elioty commented 7 years ago

Pour faire du CAN, il vaut mieux faire uniquement du chainage tout droit, cad que les gateways, comme les cartes n'aient que 2 connecteurs pour le bus de données. On pourrait mettre plusieurs connecteurs pour le bus sur la gateway mais ça serait juste pour faire revenir le bus sur la gateway pour repartir sur une autre carte, totalement débile. Par contre, il ne faudra pas oublier de faire un connecteur de "fin de bus" avec la résistance qu'il faut bien pour mettre aux deux extimités du bus CAN. Bref, je voulais faire un schéma depuis hier mais j'en ai trouvé un sur la page wikipedia qui devrait convenir avec une petite explication : Bus CAN Voila donc pour notre utilisation, je pense effectivement qu'on mettra deux connecteurs (à deux pôles) sur nos cartes. Les deux connecteurs d'une même carte seront directement reliés. Les deux liens seront tirés vers le contrôleur CAN de la carte (puce externe ou directement le µP). Et faudra faire deux connecteurs avec juste une résistance pour fermer la boucle aux deux extrémités. Aussi, d'après Wikipedia, jusqu'à 30 mètres, on peut espérer un débit 1 Mb/s ce qui devrait être largement suffisant pour notre utilisation.

Sinon pour les deux cartes que tu as trouvées @astralien3000 :

EDIT : @astralien3000 on commence à avoir pas mal d'éléments, ça serait peut-être intéressant de faire un Skype pour fixer certains points pour ensuite dérouler la réflexion/recherche ici à nouveau sur les points suivants ?!

kazord commented 7 years ago

Il existe 2mode pour le CAN, avec des connections différents/placement de résistance different Avec 1m/bits en un bus lineaire Ou 125kbits en mode osef ( linéaire et étoile mélangé) => bas débit securisé, un truc comme ca

Un gateway avec une carte connecté peu faire un T avec le bus CAN Par contre je ne sais pas le comportement du bus si tu as pas de carte (=2pin ouvert sur l air)

J aurai bien vu une carte avec juste la res de 120ohm a mettre au 2 bout sur les gateways de chaque coté

astralien3000 commented 7 years ago

Ok pour le CAN, je savais pas. Ok pour Skype, mais avant, j'aimerai qu'on liste les connecteurs qu'on pourrait utiliser.

Elioty commented 7 years ago

@kazord Ah je ne connaissais pas qu'on pouvait avoir une topologie en étoile avec du CAN. La page Wikipedia du CAN en français n'évoque que son nom (ISO 11898-3 : low-speed, fault tolerant) sans le détaillé, il est bien détaillé sur la page en anglais cependant.

Je ne pense qu'avoir deux pins en l'air pour le CAN ISO 11898-3 pose problème, tu vas juste capter un plus de bruit, mais juste la longueur de deux pins, ça devrait être totalement marginal.

Sinon, pour les résistances, c'est un peu la merde sur le bus en étoile et pas modulaire (!!), d'après Wikipedia, chaque nœud qui se connecte sur le bus doit embarquer une résistance (je ne sais pas si c'est pull up ou down ou autre chose) pour les deux liens du bus qui est une fraction de la résistance globale sur le bus, qui doit être proche mais supérieur à 100ohm (c'est le proche qui pose problème pour la modularité). Pour un bus linéaire, c'est juste une résistance de 120ohm à chaque extrémité et c'est tout. C'est pour ça que je proposais dans mon message précédent de faire juste un connecteur tout con qui relie ses deux pôles par une résistance, pour fermer la boucle. Et ça ne marche pas sans, on a eu le soucis au boulot une fois 😆

@astralien3000 Pour les connecteurs ? Tu parles en règle général pour à peu près tout ou juste pour le bus ?

EDIT : j'ai fait quelques recherches supplémentaires car je me demande depuis un petit moment comment se faire du CAN en pratique avec un microcontrôleur (parce que je vois depuis le début que ça risque poser des problèmes de tensions, tout cramer) et en fait, les microcontrôleur n'ont que le contrôleur/la partie numérique et pas la couche phy/la partie analogique, il faut utiliser à côté un truc du genre ça : http://www.ti.com/lit/ds/symlink/sn65hvd230.pdf Enfin bref, j'ai trouvé ça depuis http://www.christoph-lauer.de/archives/11833 et @astralien3000, tu devrais y jeter un coups d’œil et tester, il donne un petit branchement avec juste deux diodes et une résistance de 3.3k pour connecter les deux contrôleurs CAN ensemble sur une STM32F4-Discovery.

astralien3000 commented 7 years ago

Juste pour le bus. On a déjà à peu près répondu pour le reste. Je verrai pour l'histoire du montage.

Elioty commented 7 years ago

J'ai réfléchi un petit peu et je pense que les embases comme sur la première Hermes conviendraient. Où tu veux un autre connecteur pour bien les distinguer (ou peut-être un peu plus compact) ? À défaut, faudrait essayer de bien colorer les embases (mâles comme femelles) afin de les différencier. À noter qu'il me semble qu'on peut avoir les embases mâles (que l'on soude sur les cartes) en coudé pour prendre de la place en surface plutôt que du volume en hauteur selon les contraintes ;)

astralien3000 commented 7 years ago

Ces connecteurs peuvent gérer les 14V ? Ou il faut un 2e connecteur ?

Elioty commented 7 years ago

Aucun problème avec les embases : 250V, 3A max, on en est loin ;)

http://www.mouser.fr/Search/ProductDetail.aspx?qs=hSmm4fxMIuPWb6osY0uomA== http://www.mouser.fr/Search/ProductDetail.aspx?qs=mrPiglD9aYKHxZkM06vJ3A%3d%3d http://www.mouser.fr/Search/ProductDetail.aspx?qs=BLN8Q0P37WapYBZgTV5Zeg%3d%3d

astralien3000 commented 7 years ago

Pas si on utilise des moteurs un peu plus péchus (20A/moteur, potentiellement), si ? Bon après je viens de voir que les connecteurs qu'il y a déjà sur les moteurs sont aussi pour 250V et 3A...

Si c'est quand même bon, on va pouvoir faire le Skype, mais pas avant Mercredi.

Elioty commented 7 years ago

Ah non mais les embases que je proposais, c'est juste pour le bus de données. Pour l'alimentation, ça serait plutôt un XT60 à côté. Puis tes connecteurs sur les moteurs, faudra les changer par des XT60. Tu veux que je regarde s'il existe des connecteurs avec deux gros contacts pour l'alim et d'autres contacts plus classique pour du logique ? (pour chainer les cartes et les brancher sur la gateway, ça restera du XT60 dans tous les cas sur la batterie et sur les moteurs) Ah sinon on peut aussi essayer un connecteur avec un petit paquet de contacts et en utiliser plusieurs pour respectivement le +15V et la masse.

EDIT : On pourrait utiliser un truc du genre ça (ça ressemble au connecteur d'alim ATX et PCIe dans les PC) : http://www.mouser.fr/ProductDetail/Molex/50-84-1060/?qs=sGAEpiMZZMuzXLcWrSfMr4AImWoNFp%252b4ljYj1UH2RgI%3d Et ça existe bien sûr en coudé pour le connecteur qu'on soude sur la carte. Mais faudrait quand même deux/trois pairs pour le +15V/GND.

Elioty commented 7 years ago

Intro et questions d'ordre général

Alors pour mes devoirs suite à la dernière réunion, il semblerait que ça soit possible d'avoir deux encodeurs et du CAN sur une seule Teensy 3.2. Devrais-je regarder aussi pour la 3.5 et/ou 3.6 ? Elles ont beaucoup plus d'IO mais prennent du coups également bien plus de place en longueur mais ont aussi un uP plus pêchu (plus puissant, FPU, plus de ram, flash, cache selon les cas, bref je vous laisse lire le tableau comparatif des uP proposés par les teensy).

Démonstration de faisabilité sur Teensy 3.2

Ressources documentaires

Pour revenir à la 3.2 dans un premier temps, il faut, pour confirmer mes dires, deux documents :

Signaux nécessaires

À partir de la page 211 du user manual, il y a la description de tous les signaux gérer par le uP. Extrait pour les signaux qui nous intéressent :

Chip signal name Module signal name Description I/O
FTM1_QD_PHA PHA Quadrature decoder phase A input. Input pin associated with quadrature decoder phase A. I
FTM1_QD_PHB PHB Quadrature decoder phase B input. Input pin associated with quadrature decoder phase B. I
FTM2_QD_PHA PHA Quadrature decoder phase A input. Input pin associated with quadrature decoder phase A. I
FTM2_QD_PHB PHB Quadrature decoder phase B input. Input pin associated with quadrature decoder phase B. I
CAN0_RX CAN Rx CAN Receive Pin Input
CAN0_TX CAN Tx CAN Transmit Pin Output

Table de multiplexage

En cherchant les signaux qui nous intéressent dans la datasheet, on peut les retrouver dans la table de multiplexage (en page 62, page 207 pour le user manual). En résumé les signaux sont disponibles sur les pins :

Signal uP pin uP pin
FTM1_QD_PHA 28/PTA12 35/PTB0
FTM1_QD_PHB 29/PTA13 36/PTB1
FTM2_QD_PHA 41/PTB18
FTM2_QD_PHB 42/PTB19
CAN0_TX 28/PTA12 41/PTB18
CAN0_RX 29/PTA13 42/PTB19

La seule combinaison possible est mise en gras dans le tableau ci-dessus.

Disponibilité des pins du uP sur la Teensy 3.2

Ensuite, dernière vérifications à faire sur la schématique de la Teensy :

uP pin Board pin
28/PTA12 3
29/PTA13 4
35/PTB0 16
36/PTB1 17
41/PTB18 32
42/PTB19 25

Remarques

Bref, je vous invite à vérifier quand même, c'est rapide, vous avez toutes les infos ici a priori.

Et sur la version précédente d’Hermes, le deuxième encodeur est déjà branché sur ces pins là, et le premier utilise les pins 3 et 4 qu'on réserverait plutôt au CAN dans la nouvelle version. Cependant, les pin 16 et 17 sont utilisés pour des GP2 (en ADC donc) mais le sujet de ce message était de confirmer ou non la possibilité d'avoir deux encodeurs et un bus CAN sur une même Teensy 3.2. Il faudra donc, @astralien3000, que tu complètes ton besoin pour les nouvelles cartes Hermes, mais on avait toujours des pins ADC de disponibles si besoin.

Annexes

ps : je kiffe le markdown 😋 pps : au lieu de faire le design final dans un message sur une issue comme pour la première Hermes, on pourrait faire un vrai document en Word ou LaTeX (ou markdown justement) mis sur le dépôt git (LaTeX ou markdown seraient bien mieux pour le coups vu que c'est des formats texte), on pourrait donc suivre les changements avec les diff de git et aussi faire des releases de documentation hahaha ppps : je commence sérieusement à rentrer dans le moule au boulot, faut dire qu'avec les problématiques de safety en aviation civile, faut en faire des docs pour passer la certification de la plateforme, et je bouffe pas mal de docs entre les normes et les HSI des FPGA designés en interne par les hardeux

astralien3000 commented 7 years ago

Bon boulot !!!

Alors, je préfère rester sur du Teensy 3.2 si possible (et ça a l'air possible), 3.{5,6} c'est trop gros mécaniquement et en terme de pussance (on a pas besoin d'autant). J'ai vérifié, et j'allais te demander pourquoi FTM0 n'est pas envisagé, puis j'ai lu le user manual.

+1 pour faire un document de design dans le dépôt (plutôt en markdown). Après je suis pas sûr de comment tu veux faire ça, faudra qu'on voie. Mais c'est pas le sujet de cette issue. Et justement, je vais faire le nouveau cahier des charges dans #66 sous peu.

Elioty commented 7 years ago

J'ai vérifié, et j'allais te demander pourquoi FTM0 n'est pas envisagé, puis j'ai lu le user manual.

Oui le premier FTM n'a pas la capacité de lire des quadrature 😅

+1 pour faire un document de design dans le dépôt (plutôt en markdown). Après je suis pas sûr de comment tu veux faire ça, faudra qu'on voie. Mais c'est pas le sujet de cette issue. Et justement, je vais faire le nouveau cahier des charges dans #66 sous peu.

Ok, impatient de voir le cahier des charges pour la nouvelle Hermes. Et pour le document de design, c'est vrai que le markdown a l'avantage d'être rendu directement sur GitHub, donc pas besoin d'installer de logiciel particulier pour lire le document formaté, juste l'ouvrir sur GitHub.

Elioty commented 7 years ago

Concernant la partie alimentation des cartes, j'ai trouvé ces connecteurs qui ont l'air vraiment pas mal (spécial dédicace le nom de la marque ; et ils font à peu près tout, connecteurs coudés ou non, et aussi "in-line" pour connecter deux câbles, pour faire rallonge). On utiliserait certainement la version 5 pôles gérant 10A je pense, un pôle pour le 15V, deux pour le 15V derrière l'arrêt d'urgence et deux pour la masse. Vous en pensez quoi de celui ci ? On garderait les XT60 en sortie des batteries et en entrée des moteurs quand même je pense, ça serait juste pour le "bus" d'alim.

astralien3000 commented 7 years ago

Le problème est que les 20A qui passent par la ligne avec arrêt d'urgence vont potentiellement passer aussi par celle sans AU (si l'AU n'est pas directement sur la carte alim : voir #70 et #71). Et en plus ça fait "pas propre" les 5 fils, j'aimerai mieux en avoir 3 de 20A que 5 ou 6 de 10A. Mais j'imagine que c'est pas évident à trouver.

EDIT : Ceux là (~30A) on l'air plus intéressants, ou même ceux là (~45A).

ps: Les prix ont l'air particulièrement bas, il y a un piège ? pps: Je viens de voir que les pas pour ceux que j'ai proposé sont assez grands : 8mm et 10mm, mais si on prends que 3 pôles, on peut s'y retrouver ? ppps: Au pire pour ta solution, s'il y a un 2 rangées de 3 pôles, on peut mettre 2 15V + 2 AU + 2 GND.

Elioty commented 7 years ago

Le problème est que les 20A qui passent par la ligne avec arrêt d'urgence vont potentiellement passer aussi par celle sans AU (si l'AU n'est pas directement sur la carte alim : voir #70 et #71).

Ah oui effectivement, je devais commencer à fatiguer hier soir haha.

Et je pense plutôt qu'on se limitera au premier que tu as linké, 7.92mm de pitch, ça commence à faire assez large (27.72mm de large pour 3 contacts pour le connecteur sur la board contre 32.52mm pour le modèle avec un pitch de 10.16mm). D'autant plus qu'ils n'ont que deux ampères de différence.

Pour le prix :

Ce n'est pas si peu cher que ça je trouve. Et faut rajouter le fil 10AWG avec ça. D'ailleurs ça serait cool si quelqu'un pouvait vérifier les références pour être sûr que tout ça s'accouple bien.

Par contre, pas trouver de fil sur mouser (ça fait un moment que je cherche... je ressaierai plus tard) qui rentrerait dans les contraintes de nos crimp contact (diamètre extérieur de 3.6 à 4.9mm) mais sur farnell, avec cette recherche , j'ai trouvé ça en noir et en rouge qui ont l'air d'aller (sauf pour les brins, ces fils ont 84 brins de 0.3mm de diamètre alors que la datasheet pour les contacts dit 104 brins à 0.24mm de diamètre mais ça reste du 10AWG donc je pense que ça devrait passer).

Sinon pour l'idée des deux rangés de trois pôles, je n'ai pas trouvé chez ce même constructeur mais dans ce cas là, on peut certainement prendre le même type de connecteur que ceux utiliser pour alimenter les cartes PCI-E utilisées dans les PC (principalement pour les cartes graphiques) mais pas sûr que ça tiennent la quinzaine d'ampères par pôle.

EDIT : en fait les fils se trouvent sur mouser (4.6mm de diamètre extérieur) mais c'est des rouleaux d'au moins 100 pieds/30.5m... avec le prix qui va avec : 78€