Merci de votre soutien, j'en suis à 10 votes . Je vais essayé de faire du mailing ( j'aime spammer ) pour recolter un max de vote

Salut les gars,

Intel et Lenovo on lancé une sorte de concours dans lequel il promettent de réaliser un projets par catégories ( aventure, musique, pro ou artistique ) et par mois avec un budget de 25 000 E par projet. J'y ai donc soumis mon projet de poubelle domestique avec système de compression des déchets ( pour réduire le nombre de sacs poubelles jetés )et si je fais appelle à vous aujourd'hui c'est qu'il vient d'être retenu par le jury du concours et qu'il me faut maintenant 250 votes pour qu'ils soit réaliser.

Donc si vous avez deux minutes, ce serais cool de voter pour mon projet ici : http://www.fallaitlefaire.fr/projet.php?id=1690

Merci

Voila, si je m'adresse a vous c'est que j'ai besoin d'aide. Je voudrais construire un robot qui éviterais les obstacles a l'aide de capteurs US et se déplacerais a l'aide de petit moteur pas a pas. J'ai en ma possession le code de fonctionnement de mes capteurs ainsi que ce de mes moteurs.

Le code de mes moteurs :

/

/ This Arduino example demonstrates bidirectional operation of a
// 28BYJ-48, using a ULN2003 interface board to drive the stepper.
// The 28BYJ-48 motor is a 4-phase, 8-beat motor, geared down by
// a factor of 68. One bipolar winding is on motor pins 1 & 3 and
// the other on motor pins 2 & 4. The step angle is 5.625/64 and the
// operating Frequency is 100pps. Current draw is 92mA.
////////////////////////////////////////////////

//declare variables for the motor pins
int motorPin1 = 8;    // Blue   - 28BYJ48 pin 1
int motorPin2 = 9;    // Pink   - 28BYJ48 pin 2
int motorPin3 = 10;    // Yellow - 28BYJ48 pin 3
int motorPin4 = 11;    // Orange - 28BYJ48 pin 4
                        // Red    - 28BYJ48 pin 5 (VCC)

int motorSpeed = 1200;  //variable to set stepper speed
int count = 0;          // count of steps made
int countsperrev = 512; // number of steps per full revolution
int lookup[8] = {B01000, B01100, B00100, B00110, B00010, B00011, B00001, B01001};

//////////////////////////////////////////////////////////////////////////////
void setup() {
  //declare the motor pins as outputs
  pinMode(motorPin1, OUTPUT);
  pinMode(motorPin2, OUTPUT);
  pinMode(motorPin3, OUTPUT);
  pinMode(motorPin4, OUTPUT);
  Serial.begin(9600);
}

//////////////////////////////////////////////////////////////////////////////
void loop(){
  if(count < countsperrev )
    clockwise();
  else if (count == countsperrev * 2)
    count = 0;
  else
    anticlockwise();
  count++;
}

//////////////////////////////////////////////////////////////////////////////
//set pins to ULN2003 high in sequence from 1 to 4
//delay "motorSpeed" between each pin setting (to determine speed)
void anticlockwise()
{
  for(int i = 0; i < 8; i++)
  {
    setOutput(i);
    delayMicroseconds(motorSpeed);
  }
}

void clockwise()
{
  for(int i = 7; i >= 0; i--)
  {
    setOutput(i);
    delayMicroseconds(motorSpeed);
  }
}

void setOutput(int out)
{
  digitalWrite(motorPin1, bitRead(lookup[out], 0));
  digitalWrite(motorPin2, bitRead(lookup[out], 1));
  digitalWrite(motorPin3, bitRead(lookup[out], 2));
  digitalWrite(motorPin4, bitRead(lookup[out], 3));
}

 

celui de mes capteurs : #define trigPin 12
#define echoPin 13


void setup() {
  Serial.begin (9600);
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);   
}

