0Home Page test forums PROGRAMMATION ARDUINO MrlComm version 54

This topic contains 19 replies, has 2 voices, and was last updated by  Christian 2 years, 10 months ago.

  • Author
    Posts
  • #6975

    Dominique
    Participant

    @christian

    Ce bout de code ne fonctionne plus car la class MrlMsg n’existe plus (remplacer par Msg je suppose):

    peux tu me donner la nouvelle méthode ?

    Merci d’avance.

    • This topic was modified 2 years, 10 months ago by  Dominique.
  • #7033

    Christian
    Participant

    Salut Dominique

    Grog a retravailler la classe MrlMsg est elle s’appelle maintenant Msg (la structure des messages est maintenant auto généré.

    la nouvelle fonction est Msg->publishCustomMsg(const byte* msg, byte msgSize);

    Cependant, je viens de remarquer que Msg n’est pas accessible en dehors de MrlComm.cpp (private)

    je vais regler ca dans un prochain update

    Comme tu es un des rares (le seul?) a utiliser cette fonction, je suis a l’écoute de comment tu préfere acceder a cette méthode.

  • #7034

    Christian
    Participant

    Salut Dominique

    Grog a retravailler la classe MrlMsg est elle s’appelle maintenant Msg (la structure des messages est maintenant auto généré.

    la nouvelle fonction est Msg->publishCustomMsg(const byte* msg, byte msgSize);

    Cependant, je viens de remarquer que Msg n’est pas accessible en dehors de MrlComm.cpp (private)

    je vais regler ca dans un prochain update

    Comme tu es un des rares (le seul?) a utiliser cette fonction, je suis a l’écoute de comment tu préfere acceder a cette méthode.

  • #7036

    Dominique
    Participant

    Salut Christian,

    En fait, je suis en train de refaire Activator et le but est de ne plus dépendre des modifications faites dans MrlComm. Il me suffira donc de remplacer MrlComm.ino par Activator.ino et ça doit fonctionner directement sans que je touche aux autres fichiers.

    Cette méthode Msg->publishCustomMsg(const byte* msg, byte msgSize); convient très bien.

    Une autres questions, le mécanisme de surveillance est il activé dans MyRobotLab ? Est il possible de la désactivé ? (par exemple serial.DisableCheckCom()) ? Est ce que la surveillance fonctionne aussi entre les ports séries du méga et d’autres MrlComm déportés ?

    Merci pour ton travail.

  • #7114

    Dominique
    Participant

    @christian:

    A tu une idée quand la méthode mrlcomm.publishCustomMsg(const byte* msg, byte msgSize); sera résolu ?

    Merci.

  • #7115

    Dominique
    Participant

    Pour info, pour avancer, j’ai ajouté cette méthode dans MrlComm.cpp :

  • #7116

    Dominique
    Participant

    Juste pour info:

    Est normal qu’aprés avoir ouvert la connection, toutes les secondes, je vois apparaître PUBLISH_BOARD_INFO et PUBLISH_ACK ?

  • #7118

    Christian
    Participant

    salut dom… j’ai fait la modif, mais pas encore pusher sur le serveur, je travaille un projet que je souhaite finir avant d’uploader. La modif est identique a ce que tu a fait

    publishAck est un message de confirmation que l’arduino a bien recu une commande… MRL attends cette confirmation avant d’envoyer un nouveau message. Ca évite que les messages se mélangent

    A toute les seconde, MRL envoie une demande de BoardInfo. le board info renvoie des données de l’arduino (memoire libre, temps pour un loop, les devices qui sont attaché). Ces messages permettent aussi de vérifier si la connection est toujours correcte entre MRL et l’arduino. Le but est que si l’arduino ou MRL reste trop longtemps sans communication, il déclanche une réaction a la perte de communication (qui n’est pas encore implementé)

  • #7120

    Dominique
    Participant

    OK Merci.

    De mon coté, tout fonctionne.

    Pour la vérif de com, c’est parfait. Activator fait la même chose mais dans l’autre sens, c’est à dire qu’il reboot le PC s’il ne reçoit plus de communication après 5mn.

    Maintenant, que ce passe t’il si on mets 3 MrlComm déportés sur les 3 ports séries du méga ? Cela va faire beaucoup de communication, non ?

    Serais t’il possible de prévoir un XXX.serialComCheckDisable(TRUE) dans MRL ?
    et activé par défaut ?

    Merci.

  • #7127

    Dominique
    Participant

    Oui, juste encore un souhait 🙂

    Serait il possible d’avoir une fonction du type mrlcomm.setPixelColor(num, r, g, b) ?

    Cela me permettrait d’utiliser la librairie interne de MrlComm au lieu de celle de Adafruit.

    Pour info, j’en suis à 93% de flash utilisé sur un atmega328.

    Merci.

  • #7131

    Christian
    Participant

    dom

    tu as raison a propos des MrlComm déporté,ca peut faire beaucoup de communication sur le port Serial du mega et créer un probleme de bandwith (4 MrlComm vont utiliser le meme port série). J’ai concu ceci pour faire fonctionner un arduino accessoire sur un mega, mais c’est surement pas concu pour connecter 4 mega qui font fonctionner 20 servo chacun et divers senseur. La communication par 1 port de série a ses limitations.

    tu peux faire arduino.enableBoardInfo(false) pour arreter MRL de faire des requetes a toute les secondes. Cependant, ca va activer les devices->onDisconnect() dans MrlComm. onDisconnect n’est présentement pas vraiment implémenté, seul la classe MrlNeopixel l’implémente (apelle un animation neopixel pour signifié la perte de communication). Comme je t’ai déja expliqué, c’est en cours de progres, mais d’autre projet on la priorité et il n’y a pas suffisamment d’elfes pour créer cette magie 🙂

    Si tu veux utilise le MrlNeopixel dans ton code, sans gestion par MRL, tu peux faire

    MrlNeopixel* neo = new MrlNeopixel(deviceId) //le deviceId n’as pas d’importance pour toi, mais tu dois fournir un byte

    pour changer les pixels tu utilise neo->neopixelWriteMatrix(byte bufferSize, byte*buffer)
    le buffer fonctionne par groupe de 4 bytes (pixelnumber, r,g, b)

    tu dois aussi appeler la fonction neo->update() a tout les main loop.

    n’hesite pas si tu as des questions

  • #7141

    Dominique
    Participant

    OK Merci Christian.

    Je vais tester tous ça.

    Néanmoins, j’aimerais, si possible être mis au courant des évolutions futurs de MrlComm car ce n’est pas évident de mettre à jour Activator. D’ailleurs, j’ai l’impression que petit à petit, les fonctionnalités d’Activator se greffe à MrlComm. Bon, ça me fait plaisir évidemment.

    Ne croit tu pas que l’on devrait se mettre d’accord sur ce que peut faire Activator en plus de MrlComm ?
    Est tu au courant de toute les fonctionnalités d’Activator ?

    J’aimerais vraiment que l’on travail ensemble pour avancer plus vite, et non se concurrencer en fonctionnalités.

  • #7144

    Dominique
    Participant

    Bon, arduino.enableBoardInfo(False) fonctionne nickel.

    Ce qui va se passait plus tard dans MrlComm me fait peur.

    Serait il possible de la désactivé par un “define ENABLE_ALONE_FUNCTION TRUE” définit dans MrlComm.ino ?

  • #7145

    Dominique
    Participant

    J’ai fait cette fonction:

    mais, ça ne marche pas… comportement aléatoire. une idée ?

  • #7151

    Christian
    Participant

    J’ai lu il y a quelque temps la description de Activator, mais j’ai jamais pris le temps d’entrer dans les détails. Tu as un link pour que je puisse me rafraichir la mémoire?

    Il n’est pas question de concurence dans les fonctionnalités. Le but de onDisconnect est de sécuriser les MrlDevices lorsqu’il y a perte de communication. Par example, si on demande a un moteur DC de tourner a pleine vitesse, il y a un souci si il y a une perte de controle avant que l’on lui dise d’arreter. Le moteur dois pouvoir s’arreter par lui meme lorse que la connection au controle est coupé.

  • #7152

    Christian
    Participant

    dans ton code, il manque l’initiation

    neo->attach(byte pin, long numPixels);

    désolé pour l’oublie

  • #7159

    Dominique
    Participant

    Salut,

    Ben non, j’ai bien mis l’initialisation dans setup()…

    Le comportement est aléatoire.

  • #7171

    Christian
    Participant

    utilises-tu des interrupts dans ton code?

  • #7181

    Dominique
    Participant

    oui… bon j’ai compris 🙂

    Merci.

  • #7188

    Christian
    Participant

    le neopixel est contraignant a cause des interrupts. Il demande un timing tres precis pour recevoir les commandes. Les interrupts brisent ce timing. Dans la librairie de Adafruits, les interrupts son bloqué pendant les mises-a-jour du neopixel. Le résultats est que le neopixel fonctionne parfaitement, mais les fonctions interrupts ne fonctionneront qu’a temps partiel, ce qui causait des soucis avec les servos. Rien de pire qu’avoir un servo positionné a sa limites perdre ses repaires et bouger par lui meme de facon aléatoire. C’est pourquoi j’ai enlever le plus possible la suppression des interrupts dans MrlNeopixel. Le but étant d’assurer le fonctionnement des servos plutot que du neopixel.

    MrlNeopixel a quand meme une tolerence au interrupts. Dans mes tests, un ou deux servo était pas un probleme, mais plus et le neopixel devenait instable. Il peut donc fonctionner si il y a peu d’interrupts et que ceux-ci sont tres court.

You must be logged in to reply to this topic.