55 réponses à ce sujet

[Florent Martin]

J'ai décidé de m'occuper de l'alimentation en dernier mais qu'utilise-tu pour éviter ce phénomène?

Aussi j'aimerai n'avoir qu'une batterie pour mes moteurs et mon arduino. Quel genre de protection pour éviter les problèmes ? Un peu partout on lit de ne pas faire ça mais avoir deux batteries séparés ca me parait étrange...

[Microrupteurman]

Pour mes arduino, j'ai ajouter un régulateur qui descend la tension vers 7v avant de l'envoyer dans la carte. C'est pas très économique énergiquement parlant, j'ai mis de simple LM317.

[ailgorbot]

Est-ce que celui-ci ferait l'affaire ? http://www.selectronic.fr/convertisseur-abaisseur-de-tension-lm2596-sortie-1-25v-35v.html?suggestion=produit

[ailgorbot]

Est-ce que celui-ci ferait l'affaire ? http://www.selectronic.fr/convertisseur-abaisseur-de-tension-lm2596-sortie-1-25v-35v.html?suggestion=produit

[Microrupteurman]

Oui, c'est une alim a découpage, c'est le must, j'en ai pris 3 comme ça sur Eba*, certain font même voltmètre.

[ailgorbot]

salut, Si tu n'as pas encore mise en oeuvre les flux vidéos, je te suggère de regarder les solutions WEBRTC. Il y a par exemple opentokrtc.com qui est vraiment très simple à utiliser. Je suis en train de modifier complètement mon code pour échanger les flux vidéos. ça marche vraiment bien.

[Florent Martin]

J'ai pas bcp avancé sur le robot car adafruit à livré les pièces que j'ai commandé ... a new york pratique!

ils renvoient tout mais bon du coup ça fait 2 semaines de "perdu"

 

Je suis pas certain d'avoir besoin de webrtc, à mon avi pour mon truc un simple skype suffira.

[ailgorbot]

Oui effectivement si tu poses la tablette ou le smartphone simplement sur le robot, et que tu le contrôles via la page web proposée par le l'Arduino-YUN, ça marchera aussi. C'est vrai dans mon projet, je souhaite que le robot ait un peu d'autonomie dans ses déplacements, s'il n'est pas télécommandé, comme un robot-suiveur avec l'analyse de la vidéo. Cela induisait la récupération du flux vidéo pour analyse., ce qui doit être complexe avec Skype...

[Florent Martin]

Ah ouai pour l'analyse videoc'est une autre histoire.

Mais l'informaticien en moi me dit que analyse le flux video pour repérer des obstacles est un défit en soi, comment compte tu faire?

Pas totalement impossible ceci dit, suivant les conditions de lumière, autres capteurs ect ...et surtout les bonne librairies

[Mike118]

 un robot-suiveur avec l'analyse de la vidéo. 

Avant de sortir de l'analyse d'imageavec open CV il peut être interessant de savoir pour une petite cinquantaine d'euro on peu avoir des capteurs très bien qui peuvent communiquer directement les info qui nous intéressent par I2C par exemple : Camera IR, caméra thermique, ou caméra intelligente type cmu cam. 

Sinon si tu es capable de faire du traitement d'image avec ton téléphone je suis curieux de voir ça ! =) Pour l'instant moi je ne fais pas encore d'application comme ça ^^ 

 

 

 

J'ai décidé de m'occuper de l'alimentation en dernier mais qu'utilise-tu pour éviter ce phénomène?

Aussi j'aimerai n'avoir qu'une batterie pour mes moteurs et mon arduino. Quel genre de protection pour éviter les problèmes ? Un peu partout on lit de ne pas faire ça mais avoir deux batteries séparés ca me parait étrange...

 

 

Sinon d'autre remarque en passant comme ça : 

 

1) Je me demande si : une arduino uno + un shield yun serait compatible avec ton shield moteur 

