Aller au contenu


Contenu de Newbies

Il y a 485 élément(s) pour Newbies (recherche limitée depuis 30-août 08)



#79692 Capteur HC-SR04 et raspberry

Posté par Newbies sur 27 février 2017 - 09:04 dans Electronique

Bon, j'ai essayé un autre capteur et j'ai refait le code en c++ par la même occasion et ca marche ! (le problème devais donc être hardware) ;)

 

Par contre j'ai remarqué que de temps en temps, le capteur sors une donnée totalement fausse ce qui peut être (très) gênant pour un drone qui repose sur ces données. Une idée d'algo pour lisser tout ca ? (pour l'instant f'ai fais le basique "prend 5 mesure, enlève le min et le max et fais la moyenne du reste" mais ca n'a pas l'air de suffire :/)




#79669 Capteur HC-SR04 et raspberry

Posté par Newbies sur 27 février 2017 - 03:17 dans Electronique

Salut Olivier17,

 

J'ai essayé avec le code que tu a posté, le resultat est le même, les valeurs sont aléatoires :/

Et oui le capteur est bien face à un mur rigide ;)




#79666 Capteur HC-SR04 et raspberry

Posté par Newbies sur 27 février 2017 - 02:01 dans Electronique

Salut les gars,

 

J'ai finalement décidé d'acheter des nouveaux capteurs pour voir si le problème venait pas de la et il y a effectivement eu du changement. En effet, j'ai branché un des nouveau capteurs avec la même configuration que l'ancien et cette fois des mesures arrivent à l'écran.

 

Le seul problème c'est que ces mesures n'ont aucun sens et apparaissent comme totalement aléatoire. J'ai donc regardé un peut plus en détail en affichant les variables dans le code et il semble que le problème viennent directement de la source, c'est à dire la durée de la pulsation qui est pas bonne, je ne comprend vraiment pas ce qu'il ce passe :/

 

Pourtant, encore une fois tout est bien branché et j'ai tout triple check :/

 

Des idées ?

 

mon code :

File Edit Options Buffers Tools Python Help                                              
import RPi.GPIO as GPIO                    #Import GPIO library                          
import time                                #Import time library                          
GPIO.setmode(GPIO.BCM)                     #Set GPIO pin numbering                       
                                                                                         
TRIG = 23                                  #Associate pin 23 to TRIG                     
ECHO = 24                                  #Associate pin 24 to ECHO                     
                                                                                         
print "Distance measurement in progress"                                                 
                                                                                         
GPIO.setup(TRIG,GPIO.OUT)                  #Set pin as GPIO out                          
GPIO.setup(ECHO,GPIO.IN)                   #Set pin as GPIO in                           
                                                                                         
while True:                                                                              
                                                                                         
    GPIO.output(TRIG, False)                 #Set TRIG as LOW                            
    print "Waitng For Sensor To Settle"                                                  
    time.sleep(2)                            #Delay of 2 seconds                         
                                                                                         
    GPIO.output(TRIG, True)                  #Set TRIG as HIGH                           
    time.sleep(0.00001)                      #Delay of 0.00001 seconds                   
    GPIO.output(TRIG, False)                 #Set TRIG as LOW                            
                                                                                         
    while GPIO.input(ECHO)==0:               #Check whether the ECHO is LOW              
        pulse_start = time.time()              #Saves the last known time of LOW pulse   
                                                                                         
    while GPIO.input(ECHO)==1:               #Check whether the ECHO is HIGH             
        pulse_end = time.time()                #Saves the last known time of HIGH pulse  
                                                                                         
    pulse_duration = pulse_end - pulse_start #Get pulse duration to a variable           
    print "pulse duration: ", pulse_duration                                             
                                                                                         
    distance = pulse_duration * 17150        #Multiply pulse duration by 17150 to get di\
stance                                                                                   
    distance = round(distance, 2)            #Round to two decimal points                
                                                                                         
    if distance > 2 and distance < 400:      #Check whether the distance is within range
        print "Distance:",distance - 0.5,"cm"  #Print distance with 0.5 cm calibration   
    else:                                                                                
        print "Out Of Range"                   #display out of range  