void loop() {
 int duration, distance,pos=0,i;
  digitalWrite(trigPin, LOW); 
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);
  duration = pulseIn(echoPin, HIGH);
  distance = (duration/2) / 29.1;
   Serial.print(distance);
   Serial.println(" cm");
 
}

et voila enfin le code que j'ai essayer de faire avec mais je crains qu'il soit tout faux, je vous laisse en juger :

#include <Stepper.h>
#define ECHOPINcapteurdroit 13                          // Pin to receive echo pulse
#define TRIGPINcapteurdroit 12 
#define ECHOPINcapteurgauche 4                            // Pin to receive echo pulse
#define TRIGPINcapteurgauche 5


//declare variables for the motor pins
int motorPindroit1 = 6;    
int motorPindroit2 = 7;    
int motorPindroit3 = 8;    
int motorPindroit4 = 9; 
int motorPingauche1 = 10;    
int motorPingauche2 = 11;    
int motorPingauche3 = 12;    
int motorPingauche4 = 13; 


int motorSpeed = 1200;  //variable to set stepper speed
int lookupdroit[8] = {B01000, B01100, B00100, B00110, B00010, B00011, B00001, B01001};


void setup() {
  Serial.begin (9600);
  pinMode(ECHOPINcapteurdroit, INPUT);
  pinMode(TRIGPINcapteurdroit, OUTPUT);
  pinMode(ECHOPINcapteurgauche, INPUT);
  pinMode(TRIGPINcapteurgauche, OUTPUT);
  pinMode(motorPindroit1, OUTPUT);
  pinMode(motorPindroit2, OUTPUT);
  pinMode(motorPindroit3, OUTPUT);
  pinMode(motorPindroit4, OUTPUT);
  pinMode(motorPingauche1, OUTPUT);
  pinMode(motorPingauche2, OUTPUT);
  pinMode(motorPingauche3, OUTPUT);
  pinMode(motorPingauche4, OUTPUT);
}

