Ca viendra, un peu de patience

C'est déjà là depuis pas mal de temps
http://goo.gl/maps/R0Lg

Je parle d'une map sous R-M. La localisation dans le profil existe déjà.

Lier la localisation profil profil avec un Google Map ? ça serait cool

Wooo />
Je suis bluffé par ton prototype !
Vraiment bravo.

merci sa avance doucement oui le carton fragile mais très bien pour travailler

Avec le polystyrène entre le carton, ça doit bien renforcer la structure non ?

Je n'aime pas Youtube , mais je comprends très bien ton problème d'hébergement.

Après, tu peux très bien l'héberger sur ton serveur perso

Salut maxe.

Lorsque les deux moteurs tournent dans le même sens, le robot se déplace en ligne droite ! Fais un dessin si tu as du mal à comprendre

++
Black Templar

c'est encore bien du Apple!

... ... ...

Salut et bienvenue à toi !

Je n'ai pas réalisé de quadricoptère, mais je me suis pas mal renseigner sur ces bestioles.
Pour les brushless, j'ai souvent lu que ça devait tourner à environ 1000KV (donc 890, ça ne m'a pas l'air trop mal )

++
Black Templar

Une petite question : 1000KV ou 890KV ça signifie quoi ? Parce que moi je connais les KiloVolts (KV) mais ça m'étonnerai que ça soit çà.

Petite recherche google ?
Premier lien

C'est le nombre de tours du moteur par minute pour une tension d'alimentation de 1V.
L'intérêt de ne pas prendre un moteur avec trop de Kv pour faire un drone, c'est que du coup, le couple est plus fort et tu peux donc soulever plus lourd.


++
Black Templar

Salut !

Je n'ai jamais utilisé ce capteur, mais si ton alimentation oscille de trop, ça pourrait expliquer ce problème. (Par exemple, si tu as mis ce capteur sur ton robot et que tu fais tourner les moteurs en même temps, il peut y avoir des perturbations. Ou alors si tu alimentes arduino via le port USB et que le courant tiré est supérieur à 500mA.)

++
Black Templar

Bonjour !

Je viens de retrouver l'article dont je parlais !!
En fait, il s'agit d'une discussion par mail d'un étudiants en math sup/spé et d'un chercheur à l'INSA qui a réalisé une installation de chauffage en couplant les réseaux de neurones à de la logique floue.
Ce mail se trouve à la fin de son dossier de TIPE sur la prévision de température par réseau de neurones. Le dossier en lui-même ne parle que de réseau de neurones, (une petite partie à la fin (3.3.1) introduit brièvement la régulation floue). Par contre, le mail parle de méthode d'adaptation des règles d'inférences grâce à un réseau de neurone. Peut-être une piste pour ton PID floue auto-adaptatif

Le mail est à la page 37/48 : http://crteknologies.fr/projets/tipe_reseaux_neuronaux/dossierTIPE.pdf


Sinon, j'ai en effet sous les yeux un exemple de régulateur flou qui, malgré la finesse des réglages offre de bonnes performances. Ce sont des slides que je n'ai malheureusement pas le droit de distribuer. Par contre, je me suis lancé dans la rédaction d'une série de trois ou quatre articles sur mon blog à propos de la logique floue illustrés avec quelques exemples (planification floue c'est sur et PID floue un peu plus tard si j'arrive à bien en comprendre le principe). Je mettrais le lien d'ici quelques semaines quand j'aurais fini.

++
Black Templar

Et bien, comme je le dis depuis deux posts, dans le tuto v2, tu peux remarquer l'ajout de deux potentiomètres qui te permettent de régler la puissance de chaque moteur indépendamment ! Du coup, tu n'as plus qu'à ajuster chaque potentiomètres pour que le robot aille en ligne droite.
ça règle donc ton problème.

++

Ensuite, si le robot dévie et ne fait pas parfaitement une ligne droite, tu peux rectifier ça grâce aux deux potentiomètres !

http://www.robot-maker.com/forum/tutorials/article/9-cocotix-v2/

Salut !
Tes deux moteurs doivent tourner l'un dans le sens horaire et l'autre dans le sens trigo si tu veux que le robot avance plutôt qu'il ne tourne en rond ! Essaye d'inverser l'un de tes moteurs pour voir.

Ensuite, si le robot dévie et ne fait pas parfaitement une ligne droite, tu peux rectifier ça grâce aux deux potentiomètres !

++
Black Templar

C'est cette phrase la clé du malentendu . J'avais bien compris qu'il y avait un truc à faire avec des potentiomètres mais comme je suis un grand débutant ( d'où la section que j'ai choisi ^^ )et donc un peu boulet , je cherchais dans mon circuit où il y avait des potentiomètres , j'avais pas compris que c'étaient des éléments à ajouter .

