83 réponses à ce sujet

[inovasong]

Merci Black, encore toi et toujours toi, grand merci,

Bon comme je n’ai pas d’oscillo sous la main je vais jouer la carte de la sécurité et passer sagement a 20Hz, pour le site merci c'est déjà là que j'ai pris une grande partie des infos (en plus de ton site web).

Les plus gros doutes que j'ai sont les suivants. D’abords je ne suis pas sur de l'interprétation du PID en largeur d'impulsion je m'explique quand je fait mon calcul simple sans intégrale et dérivé et que je règle le proportionnel a 1 je me retrouve donc avec la différence entre la commande d'angle et l'angle réel, si j'envoi cette valeur sur le moteur il se met a osciller autour de la valeur de cmd ( cmd = 90 / angle mesuré = 0 donc la différence est de 90° donc la valeur de commande moteur est de 90 ) pourtant ca doit diminue en fonction de la différence, alors pourquoi mon moteur continu de tourner une foi que la cmd est atteinte ? En écrivant c'est lignes je me rends compte que c'est certainement du a la fréquence et au temps de calcul de ma fonction, donc je vais encore faire des modifications et essais. De plus j'ais asservi la rotation du robot en accélérant une roue et ralentissant l'autre mais est ce que la fonction d'asservissement en distance ne rentre pas en conflit avec la dernières ?

Je continu et persévère et mm si tu dis que l'Arduino a ses limites je me sens beaucoup plus a l'aise sur ce système qu'avec les lego NXT .
Ce que je veux faire ne me parait pourtant pas compliqué je veux faire avancer ce robot droit et tourner suivant l’angle demandé , mais peut être que je fait fausse route.

Il reste que je compte quand même investir dans un système de propulsion et codage plus préformant que celui qui équipe mon robot

Merci

[Black Templar]

Salut !

Je viens de comprendre ce que tu voulais dire par "2 asservissements en même temps" !
En fait, tu veux asservir les roues à la fois en angle et en vitesse !

D'abords je ne suis pas sur de l'interprétation du PID en largeur d'impulsion je m'explique quand je fait mon calcul simple sans intégrale et dérivé et que je règle le proportionnel a 1 je me retrouve donc avec la différence entre la commande d'angle et l'angle réel, si j'envoi cette valeur sur le moteur il se met a osciller autour de la valeur de cmd ( cmd = 90 / angle mesuré = 0 donc la différence est de 90° donc la valeur de commande moteur est de 90 ) pourtant ca doit diminue en fonction de la différence, alors pourquoi mon moteur continu de tourner une foi que la cmd est atteinte ?

