Petite question , quelle librairie PID a tu utilisé , plusieurs sont présentes dans l'IDE Arduino ?

celle ci .....  https://playground.a...Code/PIDLibrary

Merci pour la réponse "pédagogique"

L'adaptation pour le driver moteur Arduino ( Moteur A = moteur Gauche et Moteur B = Moteur Droit )

Le shield driver deux moteurs Arduino n’a qu’une seule broche par moteur pour piloter la rotation du moteur , notées DIRA et DIRB. 

La vitesse est gérée par la broche PWM de chaque moteur soit PWMA et PWMB

Pour avancer , on met DIRA à HIGH et DIRB à LOW (du fait que le moteur droit a le sens de rotation inversé par au moteur gauche ).  
Pour reculer , on met DIRA à LOW et DIRB à HIGH

Pour s'arrêter , on met PWM à 0.

Pour aller à fond , on met PWM à 255

En "PWM" , pour le moteur A ,  on fait digitalWrite(DIRA, pwm);   avec pwm entre 0 et 255.
Pour aller à fond en avant il faut donc mettre  digitalWrite(PWMA, 255); avec DIRA à HIGH 
Pour aller à fond en arrière il faut donc mettre digitalWrite(PWMA, 255); avec DIRA à LOW 

pour le moteur B ,  on fait digitalWrite(DIRB , pwm);   avec pwm entre 0 et 255.
Pour aller à fond en avant il faut donc mettre  digitalWrite(PWMA, 255); avec DIRA à LOW
Pour aller à fond en arrière il faut donc mettre digitalWrite(PWMA, 255); avec DIRA à HIGH


Hors /
Pour aller à fond dans le sens avant le PID va retourner 255,
Pour aller à une vitesse nulle le PID va retourner 0
Pour aller à fond en sens arrière le PID va retourner -255 ... 

 Donc

on va utiliser la valeur absolue de la vitesse retourner par le PID pour savoir à quelle vitesse on règle le système et le signe pour savoir dans quel sens on tourne. 

Dans les 2 sens avant et arrière ,  on est à l'arrêt avec pwm=0 ,  à fond à 255 .  

L’adaptation de ton code au driver moteur Arduino donne ceci :

