Alors après moult réflexion et un travail certainement pas optimisé, j'ai produit la partie électrique du robot dont voici le schéma

http://www.schematics.com/project/robot-main-22822/

Ce n'est pas un schéma parfait, il y a des choses en trop notamment des condensateurs inutiles ( j'ai fait au fur et a mesure en apprenant)

Il y a 8 relais ( lol ). Avant qu'on me demande,  concernant RY28

1) c'est un dpst car c'est ce que j'avais sous la main

2) Son rôle est d'éviter que des tensions <12v ne se promènent dans les bobines des autres relay. En effet si j'envoie 11 V dans les bobines des relais, certains s'activent, d'autre non. C'est très mauvais.

J'avais notamment le problème quand je branche l'alimentation et que j'éteins l'alimentation (au lieu de couper le courant brusquement), avant RY28 je pouvais entendre click click click ( les relais ) sur un intervalle de 1-2sec. Avec lui tout se fait en même temps.

Ceci dit je ne comprend pas pourquoi ça fonctionne car il devrait être court circuité a chaque fois qu'il s'active ...

Concernant les condensateurs, 

Il y en a beaucoup et c'est le point a tester car les relais mettent 1ns a s'enclencher. Temps pendant lequel le robot n'a plus de jus! le pire étant pour l'arduino ( les moteurs importent peu)

Concernant RY29

Malheureusement le circuit de rechargement a un + et un - ( et pas un + et un Gnd ) Donc je suis obligé de l'avoir....

Concernant RY17 

A priori il est inutile! mais c'est le premier que j'ai mis dans le circuit, je le laisse maintenant ...

Concernant les batteries

Sur le schéma ce n'est pas représenté mais chaqu'une possède un circuit de protection

http://www.ebay.fr/itm/PCB-Charger-3-7V-3A-Li-ion-Lithium-18650-Battery-Input-Ouput-Protection-Board-/252162638493?hash=item3ab610829d:g:ofkAAOSwF1dUR9LC

Pendant les test tout fonctionne bien sauf le circuit de rechargement que j'attends encore. Reste a tester en situation

J'ai aussi trouvé faire la connection avec la home, je posterai des photos d'ici peu!

Il me reste la home station a construire physiquement ( pour l'instant je n'ai que le système de connection)

Merci du conseil, 

je n'ai pas encore les diodes qui sont dans le bateau quelque part entre hongkong et paris. 

Mais en faisant le test dans ma tête je pense savoir ce qui va se passer

D'abord si le shield inverse le sens des moteurs, ils vont être court circuité par la diode donc drame potentiel

Ensuite en roue libre je ne suis pas certain de ce qui se passe, en tournant dans un sens la led va continuer a s'allumer, dans l'autre sens je pense que le problème serrait résolu...

Je vais les virer en attendant.

les moteurs consoment au max 0.13A Il faut ajouter l'arduino, le shield et les servos.

Les deux servo servent a orienter un ipod et consomment peu a priori mais c'est dificile de savoir al conso d'un servo on va dire 0,2A  au max

Il faut ensuite ajouter la conso de l'ipod dont je n'ai aucune idée mais probablement faible  également. Pour l'instant on est <1A a priori

Dans le futur je pense remplacer l'ipod par un écran & webcam séparé & pe un bras articulé donc la conso va augmenter.

Concernant les diodes, 

est-il normal que quand je tourne les roues alors que le shield & moteur est débranché, la diode du shield s'allume?

Ca me semble tres étrange et potentielement néfaste non?

Bien vu, en effet, les moteurs ne sont pas branché a la mass mais au shield je corrige le diagrame!

Aussi la lipo est en faite une Nimh 