2)  Pour piloter des moteur pas à pas je te recommande sans hésiter cette carte http://www.dx.com/fr/p/tb6560-single-axis-3a-stepper-motor-driver-green-10-35v-214349?tc=EUR&gclid=Cj0KEQjwy7qrBRC4lp7_hM3dgIoBEiQA72pCnklA-yYqketcF1MUvE1OmvulcjEwpUyvXKWdaWBrgsQaAucd8P8HAQ#.VW-Ft8_tmko ( Il en faut une par moteur pas à pas )  dispo aussi sur ebay et chez plusieurs autres fournisseur. 
Seul soucis perso sur un peu plus d'une vingtaine de cartes commandées, 3 avaient un défaut dont 1 que j'ai pu corrigé. Mais toute les autre fonctionnent merveilleusement bien! DOnc si jamais tu décide d'en acheter je te suggère d'en prendre une de plus " juste au cas où " et vu leur prix ... c'est pas très cher payé ^^ 

3) Pour ton soucis d'alimentation : tu peux utiliser une seule batterie sans problèmes par contre il y a différents type de protection possible en fonction de ce que tu veux protéger et de quoi ... Protection contre les inversions de polarité, protection contre les court circuit , protection de surtenstion ... mais après en général c'est tellement plus spécifique que dans ces cas là il faut se faire sa propre petite carte dédiée qui fait ce que tu veux à chaque fois. Perso moi c'est ce que je fais. Genre " carte d'alim " qui dispose de ce genre de fonction :

•  je branche ma batterie dessus, si la tension de la batterie est trop faible ça coupe tout,
•  si je branche la batterie à l'envers rien ne se passe ( rien fonctionne mais rien ne crame ) ,
• j'ai un interrupteur qui permet de tout couper ( je peux laisser brancher ma batterie sans craintes )
• j'ai un régulateur qui fournit une tension pour mes cartes " micro-controlleurs "  et un régulateur différent qui fournit la tension pour les différents actionneurs 
• un bouton d'arrêt " d'urgence" qui permet de couper que les actionneurs ( tu peux reprogrammer tranquile ) 
• une petite led qui te dis si tu es allum et, si tu as ou pas le bouton d'arrêt d'urgence 
• protection contre les court circuit via fusible ou poli switch. 

Bref possibilité de mettre que les truc qui t'intéresse sur ta propre carte en fonction de ton besoin ( J'ai pas encore fais une seule carte qui regroupe tout ça car j'en ai pas eu besoin jusqu'à présent ^^ mais j'ai plusieurs carte qui regroupe plusieurs des fonctions précédentes pour mes différents robot ^^ )
Cependant ce genre de carte c'est bien de la développer en dernier quand tu sais exactement ce que tu veux et ce que tu as besoin en connecteurs en fonctionnalité etc ...

 

Si tu as d'autres questions n'hésite pas à les poster ici  

[ailgorbot]

C'est un des intérêts du IOIO-OTG, la puissance de calcul se trouve sur le téléphone. C'est sûr que l'analyse vidéo ne se fera pas avec mon pauvre Galaxy S, cet ancien fleuron Samsung en 2010. En revanche, avec mon Elephone P6000 et son "MT6732 with advanced 64-bit Quad Core 1.5GHz Cortex-A53 " c'est largement envisageable. Le Galaxy S, ne fait qu'exécuter les ordres, va tout droit, tourne à gauche, lève la tête... etc. Et bien évidement il film. Mais le P6000 qu'il soit télécommande ou connecté au IOIO sur le robot pourra mettre en oeuvre OpenCV. IOIO-OTG étant Full-Java Android, c'est relativement "simple" de mettre en oeuvre OpenCV (ou JavaCV). Je code tout avec un seul langage. Sur Github, tu tapes Android, opencv... tu as des tas exemples de codes qui font de l'analyse vidéo... C'est le but du projet. Un robot de téléprésence, qui se gère tout seul (donc comme un robot suiveur) si la télécommande est inactive par exemple 30 secondes. je termine de peaufiner le système avec WebRTC (opentokrtc.com) et je m'attaque à OpenCV.

[Florent Martin]

Retour à la case le robot avance.

Je vais poster une photo.

En gros j'ai fait mon montage avec mes drivers md90 contrôlé par 4 pins de l'arduino. J'ai fait une petite pseudo librairie car je n'en ai pas trouvé sur le net. Soit disant que c'est trop simple ( 1 pin direction 1 pin par pas). Dommage car justement c'est pas si simple. Il faudrait gérer les acceleration et deceleration par exemple.

A part un décalage de deux secondes entre l'envoi de l'ordre et l'execution ça  marche bien comme dans la vidéo précédente.

 

Maintenant le montage de la tablette