/////////////////////////////////////////////////////////
void runMotorSpeed( int commandeMoteurDroit, int commandeMoteurGauche) {

……..

//utilisation de la sortie du PID pour asservir les moteurs
  if (outputDroit >= 0) {
    avancerMoteurDroit(outputDroit);
  }
  if (outputDroit < 0) {
    reculerMoteurDroit(outputDroit);
  }
  if (outputGauche >= 0) {
    avancerMoteurGauche(outputGauche);
  }
  if (outputGauche < 0) {
    reculerMoteurGauche(outputGauche);
  }

………

void avancerMoteurDroit(int a) // En avant
{
  analogWrite (PINMOTEURDROITPWMB, a); // Contrôle de vitesse en PWM, moteur 1
  digitalWrite(PINMOTEURDROITDIRB, HIGH); // sens de marche avant avec HIGH
}
void avancerMoteurGauche(int a) // En avant
{
  analogWrite (PINMOTEURGAUCHEPWMA, a); // Contrôle de vitesse en PWM, moteur 2
  digitalWrite(PINMOTEURGAUCHEDIRA, HIGH);
}

void reculerMoteurDroit (int a) // En arrière
{
  analogWrite (PINMOTEURDROITPWMB, a);
  digitalWrite(PINMOTEURDROITDIRB, LOW);  // sens de marche arrière avec LOW

}
void reculerMoteurGauche (int a) // En arrière
{
  analogWrite (PINMOTEURGAUCHEPWMA, a);
  digitalWrite(PINMOTEURGAUCHEDIRA, LOW);
}

Super comme initiative !

Quelques questions :

- Le cable à plat de raccordement de la PI Cam au RPI est'il une gène pour les mouvements de la caméra ?

- La vision de nuit de ce type de caméra PI avec 2 éclairages à LED est t'elle bonne ?

A part ca , j'aime bien l'idée du PCB pour centraliser les connexions

Finalement j'ai changé la carte SD et la carte RPI3B par une RPI3B+ que j'avais en stock.

Pour ma mémoire si il y a une prochaine fois :  Ré-Installation Raspbian Strech + configuration Rover1sur RPi 3

- Télécharger Raspbian Stretch et copier sur une carte SD 8GO avec Win32DiskImager (+ fichier ssh file pour activation SSH et fichier wpa_supplicant.conf pour configuration Wifi)
- Booter le Rpi3 and login via Putty + sudo raspi-config ( add Camera +VNC server, expand root file system,  timezone GMT-6) + IP  fixe dans /etc/dhcpcd.conf .
- Mettre à jour Stretch : sudo apt-get update , sudo apt-get upgrade

- Restaurer les fichiers Rpi python et sketches arduino du robot

- Connexion au RPI par le client VNC viewer

- Installer l' IDE Arduino 1.8.7 (Zip)

- Installer les bibilothèques NewPing , TimerOne and Pid

- Configurer la caméra PI V2

- Installer et configurer "motion" sur le RPI3

+ up  sur post #86

A coté de la liste des membres par ex

Grrr  .. La micro carte SD du RPI3 vient de lacher et impossible de savoir ce qu'elle a car elle n'est pas détectée sur mon PC Win10  .

Y a plus qu'à en acheter une autre , ré-installer Rasbian+ Wifi  et la conf du robot

Cette fois ci je mettrai le répertoire "var/log" en RAM du RPI3 comme sur mes RPI domotiques , pour limiter le nombre d'écritures sur la carte SD

Salut @Mike118 ,

Je suis en train de tester l'asservissement PID sur mon robot et ca a l'air de fonctionner  au premier abord .. le robot avance droit

Dans le code d'asservissement ci-dessous , je ne comprends pas bien le fonctionnement en cas de "output >0" en sortie de PID avec le passage de variable négative " -a" interprétée ensuite en "255-a " comme nouvelle valeur de PWM ?

void runMotorSpeed( int8_t commandeMoteurDroit, int8_t commandeMoteurGauche) {

................

//utilisation de la sortie du PID pour asservir les moteurs
  if (outputDroit >= 0) {
    avancerMoteurDroit(outputDroit);
  }
  if (outputDroit < 0) {
    reculerMoteurDroit(-outputDroit);
  }
  if (outputGauche >= 0) {
    avancerMoteurGauche(outputGauche);
  }
  if (outputGauche < 0) {
    reculerMoteurGauche(-outputGauche);
  }

}
void avancerMoteurDroit(uint8_t a) // En avant
{
  analogWrite (MOTEURDROITA, a); // Contrôle de vitesse en PWM, moteur 1
  digitalWrite(MOTEURDROITB, LOW); // sens de marche avec HIGH
}
void avancerMoteurGauche(uint8_t a) // En avant
{
  analogWrite (MOTEURGAUCHEA, 255 - a); // Contrôle de vitesse en PWM, moteur 2
  digitalWrite(MOTEURGAUCHEB, HIGH);
}

void reculerMoteurDroit (uint8_t a) // En arrière
{
  analogWrite (MOTEURDROITA, 255 - a);
  digitalWrite(MOTEURDROITB, HIGH);
}
void reculerMoteurGauche (uint8_t a) // En arrière
{
  analogWrite (MOTEURGAUCHEA, a);
  digitalWrite(MOTEURGAUCHEB, LOW);
}

L'implémentation de la fonction PID  a été introduite dans le sketch Arduino du robot ( en m'aidant fortement de l'exemple donné par Mike118 ) et le test commence avec la partie "void setup" pour  vérifier le bon fonctionnement des encodeurs , l'acquisition de la vitesse par les encodeurs  et que la partie asservissement tourne sans vérifier son bon fonctionnement.

Ensuite la partie asservissement vitesse des moteurs sera testée dans la boucle "void loop" pour les commandes robot "Avance" et "Recule"

Pour la Veroboard , j'aime bien que les pastilles ne soit que d'un coté de la carte et le problème potentiel est quand on chauffe trop la soudure  ..... ca fait le taff comme tu dis

Je n'ai pas d'expérience avec la solution de Melmet ( carte en Epoxy )

En qui concerne l'odométrie pour le robot , les encodeurs sont cablés et alimentés  en 3.3v .

Je n'aime pas alimenter du 5V ou 3.3V à partir du RPI ou de lArduino , aussi j'utilise des cartes convertisseur externes , sauf pour des essais ponctuels

Les liaisons encodeurs <-> carte Mega se font sans adaptateurs de niveau 3.3v <-> 5V car les entrées Arduino 5V de la carte MEGA sont tolérantes 3.3v .

L'IMU sera introduit dans un deuxième temps pour ne pas compliquer .

Y a plus qu'à  modifier le sketch Arduino ...

La photo du robot avec la veroboard comprenant l'alim 3.3V pour les 2 encodeurs et l'IMU (en attente de prise en compte) , qui est installée dans le 2ème étage du robot .

Merci @Mike118 pour le lien , ca va bien me servir de base  .

Sur l'Arduino MEGA , l'entrée 3 est utilisée par le shield moteur Arduino mais il reste effectivement  encore 5 entrées avec interruption ( 2,18,19,20,21)

Pour ajouter cette fonction Odométrie  , il me faut ajouter une alimentation 3.3V pour les encodeurs moteurs , en alimentant une carte alim 2 sorties 5V et 2 sorties 3.3V à partir de la dernière sortie 5V de la carte convertisseur 5V .

Une des sorties 5V disponibles de la carte alim 5V/3.3V servira à alimenter la carte IMU que je possède aussi .

Le tout mis sur une véroboard .

Point de situation de ce qui est fait de la version 2 du robot  :

- Un nouveau chassis Makeblock à 2 roues motrices + 1 roue folle arrière , toujours piloté par la meme app Android MIT Inventor2 avec retour video pour piloter le robot par Wifi

- Une batterie Lipo 3S 11.7V et 2200 mAh

- Un raspberry PI3 + Arduino Mega + shield moteur Arduino

- Un convertisseur 5A 12V-5V équipé  d'1 sortie 12V pour le driver moteurs et de 4 sorties 5V pour RPI3 et autres capteurs

- Deux motoréducteurs GM25-370CA avec encodeur en 3.3V + roues

- Une Caméra Pi V2 NoIR pour vision nuit montée sur un servo pour balayage horitontal pour retour vidéo et détection de mouvement avec "motion"

- Un capteur ultrason SRF05 pour détection obstacles à l'avant du robot

- Un 2ème capteur ultrason HC-SR04 pour détection obstacles à l'arrière du robot

- Pilotage du robot en mode distant , en complément du mode local

Reste à faire par ordre de priorité :

- Odométrie et correction de trajectoire par odométrie

- IMU Centrale inertielle MPU-650 (disponible)

- L'estimation de position du robot par odométrie + IMU

- Télémètrie ( distance capteur ultrasons  , tension batterie , Intensité consommé .....) vers l'app smartphone Android et vers la domotique

- Poste recharge autonome batterie

- L'intégration du robot en wifi avec le logiciel domotique Domoticz pour navigation autonome en cas d'intrusion détectée par un capteur de détection de mouvement

- Une page dashboard sur l'application domotique pour affichage de données dans un dashboard (caméra,tension et courant batterie , courant moteurs , log , ...)

=> Je vais m'attaquer à l'odométrie ... pour que le robot avance droit !

=> les motoréducteurs GM25-370CA du robot sont équipés d' encodeur en 3.3V

La prise en compte du controle à distance du robot consiste à :

- Mémoriser  l'état Local / Distant des boutons correspondants dans l'écran d'accueil

- ¨Partager cet état avec l'écran de controle du robot par smartphone  ( startvalue )

- Affecter au robot et à la caméra PI une IP de type locale ou externe (hostname) en fonction du mode Local ou Distant

Ecran accueil

Ecran controle du robot par smartphone

Le test de pilotage du robot a été fait avec le smartphone en Wifi pour le mode local et mode 4G pour le mode distant  ( retour vidéo et commande du robot).

Un indication du mode gestion local ou distant a été ajouté sur l'écran.

Screenshot en mode distant et commande robot "Avancer"

Retour sur l'application Android de controle du robot  pour y introduire la possibilité de  gestion à distance sur l'écran d'accueil  :

- Ajout de 2 boutons Accès Local et Accès Distant

- Visualisation du mode choisi local ou distant sur l'écran d'accueil et sur l'écran  "Controle du robot par smartphone"

- Prise  en compte de ce mode dans l'écran "Controle du robot par Smartphone"

=> Reste à ajouter les blocs de code dans l'application MIT Inventor2 et à tester

Suite ...
 
Le capteur ultrason HC-SR04 ,( situé à l'arrière du robot) est  intégré dans le sketch Arduino avec la bibliothèque "Newping"  et fonctionne.
J'en ai profité pour  modifier le code relatif au capteur US SRF05 situé à l'avant du robot  afin de généraliser la bibilothèque "Newping".
 
La lecture des 2 capteurs US se fait dans la boucle "loop" chaque 100 ms  ( méthode millis() )
 
Pour l'instant je n'ai pas cherché à optimiser le code , en gardant un traitement différent en fonction du capteur sollicité ( lire le capteur concerné si on avance ou si on recule mais pas les deux sytématiquement )

// Interrogation périodique (100 ms) Distance obstacle capteur ultrason
if ((millis() - previousmillisUS) >= DISTANCEUSINTERVAL) {  
 if (CurrentRobotStatus != STOP)  {    
  int DistanceObstacle=0;    
  DistanceObstacle = sonar[0].ping_cm();  // 0 = SRF05    
  previousmillisUS = millis();    
  if ((DistanceObstacle < DISTANCEUSMIN) and (CurrentRobotStatus == AV))    {      
   CurrentRobotStatus= STOP; // Etat Stop      ArreterRobot(); // l'obstacle est dans la zone proche du robot      
   Serial.print("<Distance SRF05 trop proche obstacle = ");      
   Serial.print(DistanceObstacle);     
  }     
  DistanceObstacle=0;    
  DistanceObstacle = sonar[1].ping_cm();  // 1 = HC-SR04    
  previousmillisUS = millis();    
  if ((DistanceObstacle < DISTANCEUSMIN) and (CurrentRobotStatus == AR) and (DistanceObstacle != 0))   {   
   CurrentRobotStatus= STOP; // Etat Stop      ArreterRobot(); // l'obstacle est dans la zone proche du robot     
   Serial.print("<Distance SR04 trop proche obstacle = ");      
   Serial.print(DistanceObstacle);     
  }      
 }
}    

Merci @Oracid & @Mike118 pour vos retours d'expérience .

Avec la bibliothèque "newping" ca va beaucoup mieux .

Néanmoins il y a des cas ou la détection d'obstacle est perturbée si le support de réflexion  est un angle ou si il est fait de "fibres tréssé" ( salon extérieur)  ou non plein comme une balustrade.

Le phénomène semble plus accentué si la distance augmente.

Je ne sais pas si le bruit des vagues qui sont à 50m peut également perturber la transmission de l'ultrason.

La photo ci-dessous est un cas de problème d'angle de réflexion du signal , avec moins d'angle ca marche.

EDIT : Oubli d'indiquer qu'une mesure erronée "8 cm" vient après le "0 cm" en cas de de distance > seuil de détection

Le capteur HC-SR04 a été installé à l'arrière du robot et son comportement s'est révélé parfois assez erratique ( détection obstacle à tort lié à des mesures érronées et donc arret du robot par design ) , aussi j'ai refais les tests unitaires avec le code proposés dans la boutique pour ce capteur .

#define TRIGG 9 // Broche TRIGGER
#define ECHO 10 // Broche ECHO
// definition du Timeout
const long TIMEOUT = 25000UL; // 25ms = ~8m à 340m/s

float son= 340.0 / 1000; //vitesse du son dans l'air (mm/µs)

void setup() {

pinMode(TRIGG, OUTPUT); //Configuration des broches
digitalWrite(TRIGG, LOW); // La broche TRIGGER doit être à LOW au repos
pinMode(ECHO, INPUT);

Serial.begin(9600); //Démarrage de la liaison série
}

void loop() {

digitalWrite(TRIGG, HIGH); // Lance une mesure de distance en envoyant
delayMicroseconds(10); //une impulsion HIGH de 10µs sur la broche TRIGGER
digitalWrite(TRIGG, LOW);

int mesure = pulseIn(ECHO, HIGH, TIMEOUT); // Mesure le temps entre
// l'envoi de l'ultrason et sa réception

float distance_mm = mesure / 2.0 * son; //calcul de la distance grâce au temps
//on divise par 2 car le son fait un aller-retour

Serial.print("Distance: "); //Affichage des résultats
Serial.print(distance_mm);
Serial.println("mm");

delay(500); //temps entre chaque mesure (ms)
}

Problème confirmé par les résultats des tests avec ce code , de nombreuses valeurs sont très faibles voires nulle en fonction de l'orientation du robot

=> Normalement une valeur "0" correspondant à une mesure sans obstacle mais ce n'est pas le cas ici ?

=> La valeur "0" sera de toute facon à ignorer dans la vraie vie

=> Ce capteur semble très sensible à l'environnement ( lumière ... )  , ce n'est pas le cas avec le capteur SRF05 à l'avant du robot ?

=> Capteur à conserver dans ces conditions  , je me pose la question ?

Point de situation de "rover1" :

La version 2 du robot mobile est opérationnelle et comprend  :

- Un nouveau chassis Makeblock à 2 roues motrices + 1 roue folle arrière , toujours piloté par la meme app Android MIT Inventor2 avec retour video pour piloter le robot par Wifi

- Une batterie Lipo 3S 11.7V et 2200 mAh

- Un convertisseur 5A 12V-5V équipé  d'1 sortie 12V pour le driver moteurs et de 4 sorties 5V pour RPI3 et capteurs

- Un raspberry PI3 + Arduino Mega + shield moteur Arduino

- Deux motoréducteurs GM25-370CA avec encodeur en 3.3V + roues

- Une Caméra Pi V2 pour retour vidéo et détection de mouvement avec "motion"

- Un capteur ultrason SRF05 pour détection distance & obstacles à l'avant du robot

La prochaine évolution en cours  :

- Un 2ème capteur ultrason HC-SR04 pour détection obstacles à l'arrière du robot

La partie cours est très pédagogique ( déplacement , asservissement et localisation ) pour ceux qui s'intéressent à la robotique mobile

Voici la vidéo de pilotage du robot mobile Rover1 V2 ( changement plateforme matérielle )  ... perturbé par un chien en garde pour le week end ( il n'avait jamais vu de robot de sa vie )

La course du robot est aussi perturbée par le plancher de la terrasse en bois qui n'est pas bien plat et qui bloque la roue folle par moment ....  ah oui l'odométrie monsieur !

Pour le bruit de fond , c'est le bruit des vagues du pacifique

Après test avec une Lipo 2S  , l'alimention de ces moteurs par une Lipos 2S fonctionne , mais la tension délivrée aux moteurs ne sera jamais la tension nominale de 12V et donc les moteurs ne pourront pas tourner à leur vitesse max.

 @cocothebo ,

Effectivement "good catch"  , le paramétrage PWM du driver moteur était valorisé pour les anciens moteurs 6V .

Après avoir augmenté la valeur PWM , les  2 moteurs ont démarrés .

La tension délivrée aux moteurs est proche de 100 % de la tension batterie si PWM = 255 ( le max)

Le pilotage du robot fonctionne bien , reste à faire une petite vidéo d'avancement

Pour l'achat de batterie , quand je disais "ici" , c'est au Costa Rica . Pour l'instant je vais me contenter de cette Lipo 2S meme si les moteurs ne pourront pas tourner à leur vitesse max comme avec une Lipo 3S.

Effectivement les 3 types de recherche sont utiles  afin de cibler un domaine de recherche  ( général , boutique et forum)

Pour ce dernier outil "Chercher" , il pourrait avoir sa place dans le menu déroulant "Forum des makers"

Remise en route et test du robot à partir de l'app Android :

- Retour video OK

- Commande moteur NOK ( le robot ne bouge pas ) sur commande AV ....

Le driver moteur (shield Arduino) est alimenté actuellement par une batterie Lipo 2S soit 7V environ et la tension délivrée aux moteurs par ce driver n'est que de 4v alors que les moteurs sont prévus pour 12V .

C'est la raison pour laquelle le robot était équipée de Lipos 3S initialement.

=>  Après nouvelle recherche ici , une autre boutique en ligne de modélisme vends des Lipo 3S 4000 mA 

=> A suivre

Merci p@Ulysse pour l'info et le lien mais préciser que c'est pour l'OS Windows 10 IoT entreprise

Comme Oracid , je n'ai jamais utilisé la recherche avancée