void loop() {
  int durationdroit ;
  int distancedroit ;
  digitalWrite(TRIGPINcapteurdroit, LOW);               	
  delayMicroseconds(2);
  digitalWrite(TRIGPINcapteurdroit, HIGH);             	
  delayMicroseconds(10);
  digitalWrite(TRIGPINcapteurdroit, LOW);   	
  durationdroit = pulseIn(ECHOPINcapteurdroit, HIGH);    
  distancedroit = (durationdroit/2) / 29.1;
   Serial.print(distancedroit);
   Serial.println(" cm");  

  int distancegauche ;  
  digitalWrite(TRIGPINcapteurgauche, LOW);               	
  delayMicroseconds(2);
  digitalWrite(TRIGPINcapteurgauche, HIGH);             	
  delayMicroseconds(10);
  digitalWrite(TRIGPINcapteurgauche, LOW);   	
  int durationgauche = pulseIn(ECHOPINcapteurgauche, HIGH);   	
    distancegauche = (durationgauche/2) / 29.1;
   Serial.print(distancegauche);
   Serial.println(" cm");  
   
   if(distancedroit < 10)
   {
 	moteurgauche = Anticlockwise
   }
   
   else 
   {
 	moteurgauche = Clockwise
   }
   
   if(distancegauche < 10)
   {
 	moteurdroit = Anticlockwise
   }
   
   else
   {
 	moteurdroit = Clockwise
   }
   
   void anticlockwise()
{
  for(int i = 0; i < 8; i++)
  {
    setOutput(i);
    delayMicroseconds(motorSpeed);
  }
}

void clockwise()
{
  for(int i = 7; i >= 0; i--)
  {
    setOutput(i);
    delayMicroseconds(motorSpeed);
  }
}

void setOutput(int out)
{
  digitalWrite(motorPin1, bitRead(lookup[out], 0));
  digitalWrite(motorPin2, bitRead(lookup[out], 1));
  digitalWrite(motorPin3, bitRead(lookup[out], 2));
  digitalWrite(motorPin4, bitRead(lookup[out], 3));
}

Merci, je sais que c'est un peut long a lire ^^

Pour "transoformer" un servo en controleur il te suffit de remplacer le potantiometre par deux resistances de meme valeurs ( de cette facon le recepteur ou microcontroleur pensera qu'il est enposition neutre ce qui permet de controler ton moteur grace a ta telecommande), d'enlever le moteur et de brancher le moteur que tu veut controler a la place.

Mais comme une video vaut mieux que milles mots voila regarder a partir de 1.13 si vous ne voulais pas voir la construction d'un "robot drifter"

Enjoy !

Pour la radio je crains que tu n'ai pas trop le choix, en france le moin cher que j'ai trouver c'est sa http://www.ckado.com/ST-DX4E-242-dx4e-only-mode_product_8464_fr.html et le prix est cher pour ceux que c'est crois moi...

De plus sur Hking tu peut commander tout cedon tu a besoin sur le meme site ce qui est a la fois pratique et moins cher

Fait comme moi utilise les chenilles tamiya , ta boite a engrenage et tu fait le chasssis en plexiglass comme sur mon robot

Sinon pour controler ton robot a mon avis la maniere la plus simple et d'acheter une telecommade de modelisme ( 20 euros ) http://www.hobbyking.com/hobbyking/store/__9041__Hobby_King_2_4Ghz_6Ch_Tx_Rx_V2_Mode_1_.html des servomoteurs ( 2 euros unité ) http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=662 dont tu en tranformera 2 en controleur pour moteurs et avec les autres tu pourras par exemple controler une tourelle par exemple depuis ta telecommande ( tentans non ? )

Voila si tu a des question notament sur comment tranformer un servos en controleur de vitesse, ask me

Vas voir mon post http://www.robot-maker.com/forum/topic/7141-probleme-sur-mon-robot-fini/ tu y trouvera plus de photos de mon engin

Cordialement

theo

Si je vien de trouver une battrie adequat pour ton projet http://www.hobbyking.com/hobbyking/store/__25029__Turnigy_LSD_4_8V_2300mAh_Ni_MH_Flat_Receiver_Pack.html

_De l'aluminium pour faire mon Châssi

Ce n'est pas un peut chiant de travailler l'alu ?

[(hors fraits de port)

Les frais de port de hobbyking sont assez cher et il faut payer la douane en plus, mais cela reste quand meme extremement moin cher que en france


Envoie nous des photos de ton projet car je comptais faire la meme chose sur mon chassis et sa me permettra de voir a quoi sa va ressembler

L'aventage de ma solution c'est qu'il ne faut que le recepteur ( fourni avec la telecommande ) pour commander le robot.

Aprés il te faut une alimentation 5V pour un recepteur je crois donc 3 piles devrais faire l'affaire

Donc il te faut : - telecommande et recepteur fournis avec
- 2 ou plus servos moteurs
- 4 resistances de meme valeurs les plus precise possible ( si tu est en region parisienne selectronic place de la nation sinon sur internet)
- un chassis tout fait ou juste les chenilles et un chassis "homemade"
- la boite a engrenage
- une batterie 4,8V ou 3 piles ( 4,5V )

La telecommander utiliser dans le tuto vaut 24 euro chez hobbyking je le sait j'ai la meme ^^

Non

Avec ça, tu te compliques la vie pour rien et en plus, tu auras une entrée diff qui n'est pas évident à interpréter... Que fais-tu si tu as des obstacles à gauche et à droite et devant ?

De plus ton indice sera le même si, imaginons, les obstacles à droite et à gauches sont respectivement à 1 et 2 cm de toi ou à 1 et 2 m !

 

A prioris, le cas de figure ou il y a des obstacles devant à droit et à gauche ne se produira pas dans le circuit donné (du moins je l'espère ahah)

Et oui, l'indice est le même pour des obstacle à différente distance, c'est justement l’intérêt. C'est justement pour résoudre le problème dont je parlais dans un post précédent : 

 

J'ai trouvé la source de mon problème majeur, en fait quand la voiture est dans un virage serré, l'avant de la voiture et parfois très proche du mur.

De ce fait, les mesures droite et gauche sont à ce moment la toute les deux très petite ce qui pose un problème.

 

En effet, la règle numéro deux dit que si une mesure est plus grande que l'autre, alors on tourne les roues dans le sens de la plus grande mesure, mais si les deux mesures sont (bien que différentes) petite, alors la règle numéro 3 qui dit que si les deux mesures sont petites alors on centre les roue est vraie aussi et il y a donc un conflit entre les deux règles.

Le résultat de ce conflit est une orientation des roues pas assez forte qui provoque la collision de la voiture.

 

Pour solutionner ce problème, je pense que je vais essayer en prenant en compte la différence entre les mesures droite et gauches plutôt que les mesures elles mêmes. De cette manière, j'évite le conflit de règles. 

 

Qu'en pensez vous ?

 

Et pour que la voiture ne tourne pas pareil quand les obstacles sont respectivement à 1cm et 2cm et 1m et 2m, il suffit d'include la distance_avant dans la règle. Ainsi, si il détecte un indice -0.5 a 70cm d'un mur, le tournant sera moins sérré que si il détecte un même indice à 10cm du mur.

 

De plus, le fait d'utiliser juste un indice au lieu des deux distances va simplifier les règles non ?

 

 

 

Pour un indice de 0.3, tu as une appartenance à 15% petit, 50% grand et 50% moyen.

Pour tout x, essaye que la somme de tes trois variables linguistiques fasse 100%

Tout à la fin de cet article, tu as un exemple de ce qu'il se passe lorsque la somme des fonctions n'est pas égale à 1.

 

Comment tu a calculer ca ? (parce que juste par lecture graphique, il n'y a que 0 qui peut avoir 50% moyen)

Aah, je croyais que ce n'étais pas obligatoire, c'est peut être ca qui fous le bordel alors

Il n'y a pas de conflit entre les règles car la règle 2 dit que si l'une des deux mesures est petite et l'autre grande alors ...

Dans ton cas les 2 sont petites donc cette règle règle aura un poids très petit lors de la fusion par l'opérateur OU !

 

 

C'est justement ca le problème, si au cours d'un tournant la voiture frôle un mur en face, elle devrait continuer à tourner (encore plus sérré même) or ce qui se passe la c'est que comme aucune valeur n'est grande, la règle deux à un poids très faible et c'est donc la règle 3 qui prend le dessus et dit de centrer les roues.

 

Voici un exemple (on voit ici que la voiture devrait sérrer à droite, pourtant elle va continuer tout droit):

 

J'ai oublié de répondre à ça.

Bien sûr que si ça pèse dans l'équation finale, même si sa valeur est 0 !

Si tu as un 0/20 en math, ça va influer ta moyenne !

Lors de la défuzification tu fais un calcul de barycentre ou de centre de gravité, tout ça, ce sont des moyennes

 

 

SI distance_gauche = grande ET distance_droite = petite ET distance_avant = loin ALORS ???

SI distance_gauche = grande ET distance_droite = grande ET distance_avant = près ALORS ???

SI distance_gauche = grande ET distance_droite = grande ET distance_avant = loin ALORS ???

SI distance_gauche = petite ET distance_droite = grande ET distance_avant = loin ALORS ???

SI distance_gauche = petite ET distance_droite = petite ET distance_avant = près ALORS ???

 

De plus la conclusion, c'est toujours l'orientation, tu n'avais pas dit que tu voulais aussi jouer sur la vitesse ? Dans ces cas là, pour chaque règle, tu dois déterminer l'orientation et la vitesse.

 

Le reste est correct.

 

Merci pour tes réponses

 

Je suis en train de revoir fondamentalement mon système la. En effet, au lieu d'avoir deux variables linguistique distance_gauche et distance_droite pour déterminer l'orientation des roues, j'ai pensé qu'il serait plus pratique d'avoir directement un indice de la différence entre les deux mesures.

 

J'ai donc crée une variable "diff" qui se calcule de la facon suivante :

 

diff = mesure_droite - mesure_gauche

SI diff INFERIEUR A 0

      diff = diff / mesure_gauche

SINON

      diff = diff / mesure_droit

 

Cela nous donne donc un indice de la différence relative des mesures dans un intervalle [-1;1] (-1 étant très forte différence vers la droite, 1 très forte différence vers la gauche et 0 pas de différence).

 

Il suffit donc à présent de lié cet indice à des variables linguistiques "gauche", "centre" et "droite" pour par la suite les soumettre à des règles.

 

Pour la fonction d'appartenance à l'orientation de cet indice, j'ai fais le graph suivant :

 

 

Mais la je bloque totalement du le calcule des appartenance avec ce graph :/ Comment est ce que je calcule par exemple les appartenance pour un indice de 0.3 ?

 

Sinon vous pensez que c'est une bonne idée ou pas du tout ce que je suis en train de faire ?

Bon, j'ai implémenter ma technique et ça marche (enfiiiin) ! J'arrive à faire des tours sans toucher aucun bord et de manière plutôt fluide, me reste plus qu'a implémenter la notion de vitesse pour gratter du temps dans les lignes droite et je pense que ca sera bon, je posterais une vidéo ainsi que le code quand j'aurais fini

Alors, en entrée j'ai 3 mesures de distances respectivement distance_gauche, distance_droite et distance_avant.

 

distance_gauche et distance_droite ont deux variables linguistiques "petit" et "grand"

 

distance_avant à aussi deux variables linguistique "près" et "loin" mais n'a pas la même fonction d'appartenance que gauche et droite.

 

Mes variables de sorties sont orientation_gauche, orientation_droite et orientation_centrée et la fonction d'appartenance est faite comme dans ton article pour simplifier les calculs.

 

Mes règles sont pour l'instant: 

 

SI distance_gauche = grande ET distance_droite = petite ET distance_avant = près ALORS orientation = gauche

SI distance_gauche = petite ET distance_droite = grande ET distance_avant = près ALORS orientation = droite

SI distance_gauche = petite ET distance_droite = petite ET distance_avant = grande ALORS orientation = centrée

 

Je n'arrive pas à voir quoi rajouter comme règle :/

 

Sinon, pour mes opérateurs logiques, j'ai

A ET B = A * B

a OU b = 1 - (1 - a) * (1 -

 

Ma méthode de deffuzification est exactement la même que dans ton article (http://www.ferdinandpiette.com/blog/2011/08/exemple-de-systeme-flou-un-planificateur-de-trajectoire/)

Bon, après quelques jours de galère je reviens finalement ici, j'ai donc fini d'implementer la logique floue pour l'orientation et j'ai commencé à gérer le controle de la puissance du moteur mais j'ai un problème. En effet, j'aimerais le joindre au système floue déjà existant mais je ne sais pas trop comment ca doit ce passer.

 

Pour l'instant ce que j'ai fais c'est que j'ai recrée une variable linguistique d'entrée "distance_avant" avec sa fonction d'appartenance et une variable linguistique de sortie "rapport_cyclique".

 

Les fonctions d'appartenance de ces variables sont presque les même que celle dans l'article de black templar:

 

 

J'ai donc essayé de "joindre" la vitesse du moteur avec l'orientation avec les règles suivantes:

 

orientation->droite = facteur_orien->droite  ET distance_avant->petite 

orientation->gauche = facteur_orien->gauche  ET distance_avant->petite

orientation->centre = facteur_orien->milieu

rapport_cyclique->bas = orienttation->droite OU  orientation->gauche

rapport_cyclique->haut = distance_avant->longue ET facteur_orien->milieu

 

(de cette facon la voiture ralenti quand elle est près d'un mur ou dans un tournant et accelère quand elle est centrée sur la route et qu'il y y à de la place devant)

 

Je fais ensuite un simple calcul de barycentre pour connaitre l'orientation et le rapport cyclique.

 

Ca marche à peu près mais je sens que ce n'est pas la bonne façon de faire :/

 

Des idées ?

 

 

J'ai lu les valeurs en ordonnée sur ton graphique pour une abscisse à 0.3

 

 

Sur ce graph la  ?

 

 

En fait je crois que je lis et fais mes fonctions d'appartenance à l'envers depuis le début...

Black Templar, j'ai lu tes articles sur le sujet et ça a effectivement l'aire de correspondre à ce dont j'ai besoin, je vais donc partir la dessus 

 

Dans un premier temps, je vais essayer de centrer le robot sur la piste en utilisant la logique floue (je le faisais jusqu'à maintenant en utilisant une simple règle de proportionnalité).

 

Je vais donc utilisé les capteurs droite et gauche (comme dans l'exemple du robot de ton article) pour contrôler l'orientation des roues avant.

 

J'aurais donc pour chaque capteur deux variables linguistique distance_petite et distance_grande et pour l'orientation des roues une variables linguistique "orientation" (Cette valeur me donnera la valeur de l'orientation, il me suffira de déterminer si elle doit être positive ou négative en fonction du sens)

 

Les variables linguistiques aurait ces fonctions d'appartenance :

 

 

Et les règles serait les suivantes:

 

SI distance_gauche = grande ET distance_droite = petite ALORS orientation = grande

SI distance_gauche = petite ET distance_droite = grande ALORS orientation = grande

SI distance_gauche = petite ET distance_droite = petite ALORS orientation = moyenne

 

Cela te semble correct ? Si non qu'est ce qui ne va pas ?

 

Autres questions: Quel est l’intérêt de mettre plus de variables linguistiques pour un problème sachant que le résultat sera toujours un pourcentage ? Comment est ce qu'on "code", les fonctions d'appartenance des variables linguistiques ?

 

Merci pour tout en tout cas les gars

 

La communication se fais en texte via un socket en C. J'envois mes commandes sur la sortie standards (on bosse sur un environnement UNIX) et j'ai un retour en texte aussi sur l'entrée standards (que je dois parser pour récup les informations de contrôle).

 

De ce que je me rappelle de la logique floue c'est un système de prise de décision basés sur des probabilités. Ca donnerais un truc comme ca dans mon cas SI capteur_droit SUPERIEUR A capteur_gauche ET QUE capteur_avant INFERIEUR A un_seuil ALORS on se trouve surement dans un virage vers la droite. C'est ca ?

 

J'ai regardé aussi le réseau de neurone, ça à l'aire cool, mais de ce que j'ai compris, pour que ca marche, il faut naviguer plusieurs fois dans le circuit pour l'analyser et on aura le droit qu'à un essais le jour de la présentation (sur un circuit inconnu qui plus est) :/

 

Je ne passe pas par matlab, tout se fais via le socket :/

 

Je suis en première années à Epitech, et cette école est justement connu pour ne pas guider les étudiants pour les pousser à chercher par eux même

Salut les gars,

 

Je bosse actuellement sur un projet (pour mon école) qui consiste à créer un algorithme (en C) permettant de faire naviguer un robot doté d'un lidar à l'avant dans un circuit le plus vite possible sans toucher de murs.

 

Quelques infos à propos du robot:

 

Le lidar à un angle d'ouverture de 60 dégrée vers l'avant du robot (voir photo) et il retourne 32 mesures de distance (environ une tout les 2 degrées donc).

Je peux contrôler la puissance du moteur (de 0 à 100%), ainsi que l'angle des roues avant pour contrôler le robot.

Je peux aussi connaitre la vitesse absolut du robot (en Km/h).

La fréquence de rafraîchissement du lidar est assez longue (3 mesures par secondes je dirais) donc ça complique pas mal la tache sachant que le robot peut aller (très) vite.

Les essais sont pour l'instant fait sur un logiciel de simulation robotique (V-REP pour les connaisseurs).

 

Voici une image de la simulation (les lignes bleu partant du robot représentent les extrémités du capteur):

 

 

J'ai déjà fais un algo très simple qui consiste à juste tourner les roues dans un le sens opposé quand on se rapproche d'un mur. Ca marche à peut près, mais quand il y à des virages trop serrés il se plante et il ne va du coup pas tout droit même en ligne droite.

 

Je suis sur qu'avec autant de données venant du lidar, on peut faire un algo bien plus intelligent pour par exemple appréhender les virages et choisir exactement la bonne vitesse/orientation pour le prendre etc...

 

Le truc c'est que je ne vois pas du tout comment faire ça et je ne trouve rien sur le net :/ 

 

Voilà voilà, donc si quelqu'un à une idée de comment faire ou un lien vers des éventuels informations, je suis preneurs

Que signifie la variable linguistique "orientation" ? Pourquoi ne pas avoir directement la vitesse des roues (gauche et droite) ?

 

Le fait de mettre plus de variables linguistiques en entrée te permettra d'avoir plus de règles et donc d'affiner le calcul des sorties (même si c'est toujours une vitesse entre 0 et 1, la manière de calculer cette vitesse sera différente et (on peut l'espérer), plus adaptée). Le tout, c'est de savoir si les variables d'entrées ont une réelle influence sur la sortie ou non.

C'est un peu comme l'age du capitaine : c'est une info que tu as mais qui ne te sert pas à résoudre le problème. Si tu la prend en compte, tu complique le système sans rien changer au résultat

 

Mon robot est une base de voiture télécommandée, pour tourner je dois donc orienter les roues avant (comme quand on tourne le volant dans une vraie voiture) et non pas changer la vitesses des roues (d'ailleurs je n'ai qu'un seul moteur pour les deux roues arrières). Le contrôle de cet orientation se fait par l'envoi d'une valeur comprise entre -1 et 1, -1 étant roue tourné a fond vers la gauche 1 étant roues tourné ) fond vers la droite et 0 étant roues droites

 

Je commence à comprendre mieux l’intérêt des variables linguistique, dans mon cas il faudrait donc que j'ai 3 variables linguistique pour la distance: petit pour la détection des bordures, moyen pour la détection des virages et grand pour la détection des grandes lignes droites à l'avant du robot

Bon, j'ai passé toute la journée à trifouiller les valeurs de mes fonction d'appartenance et j'ai réussi ce que ma voiture parcourt une bonne partie du parcourt. En revanche, les valeurs n'ont aucuns sens et je n'arrive pas à bien me représenter le truc dans ma tête pour savoir exactement ce que je dois faire :/ En fait, avec le circuit, il n'y à pas vraiment de cas de figure prédéfini ce qui rendre la définition de règles et de seuils pour ces règles assez difficile :/

 

J'ai rajouté des variables linguistique pour la distance à l'avant du robot, ainsi, je peux dire que plus la distance est courte, plus l'angle de braquage peu être important. Mais encore une fois ca ne marche pas tout le temps..

 

Mes règles pour l'instant sont:

 

SI distance_gauche = grande ET distance_droite = petite ET distance_avant = petite ALORS orientation = gauche

SI distance_gauche = petite ET distance_droite = grande ET distance_avant = petite ALORS orientation = droite

SI distance_gauche = petite ET distance_droite = petite ET distance_avant = grande ALORS orientation = centrée

 

Des idées ?

J'ai trouvé la source de mon problème majeur, en fait quand la voiture est dans un virage serré, l'avant de la voiture et parfois très proche du mur.

De ce fait, les mesures droite et gauche sont à ce moment la toute les deux très petite ce qui pose un problème.

 

En effet, la règle numéro deux dit que si une mesure est plus grande que l'autre, alors on tourne les roues dans le sens de la plus grande mesure, mais si les deux mesures sont (bien que différentes) petite, alors la règle numéro 3 qui dit que si les deux mesures sont petites alors on centre les roue est vraie aussi et il y a donc un conflit entre les deux règles.

Le résultat de ce conflit est une orientation des roues pas assez forte qui provoque la collision de la voiture.

 

Pour solutionner ce problème, je pense que je vais essayer en prenant en compte la différence entre les mesures droite et gauches plutôt que les mesures elles mêmes. De cette manière, j'évite le conflit de règles. 

 

Qu'en pensez vous ?

Fait des règles qui gèrent la vitesse de ton robot ... Si tu es trop près d'un mur ralentit ... sinon va à fond ! 

J'ai essayé de faire des règles pour la vitesse, mais ça provoquais encore plus de problèmes (le robot se mettais à aller à fond en ligne droite et se retrouvais presque à l’arrêt au moindre virage) :/

 

Voila les règles que j'avais fais pour la vitesse:

 

SI orientation = gauche OU orientation = droite ALORS vitesse = petite

SI distance_avant = grande ET orientation = centré ALORS vitesse = grande

De mes souvenirs de cours, l'intérêt de la logique floue était de faire des raisonnements symboliques en prenant en compte l'incertitude qu'il y a sur les notions (genre petit, grand, etc.). En relisant rapidement un cours, je vois que ça n'était pas exact, puisque selon la méthode de défuzzification, on peut avoir une valeur qui n'appartient pas à une catégorie.
Après, j'ai un biais négatif envers cette approche : elle essaie de définir des catégories symboliques artificielles (données par l'humain) pour contrôler un robot à un niveau subsymbolique.
Alors que ça peut être fait élégamment sans passer par cette notion symbolique, avec une approche purement numérique (Braitenberg en version simple, réseaux de neurones en version plus compliquée avec apprentissage des poids de connexion). Mais là, j'ai un biais positif.

L'autre intérêt, c'est qu'il est possible de calculer des informations dérivées des mesures de distance : en faisant une différence temporelle entre deux mesures, on peut obtenir une estimation de la vitesse à laquelle l'obstacle se rapproche (donc de la vitesse du véhicule si l'obstacle est fixe) : hors, s'il se rapproche doucement, il n'y a pas besoin de tourner beaucoup du côté le plus dégagé ; à l'inverse, s'il se rapproche vite, tu peux avoir envie de braquer fort pour prendre la courbe correctement.

@Newbies : 60° d'ouverture, ça n'est pas mal : si tu as assez de puissance de calcul, tu peux essayer de convertir tes données LIDAR (angle, distance) en coordonnées dans le repère de la voiture (x,y). Les points plus loin que la moitié de la largeur de la voiture sont considérés comme les côtés, les infos en dessous sont "en face". Normalement, le bruit de mesure doit faire que tu n'auras jamais exactement les mêmes distances de chaque côté et tu peux discriminer entre tourner à gauche ou à droite selon les distances perçues.

 

J'ai oublié de préciser, j'ai accès à d'autres informations : la vitesse du robot (en Km/h) et la position des roues (sur [-1;1])

 

Je n'ai pas totalement compris ton histoire de convertir les données du LIDAR en coordonnées. La voiture deviendrait l'origine du repère c'est ca ?

Sinon effectivement pour l'instant je n'utilise que 3 "point de mesure", tu pense qu'il serait intéressant de faire des groupements (dy style le prend les 5 points de mesures de droites et je fais une moyenne) ?