Soit dit en passant, je pensais au début que tu avais fais la version 2 du robot :-°

Bonjour,

J'ai déjà utilisé de la logique flou mais pas pour l'asservissement des moteurs. Plutôt pour la planification de trajectoire.
La méthode est assez intuitive et permet d'obtenir des mouvements fluides. L’inconvénient, c'est que c'est justement peut être trop 'intuitif' et pas assez 'mathématiques'.
En logique flou, tu peux customiser tout un tas de paramètres (tes fonctions d'appartenances, tes opérateurs logiques, etc.) Du coup, pour l'asservissement, il me semble que ça en fait une méthode assez adhoc qui ne permet pas d'obtenir les performances d'un PID. EDIT : Apparemment, si, avec de bon réglage, on arrive à de bonnes performances

Oui, d'après ce que j'ai lu, il y a des experimentations à mener pour régler les bornes des différentes classes d'appartenance au départ mais d'après ce que j'ai compris après c'est auto-adaptatif.

(*warning*) Non, ce n'est pas auto adaptatif. Une fois que tu as fixé tes fonctions d’appartenances et choisi tes opérateurs, l'algorithme n'apprendra pas. Il ne s'adaptera même pas. C'est un algorithme déterministe : pour deux entrées identiques, l'algorithme te calculera deux fois exactement la même sortie et ce, quelque soit le modèle de ton système !!!! (*warning*)



Le principe des systèmes flous, c'est de choisir des grandeurs d'entrées (distance à un obstacle pour la planification de trajectoire par exemple) et de les transformer en variables linguistiques (il faut transformer distance = 10.3 en distance = grand 0%, moyen 20%, petit 60% par exemple à l'aide de fonctions d'appartenances que tu auras toi même choisi).
Ensuite, tu fais tout un tas de calcul avec tes variables linguistiques (tu dresses toi même les règles du jeu (règles d'inférences) de façon intuitive : si la distance est grande, freiner peu fort, si la distance est moyenne, freiner moyennement fort, si la distance est faible, freiner très fort)
Une fois que tu as calculer toutes les règles, tu obtiens tes variables linguistiques de sorties (freiner peu fort 0%, freiner moyennement fort 15%; freiner très fort : 80%)
Il te suffit de "defuzzifier" tes variables linguistiques de sorties pour obtenir la valeur effective de freinage.


Après les avantages, c'est que t'es pas obligé de modéliser ton système, tu peux utiliser tes connaissances pour faire marcher le système de façon intuitive. Par contre, les inconvénients sont que tu doit tout régler de façon totalement adhoc. Tu n'as aucun moyen ni aucune méthode te permettant de trouver les réglages optimaux. Tu ne peux pas prouver que ton système sera stable. La précision du réglage est souvent très faible.


Je parle rapidement de la logique flou appliqué à la planification de trajectoire dans un de mes articles de mon site : http://www.ferdinand...f-etat-de-lart/
Je ne sais pas si ça peut t'aider un petit peu...


++
Black Templar

Il n'y a pas sue fu faux danx mon expmication non ?

Disons que le signal de commande du pont en H est bien un signal crénaux.
Par contre, après le pont en H, la tension (de puissance) est lissé par le filtre passe bas du pont en H + moteur. La tension n'a donc plus une forme de crénaux mais tend à être plus ou moins moyenné. (c'est d'ailleurs sur ce principe de moyennage d'un signal PWM que fonctionne les ampli de classe D : un signal PWM à rapport cyclique variable encode un signal audio. Le signal PWM commande un haut parleur via un pont en H !)

Par contre, si tu mesures la tension en créneaux de ton signal PWM directement avec un voltmètre, celui-ci te le moyennera (tu ne verras pas les fluctuations, mais la tension moyenné). Pour voir le signal PWM, il faut utiliser un oscillo.
Je t'invite à faire l'expérience par toi-même.



++
Black Templar

Comme promis, voilà les articles : http://www.ferdinand...-logique-floue/

- Le premier donne une vue d'ensemble de la logique floue (avantages, inconvéniants, domaines d'applications etc.)
- Le second explique le fonctionnement d'un système flou (fuzzification, moteur d'inférence, défuzzification, opérateurs, etc.)
- Le troisième est un exemple de planificateur de trajectoire flou pour robot
- Le dernier est un exemple de PI flou (je ne suis pas satisfais de la façon dont je l'ai écrit, je le réécrirais peut-être d'ici noël en y incluant des simulations et l'influences des paramètres sur la réponse, mais là, je n'arrive plus à écrire )