L'output de ce dernier avec le capteur immobile à 30 cm d'un mur:

pi@raspberrypi:~ $ python sensor.py 
Distance measurement in progress
Waitng For Sensor To Settle
pulse duration:  0.0130839347839
Distance: 223.89 cm
Waitng For Sensor To Settle
pulse duration:  0.0101339817047
Distance: 173.3 cm
Waitng For Sensor To Settle
pulse duration:  0.0245370864868
Out Of Range
Waitng For Sensor To Settle
pulse duration:  0.00531911849976
Distance: 90.72 cm
Waitng For Sensor To Settle
pulse duration:  0.0117380619049
Distance: 200.81 cm
Waitng For Sensor To Settle
pulse duration:  0.00693798065186
Distance: 118.49 cm
Waitng For Sensor To Settle
pulse duration:  0.0242590904236
Out Of Range
Waitng For Sensor To Settle
pulse duration:  0.0104739665985
Distance: 179.13 cm
Waitng For Sensor To Settle
pulse duration:  0.0102732181549
Distance: 175.69 cm




#79071 Un Noël Robotique.

Posté par Newbies sur 10 février 2017 - 10:30 dans Reventes, matériel d'occasion, récup

Bonsoir Newbies,
Si vous voulez Le Bras et pouvez venir le chercher, il est à vous.
Philippe.

Je t'ai envoyé un message privé :)




#79068 Capteur HC-SR04 et raspberry

Posté par Newbies sur 10 février 2017 - 09:42 dans Electronique

Je viens de jeter un oeil au schéma du circuit du HC-SR04, les pins TRIG et ECHO sont effectivement connectées au VCC via une résistance. Les tensions que je mesurait sur ces pins semblent donc normale.

Sinon, je viens de refaire quelques tests et les GPIOS de ma raspberry fonctionnent parfaitement, je ne comprend vraiment pas ce qui merde :/

 

Le schéma en question :

https://www.google.f...T7s9APwqwUBO0M:




#79054 Capteur HC-SR04 et raspberry

Posté par Newbies sur 10 février 2017 - 11:25 dans Electronique

Oui, les pins de la raspberry sont les bons.

Je viens d'essayer avec un autre HC-SR04 ce matin, j'ai eu exactement le même comportement :/




#79048 Un Noël Robotique.

Posté par Newbies sur 09 février 2017 - 11:59 dans Reventes, matériel d'occasion, récup

Je suis en train de mettre en place un stand pour promouvoir le club robotique de mon école, le bras mécanique pourrait donner quelque chose d'assez ludique, mais si le lot est indivisible, je se vois pas trop comment utiliser le reste :/




#79046 Capteur HC-SR04 et raspberry

Posté par Newbies sur 09 février 2017 - 11:21 dans Electronique

Salut les makers,

 

Je bosse encore sur mon projet de drone autonome et j'ai (encore) un problème. Cette fois ci c'est les capteurs. En effet, j'essai depuis hier de faire fonctionner des capteurs à ultrasons HC-SR04 avec ma raspberry mais pas moyen.

 

Ce qu'il se passe est assez étrange. Quand le capteur n'est pas branché à la raspberry, les GPIOs changent bien d'état quand le programme leur demande, mais quand le capteur est branché, les GPIOs restent à 1 et ne changent pas.

 

Autre chose bizzare (quoi que peut être normal), quand le capteur est alimenté en 5v, je mesure une tension de 5v continue sur les pins ECHO et TRIG (peut être lié au fait que je ne puisse pas changer l'état des pins quand il est branché à la raspi).

 

 

Le tuto préconisais d'utiliser un diviseur de tension pour protéger les GPIO de la raspi (5v -> 3.3v) avec une résistance de 1K et une de 2K. Je n'avais pas ces résistances sous la mains et ai donc du utiliser à la place une résistance de 22K et une de 44K, ça devrais fonctionner pareil non ?

 

Le code (python) utilisé pour mes tests: 

import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)

TRIG = 23 
ECHO = 24

