Salut ! Pas mal cette notion de croyance, mais surement difficile à transcrire en code^^
Pour l'exemple que tu as pris avec le jour, difficile de différencier la lumière du jour et celle d'une pièce éclairée, et comment verrifier si il est à l'interieur ou à l'exterieur..?
On pourrai voir ça autrement, SRWieZ parlait d'une horloge tout à l'heure :
-Le robot se trouve dans une pièce trés sombre
-Il intéroge son horloge qui lui renvoie 13h
-Donc il déduit que c'est pas la nuit
-Il s'éclaire et continue normalement

-l'horloge lui renvoie 23h
-Il déduit que c'est la nuit
-Il s'éclaire et cherche un coin pour se mettre en veille

Ou alors.. la croyance rejoind la probabilité : C'est qqch qui n'est pas sur.
On pourrait dire :
-Le capteur gauche indique qu'il y a qqch de proche à gauche
-Idem pour la droite
-Idem pour le capteur avant
-> La probabilité que le robot soit dans un cul de sac devient donc grande,
-Il croit qu'il est dans un cul de sac donc il fait demi-tour

Enfin c'est qu'un exemple, dans ce cas il faudrait qu'il fasse des actions pour verrifier que ce soit bien un cul de sac, sinon il aurait trop de chance de se tromper..

Salut ! Pas mal cette notion de croyance, mais surement difficile à transcrire en code^^

Oui, ça reste à un niveau de recherche tout ces concepts, pour le moment.
Mais si tu veux le transcrire en code, regarde un peu la programmation orienté agents ! c'est déjà une bonne base pour implémenter des concepts tels que les croyances et les buts.

Pour l'exemple que tu as pris avec le jour, difficile de différencier la lumière du jour et celle d'une pièce éclairée, et comment verrifier si il est à l'interieur ou à l'exterieur..?
On pourrai voir ça autrement, SRWieZ parlait d'une horloge tout à l'heure :
-Le robot se trouve dans une pièce trés sombre
-Il intéroge son horloge qui lui renvoie 13h
-Donc il déduit que c'est pas la nuit
-Il s'éclaire et continue normalement

Oui, ton horloge, ça sera en quelque sorte ton capteur.
Mon système de croyances/but vient au dessus de tout ça ! Ce n'est pas ce système qui va te dire comment récupérer l'information, mais plutôt si cette information est contradictoire ou non avec toute les autres. Si ton horloge est cassé ou renvoi des infos erronées, c'est le systèmes à base de croyances et de buts qui te permettra de t'en rendre compte car il y aura des informations contradictoires.

Ou alors.. la croyance rejoind la probabilité : C'est qqch qui n'est pas sur.
On pourrait dire :
-Le capteur gauche indique qu'il y a qqch de proche à gauche
-Idem pour la droite
-Idem pour le capteur avant
-> La probabilité que le robot soit dans un cul de sac devient donc grande,
-Il croit qu'il est dans un cul de sac donc il fait demi-tour

Enfin c'est qu'un exemple, dans ce cas il faudrait qu'il fasse des actions pour verrifier que ce soit bien un cul de sac, sinon il aurait trop de chance de se tromper..

Oui, dans ce cas, tu as des croyances : "il y a quelque chose à droite", "il y a quelque chose à gauche", "il y a quelque chose devant".
Tu as un système de déduction logique et tu lui rentre la règle : "il y a quelque chose à droite" et "il y a quelque chose à gauche" et "il y a quelque chose devant" implique "on est dans un cul de sac"

Tu donnes à ta couche de gestion de but : si tu essayes d'exécuter tel but et si tu es dans un cul de sac, alors abandonnes ce but ou bien adoptes un autre but, ou bien met le but courant en attente, etc.

Si ton horloge est cassé ou renvoi des infos erronées, c'est le systèmes à base de croyances et de buts qui te permettra de t'en rendre compte car il y aura des informations contradictoires

Mais ces croyances dont tu parles elles sont basées sur ce que le robot capte non ?
Par exemple :
D'une part
-L'horloge indique 23h
D'autre part
-Le micro indique qu'il y a pas mal de bruits
-La photorésistance indique que c'est éclairé
-etc
Donc il déduit que l'horloge est peut etre HS -> il l'a néglige ou lui accorde peu d'importance.

J'imagine bien tout ça avec une histoire d'incrémentation, plus la valeur est grande plus la donnée est importante ^^

Pour être sûr que je suit bien la conversation, j'aurais juste une question.

Tes capteurs te renvoient des données de types numériques (distances, luminosité, etc.) Ensuite, ton programme doit venir traiter ces données pour extraire des données symboliques (carte de la pièce, il fait jour, nuit, etc.)

