320 réponses à ce sujet

[transistance]

Sinon, pourquoi ne pas envisager l'utilisation d'un accéléromètre?

Tu penses donc à convertir l'accélération linéaire (en m/s² j'imagine non ?)fournie par un accéléromètre en distance (qui serait donc équivalente à la double intégration de l'accélération mesurée, si j'en crois wikipedia -> je suis une bille en math).

Par contre le problème avec cette methode c'est la précision non ? Parce qu'avec toute intégrations on cumule les erreurs... et la distance mesurée s'éloigne de plus en plus de la distance réelle. (Arrêtez moi si je dis une bêtise.)

Du coup le pourquoi dde ta question est sans doute liée à ce soucis de précision. Après c'est plus Mike118 qui détiens la réponse.

Néanmoins ce genre de système m'intéresse fortement, ça te dirais pas de tester ton idée Wmickael ? Comme ça tu pourras nous faire un retour d'expérience enrichissant

[Wmickael]

Wii c'est exact ce que tu dis que ce soit sur le fonctionnement ou sur le problème de précision (sachant qu'on n'éffectue pas une intégrale de manière formelle mais en utilisant des approximations)

J'ai déja essayé, je sais que ca marche, j'ai pas eu le temps de tester la précision (c'était un projet scolaire)

Cependant je sais aussi qu'il y a possibilité d'utiliser un filtre de Kalman pour arranger la précision (c'est d'ailleurs ce qui est utilisé pour les gps)

Sinon, pourquoi forcément devoir accéder à la position du robot?

[Mike118]

Sinon, pourquoi forcément devoir accéder à la position du robot?

Pour moi le premier soucis d'un robot mobile c'est de le faire se déplacer. Un robot qui ne bouge pas c'est pas très drôle... Si on choisis des solutions simple de type roues, ce premier soucis est généralement rapidement dépassé. Vient ensuite le second soucis : se diriger, c'est bien de se déplacer mais si on peut choisir une direction et surtout s'y tenir s'est mieux. Un des grand problème qu'on rencontre souvent du coup sur ce forum c'est ce problème de repérage... Du coup quitte à développer une base robotique intéressante autant développer une base qui a cette réponse embarquée pour le repérage.
Il y a bien quelque solutions de bases existantes possédant des codeurs intégrés mais généralement ces codeurs sont disposé sur les roues motrice et ne permettent pas de détecter le glissement de ces dernières sur le sol dans le cas de patinage.
Ainsi je cherche à développer une solution qui permet le repérage de déplacement du robot par rapport au sol sans passer par des référentiels externes...

Les solutions déjà existante que je connais étant la mise en place de deux roue codeuses folles (roues à 1 seule axe de rotation ) ou d'une roue folle ( à 2 axes de rotations ) ou bille avec 2 Codeurs... Je cherche à explorer de nouvelles voies qui pourrait être intéressante. Mécaniquement parlant, installer un composants de souris optique sous un robot n'est pas moins compliquer que d'installer des codeurs optique sur des roues folles...

Concernant les config windows j'ai enfin trouvé l'option qui permet de désactiver la prise en compte de l'accélération, maintenant me reste à trouver l'équivalent linux, et faire de nouveaux testes.

Concernant les données de la précision de ma solution à base de souris j'aimerais bien, dans les conditions correcte de fonctionnement, être de l'ordre du cm pour un déplacement d'1 mètre au moins... L'avenir dira si j'atteinds ou pas cette précision ...

Après la solution que je cherche à mettre en place n'est malheureusement pas "LA SOLUTION ULTIME" cependant dans bien des cas elle pourrait être intéressant et bien plus que suffisante !

à voir donc !

[Wmickael]

Un robot n'a pas besoin de connaître sa position pour se déplacer, connaître la position ca peut être utile si on lui dit de faire un déplacement précis (télécommandé ou préétabli)
Cela peut aussi permettre de faire l'asservissement, c'est vrai, c'est sur que si on veut que le robot aille tout droit (vu qu'il y aura au moins 2 moteurs) s'il n'y a pas d'asservissement et vu que les moteurs ne sont pas identique en tout point (même si c'est le même modèle), une déviation risque d'être observée, ça la dessus on est d'accord, après ce la dépend aussi ce qu'on veut que le robot fasse, s'il doit explorer son environnement sans forcément apprendre où se situe les obstacles ou bien suivre une ligne, est ce que c'est vraiment nécessaire que le robot connaisse sa position?

Cependant, peut être avez vous établi un cahier des charges précis? (car la je parle peut etre dans le vide)

