Aller au contenu


Photo
- - - - -

algo pour lidar 32 points de mesures


  • Veuillez vous connecter pour répondre
37 réponses à ce sujet

#21 R1D1

R1D1

    Modérateur et Membre passionné

  • Modérateur
  • PipPipPipPipPip
  • 1 160 messages
  • Gender:Male
  • Location:Autriche

Posté 02 mai 2016 - 09:37

Je ne vois pas en quoi la logique flou est inadaptée.
Un système flou sert bien à déterminer des commandes en mode continue.
Le moyen d'y arriver, c'est de prendre en compte des règles d'inférences exprimées en langage naturelle car on ne veut pas s’embêter à modéliser le système.
 
Sinon, ça à l'air sympa le Braitenberg vehicle, je ne connaissais pas :)


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.
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#22 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 02 mai 2016 - 09:50

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



#23 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 02 mai 2016 - 10:00

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



#24 R1D1

R1D1

    Modérateur et Membre passionné

  • Modérateur
  • PipPipPipPipPip
  • 1 160 messages
  • Gender:Male
  • Location:Autriche

Posté 02 mai 2016 - 11:15

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]) ;)

Position des roues : tu veux dire l'angle de braquage ?

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

En général, ce type de capteur te renvoie un tableau de distances, chaque distance étant mesurée dans une direction. Tu as donc des informations en coordonnées polaires. Tu peux les convertir en coordonnées cartésiennes (avec effectivement la voiture, ou plutôt le laser comme origine du repère), ce qui te permet de raisonner sur la position des obstacles par rapport à la forme de la voiture.
Effectivement, autant exploiter au mieux le max d'info que tu as ; en regardant la valeur de distance moyenne, la valeur minimale de chaque côté, il y a moyen de faire un contrôleur assez adaptable.
R1D1 - Calculo Sed Ergo Sum -- en ce moment, M.A.R.C.E.L.
Avatar tiré du site bottlebot

#25 Black Templar

Black Templar

    Membre

  • Membres
  • PipPipPipPipPip
  • 1 430 messages
  • Gender:Male
  • Location:Lille

Posté 03 mai 2016 - 08:42

Salut Newbie !

 

Tout d'abord, tu as combien de données en entrée et de variable linguistiques pour ces données ? Et combien de variable de sortie ?

En entrée, tu as distance_droite, distance_gauche et distance_centre ? Les variables linguistiques sont petit et grand ?

Dans ce cas, tu as 2^3 règles à définir. Sinon tu oublies des cas particulier.

 

Deuxièmement, tu ne peux pas prendre des variables de sorties comme variable d'entrée. Ta règle "SI orientation est xxx ALORS xxx" n'est pas bonne.

Tu dois tout exprimer en fonction de variable d'entrée "Si capteur_gauche = xxx ET capteur_droit = xxx ET capteur_centre = xxx ALORS orientation = xxx ET vitesse = xxx"

 

Troisièmement, dis-nous ce que tu as choisi comme opérateur ET / OU ainsi que la méthode de défuzification.

C'est aussi le choix de ces opérateurs qui conditionnent la qualité du résultat en sortie.

 

 

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

Moi aussi je préfère les méthodes du type RdN & co.

Seulement dans ce type de problème, un RdN n'est pas forcement mieux qu'un système flou pour la simple est bonne raison que dans le premier cas tu n'arrives pas à interpréter le poids des neurones, alors que dans un système flou, tu as des règles, des variables linguistiques et des opérateurs que tu peux interpréter.

 

Si tu modélises le problème de Newbie par un RdN de 3 neurones d'entrée, 8 neurones cachés et 2 de sorties, en linéarisant le RdN tu te rends compte qu'on arrive à peu près au mêmes équations qu'avec un système flou. Sauf qu'avec un système flou, tout est explicite alors qu'avec un RdN, tout est implicite. Pour une autre structure de RdN, ça devient très difficilement interprétable (voir impossible à interpréter, ça marche, c'est tout, on ne sait pas pourquoi).

 

 

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.

 

Tu n'as pas besoin de coder ça dans un système flou car si tes règles sont bonnes et tes opérateurs assez fins, le système adaptera tes vitesses automatiquement en fonction de la distance de l'objet. Du coup, l'objet se rapprochera toujours avec la même accélération.

J'ai déjà implémenté le déplacement de robots à l'aide d'un système flou et j'ai été étonné par la fluidité avec laquelle ils se déplacent.

Couplé à un algo d'attracteur par champ de potentiel ou par bande élastique, ça te fait un algo de planification de trajectoire basique mais redoutablement efficace en milieu convexe qui t'évite les obstacles sans connaitre l'environnement à l'avance et qui peut largement se calculer en temps réel.

Si tu as un peu de temps pour tester cet exemple tu te rendras compte de ce que je dis par toi même : http://www.ferdinandpiette.com/blog/2011/08/exemple-de-systeme-flou-un-planificateur-de-trajectoire/

La vitesse de ton robot sera juste limité par la vision de celui-ci (distance max à laquelle tu peux détecter un objet avec tes capteurs) ainsi que par le nombre de fois que tu réexécute l'algo par seconde.

 

Après, ça ne prend pas en compte la cinématique du robot, c'est à dire qu'on est pas garanti que le robot puisse effectuer le mouvement demandé (on ne prend pas en compte l'encombrement du robot, sa capacité maximale d'accélération et autre). Mais de toute façon, un RdN non plus.

Pour prendre en compte ces critères, il faut un vrai algo de plannif comme DKP par exemple : http://www.ferdinandpiette.com/blog/2011/05/algorithmes-de-planification-de-trajectoires-bref-etat-de-lart/

 