Est-ce que cette image : http://www.ladyada.n...mpletestout.gif (tiré d'ici : http://www.ladyada.n...ensors/cds.html ) représente bien la phrase de Black Templar ?

Pour être sûr que je suit bien la conversation, j'aurais juste une question.


Est-ce que cette image : http://www.ladyada.n...mpletestout.gif (tiré d'ici : http://www.ladyada.n...ensors/cds.html ) représente bien la phrase de Black Templar ?

Erreur 404

Euh étrange, j'ai vérifié, pas d'erreur.
Par doute je te la met quand même ici, mais je t'assure mes liens fonctionnent.

Euh étrange, j'ai vérifié, pas d'erreur.
Par doute je te la met quand même ici, mais je t'assure mes liens fonctionnent.

Ne marchent pas chez moi.
Sinon, ça, c'est un peu simpliste, mais oui, c'est la base.

Normalement, c'est tout de même plus compliqué que ça, dans le sens ou tu es souvent obligé de recouper des données de capteurs différents afin de générer ta donnée symbolique.
Bien souvent, ta donnée symbolique te donne une vision plus globale de l'environnement que ce que te fournit tes capteurs.
Par exemple, un capteur US qui te donne une donnée en distance, toi, tu recouperas plusieurs infos pour générer une donnée symbolique qui est par exemple, l'emplacement et le diamètre d'un obstacle.
A partir d'informations bas niveau de distance, tu as su généré une donnée symbolique qui représente un obstacle avec ses caractéristiques (chose que ne te donnera jamais un capteur simple ^^)

Ne marchent pas chez moi.
Sinon, ça, c'est un peu simpliste, mais oui, c'est la base.

Normalement, c'est tout de même plus compliqué que ça, dans le sens ou tu es souvent obligé de recouper des données de capteurs différents afin de générer ta donnée symbolique.
Bien souvent, ta donnée symbolique te donne une vision plus globale de l'environnement que ce que te fournit tes capteurs.
Par exemple, un capteur US qui te donne une donnée en distance, toi, tu recouperas plusieurs infos pour générer une donnée symbolique qui est par exemple, l'emplacement et le diamètre d'un obstacle.
A partir d'informations bas niveau de distance, tu as su généré une donnée symbolique qui représente un obstacle avec ses caractéristiques (chose que ne te donnera jamais un capteur simple ^^)

Je comprends peut-etre mal ton explication, une donnée symbolique c'est l'interprétation d'une donnée "bas niveau" ? Dans ce cas ce serait ce que l'on fait à chaque fois que l'on programme une réaction en fonction d'un retour du capteur, non ?

Je comprends peut-etre mal ton explication, une donnée symbolique c'est l'interprétation d'une donnée "bas niveau" ? Dans ce cas ce serait ce que l'on fait à chaque fois que l'on programme une réaction en fonction d'un retour du capteur, non ?

Une donnée symbolique, c'est une information de haut niveau qui va venir décrire ton environnement.
Ce n'est pas une réaction, car une réaction, c'est juste une action. Si tu dis : "mon capteur détecte quelque chose à gauche, tournes à droite", alors tu as programmé un comportement réactif, sans aucune donnée symbolique.

Les données symboliques vont te permettre de programmer des comportements, non plus réactifs, mais cognitif : ton robot va être capable de rassembler des informations haut niveau sur l'environnement qui l'entoure, et donc, à partir de là, il va pouvoir raisonner dessus.


ça va comme explication ?? :s
Black Templar

Une donnée symbolique, c'est une information de haut niveau qui va venir décrire ton environnement.
Ce n'est pas une réaction, car une réaction, c'est juste une action. Si tu dis : "mon capteur détecte quelque chose à gauche, tournes à droite", alors tu as programmé un comportement réactif, sans aucune donnée symbolique.

Les données symboliques vont te permettre de programmer des comportements, non plus réactifs, mais cognitif : ton robot va être capable de rassembler des informations haut niveau sur l'environnement qui l'entoure, et donc, à partir de là, il va pouvoir raisonner dessus.


ça va comme explication ?? :s
Black Templar

Oui en effet introduir la raison dans un programme est bien de "haut niveau"^^ un tel programme doit contenir énormément de variables et une mémoire. Je dirais meme qu'il devrait avoir des variables "vierges" qu'il piocherait pour l'assigner à qqch.. et ensuite le programme devrait prendre en compte cette nouvelle variable dans sa structure... ca devient dur à imaginer!

Salut

super interressant!