Si tu utilises la solution que t'es en train d'exploiter, ca veut dire que le robot sera limité au parquet ou carrelage

Pour les roues codeuses, je doute que ce soit le plus fonctionnel de les mettre sur les roues folles, je pense que le mieux c'est de les mettre directemment en sortie des moteurs (d'ailleurs des moteurs sont vendus directement avec des codeurs)


Sinon, pourquoi ne pas avoir envisagé (ou éliminé) la solution accéléromètre pour accéder à la position? (surtout que ce n'est pas très compliqué à mettre en place, ni très couteux)

Après tout cela n'est que mon avis

[R1D1]

...
Il y a bien quelque solutions de bases existantes possédant des codeurs intégrés mais généralement ces codeurs sont disposé sur les roues motrice et ne permettent pas de détecter le glissement de ces dernières sur le sol dans le cas de patinage.
Ainsi je cherche à développer une solution qui permet le repérage de déplacement du robot par rapport au sol sans passer par des référentiels externes...

Comment peux-tu te recaler sans utiliser une information externe ? La proprioception est forcément soumise à des erreurs (intégration de l'accélération, glissement, ...), et sans la possibilité d'utiliser un repère fixe dans l'espace, tu vas forcément te perdre à un moment. Quant à trouver une proprioception sans dérive, je doute que ça soit possible (la solution reste donc d'avoir un bon asservissement pour réduire l'erreur au maximum).

Les solutions déjà existante que je connais étant la mise en place de deux roue codeuses folles (roues à 1 seule axe de rotation ) ou d'une roue folle ( à 2 axes de rotations ) ou bille avec 2 Codeurs... Je cherche à explorer de nouvelles voies qui pourrait être intéressante. Mécaniquement parlant, installer un composants de souris optique sous un robot n'est pas moins compliquer que d'installer des codeurs optique sur des roues folles...
...

Je suis assez d'accord, j'avais commencé à faire quelque chose comme ça avec une souris à boule en PS2.

Un robot n'a pas besoin de connaître sa position pour se déplacer, connaître la position ca peut être utile si on lui dit de faire un déplacement précis (télécommandé ou préétabli)
Cela peut aussi permettre de faire l'asservissement, c'est vrai, c'est sur que si on veut que le robot aille tout droit (vu qu'il y aura au moins 2 moteurs) s'il n'y a pas d'asservissement et vu que les moteurs ne sont pas identique en tout point (même si c'est le même modèle), une déviation risque d'être observée, ça la dessus on est d'accord, après ce la dépend aussi ce qu'on veut que le robot fasse, s'il doit explorer son environnement sans forcément apprendre où se situe les obstacles ou bien suivre une ligne, est ce que c'est vraiment nécessaire que le robot connaisse sa position?

Si le robot ne connaît pas sa position, il ne pourra être que réactif, c'est à dire changer de direction/vitesse en fonction de l'environnement (ou pas, mais ça risque de faire rapidement un robot crashé dans un mur). Le défaut, c'est que le comportement du robot n'est pas dépendant d'un but. Si on imagine un robot qui évite les obstacles en tournant toujours du côté le moins encombré, il va finir par se coincer dans un cycle en fonction de la configuration de la pièce. Si c'est marrant au début, ça perd vite de son intérêt quand on veut permettre des comportements plus complexes. Pour que le robot soit autonome, il doit pouvoir sortir de ce cycle, et donc calculer sa commande non pas uniquement en fonction de son environnement mais aussi selon les lieux qu'il veut atteindre. Et pour atteindre un lieu, il faut pouvoir le situer dans l'espace et se situer dans ce même espace. Cette localisation nécessite une représentation de l'espace, une "carte" (au sens large). On tombe sur le problème du SLAM : pour construire une carte correcte, il faut savoir où l'on est, mais pour savoir où l'on est, il faut une représentation de l'espace. Les méthodes pour résoudre ce problème sont assez connus, je vous invite à jeter un oeil au cours de David Filliat "Robotique Mobile" (CC-BY-NC-SA 2.0 FR).

Cependant, peut être avez vous établi un cahier des charges précis? (car la je parle peut etre dans le vide)
Si tu utilises la solution que t'es en train d'exploiter, ca veut dire que le robot sera limité au parquet ou carrelage

...