print "Distance Measurement In Progress"

GPIO.setup(TRIG,GPIO.OUT)
GPIO.setup(ECHO,GPIO.IN)

GPIO.output(TRIG, False)
print "Waiting For Sensor To Settle"
time.sleep(2)

GPIO.output(TRIG, True)
time.sleep(0.00001)
GPIO.output(TRIG, False)

while GPIO.input(ECHO)==0:
  pulse_start = time.time()

while GPIO.input(ECHO)==1:
  pulse_end = time.time()

pulse_duration = pulse_end - pulse_start

distance = pulse_duration * 17150

distance = round(distance, 2)

print "Distance:",distance,"cm"

GPIO.cleanup()

Des idées ?




#79042 Quadcopter RaspberryPi et Naze32

Posté par Newbies sur 09 février 2017 - 10:48 dans Drone, Robot volant, et autres machines volantes

Salut,

 

Oui j'ai pas mal avancé, j'ai finalement réussi à dialoguer avec la naze32 depuis la raspi via le port série (protocole mutliwii). Maintenant j'ai un problème avec les capteurs mais je pense refaire un post dans la bonne section pour ca ;)




#78808 Créer un arbre en c

Posté par Newbies sur 02 février 2017 - 09:06 dans Programmation

La meilleure façon de faire un algo de recherche dans un arbre est d'utiliser la récursivité (rappeler la fonction dans laquelle on se trouve). 

 

Par exemple, pour afficher tout les éléments de ton arbre à partir de l'élement en bas à gauche, tu peux écrire la fonction récursive suivante:

bool print_tree(struct *leaf) {
  if (!leaf)
    return (false);
  print_tree(leaf->left);
  printf("data : %s\n", leaf->data);
  print_tree(leaf->right);
}



#78807 Quadcopter RaspberryPi et Naze32

Posté par Newbies sur 02 février 2017 - 08:50 dans Drone, Robot volant, et autres machines volantes

Salut les gars,

 

Je suis en train de bosser sur un projet de quadcopter intelligent mais je bute déjà sur un problème.

En effet mon drone est pour l'instant piloté uniquement par une carte contrôleur de vol naze32. Cette carte marche vraiment nickel et stabilise le drone à la perfection, en revanche, elle ne sait faire que ça.

 

L'idée est donc de laisser le rôle de la stabilisation à la naze32 mais d'y connecter une raspberryPi zero afin de pouvoir rendre le drone "intelligent" ( un algo de reconnaissance faciale tournera sur la pi).

 

La question est donc, quels solutions s'offrent à moi pour connecter une raspberrypi à une naze32 ?

 

J'ai d'abords pensé simplement faire passé la raspberry pour un récepteur RC en envoyant des signaux PWM à la naze32 mais cela ne permet pas un réel dialogue entre les deux cartes.

 

J'ai crus voir quelque part sur ce forum quelqu'un disant qu'il avait connecté sa raspberry au port série de la naze32 mais je n'ai rien trouvé sur internet par la suite sur comment faire ça.

 

L'idée de connecter ma raspberry au port série de la naze32 me plait car cela voudrait aussi surement dire que je pourrait récupérer les données des capteurs de la naze32 pour mon algo sur la raspberry.

 

Quelqu'un à déjà fait ça ? Et si oui comment ? :)

 

merciii




#69954 algo pour lidar 32 points de mesures

Posté par Newbies sur 12 mai 2016 - 04:21 dans Programmation

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:

 

var_ling.png

 

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 ?




#69684 algo pour lidar 32 points de mesures

Posté par Newbies sur 03 mai 2016 - 05:38 dans Programmation

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




#69677 algo pour lidar 32 points de mesures

Posté par Newbies sur 03 mai 2016 - 02:46 dans Programmation

 

 

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

 

 

Sur ce graph la  ?

 

Présentation sans titre.jpg

 

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




#69676 algo pour lidar 32 points de mesures

Posté par Newbies sur 03 mai 2016 - 02:45 dans Programmation

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

 

13120367_10205040611449947_805905146_o.png