ce type de programmation est il possible sur (voir 2) Arduino? ça engendre pas mal d'etape avant Action ? Non ? ca devrais peuser lourd sur les epaule de l'arduino!

il aura nécéssité de cartographier le lieu

exemple: il detecte qu'il fait froid et son but (du moment) est d'etre au chaud,

• si il n'aura pas cartographier, il va se balader dans tout les sens avant de trouver un point chaux ,
• alors que si il cartographie, non seulement il iradirectement vers LE point chaud mais il pourra (au long de ces differents deplacement) répertorier tout les coins chaud et trouver le plus chaud pour y coulé une sieste du tonnerre!

mais le fond de l'exercice m'interresse je suis ça de pret !


Pour revenir sur l'hardware, ton robot aura il un systeme de chagre? car la aussi la carto serait interressante !



A+

Salut.
Oui pourquoi pas le faire diriger vers son point de charge ^^ il faudrait utiliser le shield GPS d'arduino et assigner des coordonnées GPS a un objet ou un lieu. Ca pourrait servir pour beaucoup de comportements! Je pense que des programmes comme ceux la sont possibles sur l'arduino, faut juste trouver comment l'écrire et bien les organiser^^

Salut.

Ton programme va devoir avoir plusieurs couches. La première sera la couche matérielle; celle qui te donnera les résultats des capteurs (du genre "luminosité à gauche = 35"). La seconde sera une couche symbolique; qui transformera ces données physiques en données symboliques, comme dit plus haut (du genre "il fait jour"). Il te faudra au moins une troisième couche, décisionnelle. C'est celle-ci qui déterminera le but actif. (Comme il fait jour et que mes batteries faiblissent, je décide de faire la sieste au soleil). Et encore une 4ème couche, applicative (quelles actions élémentaires correspondent à cette décision ?)

D'une manière générale, plus tu ajoutera de couches abstraites (par exemple, un niveau 3,5 "prévisionnel", ou un niveau 2,5 de "mémoire"), plus ton robot sera "intelligent".

La première couche est facile à faire, elle est linéaire, la seconde est déjà plus complexe. Est-ce que tu veut faire un apprentissage ou est-ce que tu veut coder en dur la détermination de symboles ? Coder en dur est beaucoup plus facile, mais cela introduit un énorme biais dans l'intelligence, c'est ton analyse qui déterminera beaucoup de choses. La troisième couche, ben.... à toi de choisir le système de décision, un système expert (ensemble de règles dont l'ordonnancement est déterminé par apprentissage) ça peut être pas mal pour un début (un système de but par fonction objectif globale ne te mènera à rien d'intéressant, il n'y aura aucune "intelligence"). Et la 4ème couche ? À peu près comme la seconde plus la première, dans l'autre sens.

Si tu sépares bien tes couches, tu pourra quand tu aura un résultat changer le contenu de l'une d'elle indépendamment des autres pour améliorer ton robot. C'est pas forcément évident à faire au début mais tu y gagnera beaucoup plus tard.

Enfin, un des problèmes à résoudre c'est comment partager le temps d'exécution de ton proc entre les différentes couches. Si tu peut faire un thread ou un processus par couche, ce sera bien. (Je n'y connait rien en robotique, je ne sais pas ce qu'il est possible de faire au niveau du multithreading, mais presque tout les langages gèrent ça maintenant en info, donc j'imagine que ça devrait pas être un problème).

Et pour finir, le dernier problème : comment vas tu faire communiquer tes couches entre elles ? Un système de mémoire des résultats internes des couches, écrites par la couche n et lus par la couche n+1, me parait pas mal, mais y'a certainement d'autres solutions.

Bon courage, y'a du taf....

Salut ! Oui y'a du taf, mais c'est vachement intéressant à faire.
Pourquoi faire un traitement par couche, ca permetterait de bien ordonner le programme !
J'aimerai coder en "dur" pour pouvoir fixer moi meme son comportement général, mais aussi lui donner un système d'apprentissage.
Par exemple, lorsqu'il est retourné, lui faire mémoriser quelles combinaisons de gestes lui ont permis de se remettre à l'endroit, etc.
Le problème c'est comment lui faire apprendre, c'est à dire ajouter qqch de nouveau à la structure du programme..
Peut etre en créant des tas de variables et fonctions vièrges, le tout triés par catégories.

Exemple, catégorie de mouvement ( donc utilisation de servomoteurs) :

fonction1 void()
 servoA.write(x);
 servoB.write(y);
 delay(z);
 etc..;

Le robot voit que la fonction1 est libre et il assigne à x, y et z les valeurs testées et qui ont fonctionné.
On pourrait aussi imaginer des sous-catégories par nombre de servo utilisés etc.

Et aussi lui introduire l'oublie :
Losque qu'il n'y a plus de fonctions vierges, il efface celle la moins utilisée et la moins importante.
Il verrait ça avec un système à 2 incrémentations: pour l'importance et pour la fréquence d'utilisation.

Enfin bon, l'idée de fonctions vièrges etc est surement améliorable, faut voir.

Pour le partage de taches j'en ai aucune idée.
Je vais déja remplacer mes "delay" par le système similaire qu'on retrouve dans "BlinkWithoutDelay" dans les exemple sur le logiciel; apparement c'est pour éviter que le programme attende la fin du delay pour lire les lignes suivantes, non ??
Sinon je n'ai pas d'autre piste.

Et pour la communication entre les couches, pourquoi pas la faire avec des variables :
La couche 1 inscrit tel valeur dans la variable V
La couche 2 lit a valeur de V, et traite l'info

Aprés faut chercher d'autres méthodes et voir laquelle serait la plus éfficace^^

J'aimerai coder en "dur" pour pouvoir fixer moi meme son comportement général, mais aussi lui donner un système d'apprentissage.

Fais toutes les couches en dur, sans apprentissage, puis quand tu aura un programme fonctionnel complet, remplace le codage en dur d'une des couches par de l'apprentissage.

Le problème c'est comment lui faire apprendre, c'est à dire ajouter qqch de nouveau à la structure du programme..
Peut etre en créant des tas de variables et fonctions vièrges, le tout triés par catégories.

Pour faire de l'apprentissage automatique, il te faut une structure rigide de contrôle (exemple A réseau de neurone : une matrice de connexions (synapses) entre différentes cases (neurones) – exemple B algos génétiques : un ensemble des bouts de code élémentaires prédéfinis (des gènes) dans une population d'individus limitée) dans laquelle certaines choses vont évoluer (exemple A : les pondérations des synapses, plus leur poids est fort, plus elle transmettrons l'excitation de leurs neurones en amont à leurs neurones en aval – exemple B : le programme (ou l'adn) de chaque individu, c'est à dire l'ordre dans lequel vont êtres exécutés ces bouts de codes et les structures entre elles (tests, boucles, etc.)).