Sinon, pourquoi ne pas avoir envisagé (ou éliminé) la solution accéléromètre pour accéder à la position? (surtout que ce n'est pas très compliqué à mettre en place, ni très couteux)

Il y a un embryon de cahier des charges sur la Dropbox du projet (demande à Mike le lien de partage), mais qui n'a pas trop avancé depuis. Un accéléro, ça peut être marrant, mais de mémoire, c'est pas le top pour mesurer les déplacements s'il est tout seul. Un combo gyro+accéléro est plus efficace : le gyro donne l'orientation (au moins) dans le plan, l'accéléro permet de connaître l'orientation de la gravité et donc l'inclinaison du robot. Reste que déduire la position en intégrant deux fois, c'est bof (effectivement, le filtre de Kalman permet d'avoir une estimation correcte, mais je ne connais pas précisément la solution).

[Wmickael]

Si le robot ne connaît pas sa position, il ne pourra être que réactif, c'est à dire changer de direction/vitesse en fonction de l'environnement (ou pas, mais ça risque de faire rapidement un robot crashé dans un mur). Le défaut, c'est que le comportement du robot n'est pas dépendant d'un but. Si on imagine un robot qui évite les obstacles en tournant toujours du côté le moins encombré, il va finir par se coincer dans un cycle en fonction de la configuration de la pièce. Si c'est marrant au début, ça perd vite de son intérêt quand on veut permettre des comportements plus complexes. Pour que le robot soit autonome, il doit pouvoir sortir de ce cycle, et donc calculer sa commande non pas uniquement en fonction de son environnement mais aussi selon les lieux qu'il veut atteindre. Et pour atteindre un lieu, il faut pouvoir le situer dans l'espace et se situer dans ce même espace. Cette localisation nécessite une représentation de l'espace, une "carte" (au sens large). On tombe sur le problème du SLAM : pour construire une carte correcte, il faut savoir où l'on est, mais pour savoir où l'on est, il faut une représentation de l'espace. Les méthodes pour résoudre ce problème sont assez connus, je vous invite à jeter un oeil au cours de David Filliat "Robotique Mobile" (CC-BY-NC-SA 2.0 FR).

Pour ça ausi que je demande si un cahier des charges précis a été établi afin de connaître les objectifs du robot

Sinon exact, en pratique, le robot n'étant pas un point, ajouter un gyro est obligatoire (pour détecter les rotations du robot)

[Mike118]

Comment peux-tu te recaler sans utiliser une information externe ? La proprioception est forcément soumise à des erreurs (intégration de l'accélération, glissement, ...), et sans la possibilité d'utiliser un repère fixe dans l'espace, tu vas forcément te perdre à un moment. Quant à trouver une proprioception sans dérive, je doute que ça soit possible (la solution reste donc d'avoir un bon asservissement pour réduire l'erreur au maximum).

Je suis d'accord ... Le but de la proprioception est "sa simplicité " car c'est intégré au robot, pas besoin de balises supplémentaires ou autre... Par je ne me fais pas d'illusion concernant l'absence de dérivé, aussi infime soit elle, elle sera présente sans repère externe fixe. Cependant le but est d'avoir un bon système permettant comme tu le dis d'avoir un bon asservissement pour réduire l'erreur au maximum. C'est exactement ce que je cherche.

Kit à par la suite rajouter un système exterioceptif mais pas avant que le système proprioceptif soit convaincant !

Perso j'imagine bien un petit dispositif qui communique en I2C ou SPI et qui tout seul de sont côté regarde ses capteur et mesure en continu le déplacement du robot. Et dès qu'on l'interroge renvoit la position ou autre informations ... Mon but personnel étant de développer un petit module du genre. Par contre une des contraintes que je me fixe c'est que mécaniquement le système ne doit pas être difficile à mettre en place. De ce point de vue tout ce qui est combinaison gyro accéléro est très intéressant... cependant il me semble que ce type de solution dérive assez vite... Je n'est pas fais les test pour le vérifier mais quoi qu'il en soit ça va faire partie de ce que je vais tester . En aucun cas cela n'a été éliminé, cela n'a juste pas été la première voie explorée !

D'ailleurs kit à faire un robot sympathique pour ce projet, j'essayerais bien d'y intégrer des roues tout intégré Perso je vais bientôt avoir une imprimente 3D et je fais mes circuit imprimer... donc fabriquer ce type de roues me semble tout à fait réalisable !

D'ailleurs tant qu'on y est puisqu'il semblerait qu'il y ai un regain d'intérêt pour ce projet : si on faisait un tour de table pour savoir qui est toujours motivé ? Voir où on en est et redéfinir un peu le but ?

[Wmickael]

Vu le prix de la roue et le budget du robot, je ne pense pas que ce soit la meilleure solution

Au pire, si le codeur pose trop de problème à cause des glissements sans frottement et que la solution accéléromètre + gyro peut logiquement présenter une certaine dérive (du aux approximations d'intégrales cumulées), on peut utiliser en plus des codeurs la solution accéléromètre + gyro (ou meme sans gyro vu qu'on souhaite un écart de position, donc 1D) pour mesurer l'écart entre les 2 (vu que l'accéléromètre ne subit pas l'effet des glissements sans frottements), de cette manière la dérive causée par l'accéléromètre serait complètement annulée, les glissements sans frottement aussi mais cela reposerait quand même entièremment sur la précision des codeurs

[Mike118]

Vu le prix de la roue et le budget du robot, je ne pense pas que ce soit la meilleure solution />

c'est là où je suis pas complètement d'accord ! =) Certes notre budget robot est limité à 100 euros, mais si on prends 2 roues tout intégré à 25 euros, une arduino et une pile 9V rechargeable, en gros en soit ça fait déjà quelque chose

Et puis 25 euros c'est pas si mal pour, la roue, le moteur, les codeurs, la carte moteur et le support mécanique !

Après quand on regarde la roue de plus près c'est pas si difficile que ça a reproduire à condition d'avoir une imprimante 3D ...
Bref moi du côté déplacement je continuerais à creuser de ce côté là ! Mais quitte à en faire une, autant la faire un peu plus costaud Perso j'aimerais bien que notre amis skyhack passe par là et se penche sur la mécanique de cette roue car j'y ajouterais bien un roulement... mais si ça rendrait la roue un peu plus large ... à voir !

après c'est clair qu'on peu aussi trouver un peu moins cher genre ce modèle mais lui n'a pas les codeurs intégré par exemple et est plus encombrant =)

Biensure le robot étant censé être un robot collectif il faudrait que ça représente les préférences de chacun ! =) Du coup je pose la question à tout le monde : Et vous que proposeriez vous comme combo "roue, moteur, (+carte moteur si nécéssaire )" ?

[transistance]

D'ailleurs tant qu'on y est puisqu'il semblerait qu'il y ai un regain d'intérêt pour ce projet : si on faisait un tour de table pour savoir qui est toujours motivé ? Voir où on en est et redéfinir un peu le but ?

Biensure le robot étant censé être un robot collectif il faudrait que ça représente les préférences de chacun ! =) Du coup je pose la question à tout le monde : Et vous que proposeriez vous comme combo "roue, moteur, (+carte moteur si nécéssaire )" ?