[Mike118]

Un décalage de 2 secondes ? Qu'est ce qui provoque ce délais ? Tu as pas moyens de le réduire ? D'expérience 2 secondes est une latence désagréable et problématique pour le genre d'application que tu envisage ... 

En tout cas bon courage pour la suite ! 

[Florent Martin]

Alors, voici la petite vidéo du problème. 

 

Quand j'appuie sur avancer, l'ordi envoi a l'arduino l'ordre d'avancer et quand je relâche, l'ordi envoie l'ordre d'arrêter les moteurs.

Etrangement pour avancer on a un délai de deux sec, pour s'arrêter non. Pourquoi ? aucune idée. 

Mon code est vraiment simple et quand j'aurai terminé de le nettoyer je le poste...

 

 

On peut voir un autre problème, par moment la roue "rembobine" Je ne sais pas pourquoi car normalement a chaque impulsion, le moteur avance d'un pas, jamais je lui donne de position précise a prendre... Un problème de masse sur mes drivers?

Quand je fais rouler le robot, je n'ai pas l'impression que cela gène. A retester quand même car en l'air c'est bien violent...

 

 

 

 

Alors en rédigeant ce post, une partie de la réponse m'est apparue, la fonction 

    YunClient client = server.accept();

Du yun ne doit pas être executée trop souvent sinon le yun devient un peu "fou". 

En temporisant ( 1/10sec) j'ai supprimé l'effet "roue qui rembobine", ca tourne parfaitement mais j'ai toujours 2 sec de delay...

 

[EDIT] D'après ce que je vois le YUN est juste lent et c'est normale d'avoir ce genre de delai. 

Le robot s'arrête à chaque fois qu'il reçoit un nouvel ordre et c'est pour cela que je pensais que ma fonction stop() était  bien executé alors que pas du tout. 

 

On va peut être retourner sur un arduino + module bluetooth + Serveur sur le galaxy tab finalement ....

[Mike118]

Ah dommage moi qui trouvait le yun intéressant ! x) Si c'est lui qui est trop lent il perd beaucoup d'intérêt d'un coup ...  x)
J'espère qu'en jetant un oeil dans ton code on va pouvoir trouver comment réduire ce délais ^^ 

 

à bientôt ! 

[Florent Martin]

/*
  Motormd90.h - Library for controlling md90 stepper driver
  Created by florent martin, June 9, 2015.
  Released into the public domain.
*/
#ifndef Motormd90_h
#define Motormd90_h

#include "Arduino.h"

class MotorMd90
{
  public:
    MotorMd90(int dirPin, int stepPin);
    void setDirection(boolean dir);
    void run();
    // on lui donne des valeurs qui sont la fréquence des "ticks" ( plus petit = vitesse up )
    void setSpeed(int speed);
    void stop();
    void start();
  private:
    void motorTick();
    int _dirPin;
    int _stepPin;
    boolean _actualState;
    boolean _stoped;
    boolean _actualDirection;

    unsigned long _lastTick;
    double _actualFrequence = 100;

};



#endif


/*****************************************
 * ***************************************
 * ********CLASS FUNCTION************************
 * ***************************************
 */

MotorMd90::MotorMd90(int dirPin, int stepPin)
{
  pinMode(dirPin, OUTPUT);
  pinMode(stepPin, OUTPUT);
  _stepPin = stepPin;
  _dirPin = dirPin;
  _actualState = LOW;
  digitalWrite(_stepPin, LOW);

  _lastTick = 0;
  _stoped = HIGH;
}
void    MotorMd90::stop()
{
  _stoped = HIGH;
}

void    MotorMd90::start()
{
  _stoped = LOW;
}


void    MotorMd90::setDirection(boolean dir)
{
  _actualDirection = dir;
  digitalWrite(_dirPin, dir);
}

void    MotorMd90::motorTick()
{
  _actualState = HIGH;
  digitalWrite(_stepPin, HIGH);

// ancienne technique
 /* delay(1);
  _actualState = LOW;
  digitalWrite(_stepPin, LOW);*/

}
void    MotorMd90::run()
{

  if (_stoped == HIGH)
    return;

  if(_actualState == HIGH){
      _actualState = LOW;
      digitalWrite(_stepPin, LOW);
    }

  int dif = millis() - _lastTick;
  if (dif > _actualFrequence) {
    _lastTick = millis();
    motorTick();
  }
}