Quand tu fais juste une régulation proportionnelle, ça oscille indéfiniment ?
ça veut dire que le coefficient est trop important ! (ou que ta fréquence d'échantillonnage est trop élevé vis à vis de la résolution de la codeuse)

De plus j'ais asservi la rotation du robot en accélérant une roue et ralentissant l'autre mais est ce que la fonction d'asservissement en distance ne rentre pas en conflit avec la dernières ?

Pour pouvoir asservir le robot à la fois en vitesses et en angle, il faut deux choses.
Premièrement il faut calculer la vitesse globale du robot (et non des chacune des roues). Tu obtiens donc une erreur en vitesse.
Deuxièmement, il faut calculer l'angle du robot à l'aide des infos de la codeuse. Là, tu obtiens une erreur en angle.

Tu calculs les 2 asservissements séparément.
La première de donne donc une commande à envoyer aux 2 roues ! Cette commande est la même pour les 2 roues !
La seconde te donne un différentiel. Sur la commande globale, tu viens ajouter ce différentiel à une roue et tu viens la retrancher à l'autre !


Pour régler les coefficients (tu as 2 jeux de coefficients, un pour chaque asservissement), il faut que tu choisisses un asservissement uniquement en angle ou uniquement en vitesse. Une fois les 2 jeux de coefs réglés séparément, tu peux sommer les commandes de chacune des roues.

En écrivant c'est lignes je me rends compte que c'est certainement du a la fréquence et au temps de calcul de ma fonction, donc je vais encore faire des modifications et essais.

Oui, comme on l'a vu précédemment, tes codeuses n'ont pas une grande résolution. Il faut donc que ta fréquence d'échantillonnage soit faible pour arriver à une bonne stabilité.


En tout cas, c'est passionnant ce que tu fais ! Dès que ma base robotisé sera prête, je sens que je vais bien m'amuser au niveau régulation et asservissement
++
Black Templar

[inovasong]

Non c'est la position, soit le nombre de centimètres parcourus, mais je pense que ca change pas grand chose non ? Je calcule la position globale et après PID j'ai la commande pour les deux moteurs.

En tout cas, c'est passionnant ce que tu fais ! Dès que ma base robotisée sera prête, je sens que je vais bien m'amuser au niveau régulation et asservissement
++

Merci ca m'encourage grandement.

[Black Templar]

Non c'est la position, soit le nombre de centimètres parcourus, mais je pense que ca change pas grand chose non ?

Hum... je ne sais pas trop. Le mieux serait de tester.
Néanmoins, intuitivement, je vois un problème : si tu essayes d'aller à un point précis avec l'asservissement en position et qu'en même temps du veux aller tout droit avec l'asservissement en angle, il y a risque de conflit... (les deux asservissements étant en position...)

Pourrais-tu me rappeler ce que tu cherche à faire exactement avec ce double asservissement ?

Si c'est pour pouvoir faire passer ton robot par des points de passages, je te conseille de lire cet article que je viens de trouver : http://www.rcva.fr/index.php?option=com_content&view=article&id=18&Itemid=34
Le but ici, c'est de planifier une trajectoire à l'aide de points de passages, comme on fait classiquement et ensuite, de calculer l'orientation et la distance du robot au point afin d'asservir le robot pour qu'il passe par le point de passage.

[inovasong]

Bonsoir,

Victoire j'ais enfin réussi à asservir en position et rotation mon robot (grand merci Black), grâce a ce dernier document que j'ai bêtement implémenté sur l'arduino j'ai un système avec pour le moment uniquement du proportionnel.

Je partage donc avec vous le code utilisé
J'ai supprimé dans la fonction des moteurs la commande qui passe le moteur à 0 si jamais la commande dépasse 255, déjà beaucoup mieux pour la stabilité. J'ai aussi simplifié et arrangé au maximum mon code (au passage si vous voyez des petits trucs pour améliorer n'hésitez pas) et le calcul de la rotation du robot ne se fait plus en degré, je pense qu'il est mieux de faire appel a une fonction uniquement au moment de faire un changement de commande plutôt qu'a la fréquence d'appel de l'asservissement.
J’ai couplé les commandes de distance et de différentiel (comme indiqué par Black) et la victoire le robot reste en position et quand j'appuis sur le bump il tourne en position 20.

Il me reste à implémenter la fonction pour le calcul de commande de rotation et plein de tests et réglages.
Je vous tiens au courant de l'avancement.

#include <SimpleTimer.h>

//____________________ Definition Broches ________________________________________// 

#define IRl_R A0
#define IRl_C A1
#define IRl_L A2
#define IR_R A1
#define IR_L A1
#define US 7
#define BUMP_R 18
#define BUMP_L 19
#define CODER_L 2
#define CODER_R 3
#define V_MOT_R 4
#define V_MOT_L 5
#define SENS_AR_R 30
#define SENS_AV_R 31
#define SENS_AV_L 32
#define SENS_AR_L 33

//____________________ Odometrie __________________________________________________//
SimpleTimer timer_asservissement;
#define RIGHT 0
#define LEFT 1
boolean sens_moteur[] = {true , true};
int tick[] = { 0 , 0 };
float V_moteur[] = { 0 , 0 };
/* Variable de consigne et réel */
float consigne_distance=0;
float consigne_orientation=0;
float distance=0;
float orientation=0;
float cmd_distance;
float cmd_orientation;

/* PID distance */
float erreur_precedente_distance = consigne_distance;
float somme_erreur_distance = 0;
float kp_distance = 300;           // Coefficient proportionnel
float ki_distance = 0;           // Coefficient intégrateur
float kd_distance = 0;           // Coefficient dérivateur

/* PID orientation */
float erreur_precedente_orientation = consigne_orientation;
float somme_erreur_orientation = 0;
float kp_orientation = 30;           // Coefficient proportionnel
float ki_orientation = 0;           // Coefficient intégrateur
float kd_orientation = 0;           // Coefficient dérivateur


//////////////////////////////////////////////////////////////// Setup //////////////////////////////////////////////////////////////////////////////////////////////////////////

void setup(){
  Serial.begin(115200);
  attachInterrupt(LEFT , coder_L, CHANGE); // interuption broche 2
  attachInterrupt(RIGHT , coder_R , CHANGE); // interuption broche 3
  timer_asservissement.setInterval(1000/20, asservissement);
  pinMode(BUMP_R, INPUT);
  pinMode(BUMP_L, INPUT);
}

//////////////////////////////////////////////////////////////// Loop //////////////////////////////////////////////////////////////////////////////////////////////////////////

void loop(){
  if (!digitalRead(BUMP_R)) {
    consigne_orientation = 20;
  }
    if (!digitalRead(BUMP_L)) {
    consigne_orientation = 0;
  }
  timer_asservissement.run();
}

//////////////////////////////////////////////////////////////// Fonctions //////////////////////////////////////////////////////////////////////////////////////////////////////////

void asservissement(){
  
  // calcul Distance et orientation
  distance = (tick[RIGHT] + tick[LEFT])/2;
  orientation = tick[RIGHT] - tick[LEFT];
 
  // Calcul des erreurs de distance
  float erreur_distance = consigne_distance - distance;
  somme_erreur_distance += erreur_distance;
  float delta_erreur_distance = erreur_distance - erreur_precedente_distance;
  erreur_precedente_distance = erreur_distance;
  
    // Calcul des erreurs de d'orientation
  float erreur_orientation = consigne_orientation - orientation;
  somme_erreur_orientation += erreur_orientation;
  float delta_erreur_orientation = erreur_orientation - erreur_precedente_orientation;
  erreur_precedente_orientation = erreur_orientation;
 
  // PID : calcul de la commande de distance
  cmd_distance = kp_distance * erreur_distance + ki_distance * somme_erreur_distance + kd_distance * delta_erreur_distance;
  // PID : calcul de la commande de d'orientation
  cmd_orientation = kp_orientation * erreur_orientation + ki_orientation * somme_erreur_orientation + kd_orientation * delta_erreur_orientation;
 
  V_moteur[LEFT] = cmd_distance - cmd_orientation;
  V_moteur[RIGHT] = cmd_distance + cmd_orientation;
  moteur_L(V_moteur[LEFT]);
  moteur_R(V_moteur[RIGHT]);
}

// Commande moteur Gauche ________________________________________
void moteur_L(int V){
  if (V>0){
    sens_moteur[LEFT] = true;
    digitalWrite(SENS_AR_L, LOW);
    digitalWrite(SENS_AV_L, HIGH);
  }
  else if (V<0){
    sens_moteur[LEFT] = false;
    digitalWrite(SENS_AR_L, HIGH);
    digitalWrite(SENS_AV_L, LOW);
    V = V * -1;
  }
  else {
    digitalWrite(SENS_AR_L, LOW);
    digitalWrite(SENS_AV_L, LOW);
  }
  if (V > 255) V=255;
  analogWrite(V_MOT_L, V);
}

// Commande moteur Droite ________________________________________
void moteur_R(int V){
  if (V>0){
    sens_moteur[RIGHT] = true;
    digitalWrite(SENS_AR_R, LOW);
    digitalWrite(SENS_AV_R, HIGH);
  }
  else if (V<0){
    sens_moteur[RIGHT] = false;
    digitalWrite(SENS_AR_R, HIGH);
    digitalWrite(SENS_AV_R, LOW);
    V = V * -1;
  }
  else {
    digitalWrite(SENS_AR_R, LOW);
    digitalWrite(SENS_AV_R, LOW);
  }
  if (V > 255) V=255;
  analogWrite(V_MOT_R, V);
}


// Fonction Codeur __________________________________________________
void coder_L(){
  if (sens_moteur[LEFT]) tick[LEFT]++;
  else if (!sens_moteur[LEFT]) tick[LEFT]--;
}
void coder_R(){
  if (sens_moteur[RIGHT]) tick[RIGHT]++;
  else if (!sens_moteur[RIGHT]) tick[RIGHT]--;
}

[Black Templar]

Bravo

Le code est nickel et bien commenté en plus.
Pour gagner en temps d'exécution, tu pourrais supprimer les variables "inutiles" comme par exemple le tableau V_moteur qui n'est utilisé qu'a la fin de la fonction d'asservissement. On peut donc s'en passer.
Mais je comprend que tu l'ai mis, par soucis de compréhension du code. De plus, il est fort probable que de toute façon, le compilateur optimise tout seul ces lignes de code en ne créant pas d'espace mémoire spécifique à ce tableau, de toute manière (c'était juste histoire de chipoter un peu ^^)

Il me reste à implémenter la fonction pour le calcul de commande de rotation et plein de tests et réglages.
Je vous tiens au courant de l'avancement.

J'attends donc avec impatience les résultats

[inovasong]

Hello world!

Bon les PID c'est cool j'ai bien expérimenté et le résultat c'est ca marche mais mon kit moteur + encodeur + largeur de roue rend la précision du bot très approximative mais suffisant pour mes débuts.

Pour le moment je vais donc laisser de coté mes fonctions d'asservissement pour me lancer dans la logique flou et la je tombe sur un magnifique article écrit par, surprise, Black templar tadadadada.

Bon la je crack désoler

trêve de plaisanterie, j'ai énormément de mal a interpréter en code les explication de ces articles, j'arrive sans gros problèmes a transformer les valeurs de distances en pourcentage de mes trois capteur et j'obtient donc 6 variables distances mais la ou j'ais du mal c'est a comprendre comment on passe de cette étape a la suivante c'est à dire transformer ces 6 valeurs en vitesses pour mes deux roues.

Quelqu’un aurais un petit coup de pouce pour moi.
En attendant de vous lire je continu a faire mes recherches
Cordialement

[Black Templar]

Pour le moment je vais donc laisser de coté mes fonctions d'asservissement pour me lancer dans la logique flou et la je tombe sur un magnifique article écrit par, surprise, Black templar tadadadada.

héhé à croire que tu es abonné XD
Tu as aussi la théorie sur les systèmes flous ici : http://www.ferdinandpiette.com/blog/2011/08/exemple-de-systeme-flou-un-planificateur-de-trajectoire/

trêve de plaisanterie, j'ai énormément de mal a interpréter en code les explication de ces articles, j'arrive sans gros problèmes a transformer les valeurs de distances en pourcentage de mes trois capteur et j'obtient donc 6 variables distances mais la ou j'ais du mal c'est a comprendre comment on passe de cette étape a la suivante c'est à dire transformer ces 6 valeurs en vitesses pour mes deux roues.

Bon, pour avoir un système flou, on doit avoir 3 étapes.

La première transforme une donnée numérique en donnée "linguistique".

C'est ce que tu as réussi à faire en transformant tes valeurs de distances. Normalement, tu devrais avoir en résultat, par exemple distance = 1,2 mètre => distance = 75% proche et 25% loin


La seconde étape va te permettre d'établir des relations "logique" entre tes variables linguistiques obtenue à la première étape et les variables linguistiques de sortie.Ici, les relations sont appelés "règles d'inférences". Elles sont déterminé uniquement grâce au savoir humain.

Par exemple, on pourrait avoir une règle qui dit : "si la distance est loin, alors accélère fortement" ou alors une autre qui dit "si la distance gauche est proche et la distance avant est proche, alors tourne à droite fortement"

Une fois que tu as ces règles, il va falloir que tu choisisses les opérateurs mathématiques qui vont remplacer les conjonction ET, OU, etc. Dans l'exemple, "si la distance gauche est proche et la distance avant est proche, alors tourne à droite fortement", si tu prend l'opérateur min() pour l'opération ET et que la distance gauche est proche à 80% et que la distance avant est proche à 50%, tu devras tourner à droite de min(80%, 50%), soit de 50%

Tu fais la même chose pour chacune des règles. Tu obtiens ainsi plein de valeurs différentes pour les valeurs de vitesse de tes moteurs.

Par exemple :

• vitesse_gauche_grande : 50%
• vitesse_gauche_grande : 70%
• vitesse_gauche_grande : 80%
• vitesse_gauche_grande : 60%
• vitesse_gauche_petite : 30%
• vitesse_gauche_petite : 20%
• etc. pour la vitesse droite

Là, il va falloir n'avoir qu'une seul et unique valeur pour chaque variable linguistique, c'est à dire, un seul pourcentage pour vitesse_gauche_grande, un seul pourcentage pour vitesse_gauche_petite, etc.

Pour cela, on applique l'opérateur OU.

• vitesse_gauche_grande_final = vitesse_gauche_grande_1 OU vitesse_gauche_grande_2 OU vitesse_gauche_grande_3 OU vitesse_gauche_grande_4
• vitesse_gauche_petite_final = vitesse_gauche_petite_1 OU vitesse_gauche_petite_2

Pareil, c'est à toi de définir l'opération mathématique qui se cache derrière le OU. Je prend par exemple l'opération max() (pour faire simple), on a donc :

• vitesse_gauche_grande_final = max(50%, 70%, 80%, 60%) = 80%
• vitesse_gauche_petite_final = max(20%, 30%) = 30%

La dernière étape va te permettre de transformer les variables linguistiques de sorties en données numériques

Ici, il y a plusieurs méthodes. Dans l'article, j'ai présenté la méthode du barycentre (ou méthode des moyennes pondérées).

Je considère que la vitesse est grande si elle est à 100% et qu'elle est petite si elle est à 0%.

J'ai donc vitesse = (vitesse_gauche_grande_final*1 + vitesse_gauche_petite_final*0)/(vitesse_gauche_grande_final + vitesse_gauche_petite_final) = 80/110 = 72%

La commande de mon moteur gauche sera de 72%







Pour la logique flou, il faut bien avoir compris à quoi servent chacune des étapes.

La première transforme des données numériques en données "qualitative" (le pieton qui traverse est à 6,23323 mètre => le pieton qui traverse est proche, mais pas trop (proche à 80%)), la seconde permet de manipuler les données qualitatives comme le ferait un humain dans la vrai vie (le piéton qui traverse est proche ! Freine !!!) et la troisième permet de transformer les données "qualitatives" de sorties en données numériques (Freine !!! => Appui sur le frein avec une pression de 12 Newtons)







Voila voila ! C'est vraiment une méthode ad-hoc, basée exclusivement sur l'expertise humaine. En gros, avec la logique floue, TOUT est entièrement paramétrable : la forme des fonctions d'appartenances, le nombre de variables linguistiques, le "niveau de détail" des règles d'inférences, le choix de la méthode de défuzification (dernière étape), le choix des différents opérateur (OU, ET, NON, etc.)
Dans le cas de la planification de trajectoire, ça marche plutôt bien. Pour l'avoir expérimenté, ça marchait même très bien pour éviter les obstacles


++
Black Templar

[inovasong]

Bon merci black d'avoir éclairci ton article et pour ne pas pédaler dans l'eau je vais partager avec vous les différentes étapes au travers de mon code

Donc voici la première étape, transformation en donnée "linguistique".

// fonction capteurs  ______________________________________________

void capteur_IR_sol(){

  if(analogRead(IRl_L)<950) IR_sol[LEFT] = true;
  else IR_sol[LEFT] = false;
  if(analogRead(IRl_C)<950) IR_sol[CENTER] = true;
  else IR_sol[CENTER] = false;
  if(analogRead(IRl_R)<970) IR_sol[RIGHT] = true;
  else IR_sol[RIGHT] = false;

  if (DEBUG_CAPT_IR_SOL){
    Serial.print("DEBUG capteur infrarouge sol -- ");
    if (IR_sol[LEFT]) Serial.print("G-vrai ");
    else Serial.print("G-faux ");
    if (IR_sol[CENTER]) Serial.print( " C-vrai ");
    else Serial.print(" C-faux ");
    if (IR_sol[RIGHT]) Serial.println(" D-vrai");
    else Serial.println(" D-faux");
  }
}

void capteur_distance(){
  
  
  capteurs_distance_grande[LEFT] = map(constrain(analogRead(IR_L), 380, 600), 600, 380, 0, 100);
  capteurs_distance_grande[CENTER] = map(constrain(US_sensor(), 5, 50), 5, 50, 0, 100);
  capteurs_distance_grande[RIGHT] = map(constrain(analogRead(IR_R), 380, 600),600, 380, 0, 100);
  capteurs_distance_petite[LEFT] = map(constrain(analogRead(IR_L), 380, 600), 600, 380, 100, 0);
  capteurs_distance_petite[CENTER] = map(constrain(US_sensor(), 5, 50), 5, 50, 100, 0);
  capteurs_distance_petite[RIGHT] = map(constrain(analogRead(IR_R), 380, 600),600, 380, 100, 0);


  if (DEBUG_CAPT_DISTANCE){
    Serial.print("DEBUG capteur de distance_grande -- ");
    Serial.print("G-");
    Serial.print(capteurs_distance_grande[LEFT]);
    Serial.print(" C-");
    Serial.print(capteurs_distance_grande[CENTER]);
    Serial.print(" R-");
    Serial.println(capteurs_distance_grande[RIGHT]);
    Serial.print("DEBUG capteur de distance_petite -- ");
    Serial.print("G-");
    Serial.print(capteurs_distance_petite[LEFT]);
    Serial.print(" C-");
    Serial.print(capteurs_distance_petite[CENTER]);
    Serial.print(" R-");
    Serial.println(capteurs_distance_petite[RIGHT]);
  }
}

Il me reste à bien paramétrer les valeurs de seuils
Manque t'il quelque chose ?
En attendant je continu la suite.

[Black Templar]

Manque t'il quelque chose ?

ça à l'air d'être bon !
Je ne connaissais pas les fonctions arduino map( et constrain( ! c'est bien pratique ^^

Il me reste à bien paramétrer les valeurs de seuils

Exactement

[inovasong]

Je ne connaissais pas les fonctions arduino map( et constrain( ! c'est bien pratique

Oui c'est très pratique et c'est en partie ce genre de choses qui ma donnée envie de découvrir arduino.

[inovasong]

Bonjour,

Bon la rien ne va plus, je suis bloqué a cette étape car j'ai des gros soucis avec mon robot, Le code précèdent avais des soucis c'est à dire que la variable capteurs_distance_grande[RIGHT] prenait la valeur inversé de capteurs_distance_grande[CENTRE] donc j'ai décomposé, j'ai même suspecté la fonction contrain, et la c'est le drame j'ai l'arduino qui ce reset des que je sollicite le capteur US , je suis perdu et je ne sais plus quoi faire.

Je pense que je vais reprendre le program à zéro

[Black Templar]

, et la c'est le drame j'ai l'arduino qui ce reset des que je sollicite le capteur US , je suis perdu et je ne sais plus quoi faire.

Tu alimentes bien l'arduino à part et non avec le PC ? Car si tu utilises le port USB, peut-être que l'arduino ainsi que tous les périphériques branchés pompent trop de courant.
Si tu as un adaptateur secteur/12V, essaye de l'utiliser pour alimenter l'arduino

++
Black Templar

[inovasong]

Bonjour,

J'ai fait plein de tests et je retrouve ce problème par intermittence avec une alim externe ou non, avec alim externe et xbee c'est moins pire mais j'ai quand même les problèmes qui revient, il semble effectivement que ca viens de l'alimentation donc je vais continuer pour le moment et dans un future proche je vais reprendre au complet l'alimentation du robot.

Du coté de la logique flou ca pas trop avancé, je vais continuer et vous faire part de mes avancées

[seb03000]

Bonjour inovasong , et t'il possible de voir tes branchement , avec photo si cela et possible , ou faire un schémas.

@Cordialement.

[Black Templar]

J'ai fait plein de tests et je retrouve ce problème par intermittence avec une alim externe ou non, avec alim externe et xbee c'est moins pire mais j'ai quand même les problèmes qui revient, il semble effectivement que ca viens de l'alimentation donc je vais continuer pour le moment et dans un future proche je vais reprendre au complet l'alimentation du robot.

Essaye de mettre quelques capa de découplage sur tes alims, ça permettra de lisser un peu les parasites et d'atténuer les sauts brusques de tensions. Perso, je met toujours du 100n et 10u (parfois du 1000u, mais ça fait un peu bourrin ^^') par ci par là quand j'ai une alim qui laisse à désirer...

[inovasong]

Bonjour,


Me voila de retour, après plusieurs mois d'absence pour mon job je remet enfin le nez dans mon robot.

J'ai ajouté deux capteurs a l'arrière du robot pour éviter les collisions en marche arrière. http://www.robotshop.com/ca/interrupteur-infrarouge-ajustable-dfrobot-2.html
Mais le gros soucis du robot étais son alimentation.

Essaye de mettre quelques capa de découplage sur tes alims, ça permettra de lisser un peu les parasites et d'atténuer les sauts brusques de tensions. Perso, je met toujours du 100n et 10u (parfois du 1000u, mais ça fait un peu bourrin ^^') par ci par là quand j'ai une alim qui laisse à désirer...

Merci mais ...

J'ai préféré repartir sur de bonnes bases et je ne suis pas très a l'aise en électronique donc j'ai tous modifié ,
j'ai remplacé les alimentation 9V et 7,5V par une batterie Li-po 11,1V couplé a un régulateur ajustable pour alimenter l'Arduino et la puissance moteur. Et la c'est le jour et la nuit plus de problèmes de capteur une tension stable et plus de reboot de l'Arduino. Je suis donc très content.
Pour completer l'alimentation je vais voir a ajouter un circuit lipo-save qui est un petit montage qui permet d'avertir de la limite de décharge de la Li-po ( car on ne doit pas descendre en dessous de 3V par cellules) ou alors je pensais faire la mesure directement avec l'Arduino en utilisant un régulateur négatif de ce type http://www.lextronic.fr/P22710-regulateur-negatif-9v--1a.html , qu'en pensez vous ?

De plus pour quoi pas intégrer le chargeur de la Li-po sur le robot, mais je suis frileux car une Li-po qui explose ça fait des dégâts, j'ai peut être une solution pour calmer mes angoisse avec un sac Lipo-safe qui permet de contenir le feux et les explosions possible de la li-po



Conclusion après le changement d'alimentation l'asservissement du robot est beaucoup plus stable les informations des capteurs plus fiable, je me suis donc surpris a coder une interface de communication avec le robot sur Processing et c'est un vrais plaisir.
prochaine étapes
- ajouter le système de protection de la Li-po.
- ajouter une système vidéo soit un systèmes avec calculs embarqué comme le module Cmucam , soit une transmission vidéo afin de faire les traitement sur Processing.


Je ferais prochainement des images du robot en action.


@+

[Black Templar]

Pour completer l'alimentation je vais voir a ajouter un circuit lipo-save qui est un petit montage qui permet d'avertir de la limite de décharge de la Li-po ( car on ne doit pas descendre en dessous de 3V par cellules) ou alors je pensais faire la mesure directement avec l'Arduino en utilisant un régulateur négatif de ce type http://www.lextronic...tif-9v--1a.html , qu'en pensez vous ?

Salut !

Je ne comprend pas comment un régulateur de tension te permettra de détecter sur ta batterie est chargée ou non !?

Sinon, tu as des montages simple pour détecter une chute de tension trop importante (avec AOP ou avec transistor)

• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_002.html
• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_003.html
• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_004.html
• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_001.html

++

Black Templar

[inovasong]

Salut !

Je ne comprend pas comment un régulateur de tension te permettra de détecter sur ta batterie est chargée ou non !?

Sinon, tu as des montages simple pour détecter une chute de tension trop importante (avec AOP ou avec transistor)

• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_002.html
• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_003.html
• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_004.html
• http://www.sonelec-musique.com/electronique_realisations_indic_niv_bat_001.html

++

Black Templar

Bonjour Black, content de voir que tu est toujours sur le pied de guerre.

L'idéal pour moi est d'abaisser la tension aux bornes de la batterie, un régulateur négatif me permettra de retrancher 9V précisément ce qui donnera une tension aux alentours de 2,1V, soit dans la plage de mesure de l'Arduino.

a 2,1V batterie Ok a 0V li-po en danger cela me permet d'integrer simplement une mesure de la tension.


source : http://www.mon-club-elec.fr/pmwiki_mon_club_elec/pmwiki.php?n=MAIN.ProjetBatterieMesureTension


Mais les différents montages que tu me présente me rappelle beaucoup le schéma du lipo-save qui équipe mon hélicoptère. Ca marche aussi mais disons que ma solution me semble plus simple et plus facilement intégrable dans le code du robot , mais peut-être que je me trompe ?

[swolf]

Pourquoi pas tout simplement un pont diviseur de tension? C'est ce que j'avais fait pour mon ppe et ça marchait très bien...