Peut être qu'à ce moment là ce serait bien, même nécessaire, de refaire un cahier des charges précis. Non ?

[R1D1]

Salut,

je suis toujours motivé, mais le temps me manque de plus en plus.
Je suis d'accord pour qu'on reprenne le cahier des charges : j'avais dit à l'époque qu'on avait peut-être négligé ce point, donc je suis tout à fait d'accord pour revenir dessus. L'optique d'avoir une discussion en live là dessus (par IRC / skype) me semble une bonne chose pour avancer sur ce point. Dans la Dropbox, j'ai vu que souvent on discutait dans les fichiers : c'est pas pratique du tout. On a un beau forum disponible ici. Pourquoi ne pas démarrer un certain nombre de threads pour les différents points (et ne pas noyer ce post sous 12 trillions de messages) ? La dropbox ne devrait à mon sens ne contenir que des documents / du code / des schemas finis à un point t du projet (je ne reviendrai pas sur la promotion d'un svn/latex/wiki, commençons avec ce que l'on a />).

D'après l'état actuel du projet, on était plutôt parti sur une base roulante fonctionnelle. Peut-être peut-on dans un premier temps viser cet objectif. Les possibilités d'évolution viendront dans un deuxième temps, mais déjà, arriver à concevoir, prototyper et tester une base roulante fonctionnelle, avec tutoriels correspondants, c'est un bon point.

Pour détailler un peu :
Objectif : concevoir et documenter une Base roulante capable de se déplacer dans l'environnement de manière autonome.
Sous-objectifs :
1/ La base roulante est capable d'éviter les obstacles.
2/ La base roulante peut naviguer réactivement à ses perceptions.
3/ La base roulante peut naviguer de sa position actuelle à une position but.

1-1/ La base roulante peut percevoir les obstacles gênants pour sa navigation (question de la forme et capteurs en fonction)
1-2/ La base roulante peut manoeuvrer pour libérer sa trajectoire (actionneurs, holonomie, commande)

2-1/ La base roulante peut exhiber différents comportements en fonction de ses sensations (température, lumière, etc ...) - NB : on peut imaginer une navigation réactive aux obstacles mais qui favorise les zones éclairées.