Alors j'ai avancé sur le forum arduino et j'ai pondu deux shéma. (avec l'aide de https://forum.arduin...4186#msg2454186 )

Celui avec le transistor MOSFET P avait un court circuit donc je l'ai corrigé , il manque la resistance sur la porte a priori

Et la version avec le relai et le condensateur & des diodes pour les moteurs  ( il manque le gros condensateur sur ce shéma )

Je vais acheter de quoi faire avec le MOSFET & le relai (j'apprends!) comme ça je pourrai choisir

Question annexe, les diodes sur le moteur je les ai mise car j'ai remarqué que quand je faisais rouler le robot sans jus, la led du shield arduino s'allumait, ce qui ne présage rien de bon

Cette diode va-t-elle supprimer cet effet?

alors je débroussaille  mon chantier. 

Donc en fait le premier pas c'est que quand le robot est branché a la station home, la batterie est débranchée du circuit et l'arduino & les moteurs sont alimentés par le secteur. des qu'il se débranche de la station home, la batterie prend le relai. 

Je suis bof en elec donc j'ai besoin d'aide pour choisir le transistor qui va bien et valider le schéma. Aussi a mon avis il faut rajouter un condensateur quelquepart  ...

Voici ce vers quoi je m'oriente ( je n'ai pas dessiné les servo, ça n'a pas trop d'intérêt là )

Donc la question est que choisir pour le transistor Q1?

il faut que quand il a 12v sur la gate, il coupe le jus de la batterie (nimh pas lipo) et qd il a rien sur la gate il laisse passer les 12v de la batterie ...

Petite question subsidiaire : je pense qu'il faut un condensateur pour aplanir le changement de tension quand on passe de la batterie au +12v de la home et vice vers ça. mais où? Faut il juste décaler le 10uf après le transistor?

Qu'en pensent les experts ?

Une fois que j'aurai ça en place, je m'attaque au rechargement de la batterie

Concernant la batterie j'ai changé pour nimh pour plus de sécurité.

Il faut donc maintenant faire un circuit pour son rechargement automatique. quelqu'un a-t-il déjà fait ce genre de truc?

il y a des infos sur google mais un retour perso ici aiderai

sinn je vais explorer cette voie 

http://www.instructables.com/id/How-to-Make-a-NiMH-NiCd-Battery-Charger-Circuit/

Bonne idée les câbles tendu, je vais mettre ça en oeuvre, les mouvements sont perceptible au pilotage mais pas gênant.

Avec un bras en haut, le problème risque de s'empirer.

Pour le connecteur, la technique des languette, implique qu'on s'aligne presque parfaitement. peut être qu'un simple guide pour les roues serrait suffisant mais ça fait du travail de bricolage.

Quelqu'un a testé un connecteur avec des aimants et un câble court ( 1 cm? ) sur la base un peu comme le systeme des macs ?

un tel systeme serrait plus souple pour le branchement je pense mais il y a aussi du travail sur le connecteur ...

Alors des petites news du projet qui a reprit du poil d'engrenage:

https://youtu.be/6SLlnskDS_o

Le robot est controlé enjavascript via le clavier. on peut en parallèle lancer skype ou oovoo ... pour faire de la téléprésence ( c'est le but gérard!)

Je lui ai fixé une tête inclinable (via servo) qui tient pour l'instant un ipod3 ou4. 

La tête inclinable est importante car a 1m20 on ne voit rien des roues et obstacle au sol sinon....

Donc 

les motoreducteur semblent la solution car ils sont simple et consomment peu ( par rapport a la puissance fournie). La correction de trajectoire se faisant au pilotage de toute façon.

L'arduino yun lui par contre me pose des problèmes : le wifi est instable chez moi. ça se déco tout le temps. desfois ça marche bien comme sur la vidéo desfois ca bug. J'ai déjà repéré deux types de bugs ( peut être le même)

-1 l'arduino se déco tout simplement. Je n'arrive plus a rien avec lui, seul la led verte est allumé....

-2 Une sorte de méga latence/bouchon se cré. Au bout de 30 sec tout les ordres arrivent et sont traité ce qui donne n'importe quoi....

Je vais peut être m'orienter vers un eepc + arduino simple. 

L'avantage est que je pourrais avoir l'écran en haut fixe et juste la caméra mobile 

Me reste la question de la base rechargement. Je ne sais pas trop comment faire pour le connecteur robot/base. On doit pouvoir s'y garer facilement...

des idées?

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

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.

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??

/*
  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...

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 

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

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

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.

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

Alors les Nema 17, c'est ceux là 17HS19-1684S

J'ai branché une lippo (12v 2200mah) de mon drone sur mon shield et ça a fait cramer un contrôleur ( alors que mon alim d'ordi en 12v n'a rien fait cramer). Mes moteurs tirent trop pour ce shield ( je découvre) 

Sur ce topic j'ai pu découvrir que en plus du voltage et de l'amperage, il faut faire attention a la phase resistance ...

https://forums.adafr...=373988#p373988

Du coup j'ai utilisé les shield pololu qui venaient avec mon imprimante 3d et ça marche mieux, j'attends des piece pour les brancher proprement.

Sinon j'ai trouvé un super chassis en recyclant une caisse a vin. Je cherche la roue folle qui va bien

Bon après réflexion, je vais repasser sur le Arduino yun que j'avais. 

Ca m'évite de passer par la connexion serial-usb de la tablette qui serra limité de toute façon (comment envoyer des données dans l'autre sens si nécessaire?)

Le yun est un peu chère (mais je l'avais de toute façon) mais pour ce genre d'application c'est parfait car il héberge la page lui même.

deux bémol:

il n'a pas de régulateur de tension, ce qui aurait été pratique.

Il n'est pas compatible mécaniquement avec le shield donc j'ai du les relier avec pleins de câbles laids.

en 1 petite heure avec le yun j'ai réussit à refaire marcher les moteurs comme dans la vidéo.

Je vais récupérer les roues cet aprem pour avancer.

Sinon je pense que je vais tester le rechargement par induction. ça semble être la bonne solution aussi. 

Un petit capteur dans le yun vérifiera si on est sur batterie ou en induction et si on est en induction c'est que le pilote a bien rangé le yun a sa place.

pas de conducteurs exposés et pas de connecteurs compliqués. 

Bon en gros après moulte petits problème, j'ai 

Via un script php qui écrit sur le port serial , l'arduino Uno contrôle deux steppers ( en passant par le shield adafruit).

donc a terme

Mon ordi -> Internet -> serveur php sur la tablette -> Arduino -> shield adafruit -> steppers

Une vidéo vaut 1000 mots ( désolé pour la qualité,c'est vite fait)

Ecrire sur le serial en php c'est en fait très simple

$comPort = "/dev/cu.usbmodem1411"; /*change to correct com port */
$fp =fopen($comPort, "w");
fwrite($fp, 2);
fclose($fp);

echo "monmessage" > /dev/cu.usbmodem1411

Prochaine étape : 

Avoir la tablette qui contrôle tout ça et voir si j'utilise skype ou hangout

Ensuite, la construction du robot. 

Avec la tablette je vois un problème venir : Elle n'a qu'un port usb et s'alimente par celui ci. Si l'arduino est branché dessus, ça ne va pas marcher... Peut être faudra-t-il hacker le cable d'alimentation et sortir les câbles pour l'alimentation de la tablette pour els connecter à +5v...

Problèmes rencontrés 

Ecrire sur le port serial : dès qu'on écrit dessus, arduino reboot et j'ai donc placé un jumper entre reset et +3v. 

Quand je veux envoyer du code, je débranche le jumper et quand je veux utiliser le programme je le met.

Je ne peux pas utiliser l'arduino Yun qui m'aurait éviter ça car le shield adafruit ne va pas sur le Yun ... ( il faudrait retirer la prise ethernet... )

Normalement il faut une petite résistance entre 3v et reset mais bon sans ça marche, jusqu'à quand?

L'autre bonne nouvelle c'est que j'ai 4 nema17 en stock donc c'est partit ce week-end j'essaie de tester ca.

Une autre option serrait de mettre des Stepper motor? 

En même temps ton robot ailgorbot semble aller droit sur la video justement.

j'ai reçu le shield adafruit qui semble parfait pour ce projet puisque tres simplement je contrôle 2 DC moteur et il me reste de la place pour deux autres (future extension?).

J'ai un doute sur les moteurs DC à choisir et j'ai peur que lerobot n'avance pas droit même en prenant les même moteurs mais bon je vais voir plus tard

Merci pour ce retour,

Je n'ai pas vraiment pensé au chassis Une simple caisse plastique bien rigide ne peut elle pas faire l'affaire? 

Le plastique va-t-il de se tordre sous l'effort des moteurs?