Viewing 10 reply threads
  • Author
    Posts
    • #5761
      Dominique
      Participant

      Bonjour,

      Afin de mettre tout le monde d’accord sur le fonctionnement d’activator, je vais vous donner quelques explications.

      Tout d’abord, voici une comparaison du soft MrlComm et Activator qui sont fort différents:

      Le soft MrlComm qui se trouve dans les arduino mega gauche et droite a pour vocation d’être universelle. C’est à dire que chaque pins de l’arduino peuvent être définis pour une fonction. La plupart du temps on utilise la fonction “servo” mais beaucoup de services peuvent être utilisés comme I2C, entrées et sorties logiques, entrées analogiques, etc…

      Le soft Activator n’ai pas développé dans ce sens. Toutes les entrées et sorties du nano ont leurs fonctions parfaitement définis et figés. Evidemment je n’ai pas choisi les pins aux hasards. Les pins analogiques sont utilisées pour capturer l’audio, le réglage du seuil audio et la lecture des batteries, les pins d’interruption pour réveiller le système et le reste des IO pour divers commandes notamment les relais de mise en route.

      A la mise sous tension, Activator se met en veille afin de consommer le moins possible de courant (autour de 15mA). Toutes les 8s, il se réveille, allume le ring de la couleur de son choix, l’éteins et se remet en veille.

      Lorsqu’un pulse à la masse arrive sur la pin D2 (soit par un bouton poussoir, soit par le détecteur de présence), activator se réveille et lance la procédure de démarrage. Il active l’électronique générale, lance le PC Windows et lance une animation du ring. Puis il attend un ordre venant du python de myrobotlab pour lui signaler que le PC est prêt.

      A partir de ce moment, Activator lance les services aux choix demandés par myrobotlab comme une animation ou une couleur du ring, activation du relais de puissance pour les moteurs, etc.

      Le servo de la bouche est immédiatement opérationnelle et réagit avec le niveau audio du PC qui est fixe à 92% (attention, surtout pas celui de l’ampli audio sinon ça ne fonctionnerait plus avec la diminution du volume). Le ring réagit aussi avec le niveau audio.

      Un timer myrobotlab permet le rafraichissement d’un watchdog de supervision permettant a activator de savoir que tout va bien, sinon il effectue un redémarrage du système. Un second timer effectue la lecture des tensions batteries.

      Lorsque l’on souhaite éteindre le robot, myrobotlab envoie une commande à activator pour lui demander un shutdown. 30s après réception de cette commande, activator coupe toutes les alimentations et se mets en veille.

      Afin d’intégrer au maximum Activator à myrobotlab, j’ai utilisé la même façon de communiquer que MrlComm. J’ai donc pour cela modifié MrlComm.cpp et .h afin de l’adapter aux services que proposent Activator (les autres fichiers sont restés inchangés).

      Alors, apparemment les personnes en chargent de MrlComm ne sont pas favorable aux modifications que j’effectue. J’ai donc renommé MrlComm.cpp en ActMrlComm.cpp pour qu’il n’y ai plus de confusion.


      @Christian
      et Anthony: Il est possible de modifier le soft Activator pour que le seul changement soit Activator.ino MAIS dans ce cas, il sera possible de perturber le fonctionnement des pins attribuées aux fonctions d’Activator et peut même être dangereux. Le protcole d’Activator ne se résume pas au sendCustomMessage et publishCustomMessage. Donc, ce n’est franchement pas la bonne solution.

      Activator doit donc être un soft a part entière ET totalement indépendant de MrlComm.

      Il serait possible d’avoir un service Activator au même titre que le service Arduino dans MyRobotLab. Pour cela il suffirait de définir quelques commandes “send-received” qui n’ont rien à voir avec ceux de MrlComm.

      J’espère que toute ces explications vous aideront à comprendre le fonctionnement d’Activator et pouvoir définir les évolutions au seins de MyRobotLab.

      A+
      Dom.

      • This topic was modified 6 years ago by Dominique.
    • #5764
      Christian
      Participant

      Salut Dominique

      Ton projet est génial, et je souhaite vraiment t’aider a l’implémenter de façon a minimiser la maintenance et assurer sa pérennité. La facon que tu a modifier cause plusieurs soucis, non pas pour MRL mais pour toi. Laisse moi t’expliquer.

      MRL et MRLComm son intimement lié. Des modifications a l’un ou a l’autre peuvent generer des changement dans sa contre-partie. De plus, une partie de MRLComm est généré automatiquement par MRL.

      Qu’est que ca signifie? C’est que chaque fois que MRLComm sera modifié, tu devras mettre ton code a jour pour qu’il puissent continuer a fonctionner, et tu n’as aucun controle sur le quand et sur le quoi doit etre mis a jour. Quand tu n’auras plus le temps ou le gout de faire les mise a jour, ton code va malheureusement tomber dans les oubliettes puisque plus personne ne pourra l’utiliser.

      Par contre, si tu utilise MRLComm comme une librairie (par le customMsg/publishCustomMsg) ou que tu integre ton code comme un service MRL. Ton code est indépendant de Mrlcomm et n’importe quel quidam peut mettre a jour la librairie sans que ca brise ton code. Donc, le jour ou tu délaissera le projet, ton code pourra continuer a fonctionner tant qu’il sera utile.

      C’est un principe important en open source pour s’assurer des compatibilités.

      CustomMsg est bien plus qu’un simple transfert d’octets. L’exemple que j’ai fourni est simple, 2 octets son transferé du python a l’arduino puis vers le python a nouveau, mais tu peux aussi l’utiliser pour sérialiser des fonctions ou des structure de données complexes.

      par exemple tu peux sérialiser la fonction
      maFonction(byte, byte, int){
      arduino.customMsg(FUNCTION_NAME,byte, byte, int >> 8, int & 0xFF)
      }

      et tu peux désérialiser la function du coté d’arduino
      et vice-versa.

      J’espere que cet information te sera utile, laisse moi savoir si je peux t’aider de quelconque facon

      Christian

    • #5765
      My’s Moov
      Moderator

      Merci Dominique pour ces informations 🙂

    • #5769
      Dominique
      Participant

      Bonjour,

      OK je comprend maintenant comment s’effectue le développement de MrlComm.

      Ce qui me gène ce n’est pas la com car tout peux t’être fait avec customMsg sans problème, mais l’interaction de MrlComm sur le matériel. Par exemple, si je mets une PIN à HIGH, alors MrlComm pourrait la mettre à Low et inversement. Hors tu peux comprendre aussi que cela n’est pas acceptable.

      Si j’ai utilisé la commande digitalWrite, c’est aussi pour avoir plus facile à débbuguer car MyRobotLab propose un panel Arduino où l’on peut facilement envoyer des commandes.

      Je veux bien faire des concessions sur la manière de coder Activator, mais de votre cotés faites en aussi.

      En résumé, pas de problème pour travailler ensemble car c’est comme cela qu’InMoov pourra évoluer plus rapidement et dans ce cas trouver un moyen de développement plus facile.

      Une idée serait de séparer MrlComm et le hardware. Je ne sais pas si c’est possible de votre coté ?
      Cela permettrait d’avoir un noyau de communication commune à tous les projets (car Activator ne sera pas le seul soft en plus de MrlComm) avec une interaction hardware indépendante des différents projets.

      Bonne Journée.

      Dom.

    • #5770
      Gael Langevin
      Keymaster

      Salut Dominique,
      Je trouve ton projet super! Effectivement c’est une bonne chose d’essayer d’integrer les codes au maximum a MRL. Ce serait dommage que ton travail soit perdu au bout de quelques mise a jour et non utilisable car sans possibilite de maintenance par la communaute. Lorsque j’avais explique le principe d’Activator a Marten, (seul les Francais sont au courant a propos d’Activator, en fait a cause de la barriere de la langue), il pense que nous pourrions faire quelque chose d’assez similaire directement dans MRL en creant un service.

      Nous avions deja commence a modifier la NervoBoard car nous voulions integrer la possibilite RX TX ainsi que le i2C.

      Evidemment le travail que tu as accompli serait entierement a refaire et ce serait bien dommage.

      Je ne suis pas cale comme tu l’es en codage, ce qui fait que je ne peux juger si techniquement c’est possible ou pas. Mais comme j’ai vu que tu te debrouillais tres bien en Anglais, la communaute de MRL se fera un plaisir de travailler avec toi la dessus, si tu es d’accord.

      En fait c’est paradoxale, autant l’OpenSource c’est fabuleux car on peut faire pratiquement tout, mais c’est difficile de maintenir une branche conductrice sans qu’elle s’eparpille en disparraissant.

    • #5771
      Dominique
      Participant

      Bonjour Gael,

      Evidemment je suis complètement d’accord pour travailler en commun avec les personnes de MRL.

      Comme j’ai déjà dit ce serait génial est d’avoir un service MrlComm commun pour tout les projets qui serait indépendant du hardware car c’est la où se trouve le problème, MrlComm étant universelle et Activator pas, ben ça coince.

      Aujourd’hui j’ai mis une grosse mise à jour sur github permettant à Activator de consommer le moins possible lorsqu’il est en veille (12mA), chose que MrlComm est incapable de faire en l’état actuelle.

      Activator était l’un de mes projets pour commencer InMoov car c’est la base pour alimenter proprement le robot. Mais ce n’est pas le seul projet. D’autre sont à venir.

      Je m’explique: L’un des gros problème actuelle avec les mains est la longueur des câbles. Cela entraîne un tas de parasites et rend même presque impossible l’utilisation des capteurs dans les doigts.
      Je compte donc utiliser un nano qui se chargera de rendre la mains intelligente en gérant un capteur gyroscopique, les capteurs sensorielles et les servos. Il suffira donc de 4 fils pour commander entièrement la main (2 alimentations et 2 communications).

      De nouveaux, l’intégration à MRL sera un problème si on universalise pas la communication.

      A+
      Dom.

    • #5772
      Christian
      Participant

      Salut Dominique

      Tu ne semble pas comprendre le principe de fonctionnement de MRL/MrlComm.

      Le but est d’avoir une gestion du hardware a partir d’un ordinateur et de facon universelle. Tout pourrait être gerer a partir de MRL, mais malheureusement tout ne peux pas etre implanté a l’origine et est fait au fur et a mesure que les besoins apparaissent.

      As-tu remarquer qu’il exisite un seul sketch pour arduino sketch arduino qui peux gerer tout? Servos, senseurs (gyroscopique comme le MPU3060 ou BNO055) la gestion des pins, le neopixel, les moteur DC etc.
      Ton idée d’utilisation de capteur gyroscopique et sensorielles et servo a l’aide de 4 fils est déja supporté par MRL, et ce sans l’utilisation d’un controlleur supplémentaire.

      Presque tout ton code pourrait être gérer facilement par MRL/MRLcomm, mais tu as choisi une facon différente de faire et demander de refaire MRLComm/Mrl pour s’adapter a ton code n’est tout simplement pas un option. C’est a toi a t’adapter a ce qui est déja en place et fonctionne très bien.

      Cependant, nous somme très ouvert a implementer ce qui permettra a ton programme de bien fonctionner.

    • #5773
      Dominique
      Participant

      OK Christian,

      Bien sur je comprends votre point de vue. Evidemment je sais comment fonctionne MRL et MrlComm car j’ai étudier tout le code.

      Mais si je prend l’exemple du ring, la gestion dans MrlComm ne me conviens pas car je voulais une réaction avec l’audio.

      Si on veut une consommation minimal et certaines fonctions autonomes sans PC, et bien MrlComm ne peux pas le fournir car il a besoin d’un PC.

      La gestion de la bouche aussi est dans MRL, mais le traitement avec le PC est t’il aussi rapide qu’un nano dédié à la tache ?

      En tout cas, rien ai fait de votre cotés pour facilité l’utilisation de MRL, que ce soit avec l’I2C, senseurs, gyroscope ou autre… Aucuns exemples n’est disponible pour que tout le monde puissent facilement l’implémenté avec Python.

      Lorsque j’ai voulu commencer InMoov je partais sur une carte complète et génial SD84 de chez devantech. Pas d’arduino, une seule carte suffisait à commander le robot. J’ai posé la question chez MRL si il pouvait la prendre en compte, on m’a envoyé sur les roses en me disant qu’il suffit d’utiliser un service serial com. Bon ok, j’ai laissé tomber car tout était déjà fait avec l’arduino.

      Enfin bref, si de votre coté vous me disiez comment on peut mettre tout le soft d’Activator dans MrlComm et MRL en gardant toutes le fonctionnalité actuelles, cela nous éviterais de tourner en rond…

      A+
      Dom.

    • #5786
      Christian
      Participant

      La gestion par MRL est effectivement plus lent que par un controlleur dédié, mais on parle de ms, soit rien de très génant.

      Je n’ai pas le détail de ton hardware, mais de facon générale tu pourrait faire pour ton exemple de la bouche qui réagit au son

      Tu as un senseur sonore qui est probablement connecté a une pin analogue. La fonction arduino.enablePin(pin, rate) permet de sonder la valeur de la pin et envoyer sa valeur du coté de MRL/python ou elle peut être analyser et envoyer les commandes nécessaire, par example, ouvre la bouche, modifie le neopixel, leve le bras droit, ferme la main gauche, etc. Les actions peuvent se faire sur n’importe quel controlleur.

      Pour ce qui de mettre le controlleur en stanby et d’avoir des fonctions autonome lorsque le pc est éteint, tu as raison, le controle doit se faire au niveau du controlleur et c’est probablement a ce niveau qu’il y a un peu de travail a faire sur MRLComm. Lorsqu’il n’y a plus de connection avec le PC (PC éteint ou cable USB déconnecté) MRLComm continue de fonctionner et de mettre a jours ses éléments. Il suffira probablement de créer une méthode pour permettre de controller les éléments a l’interne. Je vais avoir besoin d’étudier un peu plus ton code pour voir ce qu’il y a a faire, mais ca ne devrait pas être un probleme.

    • #5797
      anthony
      Moderator

      Merci à tout le monde ici présent pour le travail que vous faites, c’est génial ! Le projet est libre on fait un peu se que l’on souhaite. Pour ma part je privilégie la communauté . La priorité doit être la compatibilité, l’interopérabilité et le suivi. Pour aider ceux qui vont nous remplacer entre autre. Il faut privilégier une collaboration active avec les utilisateurs de mrl et les développeurs, enfin ce n’est pas la peine de le préciser. Car mrl est le cœur du système ! je ne me permet pas le luxe de me passer de leurs précieux conseils et de leurs expertise. Avançons ensemble pour aller plus loin ! bisous

    • #5798
      Dominique
      Participant

      OK je comprends fort bien ce que vous voulais faire. Le but est d’intégrer un maximum de service pour que le traitement ce fasse uniquement par le PC. Hors tout le monde n’a pas un coreI7 dans InMoov. Si je veux une gestion correct de la bouche avec une reconnaissance faciale ou d’objet, je ne suis pas certain que ma petite lattepanda suivra le rythme.

      Mon but était justement de soulager le PC qui lui a besoin de toute sa puissance pour gérer la vidéo et l’intelligence du robot. A part cela beaucoup de petite tache comme la gestion de la bouche peuvent être faite ailleurs comme dans Activator.

      Les 2 approchent sont différentes, mais il faut comprendre que mon but est d’avoir un robot autonome qui consomme le moins possible. Un PC trop puissant ne pourrait pas donner cette autonomie. Il faut rentabiliser au maximum les ressources offerts par les microcontrôleurs externes pour soulager le processeur principal qui est le PC.

      Concernant mon futur projet de gestion de la main, si j’obtiens toutes les briques pour développer alors le nano déporté contiendra MrlComm et j’utiliserais les services proposés. Cela me permettra de savoir si une lattepanda est suffisant pour gérer tous les services, y compris openCV. Pour le moment j’en doute.

      A+
      Dom

Viewing 10 reply threads
  • You must be logged in to reply to this topic.