3-1/ La base roulante peut recevoir un but/sous-but de l'utilisateur/d'une source externe (but = lieu à atteindre)
3-2/ La base roulante peut définir un but/sous-but de manière autonome
3-3/ La base roulante peut planifier une trajectoire jusqu'à un but et la suivre pour atteindre ce but.

C'est une base de réflexion, ma vision d'une base roulante qui peut faire des choses, et qui, après l'avoir construite, ne finira pas dans un placard. Même si elle ne fera même pas le travail d'un aspirateur robot. Elle reste extensible, parce que si on sait naviguer, on peut rajouter des briques fonctionnelles par dessus. Je n'ai pas plus détaillé parce que les solutions techniques viendront plus tard. Je n'ai pas non plus évoqué les contraintes (autonomie par exemple) parce qu'il faut déjà être d'accord sur ce que permet le projet. Qu'en pensez-vous ?

[transistance]

Oui, tout ça c'est très bien mais il y a une chose qui n'a pas été abordé je crois, mais qui mérite pourtant qu'on s'y attarde car il va forcément impacter le Cahier des charges :

Le plus important avec ce projet c'est quoi, le résultat ou la façon d'y parvenir ?

Dans le cas du résultat qui prime sur le reste, on se fiche du "niveau" en électronique, mécanique et informatique de chacun. On investit donc dans du module type arduino, les roues toutes intégrées présentées par mike118 etc.
-> L'avantage c'est l' assurance d'arriver au robot fini sans avoir à faire beaucoup d'efforts.

Dans l'autre cas, on doit déterminer le "niveau" de chaque membre pour faire un robot pas trop compliqué pour dégouter personne et mener le projet à bien et pas trop simple pour que la portée pédagogique du projet (parce que c'est l'intéret premier de ce cas) n'en pâtisse pas et que ce soit amusant. On investit donc dans de l' électronique et de la mécanique "classique" (composants en vrac à souder, etc.).
-> L'avantage c'est le côté pédagogique en faisant un robot de A à Z.

Evidemment, il y a une histoire de prix en paralléle qui peut compliquer l'affaire mais je suis pas persuadé qu'un des deux cas ci-dessus impose une forte différence à ce niveau.

PS: Même si je ne prendrais pas part activement à ce projet (c-a-d que je ne construirai pas le robot) le sujet m'intéresse.

[Wmickael]

Dans le cas du résultat qui prime sur le reste, on se fiche du "niveau" en électronique, mécanique et informatique de chacun. On investit donc dans du module type arduino, les roues toutes intégrées présentées par mike118 etc.
-> L'avantage c'est l' assurance d'arriver au robot fini sans avoir à faire beaucoup d'efforts.

Dans l'autre cas, on doit déterminer le "niveau" de chaque membre pour faire un robot pas trop compliqué pour dégouter personne et mener le projet à bien et pas trop simple pour que la portée pédagogique du projet (parce que c'est l'intéret premier de ce cas) n'en pâtisse pas et que ce soit amusant. On investit donc dans de l' électronique et de la mécanique "classique" (composants en vrac à souder, etc.).
-> L'avantage c'est le côté pédagogique en faisant un robot de A à Z.