Pour ce qui est de la création d'un PID flou qui s'optimise automatiquement, finalement, en cherchant sur le net, on trouve pas mal de choses intéressantes ! (bien souvent à base d'algo génétique)

• Supervision Neuro-flou à apprentissage génétique d'un PID robuste (Soukkou 2005)
• Tuning of a neuro-fuzzy controller by genetic algorithm (Teo Lian Seng 1999)
• Designing Fuzzy Net Controllers using Genetic Algorithms (Jinwoo Kim 1995)

Voili voilou !
++
Black Templar

Hello Black,

Merci pour ces infos.

C'est bien noté pour le non auto-adaptatif. J'avais lu que c'était possible dans cette présentation: http://auto.polytech.univ-tours.fr/automatique/AUA/ressources/Application_commande_floue.ppt, page 6. Mais si tu l'as experimenté tu sais de quoi tu parles.

J'ai lu le début des slides et je ne vois pas ce qu'ils veulent dire par auto adaptatif... En régulation flou classique, si on veut asservir un système, le système sera asservi, quelque soit les variations "industrielle" du système. Par contre, les performances ne seront clairement pas les mêmes... donc l'auto-adaptivité, je ne vois pas où...
Après, il existe peut-être modification à apporter à la régulation flou pour la rendre auto-adaptative, mais je n'en ai jamais entendu parlé...
EDIT : Je viens d'avoir un flash ! Je me rappelle avoir lu un article (non scientifique) qui faisait une comparaison entre la régulation flou et les réseaux de neurones (sur les avantages et inconvénients de ces deux méthode pour une application spécifique il me semble)... Je ne me rappelle plus où j'ai vu ça, ni de quoi ça parlait exactement, mais c'est peut être une piste pour l'aspect auto-adaptatif... je vais essayer de retrouver l'article (même si j'ai aucune idée de où j'ai lu ça :/)

Je crois que la complexité de la logique floue est de modéliser et définir toutes les règles nécessaires pour que le système fonctionne. Il doit falloir s'y prendre à plusieurs fois.

Oui, les règles d'inférences ne se trouvent pas du premier coup. Il faut construire un set de règles de bases "au feeling" puis les modifier petit à petit de façon ahdoc pour augmenter les performances et la réactivité.

Certains processeurs proposent des prédispositions à la logique floue comme le 68HC12. en ce qui te concerne, tu as implémenté ta solution sur quel type de processeur ? OS ?

Oui, j'ai lu qu'à une certaine période, certain microcontroleur dédiés à la logique flou sont sortis. Je n'en ai jamais testé, mais apparemment, l'architecture est étudiée pour. Mais bon, ça ne dispense en rien de trouver toi même tes fonctions d'appartenances, tes règles d'inférences et de choisir les opérateurs adaptés à ton cas.
Personnellement, j'ai implémenté mon planificateur flou en C++ sur un linux embarqué (j'ai aussi testé le planificateur en utilisant directement le PC sur le robot). ça se programme facilement, même en C (il suffit de programmer une fonction par règle d'inférence et une fonction par fonction d'appartenance (voir une fonction par opérateur s'ils sont complexes)).
Et à mon avis, (je n'ai pas testé, mais j'en suis presque sur), ça tournera largement sur un microcontroleur classique, même basique ! (du moment que tu n'ai pas des centaines de règles d'inférences )

++
Black Templar

Concernant l'article: Algorithmes de planification de trajectoires : bref état de l'art
- Je rajouterais la méthode mathématiques des clothoïdes qui sont des b-splines très utilisées dans ce domaine, que j'ai personnellement utilisé après m'être cassé la tête sur des calculs de trajectoires à base de polynômes à je ne sais plus combien de degrés.

Aurais-tu un article ou un papier sur lequel tu t'es basé pour comprendre l'algorithme ?
Sinon, l'algorithme de Mickael Deffort utilise des B-splines pour générer sa trajectoire. J'ai expliqué le principe de l'algorithme avec des polynômes à la place des splines pour simplifier (mais le principe reste le même) dans la partie planification par juxtaposition de splines polynomiales.

Et bien dommage pour:

Sinon, j'ai en effet sous les yeux un exemple de régulateur flou qui, malgré la finesse des réglages offre de bonnes performances

J'ai repris cet exemple dans le quatrième article bien que je n'aime pas la façon dont le l'ai écrit...
D'ailleurs, j'ai utilisé l'erreur et la variation de l'erreur pour calculer la variation de la commande comme dans les slides que je n'ai pas le droit de distribuer. J'aurais tout aussi bien pu utiliser l'erreur et la somme des erreurs pour déterminer la commande directement, ça reviendrait au même !

Merci encore et je ferais un retour sur mes lectures et expérimentations en cours.

Merci

Black Templar