Dans cette structure rigide définie, ces composants évolutifs vont être "dirigés" alternativement par 2 choses : l'exploration (on change au hasard) et on évalue l'amélioration du résultat, et le renforcement (on reteste ce qui a déjà fonctionné plus tôt, éventuellement avec des modifications minimes, et on évalue l'amélioration du résultat. Dans les 2 cas, il faut évaluer le résultat (donc il faut une fonction d'évaluation, de satisfaction ou quelque chose qui s'y assimile) et en fonction de ce résultat on oriente en retour les prochains renforcements (exemple A : on augmente les poids des synapses utilisées quand le retour est positif – exemple B : on privilégie la reproduction des individus performants).

Ça a ses limites, à savoir : la rigidité de la structure de contrôle, dont on fixe arbitrairement la taille et la forme, la difficulté de doser la part d'exploration par rapport à la part renforcement, et la complexité de la pertinence de la fonction d'évaluation.

Et aussi lui introduire l'oublie :

C'est intégré : (exemple A : avant chaque passage, le poids de chaque synapses est rapproché de zéro de manière infime, afin que la somme des poids des synapses soit constante après altération des poids – exemple B : le nombre d'individus étant constant, pour créer de nouveaux ADN, il faut se défaire d'anciens, les moins efficaces). Il ne peut pas y avoir "apprentissage" sans une forme d'"oubli". Après, si tu parles d'oubli volontaire de solutions efficaces, pour introduire une propension à l'erreur/créativité, c'est un autre problème bien plus complexe encore. Je te déconseille de t'y arrêter pour l'instant...

Pour le partage de taches j'en ai aucune idée.
Je vais déja remplacer mes "delay" par le système similaire qu'on retrouve dans "BlinkWithoutDelay" dans les exemple sur le logiciel; apparement c'est pour éviter que le programme attende la fin du delay pour lire les lignes suivantes, non ??
Sinon je n'ai pas d'autre piste.

Et que fait le programme selon toi en attendant ? C'est exactement ça (le principe, hein, je ne sais pas quel langage tu utilise). Il laisse alors la main à d'autres processus (ou threads). Ceux du programme s'il en existe, sinon ceux de l'OS.
Chaque thread est indépendant en terme d'exécution des autres (ils s'exécutent en parallèle – c'est à dire un pas chez l'un, puis un pas chez l'autre, puis un pas le suivant, etc – mais comme leur contexte est chargé de manière invisible par l'ordi, pour toi, tu a l'impression que chacun fait ce qu'il veut de son coté, comme si tu avais plusieurs programmes qui tournent en même temps). Après, c'est à toi de gérer leurs interactions et de t'assurer que deux threads différents ne vont pas s'empêcher mutuellement de travailler ou se corrompre (imagine 2 personnes différentes écrivant le même poème, il ne faut pas que l'un modifie la fin de la première rime en même temps que l'autre écris la rime qui correspond, ça risque de poser problème...).

