[Dominique]

@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.

[Christian]

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.

[Christian]

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.

[Dominique]

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.

[Dominique]

@Christian:

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

Merci.

[Dominique]

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);
}

[Dominique]

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 ?

[Christian]

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é)

[Dominique]

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.

[Dominique]

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.

[Christian]

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

[Dominique]

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.

[Dominique]

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 ?

[Dominique]

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 ?

[Christian]

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é.

[Christian]

dans ton code, il manque l’initiation

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

désolé pour l’oublie

[Dominique]

Salut,

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

Le comportement est aléatoire.

[Christian]

utilises-tu des interrupts dans ton code?

[Dominique]

oui… bon j’ai compris 🙂

Merci.

[Christian]

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