#69673 algo pour lidar 32 points de mesures

Posté par Newbies sur 03 mai 2016 - 01:51 dans Programmation

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




#69670 algo pour lidar 32 points de mesures

Posté par Newbies sur 03 mai 2016 - 12:04 dans Programmation

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 :

 

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

 

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




#69659 algo pour lidar 32 points de mesures

Posté par Newbies sur 03 mai 2016 - 10:14 dans Programmation

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




#69649 algo pour lidar 32 points de mesures

Posté par Newbies sur 02 mai 2016 - 10:00 dans Programmation

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




#69648 algo pour lidar 32 points de mesures

Posté par Newbies sur 02 mai 2016 - 09:50 dans Programmation

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




#69645 algo pour lidar 32 points de mesures

Posté par Newbies sur 02 mai 2016 - 08:04 dans Programmation

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




#69640 algo pour lidar 32 points de mesures

Posté par Newbies sur 02 mai 2016 - 05:54 dans Programmation

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




#69622 algo pour lidar 32 points de mesures

Posté par Newbies sur 02 mai 2016 - 11:21 dans Programmation

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




#69621 algo pour lidar 32 points de mesures

Posté par Newbies sur 02 mai 2016 - 11:06 dans Programmation

Bon, j'ai implémenté un début de logique floue (avec les variables et les règles cité précédemment ), ça marche dans certain cas (quand la voiture est dans une ligne droite, elle va bien tout droit), et revanche ça déconne dans d'autres (quand la voiture arrive dans un virage, elle braque trop fort dans la direction du virage :/)

 

J'ai essayé de modifier un peut les fonctions d'appartenances et les calcules mais le problème subsiste (le cas du virage). En fait le problème est que je n'arrive pas à trouver de coïncidence entre la distance mesurée à l'entrée dans un virage et l'angle de ce virage :/

 

J'ai aussi un problème avec la position de mes capteurs, étant donné qu'ils vise tous vers l'avant, quand le robot fonce droit vers un mur, il est impossible de déterminer dans quel sens le faire tourner :/




#69607 algo pour lidar 32 points de mesures

Posté par Newbies sur 01 mai 2016 - 07:54 dans Programmation

Ok, je comprend mieux.

 

Du coup, la fonction d'appartenance à l'orientation aura 3 variables linguistiques : gauche, centré, droite.

Et si tu veux modéliser ça part du tout ou rien comme je l'ai fait dans mon exemple, gauche sera un dirac en -1, milieu, un dirac en 0 et droit, un dirac en 1 (et non en 0, 0.5 et 1).

 

Je vais essayer d’implémenter ça ce soir ;)

 

 

Ah, la logique floue ... L'art de faire du symbolique mais pas trop. :)

Si je comprends bien ton problème, tu cherches une manière de connecter ton capteur à tes moteurs pour commander ta voiture. Vu que ton objectif est une réponse rapide aux obstacles, tu dois avoir une approche réactive (donc pas de SLAM, de planif dans une carte).
L'approche la plus simple, c'est le véhicule de Braitenberg. Tu connectes tes mesures directement aux commandes avec un coefficient positif ou négatif qui indique comment la mesure influe sur la commande. C'est assez simple avec une commande différentielle, un peu moins trivial avec ton type de commande.
L'extension naturelle de la logique de Braitenberg, c'est effectivement le réseau de neurones (Braitenberg étant une version simplifiée). L'intérêt du réseau, c'est que tu as une règle d'apprentissage qui adapte les valeurs aux expériences qu'a vécu le réseau (donc les différents circuits dans lequels tu auras entraîné la voiture).

De mon point de vue, la logique floue n'est pas adaptée : tu n'as pas besoin de raisonner sur des symboles (ce que tu appelles variables lnguistiques), tu as besoin de déterminer des commandes (angle de ta direction, vitesse de ta propulsion) qui sont continues.

 

J'étais tombé par hasard dans mes recherches sur les "vehicules de Braitenberg", et apparemment l'utilisation de cette technique se limite à des cas précis qui n'était pas compatible avec ce qu'on nous demandais :/