void    MotorMd90::setSpeed(int speed)
{
  _actualFrequence = speed;

}

/*****************************************
 * ***************************************
 * ********PROGRAM************************
 * ***************************************
 */



#include <Bridge.h>
#include <YunServer.h>
#include <YunClient.h>



MotorMd90 *myStepper1;
MotorMd90 *myStepper2;

YunServer server;

void avance() {
  myStepper1->setDirection(LOW);
  myStepper2->setDirection(LOW);
  myStepper1->start();
  myStepper2->start();

}

void recule() {


  myStepper1->setDirection(HIGH);
  myStepper2->setDirection(HIGH);
  myStepper1->start();
  myStepper2->start();
}
void stop() {
  myStepper1->stop();
  myStepper2->stop();
}


void tourneDroite() {

  myStepper1->setDirection(LOW);
  myStepper2->setDirection(HIGH);
  myStepper1->start();
  myStepper2->start();

}

void tourneGauche() {

  myStepper1->setDirection(HIGH);
  myStepper2->setDirection(LOW);
  myStepper1->start();
  myStepper2->start();
}


// Frequence à laquelle le yun vérifie les ordres
double _clientCheckFreq = 200;
// derniere vérification des ordres
unsigned long _lastClientCheck = 0;

void setup()
{
  //Serial.begin(9600);


  myStepper1 = new MotorMd90(8, 9);
  myStepper2 = new MotorMd90(10, 11);
  myStepper1->setSpeed(15);
  myStepper2->setSpeed(15);


  Bridge.begin();
  server.listenOnLocalhost();
  server.begin();

}

void loop()
{

  int dif = millis() - _lastClientCheck;
  if (dif > _clientCheckFreq) {
    _lastClientCheck = millis();
    
    YunClient client = server.accept();
    if (client) {
      String command = client.readString();
      command.trim();
      if ( command == "Stop" ) {
        stop();
        client.print(command);
      }
      else if ( command == "Forward" ) {
        avance();
        client.print(command);
      }

      else if ( command == "Backward" ) {
        recule();
        client.print(command);
      }
      else if ( command == "Right" ) {
        tourneDroite();
        client.print(command);
      }
      else if ( command == "Left" ) {
        tourneGauche();
        client.print(command);
      }
      client.stop();
    }
  }
  myStepper1->run();
  myStepper2->run();
  //delay(1);
}

J'ai pas bien pigé comment on créait une librairie séparé dans l'ide arduino du coup le code de la lib vient avec celui du robot. Les deux étant simple ça va mais bon...

[Florent Martin]

Sur la vidéo on voit les roues revenir en arrière. Ce bug  a été résolu simplement en ajoutant la temporisation

 