Je pense que la 1ère proposition n'est pas l'objectif qui semblait être convenu (enfin je dis ca, je viens d'arriver />)
La 1ère semble plus pédagogique, plus intéressante et aussi moins couteuse (en € mais pas en temps) mais ca n'empèche pas non plus d'avoir un projet pas trop compliqué et surtout finissable

Sinon je suis d'accord avec R1D1, il faut savoir où on va, déja de manière générale, en fixant les objectifs, ca permettra aussi de mieux choisir la technologie employée

Sinon, moi je n'ai pas trop de temps, mais bon je veux bien participer

PS : j'ai oublié de dire que les roues que tu proposes mike118 me semble pas très optimisées, trop gros rapport de réduction, ce qui induit un gros couple qui me semble pas tellement utile ici surtout que ca m'étonnerait que le robot pèse très lourd (et bon imposer une grosse tension pour aller à 38cm/s grand max je trouve ca moyen)

[Mike118]

Je suis d'accord pour qu'on reprenne le cahier des charges : j'avais dit à l'époque qu'on avait peut-être négligé ce point, donc je suis tout à fait d'accord pour revenir dessus. L'optique d'avoir une discussion en live là dessus (par IRC / skype) me semble une bonne chose pour avancer sur ce point. Dans la Dropbox, j'ai vu que souvent on discutait dans les fichiers : c'est pas pratique du tout. On a un beau forum disponible ici. Pourquoi ne pas démarrer un certain nombre de threads pour les différents points (et ne pas noyer ce post sous 12 trillions de messages) ? La dropbox ne devrait à mon sens ne contenir que des documents / du code / des schemas finis à un point t du projet (je ne reviendrai pas sur la promotion d'un svn/latex/wiki, commençons avec ce que l'on a />/>).

Parfaitement d'accord... Il faut d'un côté mettre en place les treads sur les différents points... Ne mettre dans la drop box que des doc / codes schémas etc... et des fichiers types READ ME .

Idem je suis d'accord pour une communication un peu plus direct... Comment ? Quoi ? j'ai pas la réponse et je ne sais pas quoi proposer. Je suis ouvert à toute proposition.

D'après l'état actuel du projet, on était plutôt parti sur une base roulante fonctionnelle. Peut-être peut-on dans un premier temps viser cet objectif. Les possibilités d'évolution viendront dans un deuxième temps, mais déjà, arriver à concevoir, prototyper et tester une base roulante fonctionnelle, avec tutoriels correspondants, c'est un bon point.

Pour détailler un peu :
Objectif : concevoir et documenter une Base roulante capable de se déplacer dans l'environnement de manière autonome.
Sous-objectifs :
1/ La base roulante est capable d'éviter les obstacles.
2/ La base roulante peut naviguer réactivement à ses perceptions.
3/ La base roulante peut naviguer de sa position actuelle à une position but.

1-1/ La base roulante peut percevoir les obstacles gênants pour sa navigation (question de la forme et capteurs en fonction)
1-2/ La base roulante peut manoeuvrer pour libérer sa trajectoire (actionneurs, holonomie, commande)

2-1/ La base roulante peut exhiber différents comportements en fonction de ses sensations (température, lumière, etc ...) - NB : on peut imaginer une navigation réactive aux obstacles mais qui favorise les zones éclairées.

3-1/ La base roulante peut recevoir un but/sous-but de l'utilisateur/d'une source externe (but = lieu à atteindre)
3-2/ La base roulante peut définir un but/sous-but de manière autonome
3-3/ La base roulante peut planifier une trajectoire jusqu'à un but et la suivre pour atteindre ce but.

C'est une base de réflexion, ma vision d'une base roulante qui peut faire des choses, et qui, après l'avoir construite, ne finira pas dans un placard. Même si elle ne fera même pas le travail d'un aspirateur robot. Elle reste extensible, parce que si on sait naviguer, on peut rajouter des briques fonctionnelles par dessus. Je n'ai pas plus détaillé parce que les solutions techniques viendront plus tard. Je n'ai pas non plus évoqué les contraintes (autonomie par exemple) parce qu'il faut déjà être d'accord sur ce que permet le projet. Qu'en pensez-vous ?

Moi ça me va. Après il reste à définir un peu plus les "buts". Histoire de savoir un peu ce qu'on s'impose niveau capteur ...
Au final je suis très ouvert sur les contraintes fixés ce qui m'importe le plus c'est que le maximum de personnes soit d'accord sur ces contraintes ... Car ce qui m'intéresse le plus dans ce robot c'est le côté collectif... le côté moins de 100 euros étant pour intégrer le maximum de personnes ...

Oui, tout ça c'est très bien mais il y a une chose qui n'a pas été abordé je crois, mais qui mérite pourtant qu'on s'y attarde car il va forcément impacter le Cahier des charges :

Le plus important avec ce projet c'est quoi, le résultat ou la façon d'y parvenir ?

Dans le cas du résultat qui prime sur le reste, on se fiche du "niveau" en électronique, mécanique et informatique de chacun. On investit donc dans du module type arduino, les roues toutes intégrées présentées par mike118 etc.
-> L'avantage c'est l' assurance d'arriver au robot fini sans avoir à faire beaucoup d'efforts.

Dans l'autre cas, on doit déterminer le "niveau" de chaque membre pour faire un robot pas trop compliqué pour dégouter personne et mener le projet à bien et pas trop simple pour que la portée pédagogique du projet (parce que c'est l'intéret premier de ce cas) n'en pâtisse pas et que ce soit amusant. On investit donc dans de l' électronique et de la mécanique "classique" (composants en vrac à souder, etc.).
-> L'avantage c'est le côté pédagogique en faisant un robot de A à Z.

Evidemment, il y a une histoire de prix en paralléle qui peut compliquer l'affaire mais je suis pas persuadé qu'un des deux cas ci-dessus impose une forte différence à ce niveau.

PS: Même si je ne prendrais pas part activement à ce projet (c-a-d que je ne construirai pas le robot) le sujet m'intéresse.

Il est important de se mettre d'accord sur ce point aussi ... là encore pour moi comme ce qui m'intéresse c'est d'intégrer le plus de personnes dans un même projet je suivrais la majorité. Cependant pour moi le deuxième point étant le plus intéressant !

PS : j'ai oublié de dire que les roues que tu proposes mike118 me semble pas très optimisées, trop gros rapport de réduction, ce qui induit un gros couple qui me semble pas tellement utile ici surtout que ca m'étonnerait que le robot pèse très lourd (et bon imposer une grosse tension pour aller à 38cm/s grand max je trouve ca moyen)

Je n'ai pas forcément dit : "Il faut ces roues ! " Mais ce concept me plait beaucoup et la réalisation qui a été faite pour ces roues et simple et assez facilement recopiable ! ( d'ailleurs faudrait se renseigner côté license ! x) )

