MrlComm version 54

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

Viewing 19 reply threads

Author

Posts
- February 5, 2017 at 10:10 pm #6975
  Dominique
  Participant
  @Christian
  
  Ce bout de code ne fonctionne plus car la class MrlMsg n’existe plus (remplacer par Msg je suppose):
```
  MrlMsg msg(PUBLISH_CUSTOM_MSG);
  msg.countData();
  int i=0;
  while (mrlComm.getCustomMsgSize()){
    int x = mrlComm.getCustomMsg();
    //MrlMsg is the class that build message to send to MRL
    msg.addData(x);
    i++;
  }
  if (i) msg.sendMsg();
```
  peux tu me donner la nouvelle méthode ?
  
  Merci d’avance.
  - This topic was modified 7 years, 10 months ago by Dominique.
- February 8, 2017 at 4:38 am #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.
- February 8, 2017 at 4:40 am #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.
- February 8, 2017 at 8:42 am #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.
- February 12, 2017 at 8:56 pm #7114
  
  Dominique
  Participant
  
  @Christian:
  
  A tu une idée quand la méthode mrlcomm.publishCustomMsg(const byte* msg, byte msgSize); sera résolu ?
  
  Merci.
- February 12, 2017 at 9:01 pm #7115
  Dominique
  Participant
  Pour info, pour avancer, j’ai ajouté cette méthode dans MrlComm.cpp :
```
void MrlComm::sendCustomMsg(const byte *data, byte msgSize)
{
  msg->publishCustomMsg(data, msgSize);
}
```
- February 12, 2017 at 9:19 pm #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 ?
- February 13, 2017 at 3:30 am #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é)
- February 13, 2017 at 10:33 am #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.
- February 13, 2017 at 3:19 pm #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.
- February 13, 2017 at 4:57 pm #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
- February 13, 2017 at 8:51 pm #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.
- February 13, 2017 at 9:43 pm #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 ?
- February 13, 2017 at 11:10 pm #7145
  Dominique
  Participant
  J’ai fait cette fonction:
```
void setPixels(byte r, byte g, byte b)
{
  int i, index;
  byte ucTemp[64];

  for (i = 0; i < NUMPIXELS; i++)
  {
    index = (4 * i);
    ucTemp[index] = i;
    ucTemp[index + 1] = r;
    ucTemp[index + 2] = g;
    ucTemp[index + 3] = b;
  }

  pixels->neopixelWriteMatrix(NUMPIXELS, ucTemp);
  pixels->update();
}
```
  mais, ça ne marche pas… comportement aléatoire. une idée ?
- February 14, 2017 at 12:30 am #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é.
- February 14, 2017 at 12:33 am #7152
  
  Christian
  Participant
  
  dans ton code, il manque l’initiation
  
  neo->attach(byte pin, long numPixels);
  
  désolé pour l’oublie
- February 14, 2017 at 2:29 pm #7159
  
  Dominique
  Participant
  
  Salut,
  
  Ben non, j’ai bien mis l’initialisation dans setup()…
  
  Le comportement est aléatoire.
- February 14, 2017 at 5:46 pm #7171
  
  Christian
  Participant
  
  utilises-tu des interrupts dans ton code?
- February 14, 2017 at 8:43 pm #7181
  
  Dominique
  Participant
  
  oui… bon j’ai compris 🙂
  
  Merci.
- February 14, 2017 at 9:44 pm #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.
Author

Posts

Viewing 19 reply threads

You must be logged in to reply to this topic.