int dif = millis() - _lastClientCheck;
if (dif > _clientCheckFreq) {
_lastClientCheck = millis();

YunClient client = server.accept();

...

 

Donc en plus de ça je pense qu'il y a quelques bug dedans.

En quoi cette fonction server.accept peut elle envoyer des truc sur les pins 8,9,10,11??

[cocothebo]

Bonjour,

 

Je comprends pas exactement ton "architecture", pour résumer tu souhaites diriger ton robot à distance en utilisant un lien "internet", c'est bien ça?

 

Si ma compréhension est bonne, je suis etonné que tu fasses un server.accept() a chaque tour de boucle, si je comprends bien la doc succinct de cette fonction, ça ouvre une connexion depuis ton serveur.

Il suffit de l'ouvrir une fois et après d'attendfre des commandes (à voir si ya du time-out) et avoir une commande de déconnexion. Quand tu n'as pas de client tu attends alors une connexion mais dès que tu es connecté tu n'ouvre plus de nouvelle connexion, juste tu processes les commandes.

 

La ça me semble être une implémentation style "serveur web" qui balance la page qui va bien à un client, dans ton cas tu n'as pas besoin de gérer plusieurs clients en même temps, mais un client et des commandes pour ce même client (on peut donc garder la connexion ouverte).

 

Moi j'essayaierais de mettre en place un algo du style:

     1. tant que pas de connexion, j'attends une connexion

     2. tant que pas de commande j'attends une commande

     3. procésser la commande recu

     4. retour au 2 (ou 1 si commande de déconnexion)

 

C'est un algo vu de très haut et très simpliste, mais au moins ça te permet d'avoir des "sessions" qui évite de refaire des connexions en permanence, l'établissement d'une connexion reste couteux donc autant les éviter le plus possible.

 

Bien sur ce que je dis là s'applique si le server.accept() ouvre une nouvelle connexion à chaque passage, si en cas de connexion déjà ouverte ça ne réouvre pas c'est caduque.

 

 

Après pour continuer à optimiser un peu, il faudrait aussi travailler sur protocole en lui même, l'envoie de string de commande "human readable" est certes pratiques pour le debug ou autre mais vraiment pas optimal, tu as un set d'une dizaine de commande, autant envoyer juste un octet (par exemple 00h pour stop, 01h pour forward etc.) qui sera plus facile a "comprendre" pour ton pogramme. Il faudrait tester pour voir mais le readString est surement couteux, la comparaison sur les strings aussi.

 

Dans l'absolu pour gagner le plus en temps il faudrait fonctionner avec des pointeurs sur tes fonctions "stop", "forward", etc., ça permet d'éviter de tester les valeur, en gros tu stockes un pointeur de chaque fonction dans un tableau, et quand tu recois ton octet, tu vérifies qu'il est dans le bon range (pas négatif et pas plus grand que ton tableau) et tu execute directement la fonction à l'index de ton tableau.

A voir si c'est possible en arduino mais il me smble que oui.

par exemple: (ça doit fonctionner mais n'ayant pas d'arduino sous la main j'ai pas testé)

//tu créés un type "pointeur sur fonction"
typedef void (*FunctionPointer) ();

//tu créés ton tableau de pointeur de fonctions
FunctionPointer commandes[2] = {stop,avance, recule};


//les méthodes sur lequel on pointe
void avance() {
  myStepper1->setDirection(LOW);
  myStepper2->setDirection(LOW);
  myStepper1->start();
  myStepper2->start();
}
void recule() {
  myStepper1->setDirection(HIGH);
  myStepper2->setDirection(HIGH);
  myStepper1->start();
  myStepper2->start();
}
void stop() {
  myStepper1->stop();
  myStepper2->stop();
}


void loop() {
  //[...] metre en place ce que tu veux, la connexion etc.

  // On rçoit la commande
  icom = client.read();
  
  //on check le range, je considère que c'est signé, on doit pouvoir optimiser
  if (icom > 0 && icom < 2) {
     //on traite la commande
     commandes[icom]();
  }

  // [...] tu finis le traitement
}

Dans le cas d'un protocole du genre, ca te permet d'aller très vite sans faire de comparaison, ça amèliore donc forcément la latence, ca te gagne aussi un temps d'exécution a peu prêt constant que tu utilises la premier ou la derniere commande

Si on prend ton algorithme pour le moment tu as peu de fonctionnalités mais si tu arrives a mettons 100 fonctions différentes et que la comparaison prend ne serait ce que 10ms (j'espere que c'est moins sur l'arduino ), tu auras un décalage d'une seconde entre effectuer la 1ere ou la derniere commande.

 

 

En gros façon, si tu veux réduire la latence, il faut faire le strict minimum en utilisant le plus de fonctions très simples voir directement des décalages, pointeurs de fonctions etc pour gagner en temps de traitement.

 

 

Bon courage pour la suite

[Florent Martin]

Oui j'envoie des commandes via internet ( genre http://monrobot.local/arduino/avancede mémoire) et hop il avance. 

 

Je vais tester l'ouverture server.accept une seule fois.c'est vrai que c'est peut être la solution. J'ai juste récupéré l'exemple dans lequel il me semble que c'est ouvert à chaque fois. 

Pour le reste de l'optimisation c'est vrai mais là la latence est de deux sec donc je pense pas que le test et les commandes un peu plus grosses soient le problème... 

Je vais le réduire quand même car de toute façon avec 10 commande on serra toujours "debugable" facilement.

[Florent Martin]

Grâce à cette fonction   

client.setTimeout(5);

posé juste après la reception d'un "client" j'ai diminué la latence de 2 sec a environ 0,8 sec

 

J'ai essayé de n'ouvrir qu'une connection, celà n'a pas marché. 

L'autre option est de passer direct en ssh par console mais c'est BEAUCOUP moins pratique...