[Wmickael]

Parfaitement d'accord... Il faut d'un côté mettre en place les treads sur les différents points... Ne mettre dans la drop box que des doc / codes schémas etc... et des fichiers types READ ME .

Idem je suis d'accord pour une communication un peu plus direct... Comment ? Quoi ? j'ai pas la réponse et je ne sais pas quoi proposer. Je suis ouvert à toute proposition.

Skype, forum pour ce projet + chat rattaché à ce forum, ca fait déjà 2possibilités

[Mike118]

Bon je continu les tests avec le capteur de souris optique, Je met en pièce jointe une image du proto.
Les tests sont assez encourageant en plus cela peut en même temps faire détecteur de ligne. Reste à tester les différentes surfaces ... Seul problème: il faut que ça frotte le sol...
La version en bois du support qui touchait le sol était pas top car ça accroche pas mal ... Une nouvelle version est faite en imprimente 3D et là ça glisse beaucoup mieux.

De même j'ai réalisé une petite carte d'alimentation pour un autre projet : dimension 40mm*60mm*12mm qui pourrais convenir pour le projet ...

Ces deux cartes sont actuellement utilisées sur un robot à 4 roues omnidirectionnelles entrainées par 4 moteurs pas à pas.

Il y a toujours des personnes motivées pour le projet ? Le but étant de faire un robot qui intéresse tout le monde...
Si il y a des gens qui sont encore motivés qu'ils se manifestent et dans ce cas je vais ouvrir différents sujets concernant, mécanique, électronique, programmation etc...
de manière à dynamiser un peu l'ensemble.

J'espère lire des réponses bientôt.

Bonne journée à tous !

[Melmet]

Bien sur que je suis toujours là, malgré que je n'ai pas de temps en ce moment mais je suis le projet.
J'attendais un peu de voir ce que tu as fait .

Moi j'aurais du temps cet été pour essayer de faire le mien.
Je bosse sur la partie électronique là, la partie méca c'est pas un problème.

Tu postes toujours sur la dropbox?

[R1D1]

Pas beaucoup de temps dispo en général non plus.

Cela dit, j'ai un peu travaillé avec la RaspBerry Pi,rien de merveilleux (juste récupérer l'image de la caméra Pi dans simpleCV, et utiliser le GPIO). Ça pourra toujours servir si je fais quelque chose d'un peu plus évolué.
J'ai l'impression qu'on a pas fait la phase "reprise du cahier des charges". Peut-être que ça vaudrait le coup de se fixer un objectif là-dessus, du genre "avoir fait un brainstorming pour telle date", puis synthétiser le tout pour une autre date, etc ...

[Mike118]

J'attendais un peu de voir ce que tu as fait .

En fait je ne développe actuellement rien de dédié uniquement au robot des robot maker par contre ce que je fais dans le cadre de mes autre projets (Carte d'alimentation, carte de commande etc... ) peut en partie être réutilisé
J'ai actuellement 5 robots en cours x) dont l'un où je ne suis que superviseur, 2 ou je suis seul maitre à bord, un en binôme et 1 en équipe de 4 ! x) Et je ne compte pas le robot des robot maker qui n'est pas encore assez concret. 3 des 5 robots énoncé seront fini dans moins de 2 mois et demi ^^ dead line oblige En gros ce qui est servo moteur, moteur à courant continu, moteur bioloid ax12, moteur pas à pas, capteur sharp ou US en ce moment j'en mange à toute les sauces ! ^^