Au début de ton programme, tu as intérêt à créer un thread pas couche avec la structure qui te permet de les contrôler tous. Après, il te reste à faire un "programme indépendant" pour chaque couche. (Et à bien penser à éviter les interblocages et à fermer tes threads/process quand tu termine l'exécution.)

Et pour la communication entre les couches, pourquoi pas la faire avec des variables :
La couche 1 inscrit tel valeur dans la variable V
La couche 2 lit a valeur de V, et traite l'info

C'est exactement ça. Mais utilise des structures plus complexes que les variables simples, car il faudra à un moment définir quelles sont les variables partagées et entre certaines couches elles seront symboliques (leur sens fera partie de la variable elle-même). Et fait attention à bien définir de manière visible ET respecter les ensembles de variables en fonction des couches qui ont autorité pour y écrire ou y lire.

pour les servo achete surtout pas cela mais pluto ceci::
http://www.arobose.com/shop/moteurs-servos-robot/48-servo-numerique-mg995-60g-13kg-cm.html

Vive la pub, c'est de l'arnaque, tu trouve les memes à 10€ sur e***

Salut à tous^^

miq75, je programme avec le langage d'arduino. Par contre pour l'histoire du multitreads je vois pas du tout comment faire^^

Mais utilise des structures plus complexes que les variables simples, car il faudra à un moment définir quelles sont les variables partagées et entre certaines couches elles seront symboliques

On pourrait faire aussi des petites fonctions intermédiaires, qui rassembleraient plusieurs informations vennant de différents capteurs, et qui les traiteraient pour justement en ressortir une donné symbolique ? Ca permetterait de ne pas surcharger les couches de lignes de codes.

Je vais développer le programme étape par étape sur brouillon, commencant par le plus primitif au plus complexe.

Hier j'ai terminé ma 2ème patte, j'ai donc posté une nouvelle vidéo sur le blog avec un mouvement programmé "vite fait".
J'aurai aimé votre avis concernant le montage mécanique : il traine des pattes alors que le bras est quasi élevé à fond (et si j'éleve l'avant bras, ca donne l'impression qu'il nage..) la question c'est est ce que c'est ma séquence de mouvement est mal sychronisée ou est ce que c'est l'avant bras qui est trop long ? (l'avant bras fait la meme longueur que le bras)^^

Vive la pub, c'est de l'arnaque, tu trouve les memes à 10€ sur e***

C'est sur.. si j'avait su je n'aurai pas acheté les servo à 22€..

Hello !

miq75, je programme avec le langage d'arduino. Par contre pour l'histoire du multitreads je vois pas du tout comment faire^^

[...]

On pourrait faire aussi des petites fonctions intermédiaires, qui rassembleraient plusieurs informations vennant de différents capteurs, et qui les traiteraient pour justement en ressortir une donné symbolique ? Ca permetterait de ne pas surcharger les couches de lignes de codes.

Selon moi, le mieux, c'est de développer un vrai programme avec une vrai architecture dans un langage un peu plus haut niveau (le C++ suffit) et de faire tourner tout ça avec un Linux embarqué !
Dès que tu veux commencer à faire des choses compliqués ou importantes, Arduino devient vraiment vite limité...

Exemple de carte avec linux embarqué (mais ce n'est pas la seule !)
http://beagleboard.org/


++
Black Templar

miq75, je programme avec le langage d'arduino. Par contre pour l'histoire du multitreads je vois pas du tout comment faire^^

voilà un lien pour les threads, en c (donc qui devrait à priori être accessible avec arduino qui est basé dessus ?) : http://www.siteduzero.com/tutoriel-3-3291-les-threads-et-les-mutex.html

Sinon comme le dit Black Templar, directement en c++ ce sera plus facile...

On pourrait faire aussi des petites fonctions intermédiaires, qui rassembleraient plusieurs informations vennant de différents capteurs, et qui les traiteraient pour justement en ressortir une donné symbolique ? Ca permetterait de ne pas surcharger les couches de lignes de codes.

ben, oui, c'est même à priori avec ça que tu fera la couche 1.