P.S. : Je ne dis pas que les RdN ou autre méthode purement numérique sont moins efficaces, j'essaye juste de te convaincre qu'un système flou peut l'être tout autant avec l'avantage d'avoir un comportement intelligible par n'importe quel humain ;)


Mon site internet : http://ferdinandpiette.com/


#26 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 03 mai 2016 - 10:14

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 - B)

 

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/)



#27 Black Templar

Black Templar

    Membre

  • Membres
  • PipPipPipPipPip
  • 1 430 messages
  • Gender:Male
  • Location:Lille

Posté 03 mai 2016 - 10:57

En fait je pense que le problème viens de la variable linguistique "centré"  de l'orientation. En effet, comme elle est définie à zéro, sont poid ne pèse pas dans l'équation finale ce qui fait que si on à par exemple 30% de droite 30% de centré et 0% de gauche, au lieu d'avoir au final 15% de droite on va avoir encore 30% de droite et c'est pour ca que ma voiture braque trop fort :/

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

 

 

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 = loin ALORS orientation = centrée

 

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

 

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.


Mon site internet : http://ferdinandpiette.com/


#28 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 03 mai 2016 - 12:04

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 :

 

Fichier joint  Présentation sans titre.jpg   25,68 Ko   76 téléchargement(s)

 

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 ?



#29 Black Templar

Black Templar

    Membre

  • Membres
  • PipPipPipPipPip
  • 1 430 messages
  • Gender:Male
  • Location:Lille

Posté 03 mai 2016 - 01:13

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

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 !

 

 

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

 

attachicon.gifPrésentation sans titre.jpg

 

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 ?

 

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.


Mon site internet : http://ferdinandpiette.com/


#30 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 03 mai 2016 - 01:51

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 ;)



#31 Black Templar

Black Templar

    Membre

  • Membres
  • PipPipPipPipPip
  • 1 430 messages
  • Gender:Male
  • Location:Lille

Posté 03 mai 2016 - 02:00

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.

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 !

 

 

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 le détecte à 10cm du mur.

 

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

Tu peux essayer, mais je ne vois pas l'intérêt perso ;)

 

Comment tu à calculer ca ? ;)

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

 

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

Ce n'est pas obligatoire, mais dans ce cas, il faut bien savoir ce que l'on fait car ça peut entrainer des comportements étranges.


Mon site internet : http://ferdinandpiette.com/


#32 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 03 mai 2016 - 02:45

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):

 

Fichier joint  13120367_10205040611449947_805905146_o.png   677,44 Ko   74 téléchargement(s)



#33 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 03 mai 2016 - 02:46

 

 

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

 

 

Sur ce graph la  ?

 

Fichier joint  Présentation sans titre.jpg   25,68 Ko   75 téléchargement(s)

 

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


Modifié par Newbies, 03 mai 2016 - 02:50 .


#34 Black Templar

Black Templar

    Membre

  • Membres
  • PipPipPipPipPip
  • 1 430 messages
  • Gender:Male
  • Location:Lille

Posté 03 mai 2016 - 04:15

 

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):

 

attachicon.gif13120367_10205040611449947_805905146_o.png

 

Dans ton exemple, tu as un obstacle à la fois à droite, à gauche et en face !

Du coup c'est la règle qui dit que tout est proche qui doit prendre le dessus et dans ce cas là, tu tournes du côté droite ou gauche en fonction de la différence de distance entre l'obstacle à droite et celui à gauche ! d'où l'intérêt de bien penser à toutes les règles !

 

 

 

 

Sur ce graph la  ?

 

attachicon.gifPrésentation sans titre.jpg

 

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

 

Tes données en entrées sont à lire sur l'axe des abscisses et le degré d'appartenance à tel ou tel variable linguistique se lit sur l'axe des ordonnées.


Mon site internet : http://ferdinandpiette.com/


#35 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 03 mai 2016 - 05:38

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 ;)



#36 Black Templar

Black Templar

    Membre

  • Membres
  • PipPipPipPipPip
  • 1 430 messages
  • Gender:Male
  • Location:Lille

Posté 04 mai 2016 - 10:03

Super ! Bien joué :)


Mon site internet : http://ferdinandpiette.com/


#37 Newbies

Newbies

    Membre passionné

  • Membres
  • PipPipPip
  • 487 messages
  • Gender:Male
  • Location:Paris
  • Interests:Programmation et robotique

Posté 12 mai 2016 - 04:21

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:

 

Fichier joint  var_ling.png   137,13 Ko   3 téléchargement(s)

 

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 ?



#38 Mike118

Mike118

    Staff Robot Maker

  • Administrateur
  • PipPipPipPipPip
  • 8 175 messages
  • Gender:Male
  • Location:Anglet
  • Interests:Robotique, Entrepreneuriat, Innovation, Programmation, Résolution de problème, Recherche de solutions, Mécanique, Electronique, Créer, Concevoir

Posté 16 mai 2016 - 05:58

 

 

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

 

 

 

c'est exactement ce qu'il faut. 

Pourquoi pense tu que ce n'est pas une bonne façon de faire ? 

 

Peut être que si tu poste une vidéo du résultat que tu obtiens ça pourrait nous aider pour t'aider =)


Si mon commentaire vous a plus laissez nous un avis  !  :thank_you:

Nouveau sur Robot Maker ? 

Jetez un oeil aux blogs, aux tutoriels, aux ouvrages, au robotscope  aux articles,  à la boutique  et aux différents services disponible !
En attendant qu'une bibliothèque de fichiers 3D soit mise en place n'hésitez pas à demander si vous avez besoin du fichier 3D d'un des produits de la boutique... On l'a peut être ! 

 

Les réalisations de Mike118  

 

 

 





0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users