Pour en revenir à notre projet :En fait quand je l'ai crée je m'attendais plus à ce que des personnes "expertes ou non " donne leur point de vue genre faire des vue d'artiste du robot, donne des idée etc... et que des personnes un peu experte, ou qui veulent apprendre ( donc dans ce cas là genre en binome avec une personne un peu plus experte ), réalisions les différentes parties au fur et à mesure. Le but étant de relever ce défi qui est de correspondre à un "souhait " collectif. Hors moi là tout seul je dois dire que le souhait collectif je ne le vois pas beaucoup ^^ Car je pense que je n'ai pas forcément les même besoins que tout un chacun =)

En tout cas j'ai posté sur la drop box la datasheet du capteur de souris que j'utilise sur l'un des robots.

Ensuite je pense que R1D1 à raison sur le fait qu'il faut essayer de mettre en place un calendrier. Du coup moi ce que je propose c'est que dans la semaine là, je vais ouvrir un nouveau sujet, car celui ci commence un peu à être blindé ... et je vais contacter chacune des personnes qui a montré de l'intérêt au projet de manière à essayer de remotiver du monde.

Par contre mettons nous d'accord ici sur qu'est ce qu'on met dans cette nouvelle discussion, où on la met et à long terme quels sont les élement qu'elle contiendra dans l'optique où on ne dois plus ouvrir un sujet four tout mais qu'on va ouvrir un sujet à chaque fois genre en mécanique en électronique cahier des charges etc ...
Pour l'instant ce que je propose c'est que cette première nouvelle discussion que j'ouvre soit " la boite " à idée qui permet de faire le brain storming , et qu'ensuite on réouvrira une discussion cahier des charges puis on ouvrira les différentes rubrique qui en découleront. Qu'en pensez vous ?

[R1D1]

Pour en revenir à notre projet :En fait quand je l'ai crée je m'attendais plus à ce que des personnes "expertes ou non " donne leur point de vue genre faire des vue d'artiste du robot, donne des idée etc... et que des personnes un peu experte, ou qui veulent apprendre ( donc dans ce cas là genre en binome avec une personne un peu plus experte ), réalisions les différentes parties au fur et à mesure. Le but étant de relever ce défi qui est de correspondre à un "souhait " collectif. Hors moi là tout seul je dois dire que le souhait collectif je ne le vois pas beaucoup ^^ Car je pense que je n'ai pas forcément les même besoins que tout un chacun =)

Je pense que la première partie viendra avec le brainstorming (il faut juste que suffisamment de gens participent). Une fois les idées un peu plus claires, on pourra avoir un travail un peu plus technique, et organiser des groupes de travail.

Ensuite je pense que R1D1 à raison sur le fait qu'il faut essayer de mettre en place un calendrier. Du coup moi ce que je propose c'est que dans la semaine là, je vais ouvrir un nouveau sujet, car celui ci commence un peu à être blindé ... et je vais contacter chacune des personnes qui a montré de l'intérêt au projet de manière à essayer de remotiver du monde.

Par contre mettons nous d'accord ici sur qu'est ce qu'on met dans cette nouvelle discussion, où on la met et à long terme quels sont les élement qu'elle contiendra dans l'optique où on ne dois plus ouvrir un sujet four tout mais qu'on va ouvrir un sujet à chaque fois genre en mécanique en électronique cahier des charges etc ...
Pour l'instant ce que je propose c'est que cette première nouvelle discussion que j'ouvre soit " la boite " à idée qui permet de faire le brain storming , et qu'ensuite on réouvrira une discussion cahier des charges puis on ouvrira les différentes rubrique qui en découleront. Qu'en pensez vous ?

Pour moi, le premier topic doit poser une question du genre : "Quel genre de robot (simple) voulez-vous construire ?", pour que chacun donne sa vision, ses envies, quelques spécificités, pourquoi pas une première modélisation ou esquisse (peut-être faire un "mini-questionnaire" pour faire ressortir des points importants : capteurs / actionneurs / autonome (ou pas), etc ... avec des catégories plutôt fermées pour des réponses précises et d'autres plutôt ouvertes pour que chacun puisse s'exprimer). Sur ce topic, on ne juge pas les idées, même si ça nous démange (même si on sait très bien que c'est trop cher/c'est pas faisable à un niveau amateur/etc ...). C'est important de pouvoir présenter son idée sans "crainte" de la critique (qui elle viendra plus tard, quand on aura plein d'idées à exploiter). Tu peux donner une date limite, histoire de dynamiser un peu le tout.

Qu'en pensez-vous ?